This month has been consumed by automated testing and pathfinding.

It is difficult to create units which are unique and balanced. This is important for a multiplayer game, and being a solo developer I have to make tools to test the design assumptions I have created.

In generic software development automated testing allows programmers to quickly check their code is returning the right data. In an environment as complex as Real Time Strategy games, where soldiers navigate a 3D environment in real time, there are so many variables to consider, that the only way to investigate is to run gladiatorial test matches.

I created a user interface to easily customise tests. Each test places a number of units at either side of a small map. The number is determined by their cost (value). The units immediately rush to attack the other team, until one side has none left. The code then calculates who has won, and by how much, and saves that to a text file. This means I can run hundreds of tests overnight and examine the results in the morning, providing a rough measure of whether a unit type is too strong or too weak.

In any game it is unlikely that battles will just be between individual units, so each test creates multiple units, and places them at random locations. Each pairing is then repeated a number of times to provide an average result, which should be more accurate.

Pathfinding has been something else. The old system generated one path per unit, which clearly will not scale if hundreds are involved. Instead, I followed the Flow Field design described by Elijah Emerson, published in ‘Game AI Pro’.

Each map is divided into sectors, which contain tiles. Sectors connect to other sectors via portals (green dots, white lines show connections). Red lines show the flow fields themselves. Each tile has a direction, and when units enter that tile they read the direction they should be facing.

The path visualised above shows the directions five units from the top right must travel to arrive at their goal in the bottom left. Each unit starts in its own sector. But there could be five or ten units in each sector, and yet the cost of generating the path remains the same. The advantage is a considerably more efficient means of moving large groups from A to B.

Initially, it took as long as 100 milliseconds to generate a path for one unit moving along that distance. After some optimisation, the worst case was reduced to 1.5 milliseconds.

This month, good progress.  Environment art is ongoing, marketing research is complete, and new features are implemented.

The terrain system has been reworked, and the player can now edit individual walls.  There is new a query button, which allows the player to mouse over a unit and see basic information.  The healthbar has been implemented, with new and old styles to choose from.  There’s also a new charge button, which allows the player to order a group of soldiers to launch into melee against the nearest enemy.  There have been many other fixes and much refactoring besides.

I have also been consulting with friends who play strategy games, to try and get a feel for how to implement unique factions.  How many will there be?  How will they be different?  What narratives will guide them?  These questions have been answered for now, and there will be four playable factions, each with a unique identity and distinct mechanics.

The next deterministic problem to resolve will be replacing Unity’s non-deterministic Raycast system.  That will be non-trivial and expensive, but once complete there won’t be too much left for multiplayer to be viable.

A raycaster is an object which creates an imaginary line from A to B, and then checks if this line intersects any triangles (geometry in the game world).  This is used to determine if units can see each other, and if projectiles have impacted walls.  In principle, not too complex.  But the problem is efficiency; the geometry in the game world must be saved so that only the closest objects are accessed.  For example, one such design pattern is similar to a tree data structure, and is called binary space partitioning.  Doing all that well is non-trivial.

Perhaps the worst possible fate is a failure of imagination.  While mood varies, that range is usually not debilitating.  Unfortunately, I have brief and recurring periods of destructive lows.  These moments induce a complete failure of imagination, as the strength of emotion is temporarily drained.  This manifests either as a temporary loss of positivity, or a tactical victory for negativity.  Something is either missing or too much.

These moods are like stormy weather.  They come and go, and there’s only so much that can be done while there’s a storm howling outside.  For J.K. Rowling, depression was best explained by the metaphor of the Dementors from Harry Potter; soul-sucking monsters which drain all happiness and energy.

The immediate impact of such feeling is a lack of motivation.  All confidence is absent, and an uneasy distinction emerges between rational and emotional modes of thought.  It is possible in such a state to pause and logically deduce the absurd dysfunction, and quite possible to reason that this feeling isn’t realistic.  But it’s impossible to feel that.  And without feeling there’s no doing.

So that’s partly why there wasn’t a Month Three blog entry.  Another reason is that things always take longer and cost more than one anticipates.

The bad news was that work on deterministic code for the game’s multiplayer hit a wall.  The type of mathematical knowledge necessary (quaternions and four dimensional matrices) was beyond me.  I was lucky enough to find a freelancer who does have this knowledge, and is almost done working on that most essential task.

Concept art has also come a long way, and both characters and weapon explorations have been completed.  Today work begins on environmental concept art, soon the characters won’t be abstract entities disembodied from space-time.

The pause from programming has provided fertile soil for new thoughts, as the terrain and base building systems have to be refactored anyway.  This creates an opportunity to iterate ideas, making the final implementation even better, and to give players more dramatic choices.

Determinism has always been the biggest technical challenge, but progress is being made towards resolving this travesty.  When present deterministic challenges have been resolved (there will be more) work can resume, and focus will be on terrain and base building systems.

Refactoring unit code was a success, and has provided a foundation for further development.  The next tasks will include (in no particular order): computer player intelligence, group unit movement, art integration, fog of war, and GUI concepts.  Combat and networking have already been implemented, but will need more work too.

