Extreme Violence — The done paradox

Why you shouldn’t try and plan too much upfront

I’ve always had a yearning to write games, yet never truly got around to it seriously. I’m aware of Unity as a tool for developing games and have done a few things in 3D many years ago. My university project was “Virtual Weather” using OpenSceneGraph which required a fair chunk of C++. It seems things are a bit easier nowadays and the need to write a 3D engine from scratch is no longer a requirement to quickly getting a game up and running.

When some friends expressed a wish to write a game in Unity, I jumped at it. They’ve got prior experience, we all game together, and its nice spending time with them. From a productivity standpoint it can keep you motivated and accountable as well. Let the game creation begin!

As a complete Unity noob — and as our first project together — we decided to replicate a simple existing game and give it a modern twist. Extreme Violence (by Simon Green) from the Amiga was the game of choice. The mechanic is simple, giving us (primarily myself as one of us has been doing Unity for ALL the years) the opportunity to focus on learning and to discover how we all work together.

“how would we know when we are done with Extreme Violence?”

We picked a small game to get our learns before we felt comfortable as a group moving onto bigger and greater projects. Looking at it from a project perspective, how would we know when we are done with Extreme Violence?

Initially our guiding light for project choice was simplicity, something that could be done in 50 or so hours each. I wasn’t and still am not sure how much Unity development can be accomplished in 50 hours, but with a few hours under my belt now it seems like a “fair chunk”.

To recap from a stakeholder perspective:

• Time boxing to 50 hours
• Should be able to get a “fair chunk” of stuff done
• Remake Extreme Violence with more stuff

Because this isn’t a formal project and we’re working in our free time, this was enough for us all to crack on. We vaguely tended towards our own areas of interest, setup a project in GitHub and started to work.

Mentally I shifted my focus from the Portfolio level to the details of Unity. My task was the “Player” and I heavily bore in mind the famous Agile drawing by Henrik Kniberg:

Splitting my work into easily digestible chunks I did the following:

1. Put an object on the screen
2. Changed its colour
3. Implemented Keyboard controls
4. Got the object to face the way it was moving
5. Had the camera track the object

In my mind, I’ve still got a plan on how I can carry on iterating until we’re done.

I felt I was making progress and learning a lot, while one friend worked on multiplayer and the other worked on the level design.

With my head well and truly in implementation mode, I fielded some questions:

Friend: “What will our max players be?”

Me with my delivery hat on: “No limit, the point at which things fall over”

—

Friend: “Will arenas have a max time limit?”

Me with my delivery hat on: “No”

—

Friend: “We going with 10 levels?”

Me with my delivery hat on: “Happy to stick with 1 to start off with (the original game had 10)”

Friend: “So 1 level or 10? Just so I know for coding as changing further down the line will be a pain*?”

Me with my delivery hat on: “You’ll love this answer, I think 1 to start with, then rework for 10 if we want to. I don’t know exactly how much of a pain* it will be, but in general I’m comfortable with some rework, it’ll help with learning.”

Friend: “lol, right, I’ll code based on 10 levels and then we don’t need to advance past level 1 if we don’t want too”

*we may not have used the word pain

Now here I can feel some friction because we’re both approaching the work from different angles. I’ve got my Agile delivery hat on, while my friend is looking for answers to the overall project scope. It’s very reasonable to consider which constraints we should be working towards for overall project success. Especially if re-work is required. Here, my friend is trying to constrain by project scope. Ideally, we want to build things in an extensible way, which was where my friends pragmatic solution headed.

So why did I give such an open-ended non-committed answer? With Agile software development responding to change is preferred to following a plan. What I was failing to remember is that can be important to have some plan! How defined should our plan to be extract maximum value from the project though?

It was stated at the beginning that the game will probably morph away from a simple clone. This morphing could be directed by our learning, feedback from each other, parts that we have a particular interest in — the reasons for change go on and on. The net result is these reasons may cause us to add or remove features.

For this game, what we’re missing is our success criteria. It could range from:

1. 50 hours development done each
2. Completed version of the game
3. Completed version of the game with extra bits
4. Learning Unity
5. Learning the process of making a game
6. Exploring and iterating our completed game
7. To make games with my friends

Honestly, I’d say that all of these provide value and constrain the project in different ways. The tricky part is at what point we will have stopped deriving our maximum value and realise that it is time to bring things to a close? To pack up shop and start on our next game? Prince 2 says that every project should have a clear end.

We may at this stage have 100s of predefined levels or we may still only have the one but it could be randomly generated.

You may say that this is fine for a hobby project but that it certainly wouldn’t fly for an enterprise organisation. It primarily depends on the project and what you’re trying to achieve. Exactly where does the value lie?

If you’re a service agency providing bespoke software or systems for a client, then you’ll be governed by what features they require. The value is delivering what they want and is clearly defined. (assuming the client know what they need and are measuring success of course). Here the end date is more predictable.

If you’re working on product development, then the value and success could be defined by happy customers, or usage or features. Here the future is far less certain and plan more likely to change.

A common mistake I see often is that run-rate teams are terminated early, because the project has run its course. On many of these projects is clear that the maximum value hasn’t yet been reached. The implementation has been rushed to hit a specific date and customers are left with a bit of a mess, which with further refinement and feedback could be leveraged to provide the value with which the project was originally envisioned.

Going back to Extreme Violence, it’s clear that the true value is something which we’re giving to ourselves. We should stop the project and start on the next game when we’re on the downward slope on that value curve.

It’s easier to manage by defining features, we all agreed very quickly that we wanted to make a complete game end-to-end as there’s a lot of learns to creating the game UI, levels and sound etc. But after that point is where our true innovation will start, and for myself that may be the start where we start to reap our maximum value. Experimenting with new gameplay mechanics when we have a solid foundation.

If I’m honest, I probably shouldn’t have worked on changing the colour of the player when I did. I just wanted to because it was a fun thing to do.

But that is how innovation can occur

By giving myself the freedom to play around the edges, it satisfied my curiosity and gave me a lot of value. In fact that simple “off piste” act gave me exactly the type of value that I wanted from the project. To make games with my friends.

Which bring us back to the paradox, that why we shouldn’t try and plan too much upfront. We have our overriding goals to guide us and if we’re all getting value from the project then happy days. Most importantly, is to keep up our communication. Our strategy is not fully decided. We want to make games, we’re currently making our first game to get learns, but what is our overriding vision? What is our mission statement?

I’ll present this article to my friends and see what they think!