Jump to content

  • Log In with Google      Sign In   
  • Create Account

Calling all IT Pros from Canada and Australia.. we need your help! Support our site by taking a quick sponsored surveyand win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 14 Apr 2013
Offline Last Active Jul 29 2015 10:30 AM

Topics I've Started

Eve online elements in a medieval setting

05 April 2015 - 04:32 PM

I have a sandbox pvp mmo where I'm trying to model some of the elements of Eve online that I like.  Overall the gameplay is a mix of Eve and say GW2.  Much of the functionality is already playable, running on live servers, it's not just in the design phase.


So one of the key tactical elements in Eve is stargates that act as chokepoints, and I've been trying to think of something similiar to put in the game.  Practically speaking it's not really possible to have different parts of the map that only have a couple of narrow access points, it's a huge open world that is procedurally generated then hand tweaked.  Hand crafting a world this size just isn't practical for an indie studio, so we had to take a compromise route. 


I was thinking that I can apply specific access points for trade via roads, which is kind of the angle I'm going with now.  I have npc cities and player run cities, and the general idea is you have to transport your goods from your player run city to an npc city to be able to sell to players outside your guild.  To transport your goods you have to stay on a road.  If you are on a road you can carry a lot of weight, if you go off, you become extremely  encumbered.  To make things more interesting I was going to put a couple of watch towers on the road between every player run city and the npc cities, and watch towers are also player controlled.  So if you own the watch towers, you effectively control the trade along that road (opposing factions will get easily killed if they don't bypass the watch tower, and you can't do that if carrying a lot of stuff).


Anyone have other ideas on this?

Library suggestions for java 3d physics

02 January 2015 - 09:51 PM

I'm aware of most if not all the available physics libraries, but not having used most of them I'm not really sure which is best for what I need.


The use case is specifically for doing LOS checks to other players/mobs on the server side which is java.   The client is Unity.  Players and mobs are already tracked in a spatial grid.  


Ideally I'd like the simplest library possible that just let's me import meshes into it and do raycasting against them.  Also the ability to setup some type of masking so I can pick what meshes the ray will stop at when hit.


I envision the whole process something like this.


1.  Initialize the physics engine with the static meshes and a bunch of player meshes.  Player meshes all have base coordinates of something like 0,0,0.


2.  When I need to do a LOS check,  I take as many player meshes as I need for the simulation and change their coordinates to match the players actual world coordinates.  Then do my LOS checks.  Then set the player meshes involved back to the default position.


3.  Rinse, repeat


I've been looking at using one of the java jni wrappers for bullet or possibly the java ODE port.  I'd like to find something more specific to the task at hand if possible, if such a thing exists.

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.