Three months later, and I’m back.

Tactics is relevant again, I’ve been resorting code, making things less ugly, and adding functionality to the engine for almost a week now, which means I’m back!

First of all, what have I done up until a week ago?

I was working on graphics, getting polygons to rotate properly, and did it.
I released a working version of this, with a square, movement and rotation. (I was pretty proud of myself: I don’t care what anyone else thinks)Colors, scaling (i.e. zoom) and non-oblong shapes are all completely within the scope of the code I have made, but the point of the release was to test the one feature I had doubts about, not to show off the features I’m comfortable with.

Then I moved house and forgot about it until now. With school exams finished for the semester, I started programming last week, and I feel comfortable saying that I am back!

Since graphics are working, I’m changing the layout of the source, and creating a “game instance” class that will help separate the graphics, engine, and game from eachother, and then it will be work on actual game mechanics like entities and movement!

Exciting times.

Another Project :D

A while ago I mentioned a secret project, rather loosely titled “RPG engine”; well on GitHub is a repository for the design and planning involved, although as of this being published it is it not very detailed. (Also the game idea is very different to what the title tends to imply)

I recently started actually working on a programming project which is designed to be a Harvest Moon clone. It is going to run without any interface, and this will be the case indefinitely. Some day, when I get better at C++ graphics, I shall bother with that, but if I want to work on graphics I’ll just work on my tactics project.

I don’t exactly know how the project is going to go, I’ll just work on it as I wish alongside the other two projects, and try to learn something.

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.

Secret Project Now Mentioned

Over the past couple of weeks, I have put together some thoughts and ideas I’ve had into one big messy and fun project that should probably take the rest of my life.

If you think I am biting off more than I can chew, too bad, I’ve learned not to care.

It should contain lots of npc driven gameplay, and isometric graphics.

On that note, it is time to turn my development cycle back over to the zombies project!

Different Control Schemes in Tactics

A design I have long had in mind is for three different control / planning systems working together in the same game environment.


Normal tactical input, in which you construct a game plan, and submit it to then see the consequences of your plan; After seeing the consequences you reevaluate and repeat the process, stepping forward until you reach your goal or screw up and get shot.

The key element to avatars is their reaction time, which would control how the characters react to events, and how you think about your plan as you make it. When you submit a plan you would only see up to a point in the resulting consequences, for example:

Unit with 3s reaction time:

  • Peak around corner over 2 seconds:
    • move out for 0.5,
    • look for 1.0 and
    • move back for 0.5
  • stand behind cover for three seconds

The five second plan would be submitted, and you would be given whatever they saw for the first (five minus three) two seconds of the plan, the remaining (in this case idle) three seconds of the plan would be locked, as a trade off for the fact that you can see what happened in the first two.

This of course represents the unit spending three seconds to think about what they just saw, and evaluate the future plan they will take.

Being a very central system in the game, these will be explained in a lot more detail in the future.


Not sure why I chose this name for them; A terminal is a giant every-possibility-considered plan that branches depending on certain events and is generally not very much fun to develop plans in.

For the most part they are exactly identical to avatars, and depending on the level design may just act as a script that saves simple tasks you have done before in case a future opponent does exactly the same thing in the early phases of your next match.

They also could serve in a terminal V terminal game in which you need to develop the best plan that will push your opponent to a check mate position where they will have to reevaluate an earlier branch in their noded plan. (Whether or not either of the previous two paragraphs made sense, you don’t actually need to know what I mean)

I have no idea at the moment with respect to making terminal design more dynamic, though this would be extremely important as simple adjustments in a unit’s placement would otherwise require an entirely duplicated branch. Overlapping with ideas presented in the final control type (scripts) will probably prove useful.


Programmed units that aren’t controlled at all during the progress of the game. My plan for making them is to create simple scripting capabilities, and then wait for someone to learn how to use them and thus work out what their limiting feature is; when they give me feedback I would be able to significantly improve the potential of the script designing system. (So follow this blog! Leave comments! I’ll be fueled almost entirely by fanbase in not too much time at all!)

Scripts would allocate nametags to entities and go through processes to determine what they ought to try doing. (that’s all I’ve got at the moment…)

Script design would allow for some very powerful features to be added to terminal and avatar interface as well… This game could be good.

Integrated Scripts

Scripts would have the option to utilize information on the map laid out by the map-maker, to maximize the success of NPC enemies basically.

Scripts would be made to use place tags, and then a map maker (perhaps the same person who made the script?) would place these place tags on their map to create an I.S. functionality.
In the future I’ll explain the way that these three interact with eachother, and I shall also explain how the latter two systems have very strong uses in NPC construction.

Building a 2D World from Polygons

In my tactical project, I am building my world from polygons:

There are however a variety of polygon types to serve the functions of the world:


A floating platform shape, suspended in 3D space.

They have a collisionable floor and are given a specific designated height for wall structures to occupy.

By constructing a prism in the virtual space, each platform can be assigned a “field region”, the field region of two platforms can never overlap, but can touch on their extremity.

A floor thickness may be possible, but probably not until later in the project, especially since platforms won’t support 3D suspension completely anyway… Not for a long time…


This marks a part of a platform that isn’t occupied by floor; this way creating a hole in the floor isn’t the excruciating process of drawing a tightly folded C-shape. (which would no doubt result in collision errors if things fell smack-on the seam) This way the holes can also be more manipulable as well. (In both level editing, and in meta blocks.)


Block is another word for wall. A block is a polygon that is set inside of a platform polygon; the polygon represents a wall with the height associated with the platform.

Blocks are, of course, collisionable.

Properties such as visibility (glass) and penetrability (plaster/otherwise thin walls) are so far unconsidered; they would likely take on a specialized polygon based off of the Block.


