Jump to content
  • Advertisement
Sign in to follow this  
Wizecoder

MMO/Game Engine architecture ideas.

This topic is 3300 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I just want to share my thoughts on mmo/game engine architecture. For now at least this is primarily theoretical(I think I am better at researching ideas than implementing them :)) but I might try implementing them some time. I got most of my inspiration from three main places: The t-machine entity system articles, the ibm mmo articles, and the architecture in game coding complete 3. The architecture will have the three tier architecture from the ibm articles with a Database layer(with something like a PostgreSQL or MySQL server), a Web Layer(with public and private web servers like Glassfish or Tomcat), and the "Client" Layer(both Game Clients and Game Servers are part of the Client Layer). All of the applications in the Client Layer will use the same four-module game engine architecture based around the component-entity model. The four modules will be a Data Access Module, a Game Logic/Server module, a Game View/Client Module, and a Application Module. The Data Access Module will be in charge of distributing the different game components(not counting game resources like meshes). It will be used very often by the other Modules. It can have different ways of being implemented depending on the type of game or whether it is a mmo client or server. If it is a single player game than it could either store all of the game components in arrays/structs/lists/etc... or it could load the components from something like an XML file. If it is a MMO server than it would establish a connection to the private web server and be in charge of sending HTTP GET requests to get and set data. If it is a MMO client than it would establish a connection to the public web server and be in charge of getting the secure data(it would not be allowed to make any requests to set data). The Game Logic/Server module would be in charge of running the game logic/scripts. If the game is a single player game than this would be in charge of running AI and Physics and any other things based on logic then passing it to the Game View layer. If it is on a MMO Server than it will be in charge of any computations that need to be secure and than passing the result to the servers Game View/Client module which sends it to the client. If it is on a MMO Client than it will be in charge of receiving any messages from the server, running any non-secure computations, than passing it to the Client Game View it will also take player input messages from the Game View and send it to the Server. The Game View/Client module would be in charge of playing the sounds, rendering to the monitor and receiving input from the player. A single player game would receive messages from the Game Logic module and render the result. It will also take input from the player and send it back to the Game Logic Module. If it is on a MMO Server than it will be in charge of taking messages from the Game Logic and send it to the Client. It will also take messages from the Client Game Logic Module. If it is on a Client than it will render results and pass user input to the Server. The Application Module is different from the rest of the Modules, it doesn't differ very much on different game types. It is in charge of running the other Modules, handling resources and dealing with other platform specific optimizations and initializations. I would appreciate feedback.

Share this post


Link to post
Share on other sites
Advertisement
It sounds like you're trying to design a generic system that could work for everything, and like any top-down design, it specifies what you want rather than what will work and therefore actually offers little insight into practicality. In theory, pretty much everything can be divided into presentation, logic, and data for example. But in practice that doesn't solve your problem.

Share this post


Link to post
Share on other sites
Just like multithreading an application. Starting with a top-down "I'll have threads for AI, Physics, Networking" doesn't give any insight into how everything is supposed to tie together. Starting with a bottom up "I'm going to thread with worker threads running Tasks from a job queue, and then I can break AI, Physics, Networking into jobs." gives you a lot more insight into how everything works, but you might not be able to fully marshal your setup into this system. Looking at a game like Left4Dead's design with LOTS of expendable enemies, you'd be able to narrow your system design down. Knowing that you have lots of expendable enemies means you need some way of batching together relevant enemies for creation/destruction(keep memory fragmentation low), update(keep nearby enemies in the same threads so they can interact), and networking(send nearby enemies packed into one packet). Your thread/server task becomes dealing with "mob of zombies" objects as efficiently as possible. Going the other route, with EVE style battles, you end up optimizing for mass PvP where battle dice-rolls and user inputs become the bottleneck. Knowing the design helps you come up with better needs for your server setup.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!