How does one guy make an MMO? Automating everything he possibly can.

So today, I added a Subversion repository for use in updating the server with new builds. This let me cut the server update process down to two steps.

1) Commit the changes to Subversion.

2) Log on to the server and run a batch file that stops the services, updates the directory from subversion, and restarts the services.

It’s only that two step process because I have the Visual Studio project building into the same directory structure that is the final directory structure, including all the resources, dependencies and whatnot.

And for those of you who just went “huh?”, Subversion is a piece of software known as Version Control Software. It keeps a record of all the changes that are made to a project over the course of time, and allows multiple developers to work on the same documents without destroying each others work (simplified description).

One benefit for me is that it’s one command to send updates to the server, and one command to get those updates from the server, instead of the other option of using FTP which requires a lot of human interaction. The problem with human interaction is that humans make mistakes.

The other benefit for me is, if I make a bad build with a bad bug in it, it’s easy to roll back to the previous version until I can get that bug worked out.

So it seems that my update scheme has a little flaw. I’m using RakNet from http://rakkarsoft.com, and the version I’m using is still in beta. I don’t know how long it will be in beta, either, but it exposed this small issue. If, when Rakkarsoft builds a new version of RakNet, the protocol gets modified, older updater clients may not be able to connect to the new server. I just had this happen.

One solution is to add an http check for a new version of the updater, since we all know the http protocol isn’t going anywhere, but that’s a bunch of network code I don’t really want to write. RakNet doesn’t support it.

The other solution is, when this happens, to pop up a web page and have players download a new version of the updater. The initial download is not large, and these days, it’s probably considered absolutely tiny. 579Kb, at this point in time.

I’ll probably go with the http download. I don’t want players to have to do anything at all once they click the icon to play, other than play, of course.

Making progress, making progress. I have the account creation portion completed, which really means, yes, you can create an account and get it activated, if I were to provide you with the URL. Sort of pointless to do that yet as you couldn’t do anything in the game. As soon as there is any kind of interactive thing to do, I will put up the account creation page to accept your damage.

I had to write a Terms of Service, too, (boring). I’m sure it’s not complete and there are a ton of loopholes, but hey – the whole thing is under development.

Anyway, the system works very similar to any forum signup, at the moment, since I’m not charging anything. Assuredly, once that time comes, it’ll change all over again, but for now, you just type in your particulars, check the box that says you agree to the TOS, and hit submit. If you entered a valid email address that belongs to you, you’ll get an email that will have a link you need to click to activate your account.

The reason for this is that the email will be used to send updates about the service, especially if there is a problem with your account. Your account user name will also, eventually, be used for the user forums, and I don’t want spammers creating game accounts just to spam the forum.

It’s exciting to be completing pieces though, regardless of how boring they really are. I can’t wait to get to the fun parts, but all of these initial steps are necessary. Tough to play a game you can’t log in to.

So today, I finally got the first “Major” component completed to essentially an alpha state. It could use a little more work, but if I leave that work until later, it won’t be blocking other work.

Oh yeah, maybe I should tell you what it is.

In a nutshell, it’s the client update system, which includes both a server and client component. When you start the game, it will launch a “loader” app that will connect to a file server and download a file list. It will compare that file list to the file list already on the clients machine (if there is one), and if they match, you get to skip ahead and play.

If they don’t match, the app runs through each file in the new file list and verifies that the version you have is the current one. If not, it downloads the current one and saves it to your drive. Once it’s gone through the list and everything downloaded properly, it saves the list to the client computer and starts the game.

If something fails, the list won’t be saved to the computer, and running the game again will cause it to continue where it left off.

The first “good” part about this for the client, is that they only ever have to launch the game once, unless a download fails. There’s none of the “Launch the game, find out you need an update, download a downloader, close the game, run the downloader, run the patch file that gets downloaded, restart the game” crap of Wow and other games. With Infinite Suns, unless the update fails, you won’t have to do anything.

The second “good” part about this for the client is that the downloader is small, and should always be capable of downloading the latest version of the game. You won’t need to patch four times in order to play.

On the server side, I just have to propagate the client changes to the server, the restart the service. It will automatically generate the file list on startup. I am probably going to set up Subversion to do the propagation. From the build machine, just commit the changes to Subversion, and then on the server, do an update. Will save lots of pain of incorrect version issues.

I’m tempted to share the link to the setup, but you can’t do anything yet once the client runs. You’d only get to see the nifty download solution, and really, you’ll get to see that enough once things get going.

I detailed earlier (at least, I think I did) my plan to keep a live server updated on a regular basis with new code so people can play it during development. I still want to do that. I can’t do all of the testing myself.

The problem I see, though, is what happens as I add certain features like the skill system and the economy. Unless I add a large amount of skills into the skill system at once, or a huge number of items into the economy, things will be very strange for awhile. Imagine playing a game where you can accumulate experience, but have only three skills to spend it on, and then, when new skills get added, everybody has them immediately because they’ve got all this experience to spend.

Or, with the economy, if I add some items to buy, yet there’s nothing that provides money, or perhaps the other way around, where various tasks reward with money, yet there’s nothing to buy, when something is finally available, everyone will have it immediately.

The problem really stems from my ability to add things quickly enough. Once it’s up and running, I don’t want to wait long periods of time in between updates and additions.

I really do have quite awhile before this becomes a problem, as right now, it’s only these “advancement” areas where the problem exists, and I’m nowhere near adding them. But I have to figure out the solution before I get there.