A work process, Part #1 of I don't know

Hello there,

So today, I want to talk about workflow and processes.

Path of Destruction was developped quickly. Once I had the core gameplay validated (by myself), most of the game was created in 2 months.

Compared to Drakonis (my previous game), that took me 7 months for a simple demo, creating a commercial game with 110 levels in less than two months seems improbable.

What happened in between?

Well, as a good human, I learned from my mistakes and consciously or not, I came up with rules and warning signs to avoid "wasting time", "dead ends" and "procrastination".

Today, I want to talk about my rules.

My rule #1: Make poterns

The story goes that an art teacher divided his class in two. One half had to make the perfect potern. The other half had to make as many poterns as possible.
By the end of the experiment, the most beautiful potern was one made by the "do as many as possible" team.

You don't gain much experience by thinking.

Path of Destruction was created with this idea in mind from the start: I have the core gameplay, I give myself 2 months to make, by myself, a full commercial game with 110 levels.

It will not be perfect but it will exist.

And yes, I had ideas of things to improve, to add, to correct, to remove. I could have made a complete different game had I not discipline myself to look at the calendar and force myself to accept an imperfect result.

I kept these rejected ideas for a sequel if I ever had the opportunity to do one.

My rule #2: Set the deadline and stick to it

Making prototypes and being in production are 2 differents things.
I'm talking about production here.

Once production starts, every decisions is based on "can I miss the deadline because of this?". All risks and decisions are taken accordingly.

I don't do crunch time by the way.

For PoD, I worked a decent amount of hours every week (50-55 hours I think) but I slept 7 hours and worked regularly from morning to evening, from monday to saturday (included). It may have helped that I don't go out much.

It's always hard to evaluate the overall time it will take. Experience helps. iterating the content of the game can help too. And if I realise midway (or before) that I have underestimated (unfortunately overestimation happens less) everything, it's important to take the time to reassess the situation and set a new realistic and challenging (to keep tihings interesting) deadline.

"When it's done" or "When I am satisfied" are not deadlines. They are recipe for failure. I set a day on the calendar. I might miss it by a few days. But not by a few months.

My rule #3: One brick at a time

As the sole dev/game designer/creator on my games, I need to have "reasonnable" ambitions. Drakonis was a key lesson. I had great plans, I knew I could take on Platinum's Scalebound! I ended up with a simple demo which is far from the fun game I had in mind. I'm not ashamed though: the demo exists and it's not a bad game. It's just unfinished.

So for Path of Destruction, I tackled the task with muy muy humility.

I'll write an article of the new combat mode of Path of Destruction 2 later, but to sum things up, when it was time in the dev process to make the combat mode evolve, I contemplated a game flow that would probably have been great.

BUT it was just too long to test and to dev. Even if I could have prototyped it, it would have taken much more time to fine tune and complete visualy than the one I decided to validate in the end.

The idea was good, it was just too big for now. I keep it for an hypothetical PoD 3, but I'm convinced that it was too ambitious for a sequel that has enough evolutions and new features compared to PoD1.

To sum things up: if this wall works, I'll build a stronger, bigger one AFTER. But first, I need to make sure this one doesn't collapse.

My rule #4: Scrum your game

Or, in a more general term, "organize your work" (general terms are very helpful, aren't they?)

I can't start the day without a clear list of things that need to be completed by the end of the week. If I just have a huge backlog in which I pick a task depending on my mood, I will :
- waste time searching for a task
- pick a task unrelated to the priorities
- the task might be unclear as it was not planned ahead
This will end up costing time for something I may end up throwing away 2 days (hours?) later.
And you can sometime do that several times in a single day!

So, on Saturday (or monday morning), I sit down and determine the general feature of the coming week, something like "score", "combat", "gui", "path control", "InApp Purchase"...

Then, I review the big backlog I have and start picking (or creating) scrum "stories". I start by picking the mandatory stories for the feature (for GUI, I had to: 1/ buy a GUI in the assets store, 2/ implement menu results, 3/ implement buttons with new graph, etc).

The time for each story is evaluated. Usually there is still some time for stories outside the scope of the feature. So, to pick these stories in the backlog, here are my criteria:
- what are the chances that I will keep this story in the end? If it's less than 80% chance, the story stays in the backlog until I have a better idea as to how it fits in the game.
- is it important: priority factor
- will it improve the game or is it just cosmetic details: moral factor (the better the game, the better the moral)
- will it be fun to do: pleasure factor (very important)
- will it solve several problems at once: time factor

And then, by the afternoon, I have my TODO list for the week.

My rule #5: Iterate

This is SCRUM 101, I know, but I want to insist.

Let's say I work on a new combat system for PoD2. It's very important to have a rough idea of how it plays on the phone, so I forget about graphics and particles and visual effects. All of this will come in later Scrum sprints.

I know that sometimes, visual cookies are very important to the gameplay. In that case, I simulate them with quick and more-or-less dirty animations that will be replaced later IF the feature stays as it is. And when you prototype, the feature will surely evolve in an unpredicted directions.

The other day I thought "it'd be nice to have a sound when the dragon reaches the exit point". Instead of spending hours looking for the perfect sound I took a "good enough" one. After 2 minutes of tests, I knew the idea was bad and removed it. It just didn't work and it had nothing to do with the type of sound.

Same goes for gameplay features. If it's boring, adding particles and fx is just a way to hide something weak. When I created my first proto of PoD (picture above), the dragon and soldiers were simple rectangle. Later, they became mesh but without any animations. And so on.

My rule #6: The perimeter is set

I never, ever add a big feature once dev has started and especially not toward the end when everything is almost ready for production.

This is the hardest rule of them all because, as creative individual, we have tons of "great" ideas that could make things so, so much better!

When I start production, I know what the game will feature. If you take Path of Destruction, the only thing I added mid-production was the "share on Facebook" button. I added it because it did not impact the core of the game and I found a tutorial that explained it in 5 minutes in Unity. The risks were limited, acceptable and easy to remove in case of problem.

However, I hesitated to add an RPG component to the game too: experience would have allow you to change the size of the explosion of fireball, etc. I'll never know if it'd have worked in PoD 1 because it was not in the original design and never made it in the final game...

That's it for this first part of my workflow.

Thank you for reading!

Arnaud