FEDERATION 2 DESIGNER'S NOTES
by Alan Lenton
23 December 2003
Well, the next task was character (or persona or avatar, depending on your taste) set up. The mechanics of this are similar to that of account set up, only more tedious, because there is more information to get.
I decided I would give people running totals for their stats as they chose them, and automatically calculate the last stat for people. I debated making sure people used all the points available, but decided that it was a reasonable assumption that people who want to play an economic simulation can count! And if they choose not to use some of their points, who am I to argue?
That took all yesterday - it wasn't difficult, just time consuming. Now comes a much more interesting part, the player index.
The player index is the part of the program that holds details of player records and handles saving the records to disk. Since player records are relatively small (between 1K and 1.5K) and we have plenty of memory I can hold them all in memory while the game is running. If the player database gets so large that we start to run out of memory, there are two alternatives.
One, we can get some more memory - and a bigger server to stuff it into, since the present one already has 2GB of memory. Alternatively, we can just pull stuff off disk as needed, having adjusted the size of the database's in-memory cache to be a little more than the maximum number of simultaneous players times the size of player records. By keeping all this stuff in one C++ class, we can change the guts to reflect altered circumstances, as long as we keep the interface to the class the same.
This is quite a complex class, and it needs to be carefully written, because any mistakes will screw up everyone's character (including mine).
The first thing we need is something to hold pointers to each of the player records in the database. For the programmers amongst you we are going to use STL maps to hold pointers to the records. In fact we need to index these records with four different keys for fast retrieval. We need an index of the character names and one made up of ibgames account names. Those two need to cover every character in the database, regardless of whether they are currently playing or not.
The index of names is so that we can check that a name isn't already in the database when someone is setting up a new character. The index of accounts is so that when the accounts server tells us that account such-and-such is OK to log on we can find that account rapidly. Actually, and more to the point, it also means that we can rapidly process the case where the specified account does not have a character in database.
The other two indices are are indexes of players currently playing. The first one indexes the current players by name, and the second indexes them by the socket number they are connected to. By maintaining the second index we obviate the need for the IPC class to know anything about individual players. It can just say, 'Here is some text that just came in on socket number 35', and leave it to the player index class to sort out who it's actually for.
Once this was all working I was able to test the switching back and forth between disk and in-memory records that I coded a few days ago. A couple of small problems showed up, but nothing that took a long time to locate and fix.
And as the final thing today I added code to let people (well me actually) quit! Doing a 'Ctrl-]' to get out of telnet was starting to annoy me.
The remaining thing that needs doing is to put in some facilities for people to be able to talk to one another. After that it can go up while I put in movement and begin the long haul of writing the unique parts of fed2.
This is all going remarkably smoothly, I'm starting to wonder what is going to go wrong at the last moment.
