@matthallmoment@leidegre In the past we compiled to interpreted byte code for both dev and ship. Now that we do dev in native code, yes, the plan is to transpile to C next time we ship.
@AndroidBlogger So far we use this for single threaded gameplay code only. Multi thread would have to explicitly manage access to different regions of memory so you could sync when needed? Or use something like golang channels? Fun to think about but our games haven't demanded it so far.
@leidegre I still spend plenty of time coding away with the game closed when working on big picture stuff. The time spent making live changes is when you get down to the details generally speaking.
@leidegre No just regular, side effect heavy, game code. The fact that code *can hot load while running doesn't mean you would never stop the game. Certain kinds of changes work well live (constant tuning, changing one interpolation function for another, etc.) and others not so much.
@NunoPLeiria It's just that when you're doing non-trivial data layout modifications, that usually goes along with non-trivial code changes to go with it. When those code changes are half way implemented you will probably crash if you let that code run live at that point.
@Jonathan_Blow@methylphenidev In a full technical analysis of this I would also expect to hear much more about the limitations and the nature of the problems solved and not solved.
@Jonathan_Blow@methylphenidev I totally agree. There are 1000 decisions that we have made for our internal tools about tradeoffs that all cut in the direction of our specific small team and the kinds of games that we make.
@sempiedram@albertvaka Braid has probably the most polished user facing rewind feature I've seen for sure. The technical basis for this though came out of work I did previously to build a debugger to reverse engineer NES games. Overhead is low(er) if you stick to only mutable data.
@NunoPLeiria Yes, memory will get remapped as needed if you change data layouts. In practical terms though, there is a limit to how much you can mess with stuff before the simulation just runs off the rails, so I end up not doing that very often.
@leidegre The language is our own C+ kind of thing with quality of life stuff that we like. The code gen is also totally custom (but it only has to run on our development platform which is Windows.)
Mega Man 2 has underwater parts that reduce gravity and increase jumping impulse as expected. The secret third part of the effect is that the whole game engine goes idle 1 out of every 5 frames. This slows everything down, even background animations and stuff outside the water!
@davekopec For programming we use Visual Studio to write C++ on Windows. For art and animation we use Photoshop and Flash. For source control we use SVN. Everything else is built up from there.