From my squishy brain to yours.

Well, that took longer than anticipated

How is it that whenever you think things are finally coming together, something has to pop up and gum up the works so badly that you are thrown completely off schedule?  I blame Murphy.

My code had finally reached the point where I could implement the main menu and the main conversation window.  Immediate mode GUI widgets were in place.  The scripting language had been upgraded to use the node and attribute system.  The dialog script parser was largely implemented.  Everything was finally integrated together, and all I needed to do was write some scripts to tie it all together and set the ball in motion.

And then.. crash!  Memory leaked onto the floor.  Bugs in the code, lying dormant for over a decade planning their revenge, reared up and dashed my hopes against the digital rocks!  I had fallen into the code’s well-laid trap!  I shook my fist angrily at the compiler and cursed it under my breath.  It just stared back at me, unmoving, like only an inanimate object could.

For the entire next month, I laid siege to its digital defenses.  Wielding Valgrind with steeled determination, the memory leaks were the first to fall.  Uninitialized values were tracked down with a vengence.  Forgotten allocations were slain as soon as their usefulness had passed.  Soon the only villains that remained were cowardly hiding in the SDL libraries themselves.  I decided to let them live… for now.  But if they start causing trouble someday in the future, then mercy shall not be theirs.

With the crashing vanquished, I turned my eye to the disobedient code base.  I issued commands, but the system either failed to follow them, or completely screwed up the execution.  Such insolent behavior cannot be tolerated, lest other lines of code decide that they need not do their sworn duties either.  Through a grueling process of elimination, I tracked down the lines of code that failed me… that failed their brethren.  Code that could be… re-educated… was reprogrammed and put back into service.  Code that was deemed beyond repair was tactfully eliminated and more cooperative replacements were brought in.

Finally, after weeks of hunting down and eliminating the code that had betrayed me, I was finally able to behold a well-won victory.  Code compiled, read its instructions from the game scripts, correctly directed the GUI windows where to display, and the bitmap, text, and sprite routines each performed their task to display onto the screen correctly.  The end result, as you can see below, is glorious to behold.

the main menu

Our Glorious Main Menu

conversation window

The Conversation Window Of Doom!

Ok, so maybe it is difficult to make a code update seem exciting, especially when screenshots of the results look like a 5 minute comp job in Photoshop.  But I am actually excited that I’m able to drive the GUI from my own scripting language now, and the essential widgets that I need are performing as expected.  Everything is displayed with bitmaps and sprites, so a graphic overhaul is simply a matter of generating and dropping in the needed bitmaps.  Art will come later, once gameplay has been established.

Now I just have to make sure the conversation/scene scripts are updating the interface, and that the text moves forward when the screen is clicked on or the spacebar is hit.  Then I will essentially have everything that is needed to implement a kinetic novel.  After that, I can use the same script driven GUI system to implement choices and I will have the tech to do a basic visual novel.  A lot of work still remains to be done, but it is exciting to go from a collection of back-end infrastructure code and turn it into something that can be interacted with; an actual game.

Here’s hoping the next update will come faster and won’t require so much bug hunting.  And here’s hoping I didn’t just jinx it.



About The Author


2 Responses to “Well, that took longer than anticipated”

  1. Terry says:

    Why are you inventing a language when you could use C++ or other game engines, Unity?

  2. mduffor says:

    I’m not using any other game engines because this code base is intended for several other purposes, including running headless or running on multiple platforms to which the game engine might not be ported. I also chose to use my own language rather than Lua or Python or the like so that I could reduce the number of external code dependencies that my code has. This will make it easier for me to compile the code on different platforms and architectures, including hand-helds. A final advantage is that I am able to tie the syntax of the language in closely with the the internal node and attribute representation that stores all of the game/app data.

    I could have used C++, but that would require compiling and would not allow code snippits to be stored in configuration files or on objects themselves. This restriction may be fine for a game, but it is a limitation when this same code is used to develop flexible authoring tools.


Leave a Reply