Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Apr 2013
Offline Last Active Dec 14 2014 04:41 AM

Topics I've Started

Game Machine - Open source multiplayer engine

07 June 2014 - 01:57 AM

This is a culmination of roughly a years worth of work.  In some ways it is still a WIP, mostly with getting good documentation in place for the server api.  But the core is solid and it's completely usable. 


This started as a side project while I was still working as the lead server architect at a  largish game studio, and getting really frustrated with the complete lack of a good server platform for multiplayer games.  In one way or another none of them met my criteria, and the ones we did test basically fell over when we tested them for use at the scale we were working at (Billions of requests per day). 


Some of the main goals that Game Machine strives for:


  • Inherently scalable using modern architectures.
  • Provide higher level abstractions for hard problems like concurrency and persistence.
  • Be a productive system to work with, and simple enough for indie developers to dive into
  • Open source


Currently there is one working client in C# that includes some examples that work in Unity.  The entire api is based on messaging using protocol buffers, so integration is fairly straight forward.


The getting started page is up to date and should get you a working server.  Documentation for the server api is still sparse.  I spent some time today to get at least something up, enough so a determined individual could figure it out:)  I'm working hard on getting decent docs up asap.



You can access it all on the github repo:






Chris Ochs

Actor model design in the client

28 May 2014 - 01:39 PM

Posting this here instead of the Unity forums simply because I really value some of the knowledgeable people on this forum.


Note that the code below is specific to C# (Unity).


So I have a server that uses an actor model with message passing, it's actually a fully distributed system.  Message reliability is at most once.  Any sequencing and additional reliability are handled at the business (game) logic layer.


On the client side I have a simple actor system which mirrors how the server works.  So we have the same paradigm with the same rules end to end.  For example sending a message from client to server uses the same api as sending server to server or server to client.  There are a few minor differences but overall it's the same.


A bit more detail on the actual api as that will be important.


An actor has just one important method with the following signature:


void OnReceive(object message);


This method accepts messages and the user is then responsible for taking it from there and building whatever logic is required.


The actor system which manages everything has a static method to find any actor in the system (they are registered on creation):


static UntypedActor Find(string name);


Sending a message to an actor looks like this:




Sending a message to a remote actor:




Or just sending to the server without specifying an actor in which case a default routing mechanism kicks in:




Now on to the actual question.  Given that a lot of people who use this will have existing systems in place, what is the most appropriate interface to existing code?  I'm not out to force everyone into embracing the actor model end to end. (the context here is that this is a client for an open source server).


For incoming messages my first idea is to provide a callback api.  A message gets delivered to an actor, and you can then do as much or little logic as you want in the actor, then fire a callback to pass data on to another part of your system.


For outgoing messages I'm thinking about sticking with the paradigm of always keeping message creation in the actor.  So if you are off in say a chat gui, and want to send a chat message to your group, you might make a call like so:


ActorSystem.Find("ChatManager").Tell("you guys all suck I'm out","group");


The actor would take that message and then create a message the server understands and send it to the server. 


I was also thinking about wrapping this type of call in a static method on the actor.  Would make it easier to see what calls are available, and easier to document in code.


It's worth noting that messages are protocol buffers, and I've designed the message structure to model an entity component system.  So the process for an end developer to design new messages is fairly simple.  Actors do deal with composing messages, but the calls to serialize are abstracted into another layer.  At some later date I might provide actual entity and component classes to abstract it a bit more, but right now that's not a priority.


Would love to get some feedback on the approaches outlined above.

Non traditional languages in gaming frameworks

21 May 2014 - 12:30 AM

So I'll get right to the main question.


If a multiplayer game engine does not support C#, how big of a detriment is that?


I have a JVM based multiplayer engine that I spent most of the last year working on, and I'm getting close to an initial release.  You can extend the server or write game logic in the JVM language of your choice. 


I do have the option of adding support for C#.  Embedding mono in the jvm actually works fairly well.  C# would never be a first class citizen, but it would work for a lot of use cases.  I'm worried about going down that road though.  Trying to please everyone vs keeping things more focused.


On the plus side the core engine will be open source.  Still working out the details because the licensing is tricky.  Normally I would use the GPL3, but that's fairly useless for game development because the engine architecture would result in game code falling under the GPL3.  I've been fairly active in open source throughout my career, and I've just gotten really jaded by larger companies that take but never give back.   So I'm trying to find a way to keep a liberal license for individuals and startups, and at the same time force larger companies to contribute back changes they make to the core engine.


Anyways, interested in opinions on the whole C# issue.

Licensing game software as a service

12 November 2013 - 11:17 PM

So I'm working on a game server that will primarily be provided as a hosted service.  But I want to allow as much freedom as I can to developers that want to extend the engine.


Currently the idea is to provide a commercial license with the hosted service.  The copy of the software that runs on our servers uses a commercial license which would only really restrict you to using it on that specific server.


To allow developers to run a local copy during development, we would provide a copy of the software under the Gnu Affero license.  This effectively means that you can develop locally using the entire application source, and you would only have to share your work if you chose to host the game on another public server instead of using our service.  We would probably have commercial licenses as well for that scenario.


My concern is that even though in this specific case there is no danger of having your code fall under the Affero license, misunderstandings and apprehension will drive away developers.


The larger goal here is to stay away from the more common licensing model in the industry where you pay hundreds for a license if you want source access.  I want to scale the pricing in a way that makes more sense for individual developers.  If you can afford $10 a month, you get a hosted service and full source access to customize whatever you want.  


An alternative is to use pretty much the same model but have it all be a commercial license.  It would let you run a local copy of the server for development only.


So anyways, what are people's thoughts on using the Gnu Affero in this case?  Would it drive away developers?






Data compression/optimization strategies

24 August 2013 - 09:38 PM

For games where data throughput and size is an issue, what do most people use for compression?  Is it generally worthwhile using different strategies for say floating point data versus other stuff, or do most just compress everything with something like zlib and call it a day?


The specific case I have is an mmo client/server.   I'm working on the scale of say something like Guild wars II or Eve online as far as requirements.  Right now I'm able to track several thousand objects on the server side and do efficient neighbor queries on them, it's bandwidth that's becoming an issue.  Sending the coordinates of 1000 players to the client is a lot of data, and that's just movement, I haven't even gotten into combat and other stuff that will bump it up even more.


So far this is what I'm doing to optimize location tracking:


-  Use integers instead of floats.  I don't generally need the precision for x,y movement coords.


- Send local grid coordinates not world coordinates.


- base 62 encoding of string id's


- don't send data if it hasn't changed since last update


- partial coordinates.  Only send coordinate values that have changed by a certain threshold.  So a client might get a vector with x being empty,   which means use the last known value.



If anyone has ideas on best compression algorithms, or other tricks to keep bandwidth usage  down, let me know!