Here's an idea that popped into my head last night: What if you had a framework that allows you to write a game in Python as if it were a local game, only it runs in your browser?

To make it simpler, let us assume this game is turn-based and features few if any graphics.

That might seem a big restriction, but think about Candybox and A Dark Room and Fallen London and Kingdom of Loathing. Fun games can be built within these constraints.

A framework like this would be ideal for prototyping turn-based online games (and guess what kind of game I am working on right now?). It might also be ideal as a way for people to get into game programming.

The framework

For the simplest version let us further restrict ourselves to single-player games with no time-based aspects at all. So time advances because the player performs an action. This allows us to avoid doing real-time, in the web technology sense of the world, which is a bit tricky. The server can always just wait for the player and never needs to push anything to the browser. This is a big restriction but it makes for a good base that can be built on later.

So then all we would need is to design an API that resembles how you would write a game "as if it were a local game" and translate that into web technology. The two big things that API would need to handle are graphical user interfaces (GUIs) and game data.

GUIs

For GUIs, one part is a simple system to handle screens, UI elements (buttons etc.), and layouting. The system generates HTML behind the screens and sends that to the browser, a bit like a GUI API generates graphics and sends that to the user's screen. More complex UI elements (e.g. tooltips) will require some Javascript but I'd say that's more work but not a major impediment.

The other part is mapping URL-based event handling to the button-based event handling you'd expect from an offline game API. You register or otherwise create a button, passing the function that should be called when this button is clicked (much easier than event binding IMO). The system generates a URL for this button, or however it wants to handle it, and takes care of the rest.

The classical game loop then becomes a very simple function the user writes which gets called when the next turn starts. Of course the next turn starts because the user told the system this has to happen. The player sees an 'End of Turn' button, clicks on it, the button handler calls a 'next turn' function, which then causes the 'game loop' to be called. Perhaps that appears cumbersome but it sets things up nicely for the next step which is to allow the server to push to the client.

To do that, you need some additional technology, namely realtime or push. ("Realtime" is confusing in this context because we're still talking about turn-based games, but it makes sense in a web context.)

Armin Ronacher, the creator of Flask, my Python web framework of choice, writes about that here. I've not done a lot of stuff with realtime web technology and I've certainly not thought through how to use it in the context of this game system, but right now my gut tells me it's doable somehow.

Data

Handling data is interesting because of the amusing fact that on the web, the computer forgets everything after you talk to it. There are really good reasons for this, but it can be a bit challenging if you move to web development from other programming areas.

Anyway, I'd try to make it so that data automatically gets saved after each web request. A little layer on top of a typical ORM should do the trick: Basically, commit a transaction at the end of each request. Perhaps I am being naive.

Player and game session management could be built into the system.

Summary

What would be the advantages of such a system? People can use Python to write games. Python is my favorite programming language, so it's a big plus for me. But Python is also pretty easy to learn, which is a plus.

It's not so hard to imagine a system allowing people to instantly distribute these games on the internet.

The API would be simple - simpler than Unity3D because the games are more restricted, which is a good thing in my opinion. Also simpler than doing this with, ahahaha, 'bare metal' web technology. (I started this blog post with a rant about using Ruby on Rails to learn programming, but it grew too big.)

To sum up: this hypothetical system would make game programming easy to learn and to distribute, for a restricted but interesting set of possible games.

So what do you think? Stupid? Interesting? Boring? Already done? Way harder than I imagine?

Update: I should add that any HTML-based game has to kinda do what I am describing here, and conceivably although not necessarily, they've built systems that resemble non-web-game APIs. But I don't know of any such framework that is available for others to make games with.