There is certainly scope for artistry in the programming of a game engine and its servers, but programming something as complex as an MMO is intrinsically science. Designing what the coders will write, that is largely art-form. But putting together the lines of code that become an inventory system or the loot system … very much science.
Writing computer programmes isn’t just sitting in-front of a screen and banging out the storyline. If you take the novella approach, you’ll end up having to jump through the same hoops writers and editors have to go through to get a book finished – ripping out whole chapters or the entire book to date, writer’s block, chapters that don’t fit your target audience.
Programming comes with a set of associated overheads which you must not avoid unless what you are really doing is playing roulette with your investor’s money. Beware the ides of “later”.
Before the first line of code is written, you should have at least decided what systems your game is going to have, and written specs for as much of each as possible and assigned priorities to them. And they shouldn’t be considered handed-off until the code/module has been delivered and a procedural method for verifying it has been provided — ideally in the form of a script or unit test, something that can be fully or partially automated so that you don’t have to keep going back and re-testing everything with every single patch.
The sooner you start testing code, the more solid it will be by release – more importantly your testing methodologies will mature with the project.
You think that’s going to slow down game development? Then you need to be fired, and probably shot. Anyone who says developing software properly gets in the way needs to be executed. Yes, developing software properly gets in the way of making two steps progress today. Then it saves you your three steps backwards tomorrow. Be wary of these “gets in the way” people – all they want is enough to make the investors believe things have begun rolling and will leave them alone. Sorry – but if you’re going into a project perceiving the investors as a monkey on your back, then you’re yanking someone‘s chain.
If you enter into a development project with good programming discipline and techniques, you’re going to have the ability to gauge your project, to begin planning ahead, estimating delivery time. You’re going to have materials you can use to liaise with investors and potentially get more funding or time from them. The week after they’ve forked out $10m for advertising and shelf space …. not a good time to be asking them for an extension, and to accuse them of pressuring you … deserves a flurry of kicks to the gonads.
Software is, by and large, quantifiable. Like ship-building, there are long stretches where the sum of quantifiables doesn’t add up to something you would want to test for seaworthiness. But if you employ good development discipline, you will be able to see and track progress through check-ins and unit-test development. The actual data you need to gather may not mean anything to you or the people you might show it to, it doesn’t have to. What’s important is “lines of code added, unit tests added, unit tests being passed”. Ideally, your coders will be receiving work orders from a ticket system and will be doing preliminary design as a set of sub-tickets which they task themselves with and turn in as they do their work.
Yes: it means paperwork. Yes: It means time spent doing something other than writing code. But writing good software is not about quantity, its about quality. If your programmers complete and sign off 100 well thought out and executed lines of code a day – 8 hours a day, 5 days a week – your product will be deliverable far, far sooner than letting your coders knock out 2000 “first pass” lines of code 14 hours a day 6 days a week to be tested by someone when its all finished or when there’s “enough” to do a big test.
Putting a long delay between when a coder writes a routine and when he has to debug it is a bad thing. If you want agile, fast development that produces good, reliable code, you need to document and audit upfront. And try not to have Coder A write an animation system in February and Coder C write the animation tool in January of the following year – it doesn’t matter an iota that you won’t be ready to provide animations until June of the second year, you should try and have closely-bound features/components developed by the same people within the same window of time. When a coder writes a system in January, he’s no-longer the same fully-fledged expert in it by June.
And you can never have too many stats about your development. You can drown yourself by trying to use too many of them, especially without understanding them. But you can never have too many – from how many lines of code were added or changed on any given day to how many unit tests exist and how often or when any of them failed.
You can’t generate this stuff later. And if you allow your codebase to be up in the air and intangible, then you are lacking something utterly crucial to the lifeblood of your business: assets. As a software development company, that’s what you should be treating code as.
The code is notthe magical property of the programmers that, with the wave of a wand, will eventually transform into your game. The code is the product that you provided your workers with tools and materials to churn out. It belongs to you and your investors and you should be as protective of it as a South African Diamond mine is of its shinnies.
Will your investors remotely understand you if you present them with information on how many new modules have been checked in or how many unit tests failed and had to be addressed? Maybe not, but you can educate them and you will have a mutual understanding between them and you as to what is happening to their money. More importantly, over the evolution of the project that same mutual understanding will serve as a backbone for two way conversations. The investors – and you – will be in a position to determine attainability of project goals, to make informed decisions about reducing or adding goals, and you will be able to communicate this in relevant and meaningful terms.
That only begins to cover what the right sets of metrics and management of code will do for you. Many of my readers will scratch their heads at this, because you’ve known it for so long you don’t understand why it needs saying. Knowing what’s failed over time lets you know what keeps failing or causing failures.
If the inventory system fails every time someone touches it, then you can surmise that it needs rewriting. Alternatively, you can just let your coders tell you “this is really broken, I’m going to have to rewrite it” and take their word for it. Who are you to argue with them? Well, you couldbe the man with hard cold evidence that projects written off the back of the current inventory system are usually delivered faster and with less non-coding time than other projects. Or you might have data that shows the inventory system generally breaks every 3 or 4 checkins and is clearly a complete nightmare.
Yes, that sounds suspiciously like planning.
Who knew you could do that with computer software?
There is, of course, some art and magic in writing an MMO. But you should focus on getting fundamentals developed first. Players will forgive you that flying mounts don’t quite work where they won’t forgive you that their inventories are unreliable or your network layer is hackable.