text based adventure

Code Finished


I have now finished the creation of actual features in the game, and I hope that I’m done with tuning/removing debug items, because I don’t think I am going to check any more.

I have implemented all of the features specified in a previous post.

The final release on GitHub is here.


“Lots of Potential”

I’m approaching completion of the program in terms of meeting criteria, with at least three quarters of the necessary algorithm made, it’s just a matter of:

  1. Creating enemies
  2. Creating item functionality
  3. Linking all gameplay elements to create a game out of the existing toys
  4. Content such as variety of items/effects, different enemies*
  5. A levelling thing?

*Beyond this it isn’t actually necessary so I doubt it will get done.

Things I have made recently:

  • World map
  • Functionality to look around local area
  • Ability to view inventory
  • Ability to collect nearby objects (in inventory)
  • Ability to move to objects in area.

Code Released here.

Initial Design Ideas: “Extradite”

Looking at my goals for this project, I have worked out multiple ideas for a general game structure, and this one is the one I like:


You are set in a residence a short distance away from an unknown city, having been extradited from your old home (from which you are now much farther), and must survive either in the wilderness, in the urban community, or in the depths of your adventures. (Hell.)

This setting opens up three primary linked stories, and to an extent you will need to participate in all three, but which ones you thrive in are up to you, and your character preferences.

The game has three layers:

  1. Text interface
  2. Area map
  3. World map

The text interface is the input and output for the game, whereas the area map is just an auxiliary to this.

The world map simply names the different regions as they appear geographically, and although the game could be enjoyable with personal memorization of maps, (Minecraft!) I have a marked criterion to meet, so that is what I shall be exploring: map integration in a geographically driven survival/exploration/adventure game.

I also have some more story in mind but that shall be discussed in the future, and finally:

I’m not going to use the geometry system for actual controls; there shall be no “move (1,1)”, no “move left” and definitely not any “goto (547.8, 38664.2)”.

New Blog! (Not Really!)

Blogging about blogging is boring so I apologize for being boring, (also apologizing is boring so I apologize for that as well)


I am starting a new category corresponding to blog posts that relate to a school project I need to be doing.

It needs to be in python so it is rather different to the entire purpose of this blog, but maybe I’m okay with that;
It also needs to be a text based adventure, but I won’t be redesigning Zombies for that, I also won’t be making an engine for this, but rather just a normal text adventure implementation.

The criteria I shall be working around can be summarized as follows: answer the question. (School.)

This means I will need the following:

  • A map system incorporating rooms and/or areas.
  • An inventory which has functional contents that can be manipulated.
  • Travel.
  • Leveling/character growth.
  • Battle algorithm/s.

(Although battle isn’t specifically defined… but I want to explore the obvious definition anyway, so classic RPG it is.)

In terms of personal interests I’m going to be exploring the way that grinding/monotony exists as a trope in RPGs, and how that is/isn’t optional, as well as the applied ways that item functionality interacts with crafting + recipe systems in terms of things which I don’t fully know how to explain at this time.

That’s all!

My Super Cool Storage Design For Video Games

This is an idea I have had in previous text based designs, that I think I shall finally implement in my zombies project:

It is a system for determining how much stuff can fit inside a storage container;

It works by using hard coded dimensions for the sizes of objects and containers, (rather than a “size” attribute that directly determines how much storage it occupies.)

Then two processes occur to check to see if it could probably fit in:

First it checks to see if the object could fit into the container if the container were completely empty:

  1. Arrange the dimensions of the container in descending order, have a biggest, middle and smallest.
  2. Do the same for the object being fitted.
  3. Compare the respective sizes,

if any of the three object dimensions are greater than their respective container dimension, the object doesn’t fit.

Then it performs a check which is equivalent to the usual “size” attribute check, using the volume of the object and the volume of all other objects and the liquid capacity of the container to check the plausibility of the object fitting.

If both checks succeed then the object fits fine. This system isn’t quite perfect, but it is very good.

Of course not all objects are a simple cubic three dimensions, so three dimensions must be chosen that encompass the object for the sake of the algorithm, although most objects will have square or circular bases (buckets, sticks, kitchenware) and the latter can simply be translated to the former.

The empty space that is ‘wasted’ in this process by rounding circles up into square objects compensates very well for the fact that some situations are completely impossible but pass both tests anyway. In other words, since there is no actual tetris involved in the storage process, there is a space penalty.

Now in terms of benefits, this system provides variety, in fact, this system can create gameplay by providing situations in which the size of containers needs to make you think about how you are going to sort your possessions to deal with them.

