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
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?"
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.