What spam filter are you using?
Browsing articles from "January, 2009"
Building MMOG’s for the Flash Platform: Metaprogramming
Previous posts in this series:
Straight from the start of our MMOG Platform project we knew we wanted to create a technology which is better than anything previously available (or unavailable in the case of proprietary, closed platforms). Quite big words, so we needed a big idea.
We didn’t start the project with a concepting or architectural design phase. Instead we wanted to get coding straight away and try out some of our initial thughts in a working example and build out the technology stack from there. So we decided to start with a simple game which would still enable to test most of the critical aspects of our technology: Asteroids.
Although TrunkTech (the code-name for our technology platform stack) is designed to run MMOG’s, we don’t want to limit what kind of games you can write with it. While most people think about online MMOG’s being isometric, tile-based, slow-paced games where the emphasis is in moving to a certain tile and chatting, we did not want to make that assumption. We also wanted TrunkTech to be able to deliver realtime, multiplayer action-games as part of the virtual world, so Asteroids was a great playground. You have free-moving ships, fast-paced action, network latency to take into account, a world that has to be synronized across clients and server-side game logic.
After creating the single player game it took us about 30 minutes to get multiple players connect to the game space, have the space synchronize itself across all the clients with everyone swooping around without any noticeable problems from lag. Pretty sweet.
Eventually we didn’t finish the game as we got too excited about what we had just unleashed and got on to create the rest of the technology stack.
Client synchronization and metaprogramming
We’ve been programming the client-server-side solution for a few months now and in retrospect must say that the most important ideas that we came up – which enable us to create multiplayer games in a fraction of the time it would usually take – were automated synchronization and metaprogramming.
Without getting into the boring details, our synchronization stack works essentially this:
When a client connects to a game instance (essentially a script written in AS3) the TrunkTech client and server start talking without imposing any work on the actually developer of the game or it’s objects. The server synchronize the game state with the client using our custom-developed, AMF-based protocol to get the client up to speed on what’s happening inside the game instance. For example, a number of other players might have joined earlier and shared their avatar instances (essentially the representation and behavior). The game instance itself might have spawned a number of game objects that need to be shared across all clients (e.g. the actual Asteroids in the Asteroids game), or the state of the game instance itself (time remaining, high-score, …). All this synchronization happens without any developer intervention. You just join a game instance and automatically receive all the shared objects that are associated with the game.
Even after receiving the first representation of a shared object it’s properties will of course change overtime. A spaceship might change it’s course, accelerate, rotate, or a Avatar might say a phrase. But again, the developer does not need to implement anything to make this happen. TrunkTech keeps all shared object in sync by sending messages back and forth and automatically updating properties of these shared objects or calling it’s methods as requested by the originating client.
Once connected to a game space, the client can choose to add some object to the game instance itself (his avatar or spaceship or whatever). From a developer perspective all that is needed to do is to create a instance from a Class that itself extends the SharedObject definition and tell the game instance to add it as a object that needs to be shared across all clients. The SharedObject base class will take care of all the hard work to keep the objects synchronized. This all happens through object introspection made possible by metaprogramming.
Whenever the programmer wants a property of an object to be synchronize he adds some metadata to the property to describe the type of synchronization necessary to keep all clients up to date an be able to simulate the behavior of the object perfectly. Synchronization might happen at certain intervals or whenever the property or state of the object changes.
In the ship class of our little Asteroids try-out, all we really needed to do is define metadata for a few properties to get that object synchronized correctly to all clients and thus convert a single-player game to multiplayer. Whenever the state of the controls change (an Vector containing the down-state of the arrow keys), these get synchronized. The metadata for the control-property states that whenever it’s state is synchronized, the location and speed of the ship should be synchronized as well. That’s really everything you need to know to simulate the movements of one ship across multiple clients.
The server is of course aware of all shared objects across the game instance, including all of their properties and can even intervene and change them at will, essentially taking control of a users objects. When a new client joins the game instance in the middle of the gameplay, the server has all the necessary information to send all the shared objects to the arriving client at get them up to speed.
Take away
Metaprogramming is utterly cool and provides you with the tools to create a system which magically do complex tasks on a complex set of objects but let’s you preserve the speed at which AS3 operates by not using dynamic objects.
For MMOG platforms, where you don’t want to restrict the imagination of the developer actually building out a product it’s a fantastic tool which let’s the developer write cleaner and meaner code in a fraction of the time otherwise required by taking all the hard stuff of client synchronization and dealing with it “in the background”.
Obviously I need to show you some code examples for all of this to make sense, but that’s a topic for some future writing.
7 Comments
Change… oh yes…
It's odd that I feel this happy for something that does only indirectly affect me. Still I feel that the whole world has become a better place as Barack takes his place as leader of – what can once again become – the free world.
Congratulations to everyone in the U.S. I have absolutely no doubt that the next years will be better than the last.
Spam… Is it still out there?
Thanks to good spam filters, I’ve received very little unwanted emails during the last few years. So little indeed that I didn’t even remember that spam is still a huge problem. Well, our spam filter’s license expired and it took a few days to get it back online. My email was almost rendered unusable with the HUGE amount of spam arriving in just 48 hours.
So to anyone behind a filter who’s wondering whether spam is still a big problem… Yes, very much so.
2 Comments
-
-
It’s part of our hardware Firewall, don’t recall the name.
Follow me on Twitter!
Other services
Sounds great, but the question is when? When can we try this thing out? If you’re considering to collect testers at some point count me in!
A tiny promo-game will be available in a few weeks. That’s single-player only though, but it uses the technology-stack in the background.
So how does this differ from SmartFoxServer?
You really got AS3 support on server-side?
How does it differ from SFS? In every conceivable way. Maybe we should discuss this over some (loads of) beer;)
Yeah, we have a AS3 comiler for Java, which we use for all the grame logic. It actually is AS3 on steroids, with some very neat additions for developing MMOG’s (e.g. threadless threadding, but that is the topic of another post on the subject).
I think this company has already solved your problems
disciplemmo.com
“You keep using that word. I do not think it means what you think it means.”
http://en.wikipedia.org/wiki/Metaprogramming
Grazer, you’re sort of right. It seems that the definition of metaprogramming changes depending on who you ask. If you look at Wikipedia’s definition for Reflection-oriented programming (a specific type of Metaprogramming), it oddly quiet different and in controversy woth the definition of Metaprogramming.
But yeah, I should have used the term Reflection-oriented programming instead of the more generic Metaprogramming term: “Reflection-oriented programming, or reflective programming, is a functional extension to the object-oriented programming paradigm. Reflection-oriented programming includes self-examination, self-modification, and self-replication”