next »

[Ryan]

I have been reading up on Naughty Dog's GOAL language, and it seems like a very neat concept. Basically, it allowed them to make modifications to their game code without having to recompile or restart the game itself.

I've also been looking at Unity, specifically their iPhone demo located here. Again, the game was modified without ever restarting the application.

I'd like to hack together a demo similar to these ideas, and try and get it fast enough to be a viable development method. As for the scripting I'll either embed Lua or the language I've been designing, but my primary question deals with the actual updating of scripts itself.

Ideally, it would be nice to just have the ability to have the application "know" that a certain script has been modified, so I just have to load up my script files into TextMate, make changes, and see these changes appear in the game window once I save. Does anyone know a nice way of doing this? Or will I have to resort to having some type of console that I can call up in-game and say something like

Code:

(reload 'player-movement.script')

I would appreciate any brainstorms, ideas, questions, or comments you have. Thank you.

[AaronAardvark]

I've been considering doing this with my initialization scripts.

It should be a simple matter of checking the modification timestamp on the file, and re-init if it's newer than what's on record.  For instance, I have several modules that can be passed the name of an initialization file when they are newed.  I already store this file name as a class attribute, so I'd simply create a similar last_modified attribute, then add a method call like scan_script in the update method.  The method scan_script will use some os-level wrapper libraries to check the modification date of the init script, then re-initialize the class if the date is updated.

Here's something else to consider: at the last company I worked for, we'd package related assets into groups, then load those packages into the game instead of individual assets.  To allow for quick testing of assets, the engine would search for 'loose files' first, and failing that, default to loading the asset packages.

[Robotacon]

You could just check when the script files are last updated in a loop with a couple of seconds delay so that it doesn't screw with the games performance.

I do that for the graphics in my game engine so that I can edit the sprites and tiles and even map data while the game in running.

[Ivan]

Yeah, there's no black magic to it. If you have a resource system (which you should), it should be a feature of the resource system to reload modified resource assets.

[Ryan]

Woah, you guys are fast! From reading through everyone's posts, it seems that I was making live editing out to be harder/less common than it really is?

The time stamp idea is really good, RazputinOleander. Seems like this will get me what I need. Thanks!

You could just check when the script files are last updated in a loop with a couple of seconds delay so that it doesn't screw with the games performance.

Could you explain this further, what you mean by adding a delay? Are you talking about loading all the updated resources in the background and switching them all out at once when everything is loaded?

Yeah, there's no black magic to it. If you have a resource system (which you should), it should be a feature of the resource system to reload modified resource assets.

Do you know of any open source games that use resource systems or articles explaining a good way to organize things? I've always handled resources manually.

[Robotacon]

Could you explain this further, what you mean by adding a delay? Are you talking about loading all the updated resources in the background and switching them all out at once when everything is loaded?

I was trying to say that you shouldn't access the file system in your regular game loop but instead use a separate thread/loop with a greater delay to avoid performance issues. I think I've got a five second delay but you could probably do much better with some multi-thread magic.

Having that said I'd first listen to what tostie has to say because I trust him more than I trust my own advice. I don't know what the duties of a resource system usually are but it sounds interesting.

[Ivan]

A resource system is usually something like a central manager, akin to a factory pattern, which loads and caches all the resources you use in the game, which you then request through it, through a singleton or however, instead of manually loading it.

A basic resource system would involve parsing a folder at startup, loading all the assets and creating ready-to use classes from them, which you can then request from the resource system by the whatever identifier you choose to use for them (usually their paths relative to their parent resource folder). Since most assets, like materials and sounds, can be used from a single instance, all you do is return the pointer to it from the resource system.

In that vein, the resource system would keep the absolute paths of each file, so that each resource can be reloaded (It's a good idea for many reasons anyway, for example, if you change certain video settings, you have to reload all of your textures. If your resource system keeps track of all the paths, all you have to do is tell it to reload material resources, instead of manually reloading them).

A more complex resource system could use zip files or custom pak files and could group your assets by the place they're loaded from. So that you can say, loadResourceFilePack("menu.pak") or wahtever, and it will load all the menu graphics, which you can unload when you dont need them all at once.

If you want to see a good example of a resource system, take a look at the OGRE3D source.

[Ryan]

Excellent description, Ivan, it now makes perfect sense to me. I remember you mentioning the Ogre 3D source code before, back when you had a previous iteration of RGS written in C++, I'm downloading the source zip now, I'll take a look.

Robotacon, thanks for the further clarification. I'm not sure if I am ready to work with threads in C++, but perhaps having an in-engine toggle to check for updated resources would be a nice thing to have.

[rogerlevy]

Yet another technique is to embed editing programs into the game engine. That way you are doing the reverse; saving files from "in the game" instead of checking/loading them. But you should do it in a way that allows these to not be included in the final product. Good modularity exercise, there. 

[mcc]

If you are developing on the macintosh and your program is in C++, you can do this using the "fix and continue" feature of XCode. I do not know if Visual Studio offers an analogous feature.

[Zaknafein]

I do not know if Visual Studio offers an analogous feature.

It does in C#/VB.Net, dunno about C++. But "Edit And Continue" as MS calls it becoming more and more tricky, because a lot of code modifications cannot be injected at runtime. For example any method containing an anonymous delegate/lambda expression/LINQ query cannot be edit-and-continue'd... it sucks.

[Impossible]

C++ has edit and continue, and has had it for a while. Given the nature of C++ it rarely works except in the simplest of cases (like changing hardcoded values.)