How have you all been?
We’ve gone super quiet at the moment and I promise it’s not us running away and hiding it’s just been a case of getting Overruled!’s console versions finished up. We sent over the build to T17 last night which is hopefully signed off this morning to go into cert. Which is terrifying by the way!
Assuming everything goes well then we should be able to announce an official release date soon. It took longer than any of us could have anticipated, or predicted for that matter. We’re super aware that we haven’t updated the content to the live Steam build in a couple of months but I assure you there will be a nice new content drop come out when we fully launch.
Now for something super exciting, saw a tweet from our PR rep Beth that we’ve actually been named a “Must-Play Game for 2015″ by Official Xbox Magazine.
This is completely mental, was not expecting that at all. We love Overruled! but, as many devs will no doubt agree, it becomes very hard to separate yourself from the game towards the end of a dev cycle. You are no longer being creative and making new awesome things appear, you are plugging in platform specific features and discovering how different those platforms really are from each other and worst of all you are fixing bugs. Now most of us here have shipped a game before so we’re use to the cycle, but for those of you that aren’t. You very often end up in a situation where you are so anxious to get the game out that you fix a bug and then accidentally cause some more, or what happened more for us is that we would fix a bug and there would be another edge-case bug hiding behind it. It happens on every game though. This is the reason QA teams exist. You don’t always spot bugs as you are writing games. It’s like those word “tests” you get online where the words and/or letters are switched round but you still read the sentence perfectly. When you build/create something you know what you want it to do and then you make it. Thing is if it does very close to what you wanted it to, more often than not, your head will fill in the blanks. It’s not until someone separate from the project has a look, someone not close to the creation process, and they go “Hey do you realise that this guys head is actually attached to his ass”, ok not a great example but you get what I mean….right?
It does remind me of a funny story from my-so-called career. Back when Craig and I were devs I once had a producer tell me that we shouldn’t have bugs on a new feature for a live product and that the upcoming game from another team within the same studio would, and I quote, “have no bugs at launch”.
This was hilarious to me.
I mean firstly it was very much the typical situation:
**Month back in time – it’s project planning time**
Producer: How long is feature X going to take?
Aj/Craig: Well it’s hard to judge as it’s an unknown, looking at it it’s probably going to take about Y amount of time.
Producer: We need it in Y – 2 weeks.
Aj/Craig: Umm we just said that it’s going to take Y.
Producer: Yep, but we need it before then.
Aj/Craig: Can you see the problem here?
Producer: Needs to get done, Marketing want it out then.
Don’t even get me started on how backwards the developer to marketing relationship was. But this was the start of another horrible, pointless crunch period. Sleeping under the desk on a bean bag and Craig and I working all hours of the day with no breaks. This method of development is not going to lead to a clean, perfect product. To be honest no method of development will ever lead to perfect.
The second reason this was so funny is simple:
All games/software has bugs at launch.
You cannot find every bug in a game and you cannot anticipate how your players are going to play the game. This is why we have QA teams who do strange things to games. When you first witness this it’s often the first reaction to go “Why the hell are you spinning on the spot 10 times and then jumping off two ledges into a pot of jello”, then suddenly the game blows up and you go “Shut the front door, that’s mental”. Players do things like this, you know how I know that? Because I am a game player and I have played games with other people. We’re always looking for glitches and bugs, it’s just part and parcel of it. Sometimes it’s hilarious (Tony Hawks Pro Skater infinite spin bugs) and sometimes it’s not so hilarious (unnamed recently released title where I had a door I needed to go through but the door hadn’t loaded”). But players will find bugs. Devs are not perfect, QA are not perfect and management (speaking now as a ‘manager’) definitely aren’t bloody perfect.
So how do we solve this problem of imperfection? Simple. We don’t.
We acknowledge it, we embrace it and we prepare the best we can:
Don’t take all the assets off at the end of a project so that we can get that new project kicked off. Hell why not bring on some extra assets to help with fire-fighting.
Don’t set stupid unobtainable deadlines. We’ve seen first hand in the not-so distant past that some ‘managers’ still use the technique of “well deadline is on July 1st but we’re actually going to tell the devs it’s March 31st so that they crunch and get it all done with time for errors”. Umm. HELLO. ARE YOU DAMAGED? How is this good? If you’re deadline is July 1st tell your team that is the deadline, but hey maybe say to them “look guys we have to deliver this on July 1st, it would be awesome if we could aim to get it done before then so that we can get some extra testing on it and we don’t have that last minute rush.” Or hell why not take it a step further, sit down, talk to the team and figure out how much you can get done in that time before you commit. That’s not to say that the time estimate will be right. You have a few things to take into account when you ask this questions:
- Time costing is guess work. Doesn’t matter how experienced you are it’s guess work. Sometimes a 2 day task turns out to be an hour. Sometimes a one day task turns out to be 2 months.
- Know your audience. Are there team members who are looking to impress you? If so is there a chance you’ve give them the feeling that getting stuff done quickly impresses you? This can be deadly for a project and for a team’s morale.
- Shit you don’t expect to happen will happen. You’ll forget that your lead tech has a two week holiday booked right in the middle of that development period, your designer will break his leg and need time off for physio. The unexpected will happen.
Let me give you guys an example of how we did some bad time costing, luckily for us it was in a time where it didn’t damage us too badly:
When Craig and I sat down and started designing Janksy we were feeling very confident. We were confident because we’d just started our own studio, we’d just made a great agreement for some marketing with Microsoft and we’d just found a killer dev in the Crickett himself Chris. So we started designing some levels, then we had the discussion “ok how many of these can we get done for launch.” Now Aj now knows better, Aj now knows that you always under-commit and over deliver. Aj back in 2012 didn’t. So the discussion basically ended up with Aj and Craig going “100 levels at launch EASY!”. It wasn’t easy we didn’t do it, hell even after all the extra packs I don’t think Janksy has 100 levels. Now if MS had been paying us to make the game, we had committed to 100 levels and attached a deliverable milestone to it. We would not be getting paid. Luckily for us the only people not paying us at that point was us.
Ok, so this turned from a quick update into me preaching from the school of “life is so hard”!
I’ll leave you guys be. Maybe I’ll randomly popup with some more stories soon. Definitely should tell some “why blame doesn’t work” stories!