Meta-blocks are also set within a polygon. The specifics can be explained in a future post, but a meta is an alternate map for the platform, alongside programmable property systems that would allow you to control when, and where, the alternate mapping would replace the current one.

I don’t know if that makes sense, but the system I have in my head allows for the creation of destructible terrain, interactive elements such as oil slicks, and special map triggers, for all of your map-making needs.


The just-now named “effectygons” will be what manages certain live gameplay aspects of the game.

Effectygons will always hold the kinds of property that meta-blocks use as input, and will also have the possibility to interact quite heavily with meta-blocks. (as well as other effectygons. So then an oil slick would probably work better if it were just an effect!)

The flame of a flame-thrower, the smoke or explosion of a grenade, and specialties such as liquids and chemical coverings are all possibilities of this system.

The exact extent to which they will be programmable is currently unknown; the only thing I really understand is how properties and timers will work, and how meta-blocks can be used to extend their effects in map-specific ways. Things like fluid dynamic, or projectiles parting smoke would be fun and ideal, but not confirmed… I don’t know yet how it might work.


Moving and functional blocks that have a height independant of their platform could be useful for map design.

Tables, working doors and miscellaneous objects and blocks would be ideally constructed in this manner… the possibility of vaulting low objects is an immensely exciting idea for a tactical shooter design as well.

The problem is that having non-rigid objects would create complications in that certain situations may desire explosions, and physics, the latter of which I am undoubtedly incapable of delivering; even if I could it would be very displeasing to have objects that behave with physics but cannot pitch or roll due to their 2D constrictions… it would be even more displeasing if they actually did pitch and roll in what is otherwise a beautiful and elegant design scheme.

As indicated by the question mark, I am not certain enough of this to really give much speculation or implication about how it would work; my first priority is working that out on a semi-technical level, to get an idea of complexity and direction.

Time Stamp

These are my thoughts and ideas so far!

They have been a few months in the making, so hopefully they are going to be good.

I’ll post some follow-up as more ideas and thoughts come… but first I am going to be posting about the technical side of collision detection in a tactical game environment such as the one I am planning and making.

Combat Systems for Zombies

In my zombies project I would like to strengthen zombies in terms of their abilities as a group.

The Sagittarian is a zombie themed interactive fiction which is definitely worth checking out.
The combat scenes are usually dictated by two rules:

  1. More than two zombies and things are getting risky;
  2. If you don’t know what is around the corner, it will probably bite you.

The events are all about zombies that you hadn’t seen getting to you, or too many zombies being in front of you and having you succumb to distraction.

This is how I would probably like to see zombies in my zombie project.

The game would be about avoiding tight melee situations, and altogether avoid being close to zombies if you aren’t providing your fullest attention.

Systems that could enforce this that come to mind involve an “attention quota” that you manually distribute between hostiles and environment in a situation, and the less you assign to an element, the more chance you have of screwing something up with it, assuming that it does do something.

This doesn’t however take into account the existence of firearms. For these two systems to work well together, firearms would need to be quite expensive, and consume ammo readily.
A supply of ammunition can help you through a couple of sticky situations, or maybe one horde situation.

The thoughts that this all leads onto, relate to some ideas such as:

  • explosives
  • non-zombie npcs
  • non-common zombies
  • environment interactions
  • firearm diversity
  • fire-arm noise that attracts more zeds
  • ad-hoc weaponry
  • status buffs like adrenaline to affect attention span and such

I’d be interested to know what other people think about where I could take these ideas as well!


The tactical project has been long in planning, and as is often the case with me, it is the final design scheme coming out of several similar or connected design goals.

The newest element of this complete plan is the use of polygons for all terrain design.

The idea was for the concept of having a mass horde fighting game which was meant to feel like L4D in many ways, and the polygons would allow for terrain that would feel nice and dynamic in a way that rectangles or tiles can’t achieve.
A point of note here is that my main concept vision was a pair of cliff faces with a path between, a horde of circles rushing in one end and a foursome of circles with guns standing on the opposite end. In a tactical environment that could be very fun to watch and manipulate.

The advantages with polygons I have in mind are:

calculations are easy – Detecting if two lines are touching isn’t very difficult, and relevant ray-casting calculations are well within my reach.
works well with top down – Complex object designs aren’t very friendly with a top down 2D view. I’d like to go directly top down and polygons are my friend here.
no losses – Tile designs and orthogonal designs can be made with polygons anyway.
rendering is easy – There are functions available within the windows api that allow for polygon rendering; super easy.

Using block color polygons to build a world populated with block circle entities and projectiles looks very nice in my head; although special visual effects aren’t within my reach, I can see things working quite well, and being quite low demand to build and operate.

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.

The first post: Details and thoughts at this time.

“My affair with C++” is going to be a project blog about my two standing C++ projects, as well as whatever C++ related learning events happen along the way.

Project number one:

Tactics engine; top down block colour tactical engine with one gamemode in mind. I call it an engine because I can imagine how versatile tactical game environments are by playing them.

Zombie Text:

A kind of sketchy zombie survival text thingo that might be okay if I make it.
The idea comes from the fact that all of the zombie PBBG’s I have ever seen, either are crap, are non functional at this time, or I can’t remember what they are called and where I can find them. (Oh there is this one semi-decent one but it is all freemium and junk… nice inspiration from it though!)

Yeah so I’ll be working on them, talking about C++ stuff as it comes by, and thinking about where I’d like to take both projects (if only as an experiment for hypothetical game design)

Let me know if you are interested in contributing thoughts and ideas, or playing around with my early versions as they start to actually pump out!

Thanks, Spivee.