next »

[or]

-

[ProgramGamer]

I don't think it would be very practical to make fully featured games with this sort of setup, but you might have more luck in making a niche fantasy console ala PICO-8. Not interrupting the game loop while still adding features sounds really neat though.

iirc, Java is capable of doing something like that.

[InfiniteStateMachine]

I worked on a AAA open world game who's engine did that. You just launched a non RTM version of the game, ran somewhere and opened up the editor, got to work and moved on. Had really cool auto-source control integration too IIRC. It was pretty cool. One of the main guys behind it I consider a mentor. Much much smarter than I will ever be I suspect.

EDIT : Doesn't the Skookum script addon for the Unreal engine do this?

http://skookumscript.com/unreal/

[DireLogomachist]

The guys behind Hyper Light Drifter built an editor into their game. As they were using GameMaker and it didn't have the tools they needed, they just started building a game editor into the game itself. So in realtime they can edit levels, draw new sprites, etc. Basically they moved almost all their dev process into the game itself.

https://www.gdcvault.com/play/1024062/-Hyper-Light-Drifter-Secrets
The bit about their editor starts at around 17:40. Pretty cool stuff.

[InfiniteStateMachine]

I worked on a AAA open world game who's engine did that. You just launched a non RTM version of the game, ran somewhere and opened up the editor, got to work and moved on.

That sounds awesome! That reminds me a bit of Second Life, where you could enter scripts in the game itself too if i remember correctly...

EDIT : Doesn't the Skookum script addon for the Unreal engine do this?
http://skookumscript.com/unreal/

I'll have a look into this one, thanks.

SkookumScript has key game concepts such as concurrency built in at the language level. (...) the integrated SkookumScript code can be live-updated and modified while the game is running. Blueprints and Blueprint variables are automatically exposed to SkookumScript as classes and data members, where they can readily used. The C++ API makes it easy to call from SkookumScript into C++ or vice versa.

Woo, that sounds great! Too bad that Unreal Engine 4 is such a huge beast... It would be so great to have something like that in a more lightweight tool...

The guys behind Hyper Light Drifter built an editor into their game. As they were using GameMaker and it didn't have the tools they needed, they just started building a game editor into the game itself. So in realtime they can edit levels, draw new sprites, etc. Basically they moved almost all their dev process into the game itself.

https://www.gdcvault.com/play/1024062/-Hyper-Light-Drifter-Secrets
The bit about their editor starts at around 17:40. Pretty cool stuff.

Thanks, just watched it, and it looks like a huge amount of work they put into the game and their own tool, very impressive!
Looks like very much tailored to their needs, but could be done in a more general style too I think. Level design + behavior scripting + linking objects. - Many games have built-in editors that lets the user edit some of the mechanics/levels... The behavior is often fixed, i.e. the scripts don't change, and the editor can be used to configure and tweak the behavior of the entities?


---
It might be worth it to look at basic OS design...

Operating systems already do it: multi-tasking. It should be possible to use preemptive or cooperative scheduling to run/stop scripts, and use some sort of inter-process signaling or some sort of virtual files pipes, shared memory etc. to make the scripts work together, without interrupting the whole engine when something breaks...

Or the concept of interrupts in microcontrollers. Simple programs that have some I/O channels, and listen to events/interrupts from in or outside... but run independently. A "software emulation" of that... in a multi-threaded program? Or by forking different sub processes... Or a basic event based system, publish–subscribe? It gets complicated very fast... hmmm...

Probably it is a good idea to look around a bit more before trying to do something like that...

Do you know any other tools that do something along those lines? Or keywords that could be used to do some searching?


I'm gonna look into those famous REPLs for JavaScript, Python, Lua interpreters eventually, and how they let the user spawn processes "in the background", and how they manage those tasks...


Something interesting found right before:
http://lua-users.org/wiki/CoroutinesTutorial

So skookum script wasn't built for the unreal engine. It's actually the same scripting language we used for Sleeping dogs (and other UFG games). I think the main deal is they got a grant from Epic so Unreal has been their focus lately.

Looks like they offer a non-engine bound version too.

http://skookumscript.com/download/

As for your OS comparison. That sounds about right. I guess the hard part is making it granular enough so that when you modify a script it only changes what is affected rather than doing something like resetting the scene. I imagine that gets pretty tricky. It would be interesting to see how developers get around that kind of stuff.

