abstract / irrelevant

Testing my Game

Not because I was worried about it not working, but because I have to.

Testing Procedures

Some browser-side zooming is recommended on that image.

The first test poses a number of battles of Frog versus Toad, to see who wins.

I am testing the defending advantage, then a neck-and-neck battle with a slight bias, and then a battle in which both sides can insta-kill. (falling back then, to the defender’s advantage)

The first test made me realize that I’d programmed a defender’s advantage when I was expecting an initiator’s advantage, but that is fine.

Once I knew how the advantage behaved the rest was fine.

Next I tested potions, which have been designed to provide three stat boosts, and all of the tests went as expected.

The algorithms are all being calculated as expected, and caps on health are functional as well.

Equality in My Games

As an independent game fanatic (some day I’ll call myself a developer…) I have room in my game concepts to be a feminist.

As a consequence, I recently decided that for the rest of time, I shall, to the best of my ability, make the gender of every character that I introduce in a game determined by the flip of a coin. (physical, metaphorical or virtual) This way I am truly doing my best to avoid letting stereotypes guide my roles.

I should try my best to determine a role, begin to think of character details and dialogue even, and then determine their gender via a random process as such. Further character development would happen after that and hopefully that will guide things towards reason without guiding them to even worse stereotyping.

Also it would be nice to determine things such as sexuality (if only secretly) by similar means… preferably by using real statistics regarding the way people have identified their sexuality.

I suppose that in the realms of racial identity I will have to look at the setting being dealt with, and the associated statistics, since getting an intuitive sense of racial balance as it exists in real life is hard. (Racism isn’t so much a part of feminism… it is still important of course!)

I Said No ETA!

One thing quite interesting about the programming world is that it is one of the hardest things to predict a time for.

The two main games I am watching right now are Project Zomboid and Heat Signature; both of these games are made by developers who insist upon not providing time of arrival for any finished product they produce. This has gotten me thinking about why it is that software is so hard to give predictions like this for time of completion.

The obvious reason, of course, is bugs.


When you make something, it isn’t going to be perfect, it isn’t going to be functional, it is going to be flawed, it is going to contain mistakes and you aren’t going to realize them all at once. Each individual bug is a mystery and will take an indefinite amount of time to understand.

Point A. In software design, things go right the first time as often as mysterious and big problems occur in most other field. (That is, not often)

Point B. Every bug is a mystery, and can only be solved with the right eureka moment, unless you want to completely rebuild something. (which in most cases is the more time consuming process) Every individual bug represents the same time frame as assigning someone time to come up with an idea, except on a smaller scale. Ten bugs is like assigning a person to develop ten ideas in succession: for every single one will happen on time… either they won’t, or you’ll require very generous time frames for every single one.

The reason that bugs work like this and occur in software so exclusively, is that talking to a computer is like talking to a person with a very restricted sense of your comfortable language. You need to think for yourself, but you also need to think for them to figure out what they must have thought, and if you say something completely illogical or unexpected, the reaction of the low familiarity person will be more something like “Oh that must be some cultural trend or tradition that I don’t yet understand”, than the more convenient realization that the programmer/amateur linguist made a mistake.

Really all of this is quite ironic, because within the gameplay of video-games tasks are usually represented by flat rates, and a programmer in game would have skills that determine their flat rate of lines of code per minute, and the task would have an inevitable closing date. Even when random events or modifiers are thrown in, (as proven by RuneScape) the process is still extremely predictable, and averages dominate in the end anyway.

It isn’t actually very surprising, but it is a nice contrast when, at least in the technical peculiarities, playing games and making games are so different.