Now we have some ideas for our game we need to start designing. And diagrams are the tools for that: cheap, quick and flexible. While there are very formal ways of doing such diagrams eg UML the big advantage is that even less-than-rigorous diagrams are still very useful communication tools. Communication and being specific is what it’s all about here. Having to create diagrams has a way of focusing thought, making abstract ideas visible and generally if you can draw your software you can build it. While there are many potential diagrams possible, the attached PDF shows the major ‘things’ in the game and how they relate to each other. It doesn’t really matter if you can’t understand the diagram, another developer could and it’s primary purpose is to structure my thoughts. It documents that a planet will have a population, contain various resources (eg coal) and can have facilities and factories built on it. Alongside this static class diagram will be scribbled notes about how, for instance, a university increases the planets IQ which in turn improves it’s research abilities. There are two points to make here. The ‘things’ are technically called classes and are part of a technique known as object-oriented programming (OOP). The technique is about breaking the real-world problem down into identifiable classes with each class representing a type of item or concept. So we might break a library down into a ‘book’ class, a ‘checkout desk’ class and perhaps a ‘librarian’ class. Each class can than then be thought of individually, designed and code developed. OOP takes a divide-and-conquer approach: there are other techniques with strengths and weaknesses and a good developer is capable of choosing between them. The second point is that in ye-olde days, design was considered a meticulous process with filing cabinets filled with what where effectively blueprints for the software. Nowadays there is a lot more flexibility with concepts such as Agile development all the rage. I’ll write elsewhere about that, but suffice that for this project the design phase is just enough to crystallise some thoughts, isn’t set in stone and will probably be refined as time goes on.

Tech-takeaway

The main purpose of design is to crystallise ideas: don’t rush to code! How much or little to do is moot. When you are no-longer significantly improving your understanding or discovering new problems is a good point to stop. Design and coding is iterative; step-back from coding to reconsider problems as needed. Code when you have sufficient certainty to continue.