RAD loop?

CrazyPyro on 2012/05/15 04:17

Did anyone use any techniques (in Idle or whatever) to hack on parts of their game *while* it was running to get instant feedback?   Or did everyone do more of a classic "edit, run, test, stop, repeat" loop?

(log in to comment)

Comments

richard on 2012/05/15 05:35:

I've never had a REPL in a game. I have been know to have unit tests though :-)

tartley on 2012/05/16 07:01:

The idea of reloading modules on-the-fly has always interested me, but I've never pursued it. The ability to do so is one of the things that Steve Yegge included in a list of "essential features for a truly great program or programming environment" - but I can't find which of his essays I'm thinking of right now.

I'm assuming that if the module in question contains no state (i.e. no mutable variables) then reloading the module is trivial, just use the 'reload' command (whether you do so from a REPL, or from some other means within the program.) I think that would work, but I haven't actually tried it.

But if your module contains mutable state (e.g. class definitions with instance variables) then I don't think a simple 'reload' can suffice. What should one do about all the objects of the redefined class that currently exist? If you've just changed the logic within methods, then that's fine, but if you've changed the name or definition of  the data members then presumably the old instances won't work with the new code. You'd have to find some way to re-create each instance, presumably by calling the new class constructor once for each existing instance. That sounds fiddly and error prone to achieve in the general case, and even if you did it, you'd be resetting so much state that perhaps it would be no better than restarting the program again.

So I'm interested in the idea but puzzled as to how useful it could actually be.

Mat on 2012/05/16 08:50:

I've been interested in this ever since I watched this video http://vimeo.com/36579366

There is a livecoding module (http://code.google.com/p/livecoding/) that does this by overriding the import mechanisms in python, but yeah, the tricky part is working out how to persist state between reloads.

It would be fiddly, but in theory you could create some framework for storing some of the state at a given time, and reverting to that after you have reloaded all your modules. Ideally you'd also store input so you can replay your last few seconds while tweaking the level, physics or graphics, like in the video.

Something I will probably try out before the next pyweek is a debug interface that would let you manipulate constants from the game, and maybe an in game console. It's really tedious to have to keep restarting your game just to get something like jumping right.

cyhawk on 2012/05/16 14:53:

In Lab Lab Bunny Lab I reload code snippets that generate the creatures every time they are written to. This was really useful for quickly tweaking the stock creatures.

Ernie on 2012/05/16 17:34:

That would be nice although it should be tricky to handle the state between different reloads. One could separate the state from the game logic and only reload the module with the game logic. Then the state could be persistent between the reloads. But replaying, pausing and tracing the future of an object like Bret Victor in that talk also did is a LOT trickier. You need special input handlers that record the inputs and also record game state over time. It should be very difficult (not impossible :) to get a general solution for this.
I recently red about the programming language Circa which is extra designed for livecoding. There state is handled specially and can be kept persistent although it isn't separated from the rest of the code.

bjorn on 2012/05/25 20:08:

(almost) all of my state was essentially in one collection of objects, which, by pickling and unpickling that collection, how I created, saved and re-load levels.  I'd just essentially play the game, adding different pieces and when I had something i was happy with, press a key to save that off.  tweak some more, and I didn't like where it went I'd press another key to reload my last saved level.

Pickle does claim to enable saving data and then loading into a newer version of an object, so if, as you say reloading a module that is stateless is trivial, then if you designed your game such that it pickles all the state, reloads the module, and then unpickles the state into the new objects, you'd probably have the basics in place to iterate w/o restarting your game each time.

At the very least, it should be doable to have the code that creates the window etc separate and throw out/reload the rest of your game such that you don't have to pay that startup cost, and do it automatically on saving a source file so you don't have to pay the tax of manually starting your game.  Could make the iteration loop pretty tight.