The module design

    In C++ you can add “libraries” to your program, basically making harder things easier, and making the impossible possible. For example. you might find a library that makes drawing to the screen easier, or maybe even one designed to aid in the game development process. In Zonerunners I want the same control, maybe even more. But for any of this to happen I’d have to do some serious thinking.

So now I have to decide: Do I want the hassle of external script reading and the hassle of fixing things outside of the GameMaker GUI? Do I want to give the player some ability like importing their own script into the game? Or will that be too much of a risk?

All these are issues that must be addressed when approaching the idea of a module design, which is the ability to attach external “modules” of code onto the existing engine without recompiling it. The possibility of keeping the module design until the game is finished, upon which you make all the external scripts internal (inserting them into the Game Maker GUI), is also a good approach.

But like I said, I needed a way to code while actually PLAYING the game without handing over total control to the player. If you look back at my previous post called “The Introduction!” you’ll see my code for the in-game console towards the end. We’ll be using the same approach for this, so look it over!

Modules work this way in Zonerunners: An external script is loaded and parsed much like code is handled with the console. Only this time, the parser also runs through a list of blacklisted commands (commands I don’t want the user using), and are removed from the script. Wow, that was simple!