What's in a name, hey?

A name is crucial in deciding how the design document continues and, therefore, the final product. Whilst many people (fairly) argue that a name should be left until the end of a document, I feel it reverberates throughout the design too much to be left out. So long as your name is sound, it will direct the course of the game’s priorities.

For example: Consider the name Formula One Manager. This has a variety of problems. First of all it breaks the golden rule: A product of that name already exists. Aside from the inevitable confusion that causes users, it could also lead to legal problems. Not good.

The very inclusion of the words ‘Formula One’ also pose a problem. The rights to Formula One games are dolled out by the FIA. Without those rights, stating the game as a Formula One product could appear to be in direct contention with the legal rights of whomever has those rights.

Finally, the word ‘Manager’ gives conotations of a management simulation. However, I had already decided by this stage that the game would be less management simulation and more competitive management and tycoon-style investing. Had I stuck with ‘Manager’, I would have created a justification for including things I didn’t want. “It’s called Formula One Manager, therefore I can justify going in-depth into research and development”. That is not a situation one wants to deliberately create in the design process.

Moving on, a name also gives prospective users an insight into the content of a game. A user expecting a hardcore F1 management game might be turned away by the lack of focus on team micromanagement. If the name had been, say, ‘Grand Prix Tycoon’, they would have already known to expect less team micromanagement and more $$$.

So what’s in a name? Legal issues aside, a name is a first impression. It creates a state of mind not just for a potential user but also for the game’s designer.