[McHorse]

iirc, Java is capable of doing something like that.

Oh yes? Java is huge, and I know just a tiny bit of all the language features... Do you know any keywords that might help searching?

-> edit: I think I found it again: is that feature called reflection (?)
http://tutorials.jenkov.com/java-reflection/classes.html

It's called hot swapping. In Eclipse, for example (not sure about other IDEs), you just run the game in debug mode, and any code can be reloaded to the running JVM. It works only with code inside of methods, tho (but AFAIK, there are libraries/software to allow creating new/modifying classes, method signature and fields also).

At the moment, I use it with LWJGL3, and it works quite good (I make a 2D platformer game from scratch). Unfortunately, I'm not sure if other resources like levels or any resource files can be reloaded (at least, you'll need some trigger of your code which is responsible for loading the data).

[InfiniteStateMachine]

Totally forgot about JRebel. That's pretty much exactly what you are looking for I think.

I think Princessa has something like this going for C++.

[JWki]

visual studio has edit and continue but it only works well for c# and isn't really nice with C++. There's ways to implement it for C and C++ ranging from relatively trivial to implement to fucking nightmarish depending on how C++y your code is.

[deWiTTERS]

This is exactly what I'm doing with http://rpgplayground.com. I'm currently focusing on RPG's, but in the far future I want to extend this to other genres.

Basically you play your game, and you can open a "project pane" that allows you to change it. At first I kept the game running while changing the game, but this is really not a good idea. So now I pause the game, you make your changes, and then can continue playing.

There are a few difficulties though. The tool needs to make a clear distinction between changing properties at startup, and properties at runtime. Because this might confuse the player.

So yeah, I'm working on it, so remark that it's definitely not completed yet!

Some of my users are already making some nice games with it, such as http://rpgplayground.com/a-lill-girls-tale/

[InfiniteStateMachine]

very cool!

[bateleur]

Presumably working with this kind of always-on environment places very strict limitations on your code?

Thinking about games I've worked on, there's usually a substantial warm-up phase at the start in which all sorts of data structures are initialised and files loaded in from storage etc. If a hot swapped script changed anything, all the live data would somehow need to be ported over to the new version of each changed script. Reloading from storage wouldn't be an option, because that's not really a hot swap (and the data might have changed). But in general moving the data across isn't just a copy, because the old data might not be in the right format for the new script.

[Polly]

Presumably working with this kind of always-on environment places very strict limitations on your code?

No. In for example ZGameEditor you can literally add / modify / remove anything in your project while it's running.

[Polly]

does it use a game tree that can be changed at run time?

