This falls into the Blue Sky Thoughts category, but I’m wondering how hard it would be to turn a Codea project into a game that can execute neatly from a web page. The individual pieces of such a task don’t seem by any means impossible, what with the Lua bits and frameworks that are already out there. The real challenge would be to make it clean and straightforward, to build a site where you could copy in a Codea project and execute it without having to meddle with anything in the hosting environment.
I’m envisioning a site where you could log in, upload your code (even if through copy / paste) and invite people to play. Naturally, browsers don’t support all the interactivity of a portable device. There would be issues with translating between touches and mouse actions, and games dependent of gravity or acceleration sensors would be out of luck. But really, a lot of games would translate well enough (see Birds, Angry).
I have to admit that what drove me to think about this was primarily the Ludum Dare. The next Dare comes up in April, and it looks as if there’s nothing that would prevent anyone from submitting a Codea project. However, the way Dares are judged rewards games that are tested by a larger number of judges, giving web-based games a big edge. But even aside from the Dare, this seems like a keen idea.
Codea is based conceptually on Processing - which is pretty much what you describe. It’s a different language, but the architectural models (a draw() loop) are the same, so porting should be fairly easy.
@Dylan has been really interested in getting a WebGL version of Codea running, something that uses a Javascript based Lua interpreter. It’s probably too large a project for just us, though. Hopefully when we release the engine code people might find it possible to port.
Mark, Processing.js would be a great environment to do a web game in, if you can get past using JS (yuk)
Zoyt is right that it will be incredibly slow on iPad.
I experiment around with Studio Sketchpad sometimes. It is a Processing.js environment with an interactive / collaborative code editor. Here’s an example.
(After clicking on the play button on the canvas area, click and drag within the circles to set their speed and direction, then sit back and watch for a while. Click and drag to interact some more.)
Runs great on a Mac or PC with Safari / Chrome / Firefox. Not so great on iPad.
I imagine including Processing.js in a custom repl.it installation is the first step in hacking around with extending repl.it to support a Codea-like environment.
If I was going to implement a web-based Codea, I wouldn’t do it in a script environment. I’d put most of the functionality server side, and send nothing to the client but the necessary elements to display graphics and handle interactions.
@Simeon Also, their search field in the documentation looks nice. I realise this’d be a little tricky with the current HTML-based documentation, though.
Reading the documentation, this looks like a Processing.js just for the iPad in that if you take full advantage of everything it includes then your programs might not work on other systems with the “standard” processing.js.
I think I’ll stick with Codea for the time being. But I like the idea of “web codea” and would be very interested in seeing it.