Articles

Preface

This is the last part on a series of project postmortems I’ve been publishing. If you want more background details, you should read:

• So about that game
• It always start simply enough
• Focusing on gameplay design
• The not-so-artful dodger
• Lost in translation
• Laying tile
• Quality improvements
• Detail begets detail
• Stage testing
• Excess in moderation

Introduction

Last June at the Game AI Conference someone asked me “so are you doing the whole indie dev thing?“. I replied without any hesitation: “not exactly – I’m mostly a stubborn hobbyist“.

Even if at this point I had already decided to cancel Wallachia (or at least put in indefinitely on hold) I didn’t realize until a bit before I began writing these postmortems that had he asked that question a few months before, I would have answered affirmatively.

What changed?

I had re-learned a fundamental lesson: domain knowledge is everything.

That’s business-speak for “you have to know what you’re talking about“, which I would expand with “if you haven’t personally done something yet, shut up“. Funny enough, I already knew that. A lot of my background is on data analysis and the more traditional side of AI, and when developing a system nothing whatsoever beats having someone with good domain knowledge on your side.

Modesty aside, I’m a damned good project manager. I can deliver projects on against a specification and on budget, and if you’ve done any sort of business development you probably know that’s a rarity. I’ve also done a fair amount of game development contracting, always keeping to the estimates I’ve given to clients.

Put the two together and hey, insta-gamedev magic, right?

Um… No.

During development of Wallachia I found things taking longer and longer than planned, schedules and deadlines always slipping. Part of this was an issue with contractors, but it also happened on tasks I’d set for myself.

Why? Not only should I had been able to foresee and handle those delays, I should have at the very least kept to my own estimates. So what was going on?

Truth is, I only believed I actually knew what I was talking about. No matter if you consider Producer to be a fancy way of saying Game Project Manager, the fact is that I am good at leading projects because having gone through so many, I have a very good grasp of what can go wrong and where. This experience allows me to see problems coming, and to do something about them before they became an issue.

Not so for games. I had disregarded the fact that my experience as a game contractor had isolated me from the rest of plumbing of making a game.

Since I’d never managed artists myself, I did not have my glasses calibrated to focus on the red flags, only seeing them when they smacked me in the face. Never having commissioned art before, I didn’t know how to judge model estimates. Clearly I had even underestimated the time to put all the pieces together for a scene. And how do you even begin estimating game design time when you have fairly little game design experience?

But let’s look at the balance sheet for what went right and what went wrong.

What went right

1. Clear vision of the game and gameplay styles

I had a clear vision of the game style pretty much from the get go. While initially I toyed with the idea of making the game more oriented towards larger scale wargaming (think BattleLore), I decided relatively quickly that the squad-based approach was much better. This informed the rest of the decisions I made through the process and acted as a guide for the choices in the design.

In the same way, focusing on gameplay design and playtesting from the start helped in getting out of the way early on decisions that seemed good on paper, and which playtested well when you had two people playing on a table, but which made creating a competent AI opponent significantly more complicated (and would have had a direct impact in development). On top of that, the decision to change from full alternate turns to a staggered unit activation brought the gameplay closer to the fast squad feel I was aiming for, validating the approach.

2. A solid foundation

It might seem like a minor thing, but the fact that I had a good codebase from past experiments and personal projects to build on made the initial prototyping and start up significantly faster. This allowed me to experiment with randomized stage generation and testing knowing that the hexgrid code was stable, focusing the initial development on the features that were specific to the game. It would also save a significant amount of time later on, when my focus had to shift more and more from development to production.

3. White-boxing and playtesting

While not something I went over explicitly on the postmortems, a key part of having a well-tested gameplay system was trying everything first with the most basic components – a mostly empty hex stage with red and blue colored boxes representing units, their name floating above them. This approach carried on to the stage creation, when we first created a big white sketch of Yuriy Mazurkin’s concept stage and tested with it before adding any further detail.

4. Learning the ropes of production, setting up an art team

While I had initially underestimated how much production domain knowledge I needed to acquire, the learning process went well and I was able to set up an art pipeline that ran smoothly with relatively little intervention. Once I had learned to recognize red flags on contractors and had found responsible, professional people, the art production mostly ran itself and I was able to focus on development and integration.

5. Narrowing things down

The initial scope was even larger than what we have discussed here, with a high level gameplay revolving around areas of control (which directly affected the resources you had on any skirmish depending on where it took place) and a byzantine plot – clearly a case of blue-skying things. I very quickly mapped out how long this dual-level gameplay and excessive narration was likely to take and chucked it out the window (or more specifically filed it away for a future version, if at all).

Needless to say, this was the right decision – I had my hands more than full throughout the process with what I did decide to do, and had I attempted to do not just the skirmish level gameplay but having to calibrate the area of control decisions as well, the scope would have been beyond what I could have handled myself (and beyond what one should even attempt in such a microscopic team).