Now all I need to do is think of something to make that a good thing, and not just completely annoying.

Interactive Novel Versus Economic Dice Rolling

A project which is designed to be a text based survival game faces the risk of becoming what I am calling “Economic Dice Rolling”, particularly when design choices relating to RNG world design are used.

My ideal game plan is to have a large variety of flavoursome text rich choices which occur randomly throughout a game, and have a variety of ways of being approached, depending on your previous choices and current resources and abilities.

The world is meant to be open and isn’t meant to be directed, just like a real life zombie apocalypse.

The nomadic storyline of Left 4 Dead with improvised traveling and escape plans should be a major influence on my game design, despite the heavily linear and guided (level boundaries) level layout used in them.

All in all, the overall goal I have in mind is to create a game that acts as a framework for zombie themed roleplay, storywriting and/or planning towards real-life imaginary zombie apocalypses.

Lasagna and You: Coding in Layers

For the text based project  I am working on, I am embracing a thing called lasagna code, the use of distinct layers in a program’s structure. Since I am using C++, these layers also show in my file structure, I have main.cpp, command and eco.cpp, all alongside their relevant header files.

Lasagna code to me has two main good points, and one main bad point.

Lasagna code is easier to visualize, and harder to forget:

Most of the time we forget the details of our programs almost as soon as we stop working on them for a few minutes, but having a visualization of how you made something makes it much easier to remember how it works. Spaghetti code tends to just be spoken in a stream of consciousness, and is much easier to forget as a result.

Lasagna code is more portable:

It is easy to visualize separating layers of cooked lasagna; you have two distinct layers of pastry separating without objection, and a whole lot of meat/vegetarian filling that doesn’t know which way it wants to go.

That is exactly what seperating layers of lasagna code is like, your two main functionalities (in my case, user input and world/item management) are easy to identify and seperate, in fact they are already completely separate, their is no interaction whatsoever between command and eco.cpp; the interaction happens in commands.h*, which has functions that take input interpreted by command, to pass that input to world functions in eco.cpp.

As a result completely rewriting certain layers, but not others, can make dramatic changes to the program, such as:

By replacing the user input layer with an autonomous layer you can create bots to run a ‘simulation’ instead of a game. Creating an output layer on top of this would give you a finished product.

By replacing the system of input, you could create a windows based application and set up your own gui to collect input, but once you have done that, if you are passing the same strings to the rest of the program, command and eco.cpp remain completely unmodified.

Lasagna code is a massive pain:

Dealing with multiple layers of code can be bothersome.

In my example, creating a new functionality, like deleting objects would go something like this:

eco.cpp: create function bool deleteItem (LocId todel); to delete an object

commands.h*: create function int C_delete (string arg); to cast user input into the number associated with an item
(I know that making users type in numeric identifiers is bad, but it is temporary, we are still only making a delete function for the first time at this stage, after all.)

main.cpp: add entry to the hard-coded list of commands that looks something like this:

+ command (“delete”, C_delete, ” “)

which quite simply specifies the string the user should enter to invoke the command, the function that will interpret the other arguments, and the delimiter that that part of the function will use.

This is all neat and fine, and this is what I had in mind when I decided to use lasagna in my coding style for this project, but it makes the production of secure code just that little bit more bothersome when you need to create checks for invalid LocId input, and then pass back a return value that represents that, and then interpret that again to determine what to display on the screen.


Basically what you are actually doing when using lasagna code, is developing a number of discrete API systems, and integrating them in a way that gives you an actual product to debug and play with, instead of the much more lifeless alternative of creating an API entirely without using it, which sounds fun, but can slow down quite quickly if you are an indie game developer instead of a large company with monetary incentives.

So despite the massive pain, I would recommend it if you are planning on doing versatile things with your program. Three layers to integrate at once will save you making three entire reproductions of the program, and that is reassuring.

If you are working on a small learning project, or a proof of concept, just throw it together; if it compiles right, it doesn’t matter how you did it until you want to make changes to the program – save the serious and secure building for when that happens.


*commands.h is a header file for main.cpp, I have another file named command.h, (a header for the file command) although it is invoked as such:

#include “..\header\command.h

as opposed to the former file, which is in the same directory as main.cpp.
I plan to develop the graphics based project in a lasagna format as well, it is just that for the time being I am focusing on getting win32 working well, and am not actually working on gameplay at all at this stage, for obvious reasons.
I have already started to separate my file structure though, and I know how I am going to place my layers when I do.