And thus your semi-massive switch-block becomes a semi-massive switch-block with a pile of error handling in it: Would you want to re-launch your game just because you typo-ed a variable name? I can make a confident assumption that most people wouldn't.
GAME MAKER STUDIO 2 GML CODE
Which means: If your interpreted code throws up an error, the game does as well. There's a small detail here: GML has no exception handling. If you have a plenty of experience with various programming languages, the act of writing an interpreter might look like an easy part - first you decide on a set of bytecode instructions to cover the syntax that you want to support (GMLive has 75 of these in total),Īnd then you write a function that has a semi-massive switch-block in it, doing more or less exactly what each instruction defines,īut wait. Or, in my case, making Haxe generate GML code to save time. While GameMaker's extension system has seen improvements over past years, some things remain platform-specific or inaccessible entirely - such as access to raw variable data, instances, or calls to built-in functions or scripts from extensions.Īs result, the most reliable method of implementing an interpreter that can access entirety of GML is to have it done in GML itself. Overall it's mostly about having solid logic in place for everything, but still a handful of work. a ) push ( pop ( ) + pop ( ) ) trace ( pop ( ) ) c ) push ( pop ( ) * pop ( ) ) push ( self. some ) if ( ! pop ( ) ) goto ( label_1 ) push ( "yes" ) trace ( pop ( ) ) goto ( label_2 ) label_1 : push ( "no" ) trace ( pop ( ) ) label_2 : push ( "done!" ) trace ( pop ( ) ) The interpreter is implemented as a stack-based VM (as opposed to register-based), which saves from some headache when implementing a bytecode compiler. The main difference here is that instead of generating JavaScript you generate bytecode. This bit hadn't actually changed much, and you can see post about GMLive for technical details. The whole thing can be separated into several distinct modules:Ī compiler must take source code, verify correctness of it, and produce data for interpreter to run. Certainly not an easy task, but still a one that I was able to pull off. Now, unless your programming language of choice was specifically designed with this functionality (or general dynamic evaluation) in mind, you cannot simply have live-coding with it - in case of GameMaker, recent versions (GameMaker: Studio, GameMaker Studio 2) no longer ship games with complete source code and compiler+interpreter packed in, and do not natively support "side-loading" additional game logic.Īs result, the only way to make interactive programming a reality with GM was to implement a custom compiler+runtime for GML that would be overwhelmingly compatible with the original language. Needless to say, that can be a bit of a bother, especially since compile times grow longer as projects grow bigger, and it can take time to get the game into a state where you can observe subject of testing if you did not spend time making some general-purpose debugging tools.Ī solution to that is interactive programming - updating parts of a program while it is running. So you change something, run the game, look at it, close the game, change it again, run the game. With things like user interface or game mechanics, it is extremely common to tweak code or parameters decades of times for them to be just right. Game development often requires multiple iterations to get something right. Today I'm pleased to announce that situation further improved and I am bringing live-coding to GameMaker: Studio and GameMaker Studio 2 themselves.ġ. Roughly this time last year, I released GMLive - a web-based program that allows to write and run small snippets of GameMaker code right in the browser, including live reloading.