FEDERATION 2 DESIGNER'S NOTES
by Alan Lenton
19 December 2003
There are three major components needed at this stage. First the code that handles locating, saving, and loading player records. Second the code that talks to the accounts program and handles logging in. And finally the code that lets you set up a new persona!
This is one of those classic things. If you want to test the saving and loading, you need to be able to create records to save and load, and if you want to create records, you need to have some way to get to that part of the game where you create a new character.
So we start with logging on.
OK, let's split this down into two parts - setting up a new account, and logging in with an existing account. We'll start with the former since we can't test the existing account code until we can set up accounts to test with.
Fed's account and billing server runs as a separate process. Eventually it will handle accounts and billing for all ibgames games, not just fed2. The accounts server runs on the same machine as fed2 and I did consider using Unix sockets to access it. They carry a lot less overhead than the TCP/IP flavour, but they only work if poth processes run on the same machine. Since it's likely that the accounts server will run on its own machine in the future, we'll go for TCP/IP.
I had to dig out the documentation for the different commands the account server expects. Nasty moment there - I thought I'd lost it when I moved computers. Eventually I found it in the wrong directory. Right, we know how to talk to the accounts server, let's go.
First decision. This is a text game with a generic telnet access. How do new players say they haven't already got an account? There's no front end that we can put up a form to fill in. Answer: the game will look at the login ID - if it is 'new' then the game will assume the user wants to set up a new account. (Some people will miss this and assume they can just type the new account details in, but I'll deal with that later.)
Right - so we've got a 'new'. We need to get a login ID, a password (twice in case they mistype it), and the e-mail address. We can leave any other info till after they've tried the game out and are ready to pay. Also this isn't an encrypted connection, so we don't want to risk asking for financial info.
When we have the details we need to forward them to the accounts server. Two possible outcomes here. Either the account ID is already in use, in which case we need to ask them for a new account ID. Eventually we will get a valid ID and we can register then in the accounts database. Or possibly they will give up, in which case we need to clean up.
Assuming we successfully register, we pass the account ID through to set up a new character. Since the code for doing that doesn't exist at the moment, we pass it through to a stub function that prints a message in the log saying what details it was given.
Ooops! Just as well I wrote that out to the log - I'd forgotten to clear a buffer stream and ended up with an account ID that included all the stuff I'd previously used the buffer for!
That's fixed. Now let's look at the other side of the equation - logging on with an existing account. The start is easy - if the account ID isn't 'new' ask for the password and send the ID and password off to the accounts server.
There's a variety of answers can come back to us from the server. The easy one is that everything's OK. In that case we can pass the account ID through to the game to bring in the player (if they have a character, otherwise they need to set one up). That was the easy one - again we use a stub function to check what's going on, and it seems to be working properly this time.
The next possibility is that either the account doesn't exist or the password is wrong. I think we need to ask at this stage to find out if they meant to set up a new account. If they did we can send them through to the new account code. If they didn't we can ask them for the ID and password again.
Another possibility is that they are already in the game. It sounds unlikely, I know, but it happens all the time. In that case we need to tell them they are already on, clean up and drop the line.
The final possibility is that they've been naughty in the game, or maybe their credit card payment didn't come through this month. We'll send them a (reasonably) nice message telling them whom to contact to sort out the problem before dropping the line and cleaning up.
That's taken a lot longer than I expected, mainly because there are a lot of messages that need to be available to send to players. It's getting late and I promised to go out for a curry this evening, so I'll leave the character set-up stuff for tomorrow - D-day minus 5!