This got added recently .. however, it's only available in the IDE ( at the moment ). When building a standalone executable your project is compiled, at which point you can't change your scripts anymore nor search for components by name ( standalone doesn't contain any identifier strings ) etc.

[McHorse]

Sounds so useful, didn't know that term and only heard that the current VisualStudio can also do something similar with C# and C/C++ code (edit and continue in the debugger), but I haven't tried it out recently. I just remember that it never really worked properly i think in older versions of MSVC.

Yeah, I also heard that you can do similar in C#, but not sure about C/C++...

Nice, so you can really stop the game anytime and change things in any existing method or variable?

Not necessarily to stop, I can modify the game's method code just by going back to Eclipse, modifying any method code and then saving source code. Look at this

for more details.

Are you using this hot swapping with plain Eclipse project or with a plugin, like this JRebel one (just found by searching...)?

To be honest, I'm not sure, I think it comes by default in any recent builds of Eclipse for Java developers (or default bundle, IDK exactly).

Overall, it's a pretty decent feature, but IMO it shouldn't be used for everything. For stuff such as OpenGL resources, this is a no no, since it may cause memory leaks (due to uncleared data on GPU).

[McHorse]

Ok, now i need try this in Eclipse... sounds great that all this is already built in. Thanks for pointing it out...

You're welcome!

By the way, in Chrome/Chromium, live editing JavaScript right in the developer tools is also possible, as well as inspecting all the variables etc. It's pretty great actually... (tested it again).

Uhm, yeah that might work, but, in my opinion, browser games won't have same performance as GL games. I made a lot of JS games in the past, and I must admit that you gotta be careful about which kind of calculations you're doing during the loop. My past JS games are simple 2D games which run 30FPS in 640x480 canvas, but if I would resize them to whole screen, goodbye performance... (they used CanvasRenderingContext2D instead of WebGL, simply because I didn't wanted to learn how to make WebGL games due to complexity of the API).

Yea, there are certainly limits, but as a long as the gameplay code does not have to be compiled again and again, it's fine... I remember how annoying that was, especially when it's just about changing "the feel" of something... 100x build/quick test cycles.

Yup, you're 100% right, but I doubt it's possible (unless compiler would be able to replace/reload the loaded program in the RAM). Why Java is able to do, is because it's running in JVM which basically stores all that class data on RAM (I guess), and thus it can simply recompile new incoming bytecode.

[oahda]

It's certainly possible in C/C++! Both JWKi and I are working on this right now. There's some info on it over in the happy programmer room. But it's not out of the box. There might be a ready-made solution out there that works for you, but it might be more practical to come up with your own solution.

The basic concept is to reload a dynamic library at runtime (.dll, .dylib, .so…). Depending on how complex, flexible and automated you need it to be, it will require more or less work. If you only need to reload stateless functions it's almost no work at all. If you want some data where the structure doesn't change you can just memcpy the old data when you reload the library. But if you want to be able to add and remove and shift data around you'll have to come up with some kind of serialisation as well. You'll also need to do more work if you want to be able to load arbitrary stuff and not just stuff following a template that you hardcoded support for.

[InfiniteStateMachine]

I listend to a podcast about programming recently and they brought up the language smalltalk. Apparently the whole concept is that you are editing and mutating a running program rather than editing and compiling

sounded pretty interesting.

The episode wasn't about smalltalk so they only talk about it for 5-10 mins but here's the link in case. https://www.dotnetrocks.com/?show=1473

[photex]

Also worth noting is that this is precisely how Common Lisp is intended to work. Fire up SBCL and hack away.

[qMopey]

... snip ...

The easiest way to get a reloadable DLL going is to have your main executable hand over a couple pointers to the DLL. The pointers allow for some basic memory allocation. Here's my setup in my own personal engine:

The DLL exposes a few functions, things like "SingleTimeFirstInitialization", "OnReloadDLL", and of course "MainLoop". I called the main executable the Launcher. Here's the launcher's actual main loop:

It's actually very little code, hardly any. SDL2 can be used to implement cross-platform dynamic lib loading and function loading, so this can work on your favorite dev environment very easily.

The game itself uses the allocators provided by the executable to do all dynamic memory allocation. Like setting up graphics libraries, or sound libs, holding assets from disk, the game state itself, etc. Anything that should *not* be wiped during a reload goes on the heap somewhere.

Since the CRT owned by the launcher is never reloaded, when a DLL is reloaded it is guaranteed all heap memory will be untouched. This makes it so the DLL doesn't have to worry at all about static vs dynamic CRT linking. No serialization is needed for a hotload.

This has limitations: if the data layout of any structures on the heap changes your code will crash. To prevent this involves a *lot* of work to support serializing the entire game state upon reload. I don't bother with this.

To support polymorphism (like the virtual keyword) I implement custom virtual tables as static arrays of function pointers, indexed by the "type" of game entities. These static tables are reloaded and initialized upon DLL swap, so new code can be written and reloaded! The limitation is just on structure definitions for reloading.

I wrote about all these insights on my blog.

---

Some work needs to be done to pick and choose what get linked into the executable vs the game. I would say try to link everything you can into only the game and leave the launcher as barebones as possible. I placed a few things into the launcher (like SDL stuff), but pretty much the rest is in the game. One note: spawning threads needs to happen on the launcher so thread stacks aren't corrupted on reload.

It's also possible to just link the entire game into both the launcher and the dll, but after spending some time on this style I don't recommend it. Too much time thinking about weird implications across the dll barrier for it to be worth the ease of implementation. I recommend really taking some time to think about the difference in memory locations regarding the dll and the launcher. Make sure to understand lifetimes and separations, and then decide where to link what.

---

I've used this exact style while working on a AAA game, and can say it provides the best iteration time I've ever experience. This feature was critical for taking development iterations to the next level. Personally I don't think there's any point to actually keeping the game running 24/7 since you get diminishing returns for time spent implementing reload features... But imo reloadable code is priceless. I'm glad Casey Muratori popularized the idea, so we can have some nice forum conversations about it all

[JWki]

Yeah my code works similiarly to the above. Not quite the same but pretty close.