Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Apr 2013
Offline Last Active Sep 20 2013 12:19 PM

Topics I've Started

MMO Network Layer Architecture

17 September 2013 - 03:08 AM



I'm developing a game server for an online game, and I have some questions regarding how to handle threading from the network layer to the main loop. Some of the articles I have read regarding high performance servers actually raised the questions I'm about to ask. Here are the two articles if anyone is interested:





My main concern after reading these articles is the context switching. I've previously developed a prototype game server using python using microthreads/green threads to avoid context switches (to a large extent anyway). In this prototype I used two processes where they shared a msg queue. The network process would enter a message into the queue and then wait (its really one of the green threads waiting,..) for the game loop process to finish its processing. Once the game loop is finished it notifies the waiting green threads about the result (this has to be done, because the client expects a new state and a result from the previous operation). This sending of messages back and forth between processes/threads is one of the items the first articles discusses as a performance killer for servers. My question is now how to best remedy the situation when I'm developing the real server using C# 5.0.


The articles describes a way to remedy the situation of too many context switches by allowing the same thread that handles the incoming network connection to also take care of the processing and then send back result to client. In this model we may have say 10-15 threads (just a suggestion), waiting for a connection on the network side, once a connection has been established and message received, the thread turns into a worker. The worker then tries to aquire a lock (shared by the 10-15 network threads), and processes the message and sends back result. Afterwards the lock is released and the thread waits for next connection etc.


Does anyone have any experience with this kind of setup? Pros/Cons? One of the obvious pros is the ease of knowing who sender/receiver is as you're responsible for the current connection.


My goal is to be able to serve 50k messages/second. The game is not heavy when it comes to math, so the game loop won't have an issue crunching 50k messages/second. I'm more concerned with the network issue...


Thanks in advance!


Component Design in Component Based Game Engine

15 April 2013 - 11:43 AM

I'm developing a turn-based strategy game using a component based game engine and have been wondering how to structure my components.


There are quite a lot of collection components in my game. E.g. an Army contains many units. Is it suitable to have an ArmyComponent containing many UnitCpmponents? Is that a suitable level of abstraction for a component?


Another thing I've been considering is the level of abstraction for the buildings I'll have in the game and also connected properties. A player can create a farm, which produces food. A player can also create a barrack to construct units, but this building also increases the offense points of troops by 10%. These types of properties can obviously change (although not likely that any other building than a farm will produce food), and as such this should be customizable easily. My question is what level of abstraction the components should be? Should there be a BuildingComponent, ProductionComponent, and ResourceComponent? Or should there be a FarmComponent, ProductionComponent and FoodComponent? Am I making my components too granular?


I obviously want to create a flexible system, but I don't want to over engineer either. Most buildings will be static, while their properties will change. That's why I'd like to hear your opinion of how you'd structure these relationships using a component based engine.


One more thing, and this question is about sub systems. I intend on making the sub systems handle the logic, and only have the components store data. Does anyone have some tips & tricks regarding how to think about sub systems? I've read that one should aim for a 1:1 relationship between components/sub systems, I am not sure this would be the case for me given my current setup with regards to my granularity of my components.