My last go at an online game service was called Gemini because I thought Gemini sounded cool. But because Gemini 2.0 doesn’t have quite the same ring to it, this time around I’m calling my online game service
This is in keeping with the astrological theme of things, and I’ve found out that “Sagittarius” has a few neat qualities going for it:
- It’s directly opposite from Gemini as far as astrology is concerned (I don’t know about you, but that’s pretty eerie considering I picked both names on a whim)
- Its planet is Jupiter, the “king” of the solar system
- It’s associated with fire, and can shoot arrows and hunt and stuff
But enough about the name. Let’s see what Sagittarius can do.
This time around, I’ve structured Sagittarius as a collection of modules. Think of a module as a single action that you’d like your game backend to do. For example, if you wanted to have a Message of the Day, you could write a Message of the Day Module to handle that and register it to Sagittarius. The way to do so is fairly easy:
Sag = Spawn(class'Sagittarius'); Sag.Initialize(SagittariusHost, SagittariusPort); Sag.RegisterModule(new class'MOTDModule');
You can write and register as many modules as you’d like: a Server Module, a Login Module, and so on…
And when you want to do something with a certain module, you just retrieve it from Sagittarius and do what you want with it:
local MOTDModule motd; motd = MOTDModule(Sag.GetModule("motd")); motd.RegisterOnMOTDReceivedDelegate(PrintMOTD); motd.GetMOTDFromService();
Notice the use of delegates. This is because web connections are asynchronous, so you can’t predict when they’ll be done. But don’t worry, Sagittarius handles it all for you. I still have a lot of little details to iron out but the basics are there.
And just in case you’re wondering, the reason for the modularity is so that Sagittarius remains lightweight. You decide how much power to give your game backend, so to speak, by writing modules to do the heavy lifting for you, while Sagittarius acts as a sort of “referee” to make sure everything runs smoothly.
Some functions are too unique and important to be stuck in a module, so they’re built right into the system. One such function is sending an email from within your game.
Sag.SendMail( "email@example.com", "Hello from UDK!", "This is a test of the send mail function.\n" $ "Have a nice day!\n\nUDK Game", "test" );
Wait, say what? Can UDK really do that? Well, here’s the proof:
And inside my inbox not even a minute later:
Neat, right? Once again there are some issues to iron out, namely security. But they will be ironed out in due time.
Back in Gemini, things were pretty strict as far as data was concerned. I gave you a field of between 1 and 50 messages, each of which could be any sort of string that had to be encoded and parsed by the game. I did this to avoid someone crashing my database by adding a thousand messages at once (and believe me, someone would have tried), but the end result was that not much could be done.
This time around, everything is an expandable DBObject. Each DBObject must have a type and a name. For example, a server DBObject might have type “server” and name “MyServer1”. Each DBObject also automatically comes with a date property which gets updated each time the object is modified. Apart from that, however, the properties are entirely up to you.
Why can I do this? Because I’m no longer hosting Sagittarius!
This time around, I’m giving you guys the entire application base to host on your own Google App Engine account. I’m even planning on throwing in a Setup Wizard to make deploying Sagittarius to App Engine a breeze. This way, you get full control over managing your application as it scales — and I don’t have to pay for when it does 🙂
So Where Can I Get It?
Unfortunately, nowhere just yet. I’ve still got a lot of things to do before I make Sagittarius ready for even a pre-pre-before-almost-alpha release, but in the meantime I’ll be posting regularly about my progress. Stay tuned for that download link!