ONE GOOD RULE in life is ‘never boast about anything until you have seen it through’. And the other pearl of wisdom you tend to hear is ‘things are always more difficult than they look’.
Taking the first rule, I think we can safely say there have been many companies who, in retrospect, would have done well to take heed of it. You don’t have to look too far for examples of games which demonstrated this rule; here are a few of the notables: Sherlock, The Great Space Race, Swords and Sorcery, and, of course, Psyclapse and Bandersnatch. Big things were expected of these games, not because of previews generating interest but on account of rather large advertising campaigns. Their high public profiles suggested that an enormous expenditure on hype could only possibly indicate a similar expenditure in time and effort on the program itself. Which leads me on to the second rule...
Things are always more difficult than they look — but in the case of programming, things become nigh-on impossible. Take the balance between speed and length. The number of moving graphics will determine how quickly a game will play: too many moving graphics and all will be reduced to a snail’s pace. If the graphics are stored in a compact form then the code to decipher them may well slow the game appreciably. The length of code becomes critical if the graphics are stored in the form to be displayed on screen, as a vast amount of memory is required.
It is difficult to know how this balance between speed and memory will work out until the project is well under way. Indeed, it may only be at this later stage when it is discovered the whole programming project was too ambitious in the first place. This problem besets all programmers but will affect those who work on orders from above to a greater extent.
Every software house worth its free publicity has a whole menagerie of Managing Directors, Marketing Managers, Public Relations Officers, Secretaries, Graphic Artists, Games Designers, Cover Artists and someone to make the tea (teaperson). This is a considerable number of people — even if the ‘s’ signifies at the very most two people with each job title, and there is much overlapping of roles, eg a Marketing Manager may make the tea, while Public Relations ensure each cup has the correct amount of sugar in it.
The problem is that the orders from above can come down so thick and fast, that they soon form a heavy overburden which begins to exert a significant pressure on the poor guy at the bottom — who is none other than our poor little programmer, struggling with the implications of our second rule. He may be having difficulty implementing some big idea from above, perhaps a film/TV/superstar endorsement, and and be desperate to get the game finished knowing how much the software house paid to secure the rights.
Don’t get me wrong. The marketing, graphic and design skills are a very important part of the new mega-game blockbuster. All I am saying is spare some resources for the people actually programming — it may well pay off.