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.


I Take It Back

I’ve lost motivation and interest completely for the non-mandatory side of this assignment, soooooooo that’s embarrassing. I don’t know if I’ll ever run on a sudden desire to use Python in a few years: if I do then I may turn this base-assignment into a fun extradite game, but for now I’m making inventory and battle and victory and that is it.

The reason why is partly real life circumstances, and the rest has to do with me feeling too inspired with my long-term dream for me to want to develop this small idea; perhaps this makes me less reliable with my project commitment, but most of my blog content is theory and design, and that is unchanged whether or not I give up.

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!

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)”.

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.


GitHub is Really cool.

Since I am a programmer, and also since open source is amazing, I am now using GitHub for my source.

I have a repository for both of my projects, and some other ones as well; you can look at any / all of them here.

I will still use both of my blogs, but not nearly as actively, particularly at this time (because I should be spending more time creating than blogging!)

The more interest my blogs receive, the more I will maintain activity and interest when communicating updates, obviously.

Now you can finally see my actual work; design ideas posted on the blog will also make their way to the repos.

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.