Skip navigation

Tag Archives: game-engine

Well, I admit I was envisioning today’s post being written while sending off yesterday’s. It was inevitable: I have spent all morning tweaking the game engine further.

After around 30 minutes of planning the flow of the game, I realized that the engine, while finished, was simply not flexible enough to make even the 1/10th interesting game I was planning. You would have been only interacting with doors and objects in your inventory that open the doors (keys, prybars, etc.). I did not expect the game to be complicated, but that is too lame.

So, last night, I began by making objects more complicated: you can turn them on or off. And, because my engine previously allowed only one game-altering action per command, this morning I decided to upgrade it, so now you can make an infinite amount of changes per action.

Here’s an example.

Using my engine, the game designer (who is also me for this game) writes out all the possible commands combined with a string of text describing the results and code that tells the program how the action affects the game – all written in a specially dedicated text file according to special formatting determined by the coder (me again) in the definition Library class.

In the first area, the thief needs to place coins in the outstretched hand of a duplicitous slave in order to get into the house (this is the second thing you do, and it is explained in the intro, so this is not a spoiler). Before this morning, the entry in the design document looked like this:


pay hand
You spit out the coins, wipe them on your exomis, and give them to the outstretched hand. The hand disappears, and the door creaks open slowly.|unlockRoom01#


(Yes, people in ancient Greece kept coins in their mouths. An exomis is a male toga-like garment. I am an ancient history nerd – so sue me.)

So the Library knows how to read this and chop it up nice and good for the main program, which would know how to run it. “unlockRoom01#” means the player now can enter the appropriate command (“enter house”) to go to the next room – whose reference code happens to be “01.” All done, right?

Wrong! There are three big problems with this version:

  1. You still have the coins after making the transaction.
  2. You can still do things to the door which you shouldn’t be able to.
  3. The hand is still hanging in the air. That’s just weird.


So I needed to allow multiple results to a single action. This did not prove too difficult, though it took a little bit of tweaking (especially with Mr. Library).

The result is now this:


pay hand
You spit out the coins, wipe them on your exomis, and give them to the outstretched hand. The hand disappears, and the door creaks open slowly.
unlockRoom01# loseItem00# deactivateObject00# deactivateObject01#
#This is a blank line in the actual document


So, as you can see, there are two large changes: actions are on a separate line now, and there can be multiple actions per command (separated by a space). A small change is the empty line at the end, which I added to make the document more readable. So now, when you type “pay hand,” you not only unlock the next room, you lose your coins, and the hand and the door are no longer usable objects.

The perfectionist in me laments that it would be better if the door were not “removed” from the field of play. I might tweak that, but it’s finally entering the territory where it’s an acceptable omission. I need to take time into consideration. We’ll see where I end up next…