FEDERATION 2 DESIGNER'S NOTES
by Alan Lenton
18 December 2003
Well that's the player record sorted out - at least the data part of it.
I decided to keep the same four stats as in Fed1 - strength, stamina, dexterity, and intelligence. Since Fed2 has more opportunity for puzzles, I considered adding hit points, but eventually decided against them. I think the stamina will do as an adequate surrogate.
Fed1 stores the details of player's factories in the player record, but I think I'm going to make the factories part of the planet they are on, and do the same with warehouses. In effect they are part of the planet not the player.
One of the problems with program design for games is that once you have a player class it (and to a lesser extent the map class) tends to grow like topsy. This stems from the fact that, in a game, virtually everything that happens involves players in one way or another and the natural tendency is to put the action into the player class.
If you are not careful the file containing the player class can grow to be bigger than all the other files put together! Memo to self - where possible put things in classes other than the player class.
I've decided to add another attribute to players for this version - 'race'. It's something that players have asked for in the past, and our players are inventive enough to use it. I just hope that it doesn't result in an outbreak of Celtic Elf Princesses. I resisted the temptation to change all such occurrences to 'dork'.
To go with that we need to add a 'neuter' gender. Sooner or later we are bound to get the neuter member of an Altairian bonded triplet wanting to play...
For the time being the comm unit can be represented as a bit flag, in the long run it will be a C++ class of its own handling all the in-game communications, including the ignore facility, which I plan to add later on.
The player record comes in two versions, the disk store version and the in-memory version. I've added a spare 512 bytes to the disk version to give me some space to add things I don't yet know I need.
My programming friends will be shaking their heads. You are supposed to design programs (and games, if it comes to that) before you start coding them. That's true, but for me inspiration doesn't all strike at once - it develops over time and with lots of coaxing. You can only design things if you know what you want. Incidentally, I don't recommend anyone else tries developing games that way. It happens to work for me, but the number of other people I know who can do it, I can count of the fingers of one hand.
In the original Fed1 I just had a single player record for disk and in-memory. Well at the time I was learning, and there wasn't anyone around to tell me how to do it - everyone else in the company (Compunet) was programming in Fortran IV and I was learning 'C'. Later on I realised that I was saving a lot of temporary stuff to disk - like the socket number the player was using for the current session. I also realised that I could keep the different attributes in alternative, more convenient formats if I had two different records, each optimised for the medium in which they are used.
To give the more technically inclined an idea of what I mean, Fed2 holds the player name as a C++ string in memory, but as a C-style char array on disk. It doesn't bother to save any of the temporary bit flags to disk, because they aren't relevant across sessions. It holds permanent bit flags in-memory as a C++ bitset, but saves them as a long. I'm sure you get the idea :)
I also wrote the basic functions to go from one type of record to another, but, unfortunately, I won't be able to test them properly until I have the code for saving the records out to disk, and retrieving them. The will be one of the next tasks, if only because I hate not being able to test code in small chunks. The bigger the chunk of code you test, the more difficult it is to locate any bugs that manifest themselves - and the more difficult it is to be sure you've tested everything.
