Converting ideas into software starts with analysis of the situation and creating a specification, which is a detailed list of what the proposed software should do and achieve. Analysis and writing specifications and how detailed they should be is a major topic in it’s own right with it’s own specialist practitioners. It’s frequently the case that the intended users may be experts in their field but hopeless at explaining exactly what they do and how they do it, users may have conflicting requirements, and this all needs to be staffed and paid for. There can be a lot of people and political skill required at this stage.

Modern techniques (e.g. “agile”) often use story-telling to encourage users to describe their current practices or what they would like them to be and these form the basis of the specification. Older techniques (e.g. “waterfall”, SSADM) would try to systematically document the complete task, identify every requirement in detail before proceeding. The downside is you never get 100% coverage and users change their minds during the development anyway! The process could take so long and business needs have changed so much that the project is obsoleted even as it starts.

For many projects there should be a step even before creating the specification and that’s defining the project itself. This isn’t specific to software, any serious project should start by answering some basic questions around aims, risks, costs, timescales, who the customer is, who is in charge etc, etc. This appraisal really isn’t a big thing and shouldn’t take long even for big stuff. We can make it more formal and part of a methodology (eg Volere) or not. As the Roman politician Seneca said “If a man does not know to what port he is steering, no wind is favourable to him.” [3] This is all about being clear about what port you are sailing to and putting it in writing, but it’s surprising how many companies miss this step. They all rue it.

Since this is a project for my own needs and is a game (and can thus be flexible it what ‘problem’ it is solving), there isn’t a need to create much in the way of preliminary design. But it is good to try - the process helps clarify thoughts and ideas. It also forces a narrowing down of possibilities to the reasonable playable minimum. Fancy gameplay options can come later.

The next post in this series points to the actual game design documents where that is done, but simply put Zodiac Empire is going to be a ‘4X’ space empire game [1]. Manage your planetary resources to build space ships. Defeat other factions to capture their planets and resources, continuing until you win (or lose). This quite deliberately isn’t a ground-breaking concept, but there is still plenty of challenge from the coding aspect [2]. There should also be some interesting gameplay features to make the game distinctive.

[1] 4X = explore, expand, exploit, exterminate - wikipedia

[2] completing, timescale, visual and artwork quality, performance considerations, 3D computer graphics…

[3]