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.


Party Grinding (not to be confused with grinding party)

One thing I want to achieve in py4school is a lack of grinding mechanics, which in my opinion damage the replay value of games; (which is in turn at odds with the purposes of random generation.)

This, however, leads to a problem, in that I indeed need some kind of character growth implemented in-game; the first thing that comes to mind is to implement a kind of grinding that deliberately and exclusively holds complicated gameplay back from new players.

In order to implement this in a normal leveling and exp way, which I’d like to do, the best game feature I can think of is a reputation/fame system; (fame is also a nice tie to the Diablo roots I’m embracing.)

Fame would affect the amount of followers you can keep, holding back the complexity of optimizing multiple characters, allowing you to practice and master the usage of 3 followers before you start playing with 4, or say, the usage of a new class without any followers before you start playing with a follower.

And with this I add that my aim is to make less of an RPG ‘idler’/’infinigrind’ (new term!) and more of an RPG puzzler, relying on stealth and choices to take out enemies in a non-direct way, all in a quasi-medieval age of civilization.


There will be more than one system determining your maximum party size, however the raw grinding aspect is the one that both gives the complexity to players who fail to prove experience more efficiently, and that allows players easier victory when struggling, as well as satisfying the criterion of the assignment!

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.

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.

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.

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!