It’s still a bit rough around the edges, but it has to get out there sometime.
I’ve been working on an open source server engine for the last 5 months. The last few years I’ve been working on games at massive scale. I was the lead dev on half a dozen successful social games,and lead on the 2012 social game of the year, Marvel Avengers Alliance. Part of why I created this project was simply because I wanted to, and I have some experience with these things. Some of it was my frustration at the lack of open source server engines for games. And lastly some of it was that after seeing so many horrible C++ game servers, I wanted to show there was a better way.
I decided to target Untiy3d as the first client platform, so there is a very basic demo client available as well.
The main goal of this project is massively scalable. The demo is a small virtual world with 2000 npc’s. When you get into range they chase you, all server side driven.
If you need something to handle hundreds or thousands of concurrent anything, this is designed for you. If you just need a basic server for an FPS game or RPG, it’s probably overkill.
The server is a mixture of java and ruby (via jruby). I stay in high level languages until benchmarks show it needs to be pure java.
There is some experimental code for running an embedded mono runtime and being able to write game logic in C#. It’s not really usable yet,but looks promising and works in basic testing I’ve done.
My immediate goal is to get the installation down to plug and play. Another week that should be done.
I’d be extremely grateful if someone wants to help polish up the client. Not my strong suite. Right now aside from the networking code, it’s a mix of stuff I pulled off the net and from the asset store.
Sounds very interesting, I’ll have to check it out when I get home.
Would you mind sharing some details on how you are handling server side collision detection for all of those npcs? As in, your approach and what libraries you might be using?
I could have swore that I posted a reply and it just disappeared. In any case…
Server does no physics at the moment. I have experimented with bullet, jbullet, and the bullet java wrapper from Jmonkeyengine. It’s fairly simple to load in bullet and make the api available, but I need to spend more time with it to see how it handles exceptions, threading, etc…
I did find a decent A* pathfinding library and it’s in github, I just haven’t put an example of how to use it in the demo.
As for server authoritative, the server core is fairly agnostic as to how you want to do things, and I think it should be given that games often handle this kind of thing differently. Sometimes you want server authoritative in real time, sometimes you just want to sample to catch cheaters, and a run behind model is ok.
That said, the default for stuff I’m working on in the demo is to be server authoritative. I would probably approach this the same way I do with what language to use. Start with full authoritative, then move to more advanced stuff like sampling only when performance/latency shows that it is necessary.
My primary goal is to provide controllers for common patterns in games, without forcing a specific implementation. I’m trying to balance this with creating a set of basic implementations for the most common things, that you can take and modify to suit your own needs.
Right now documentation and a simple install is first priority. I’d rate pathfinding and physics as right after that. The engine is totally usable now, but without documentation it’s going to be a bit painful to figure stuff out.
i do agree, without proper documentation will be kind of hard for others to test drive.
i do like what i read and your future plans,
you know, i was planning to implement the existing multiverse open source server to unity since it is all java server and seems to be a good scalable server, but yours seems to be even more powerful as per the reading I’ve done from your posting and the github info.
quick questions:
so for server scripting will be pure jruby?
i never tried ruby before, but am familiar with java, i wonder if it is kind of easy transition to follow, ill bet it is.
i was trying to setup a windows server to test locally but no documentation for it yet, so was wondering if you have a server online to test the unity client demo?
Ok windows installation is now supported, and is the simplest way to get everything running.
As for languages you can script/develop in, java/ruby will be the main supported languages for now. The underlying framework I use is java based, you can code everything in java if you want. Because everything is based on message passing, you can send messages between java/ruby actors without any issues. I do a lot of that already, and most of the ruby classes actually inherit from java classes. And because messages are based on protocol buffers, you can communicate with other systems in completely different languages also. There is built in support for Zeromq and Apache Camel if you need to integrate with other systems.
Docs are on the short list. Putting up a server is also on the list, but I want to have the client a bit more polished before I do that.
i agree with CaptainExtra300 , a quick note for how to get the server running in windows will come in handy for local testing and developing, but for production a linux be more suitable.
do we need jruby installed on the host machine or will JDK 6 OR 7 be sufficient in this case to run the server if we want to run and code all in java?
i am too interested on the server side collision, and a fully authoritative server.
question:
1- for this server that can handle massive worlds will an Area of Interest be planned so the player will only receive updates from objects closed to his to save up bandwidth and bottlenecks?
2- is this a zone based or seamless/continuous worlds? is this also planned or already supported?
3- i assume protobuf-net.dll from client side is the API to get communication to the server , right? is this also open source code? i did not see it on github, or maybe i missed it.
I made some updates last night, installation is now much simpler. You do need to install jruby it is required, but there is a simple windows installer at http://www.jruby.org
Players only receive updates from things close to them. There is a general purpose grid system that uses high performance spatial hashing to do efficient neighbor queries. The size of the grid and the neighbor radius are configurable. The demo with 2000 npc’s is generating 20,000 neighbor queries per second (one per npc every 100ms).
There are no zones per say as part of the core architecture, but you have the tools to create them if you want. I’ll put this on the list to document. The simple approach is just create more grid instances, and add an attribute to players/npc’s to say what grid they are in, and thus what grid to use for neighbor queries.
For larger scale stuff you can just run separate servers that are not part of the main cluster, or run groups of small clusters. This might make sense for things like general pve versus world vs world pvp, where you have significant differences in gameplay, load patterns, libraries used, etc… In that case I would just run two separate clusters, and have the client connect to each one separately.
ok when you say to “create more grid instances” do you mean as world instances? like instanced zones to load balance?
instead of one large world?
the reason i ask is because as you know unity is scene based, 1 scene being sort of a zone, but it is not set for large scale world into one scene, unless
you do some sort of voodoo tricks to stitch maps together and load and unload them in runtime etc… to not bottleneck the client
or do some sort of seamless scene/zone dynamic transition sort of thing.
or just add a zoned game 1 scene = a small zone, then once done in that zone teleport player to next zone etc… idk
also when you mention to run 2 separate clusters meaning: 2 separate hardware nodes that when connected together can load balance the same whole world? or to manage the cluster as 1 single zone?
i am still confused, but trying hard to get the hang of it.
So what constitutes a zone or world is kind of arbitrary to some extent. The grid is the only thing I can think of that you would definitely want an instance of per zone/world. The grid just does one thing, tracks moving objects within a defined coordinate space. By default there is one, but it’s a thread safe class that you can have as many instances of as you want.
If you want further separation then it’s all in the details of what you want separate. You can run two worlds each with their own grid on the same server, and as long as all of your game objects are using the correct grid, they are only aware of objects within that grid.
For unity specifically you could probably create two grids of equal size, but with the cell size being different. The cell size is basically how the grid is subdivided into smaller sections. You could use one for nearest neighbor queries, and the other for controlling asset loading. The one for neighbor queries might have cells that are 25x25, where the one for scene/asset loading would have a cell size that is equal to the scene size.
At present I don’t have built in functions that can tell you how far you are away from the edge of an adjacent cell. The information to calculate that is there, but the helper function that does it for you is not. you would need that for the grid used for scene loading. When you come within a certain range of an adjacent cell, you load the scene for that cell.
I would probably keep the scene/asset loading abstracted away from everything else, and not conflate that with everything else happening in the world. In other words keep everything else based on the world, just have your scene loading zone specific.
By cluster I mean the actual clustering abilities of the server. There is a yaml config where you define servers and whether they are part of a cluster or stand alone. When in a cluster, there is automatic replication and distribution that happens. For some things we replicate using delta’s, such as logged in players and the grid. For other things like the object store, we use a consistent hashing mechanism to spread reads and writes over the cluster.
I’ll have to play around with scene loading and see if I can get plug and play support for that. It’s mostly a matter of me learning how that’s done in unity, should be an interesting evening or two.
Why not use something like Sweep-and-Prune that takes advantage of temporal coherence, as opposed to 20,000 queries every second? Since you’re using a grid for this, it seems like SAP would be excellent here.
Sweep and prune would work well for collision detection. I can see adding that for that case. It’s not really appropriate for just tracking objects in visual range, especially for things like pvp where you cannot reliably predict movement.
Actually the project is very much alive. For better or worse I decided to make it private for the time being until I could get it into a more polished state.
Currently I am working on this full time. While it will remain open source this is also a business venture, so the official launch will have a website + hosted solution.
Official launch estimated at 1 month from now, although I am pushing to have the github project back up in a couple of weeks at the most.
I am looking for a an mmo type game out there to work with. My ideal is to find someone who has an mmo hobby project. Something that looks good but is missing the server side. I want a platform where I can eat my own dogfood so to speak, but client side gui anything is just not my forte. In exchange for making your game free to play, I would do the multiplayer integration, work with you on new features that have server side requirements, and pay for the costs of running the server and making it available to the public. If this sounds interesting to anyone contact me at chris@ochsnet.com.