6. Leaving visual effects for later

As I discussed on Detail begets Detail, getting great art is one thing, but getting that great art to look right is an entirely different matter. When I first imported the models into Unity and saw the way they looked with the default shaders, I got the impulse of going out and immediately hiring a contractor to work on custom shaders for them.

I quickly came to my senses. Not only weren’t the shaders a blocking issue (there wasn’t a single part of the process that could not proceed without them), but they would be a distraction: I would need to find a contractor, preferably one experienced with Unity, give him some background on the project, collect a list of things to create, evaluate the work, possibly pass notes back to the modelers, and so on.

This would have incurred a double cost: the time it consumed on my end (I was already spread thin enough) and the actual cost of developing the shaders. Considering I ended up freezing the project, the decision to postpone development of a non-fundamental part was the right one.

What went wrong

1. Not dealing with contractor red flags earlier

I’ve gone over this topic extensively on two previous posts, but I should have dealt with the first company I hired for art much more swiftly than I did. There were several obvious red flags, from their assigning untalented plagiarists for the work to disregarding the documentation and references to continual delays and slow progress, which indicated that things would end badly. Had I dealt with these and found new contractors immediately, I would easily have saved a couple months of development time and quite a few headaches.

2. Underestimating the time art production took

Yes, I’ve mentioned this multiple times, but I don’t think I can go over it enough. Jumping into this project without enough domain knowledge of all the moving parts involved in producing a game put me in a situation where even once I had found professional modelers, I was unable to evaluate upfront the time that creating a model with a certain level of detail would take, or what the likely delays on the modeler’s estimates would be (seeing as they had other obligations as well).

Had I had that experience, I could have calculated based on the concepts and proposed detail how long each piece was likely to take, and not only balance my schedule accordingly but estimate if the total length of modeling was something that the project could take.

3. Oooh! Shiny stuff!

I did my own fair share of getting sidetracked into pursuing shiny concepts, such as the procedural stage generation. It could be argued that these were important to the project, seeing as we are a small shop and anything we can procedurally generate could save us a significant amount of time over things that need to be produced manually, but procedural stages weren’t a fixed part of the project charter at the start, just something I wanted to have (and which I discarded later on when I saw Yuriy’s stage concepts).

4. Obsessing over art production

Oh boy. This was a tough one.

Ovidiu and Matei did an excellent job of creating the character models, which made it very difficult for me to see the game afterwards in any detail level except the one they had crafted. As I mentioned on the post: Needing [those models] wasn’t an issue, now that I wanted them.

But you see, that wasn’t the intended level of detail for the models. I had originally envisioned them as something simpler, static, faster to produce. But not heeding Lao Tzu‘s warning, I was not content with what I knew I could produce in a reasonable timeframe, and aimed for what I thought I could get away with. It wasn’t until I took a step back and analyzed how long production was taking (for which I first needed to move a few characters through the pipeline) that I realized that the approach was untenable.

This cannot be said often enough: if you’re running a small team, do not get too tied up on static content. It’ll be the death of you.

5. Getting tied up in story

Again something that we haven’t gone over in detail on any of the postmortems (even if I had one planned with the title Your story sucks – and so does mine), but which permeated the whole project. I’ve always been into world-building, and a big part of what was driving me for the game was the desire to tell the story for these characters. Even once I put the more elaborate plot in the backburner, my mental images of the characters fueled the desire to see the models reflect them, which fed into the obsession with art production.

But it’s not about art production, it’s not about story, and it’s not about those characters you have been carrying around in your head for a while – it’s all about gameplay. That’s what you should be focusing on. If you’re spending time on peripheral concerns before you’re done implementing your gameplay, you’re doing it wrong.

6. Wearing too many hats

But of all of the above, what went really, really wrong in the project was that I was trying to wear too many hats. I was simultaneously:

• Doing client work
• Learning game design
• Working on gameplay and AI implementation
• Learning production and setting up an art pipeline
• Finding contractors and coordinating between them
• Doing world building level design

I was trying to juggle too many knives, and eventually I was going to fumble one and it would end in tears. By the time it looked like I had to dive into production again to set up another art team (or expand on the current one), I was already burned out and had realized that the approach needed some serious re-evaluation.

In conclusion

And after this very long process, what have I learned?

Other than the lessons I mentioned on the various post, I’ve learned that not having completed a game fully produced within Arges yet, I’m still a hobbyist at this whole producing thing. I learned that lesson the day I decided to put Wallachia on ice, so I could switch focus to something simpler first. I’ve learned the ropes as I go, but I’ll be damned if I assume again that I know what I’m talking about until I’m done. And in case there was any doubt, I’ve learned I’m stubborn.

Which brings our current project, and how we’re doing it. More on that soon.