New Patch on Old Garments?
Two rather popular games (the franchises being very popular), Oblivion and Heroes 5 just had their first patches released.
I’ve been reading with interest the Ubisoft forums (the publishers of Heroes, Nival being the Developer), in the weeks since it was released.
Heroes 2 was the very first game I bought with my own money. $90 being the amount of money from a relative for my 21st birthday, if I recall correctly.
I’ve invested a lot of time into these games, 2, 3, 4, and now 5.
But that’s not what I’m rambling about today. It’s just building some kind of foundation.
It’s very informative to watch how both the Users and the Developers react to each other. The patch hasn’t been out for 24 hours yet, and already there are some people very annoyed on the forums. There are also people very thankful. And so far, the Developers haven’t said a word in reply. Which is good I think.
There are differences between the products we make and these. For one thing, we don’t make games (ohhhh man, what a dream life .. ha ha ha). But we still create software that will get into the hands of the User. They will still experience our creation, and most probably will have something to say about it.
To the patch.
With both games and business applications (and general applications, everything lumped in there), you would have to work hard at deciding what went into the first patch. If, that is, a patch was needed.
In my simple understanding, a patch has two distinct purposes. It has the ability to Fix Bugs, and Introduce New Bugs, ahem, I mean Add New Functionality.
As in the case of Heroes 5, deadlines being what they were, the wheels of commercial success driving onwards, you are going to release a buggy product. Buggy, and lacking in a full feature-set.
What do you put into your first patch?
I imagine it goes something like this ..
The Patch Discussion, Scene 1, Act 1
Head-Honcho, Non-Developer, Parent Publishing Company
- “Get the patch done.”
Developer, Guy Who Started In The Biz With Wonderful Dreams, Currently Crushed In Spirit
- “Okay.”
Gets the Development Team together.
Some are missing, presumed to have left the state, seeking actual life outside of the desk/chair scenario they’ve experienced for the last 2 years.
The rest are present, in body. Some have their eyes closed, Sleeping. Some, the lucky few, have their eyes open, Sleeping.
- “Okay team. We planned for this. We know what didn’t go in. We know what is going wrong.”
This last statement is partially correct. The rabid user-fan-base of a community ferreted out at untold number of bugs and missing features.
- “We have to decide what goes into the first patch.”
There are groans from the crowd/team.
A developer, who had recently lost a great deal of weight, having not eaten in 40 days, falls to the floor. He curls into a foetal position, puts his right thumb into his mouth, and starts cooing.
The Head Developer strives to ignore this, as two large men with White Coats (and Blue Hands, ha ha) appear to take the stricken Developer away.
- “I’ve put out some of the fires. The situation is as follows.”
- “We don’t have to worry about Feature #1 (eg, the Map Editor) or Feature #2 (eg, the Random Map Generator) for a while.”
There are a few feeble attempts at joy, a girl claps, and one fellow makes some kind of sound that possibly was a joyous shout of rapture. That, or a death-rattle.
- “Apart from that though, we’re in the crapper. Any ideas?”
Silence
Finis
It is never easy. This is the time when the dreams of creating something amazing would be tested. The long haul. The great ideas have already gone into the software, or they’ve been discarded by the roadside. And for those that build their dreams on these ideas, without factoring in reality, this would be a very hard learning curve.
I guess that’s why a lot of development never finishes. You don’t go in prepared. You can’t think on your feet. You don’t listen when people say it’s gonna get really, really, hard.
So I’m determined to understand that, in development, things will most definately get harder, before they get better. Or, that you can make things better, but it takes a lot of hard work.
To be ready.
In terms of “Feature #1 (eg, the Map Editor) or Feature #2 (eg, the Random Map Generator)” some times these are built early on in the project when creating development tools for the content providing part of the game dev team.
Modding. Another thing that is done now is let the community build your content for you for free, by providing them a reasonable editing suite - often a variation on the ones built for the actual development of the game. A decent plug in system is needed.
But yeah the old patch issue, buggy releases etc. The initial release still has to be a certain quality however, or it gets totally panned in the press and on the web. So it is not that there is no floor - it is just set lower.
Bugfix or new feature, there does seem to be an increasing habit of back loading some “optional features” into the patch schedule. Is this where property version numbers help - 1.05.023 (major version 1, feature patch version 5, bugfix patch 23? Probably to meet Christmas release deadlines etc but there is again a floor (minimum) in what can be done here, there are lots of games released, and one needs to grab the mainstream attention to have a big financial success - so the game still needs to be pretty damn good.
But what lesson for us as developers? Well in patching, modding and plugin technology. Plenty of examples in the field of different approaches to these problems put into action in designing our own auto-patch system etc.
–
CodeMonkey Blog
Comment by Adam — June 10, 2006 @ 7:39 am