01 Dec Goals and Milestones
Goals & Milestones
We have about 3 working weeks left this side of 2014 so it was a good time to set some goals for the team to achieve. This got me thinking about milestones and the purpose they serve in development.
What is a Milestone?
A publisher usually advances money to a developer as long as the milestones are satisfactorily achieved. As long as the developer is hitting their milestones, progress is deemed on-track, the developer gets paid and all is well. As far as I can tell, all developer-publisher relationships work this way.
In a typical publisher/developer relationship, milestones are the backbone of development progress. When you sign a deal with a publisher, a milestone schedule is drawn up and this becomes a contractual obligation.
Milestones are typically 4 or 6 weeks apart and have specific goals to hit. For example a typical milestone may say something like this:
Milestone 5: Interim (Pre-Production) – 8th November 2011
- Character A In Game Model & Texture
- Character B High Res model
- Character C Cage Model (& base rig)
- Ranged Enemy Base Cage Model (& base rig)
- Melee Enemy Concept
- Melee Enemy Base Model (& base rig)
- Warehouse level grey box level
- Caves 1st pass playable
- Updated Risk Log
- Updated Project Development Schedule
- Updated Game Design Document (including change log)
- Technical Design Document (including change log)
- Updated Design Workflow document (to include timescales)
- Full Game: Story Mission Breakdown (progression of story synopsis to include individual missions)
- Updated Story Treatment (Story Beats iteration)
- 1st pass Vertical Slice script
Demonstrable in Engine (Console / Networked)
- Traversal mechanics 1st Pass including:
- Wall (run up and grab)
- Drop down to Ledge
- Low Cover Vault
- High Cover Vault
- 1st pass Vertical Slice mission setup (Phase B – Geometry Blockout)
- 1st pass AI Enemy Behaviours: Patrol, Cover, Alarm, Investigate, Distract
If you find the above milestone list a little cryptic or uninspiring, you are not alone. There are reasons behind this.
THE MONTHLY MILLSTONE?
There are a few problems with milestones. The first problem is that the milestones for a game have to be fully fleshed out before a contract can be signed. So you have to know two years in advance, what the contents of your game deliverables are going to be month-by-month.
The Nostradamus Issue
Unless you are making a clearly defined sequel to a sports game where the only variable is the team roster, you would need Nostradamus-levels of insight to come up with a sensible milestone plan. So inevitably you have to do your best, stay as high level as possible in the descriptions of the milestone and agree to adjust the definitions along the way with the publisher’s consent.
The Contractual Issue
So that’s workable right? Clearly yes, as most games are made this way. However, once you have the list of milestones agreed and in the contract, changing them requires quite a bit of discussion and amendment to the contract. Major changes raise alarm bells so everyone agrees that we should only change milestones under exceptional circumstances as it could lead to loss of trust or breaches of contract in extreme cases.
The Ambition Problem
So devs end up defining milestones that offer flexibility for development without putting contracts at risk. Inevitably, the goals of each milestone become unambitious. You can get around that by setting your own internal milestones that are far more ambitious than the contractual ones but it can be a confusing thing for the team members to work to. And really you have to ask yourself why you are having to bypass a system that is supposed to help you, not hinder you.
The Tunnel Vision Problem
So you have a list of items that cover modelling, animation, texturing, be it a character model or level layout. Team members check off their work against the milestone definition and the build goes out with everything done.
The problem is that your character, vehicle or level is bland. Yes all aspects of it are technically done but it doesn’t mean it is any good. And while you may want to revisit it, everyone on the team has to move onto the next milestone items because that is what the contract says we should be working on. And so it goes on.
The Predictability Bias
These issues bias production towards being predictable and safe. To make milestones work, they have to be conservative and predictable which means the game design has to be predictable and achievable. If you are wondering why so many games seem to be facsimiles of others, this is one of the major reasons.
Everyone I know of in development is creating games because they have a love of games. The thrill of development comes not from knowing all the answers up front but from discovering them through a mix of creative thinking, science and craft. Strip that out, and development becomes a grinding millstone and no one wants that.
The Threat of Mediocrity
You may hit all of your milestones, deliver the game on time and on budget and feel like everything is sailing smoothly. But the ultimate judge and jury are the players and the critics and they have no investment in the process, contracts or milestones. They will gladly rip you a new one if your game is not up to par. You might have appeased your publisher’s lawyer and accountant along the way but you’ve just delivered a soul-less game and everyone knows it.
Your best and most ambitious people know it and start looking elsewhere, your publisher knows it and walks away, your customers know it and avoid your games, and your critics ignore your games next time around. In that context, the importance that you placed on hitting your milestones is little consolation and rightly so.
Now as a developer you do not control nearly as much as players and critics assume you do. You have to work within the constraints you have: budget, timeframes, and resources being the obvious ones. But you also have to respond to all creative input and changes of directions from the publisher, deal with milestone definitions that can sometimes work against you and you have no control over marketing strategy and budgets. The market is littered with games and developers that are highly rated, widely loved but sank into obscurity.
There is no silver bullet, no fairytale ending, but you can improve your chances of survival and success by making the very best game experiences you can and driving this are the values that you hold as an individual and those that you nurture in your company.
WHAT MATTERS MOST?
Your Team’s Values
We don’t have a nice neat alternative to the milestone millstone but we do always protect our values as a company and these come above everything else we do.
There was a point in our past where we were in serious trouble as a company and there was a very real chance we would stop trading. It was at this point that the values that we strived for were tested fully and we came through, bruised and battered, but ultimately stronger than before.
These aren’t values that are written down in a manifesto. They are held by us and spread through example and reinforced by more experienced team members. Perhaps they should be written down but I think they come across pretty well in our dev-diaries.
So for me there is no doubt that the values we hold inform everything we do and how we do it. On occasion this causes friction with publisher as we end up working against or outside of the milestones process but it always comes from a good place.
On AAA publisher projects, most developers hate doing demos for events like E3. It puts your comfortable milestone grind at risk as you now have to do something that is intangible: you have to make it fun and amazing.
Making something fun and exciting often means tearing up the carefully laid plans to focus on the user experience. So while the perception is that making demos takes development off track, you can argue that it actually focuses development on what really matters.
That intangible goal of making it “fun”, “thrilling”, “exciting” has such a powerful draw on the team and the game so why do we eschews such goals for milestone checklists that must be completed or else….?
Stating Goals for Hellblade
On Hellblade, we don’t have a publisher so the attitude is different. When we set goals, we set goals we think is just about achievable but ambitious enough for us to think we may miss it.
A goal has to be ambitious because it will help make a better game. If we miss a goal, we don’t worry about not getting paid. There is no publisher there to pay us so it has to be about what we want to achieve.
No one gets punished for failing their goals so there is no threat. We want to build a team where you are rewarded for ambition and excellence, even if that includes failure along the way.
So when I set the goals, I’m setting expectations from an experiential point of view and I will work with the team to hit them. They are goals, guidance and notes to strive for and not binary checklist of items.
I’ve set goals for all areas of the game but here I will share our Christmas goals for combat:
Combat Movement Feeling Good
Default combat poses and locking on and moving around enemy feeling good where all combat moves, evades, blocks etc respect these poses. All hero movement around an enemy should support combat stance, blocking, charging etc, and preferably working with partial animations to reduce animation work and complexity.
One Satisfying Combo
Hitting a static enemy with a combo should be responsive and satisfying. Animation for attacks and reactions should be kick-ass. Sound, Visual, Camera Rumble effects are placeholder but give good feedback. There should be scope for the player to experiment with cancelling techniques.
Core Combat Loop Playable
The core combat functionality playable, tactical and fun between Senua and a copy of Senua (Evil Senua). We can use split screen, dual pad functionality to simulate an advanced AI and it should be compelling to play in this manner. To get a rounded combat loop, we will need to implement all core attacks, blocks, evades, and experiment with additional input methods (dual buttons, hold button, stick+button) to create new attacks.
Hellblade is proving to be a testing ground for a great many ideas for us and genuinely a chance to try out different ways of working outside of what is considered convention. I feel that goals such as these places more trust in the team to make things that we can be proud of rather than the conventional milestones that come from a very different place.
Till next time