So there’s cause for optimism.  In the meantime, I’ve been reading Gerald Zaltman’s ‘How Customers Think’.  Like Daniel Kahneman’s ‘Thinking, Fast and Slow’, it is an invaluable book that is unfortunately something of a slow read.  I hope the book will help me to better understand the desires and needs of players as I design game play and direct art.

It has been two months of full time development.  Ten months remain.  The clock is ticking, but the light at the end of the tunnel grows brighter!  Right now I’m deep in vector mathematics.  Which is about as fun as it sounds.  Regardless, code integration is going well.  In my last two jobs as a software professional I could never give decent estimates, so I’m not going to try here.

Instead, I’m going to talk about art design and process.  How does one go about moving ideas from brain to screen?  The first step is finding an artist.  In my case, with limited budget, I can’t afford to employ an artist with the skills I need.  I can however afford to pay a freelancer.  This will still be very expensive, but it limits potential cost and risk.

There are many relevant websites.  Generic spaces, like Fiverr, were recommended by a few people.  However, I decided upon specialist websites, starting with Polycount.  Polycount’s “Artists Looking for Work” forum allows you to post an advert, and then scrutinise each message based upon the artist’s portfolio.  I later used ArtStation, which requires browsing artist portfolios, but you can specify search criteria which is really helpful.

I found an artist on Polycount whose portfolio I liked the most.  This was from about twenty applicants who messaged me.  It’s very important to accurately describe what you need, from the style (preferably with examples) to the quantity of work, price range, etc.  It’s also important to find an artist with a portfolio demonstrating the kind of things you want.  One applicant had the most excellent portfolio of human faces… when I’d asked for robots and animals.

Where they live is another consideration, as this can influence cost either way, and legal concerns.  The artist in question was Malaysian, and I used Transferwise to pay them.

Concept art is a gradual process, and so will be expensive.  It requires iterations of designs.  First, you must describe a clear vision of what you want, and from this the artist creates an estimate.  The more professional, the more likely they are to ask for exchange of contracts and some of the cost up front.  Contracts are good, but only if they’re from a jurisdiction accessible to your lawyer.  Asking for references before signing contract is also a good idea.

After the first draft is done, the problem is trying to figure out and then describe changes.  You must have a strong idea from the start, the last thing you and the artist want is badly defined designs, as this just stresses people out and wastes money.  If this isn’t possible, make it clear that you really don’t know what something should look like, but are happy to take the time to explore different ideas.  Professionals will be able to provide good ideas, and you need to do your homework: at the very least to know what you absolutely don’t want.

The first artist developed rough designs.  They were good, and really helpful.  However, they did not have the skill required for the final rendering, which must have absolutely no visual ambiguity.  A good question is what makes good art, but poor concept art?  When a digital artist creates something in three dimensions, and there’s visual ambiguity (for example, only the front is shown) this is a big problem.

So I had to find a new (and more expensive) artist.  I used ArtStation, messaging artists from various places who I thought may be appropriate.  In the end I paid three artists to do exploration sketches, and from this had something to compare.  Though I already had a favourite, it was best to be absolutely sure.  It’s basically a job interview at this point, you want to see how they work; not only the quality of the art, but how long it takes and how well you communicate with each other.

There is a lot of work to do, but it’s best to take it slow.  This works really well, I’m in no hurry to acquire art assets.  I can use programmer art (read: cube soldiers) until the art is done!  Everyone appreciates being given the space and time to do a job properly, so I was keen to avoid any undue pressure; which is especially bad for creative work.  If the contractor needs time, give them time.  Delays are sometimes inevitable.

The conclusion of all this is that concept art for units is almost complete.  Next step is final rendering, which will be done gradually to make sure everything is perfect.  I also need concept work for weapons and environments.

In the meantime, I am more confident than ever in the code and art.  Existential terror is at an all time low.  And I’m still excited that I will eventually have something to show!  I suspect this will suddenly arrive all at once, when programming and artistic labours finally meet.

It has been a month since full time work began on 13 January.  Finally, light flickers at the end of the tunnel of technical challenges.  A lot has happened, but it has been overwhelmingly technical, so I won’t bore you with details.

Time spent trying to understand someone else’s code is frustrating, hours spent reading doesn’t feel productive.  Especially when feeling overwhelmed by the scale of the task at hand.

There is new concept art, but it’s not ready to show.  I didn’t think I’d be quite so stressed doing what I’ve always wanted to do, but mercifully this isn’t constant.  At least, as the technical solution slowly takes shape there’s less anxiety hanging around.  During the early stages of any ambitious or ambiguous work self doubt is at its most distracting.  Especially when working alone, so having programmer friends is indispensable.

Month Two should certainly feel busier, as there’s less mystery about what is left to do to achieve a working deterministic (multiplayable) system.  Preparing Lockstep and Pathfinding libraries for integration has been no joke.  Integration will consume the coming month, along with finalising character concept art.

After all this time, the game design feels less flimsy.  It has been years of arguing with myself.  Though, there are still some questions to resolve, but the core of what will make this game unique and fun is obvious.  Ideas are like wine, best left to age in the cellar of the mind.