OGServer -- A simple, easy to use, Game server framework/api.

I guess it’s time to come out from under the shade with my latest server project, which has been tested in numerous applications so far, recently I took the project and did a complete overhaul and added a ton more abstraction. The goal of OGServer is to allow people to easily create servers that can withstand a large number of connections; Of-course this will also be limited to the amount of logic the user is processing, how they’re processing it, and the hardware of their machine; However I’ve used this framework in stability tests before and I was pleased with the results.

The project isn’t exactly ‘closed source’, but it’s not ‘open-source’ either, I don’t use obfuscation; However I’m not providing the .java files for the time being. – I’m thinking about rewriting this again, however this time built for extreme stability and ease of use and selling licenses, possibly. I have a fairly large game-developer network that follows me around like puppies and it could be an easy coin or two.

Here’s an example of the “meh” packaging for the project:

Currently the server has the following features, with a lot of features planned; Consider it a game-server framework.

  • Entity System
  • Built in friends list and ignore systems.
  • Abstract classes for containers, for things such as inventories, to hold items
  • Stackable and single item support, uses an ID/Amount, can be built upon for more complex item systems
  • Basic region based logic support that can be extended upon
  • TCP and UDP Support, automatically links the UDP data to the proper user, all done in the background
  • Basic collections set up for all “mobs” for other nearby mobs, updates in real time.
  • Easy to use packet system, allows for sending global/single/broadcasts very easily.
  • Built in abstract login protocol, easy to use and build upon
  • A “default login protocol” which uses JSON format for saving accounts, great for testing
  • Uses reflection/annotations to find packets, just create the class and you’re good to go.

Planned features include:

  • Remote Administration System(in dev)
  • Websocket networking support
  • Model loading, for authoritative collision
  • An Abstract A* Pathfinding implementation

Current Client API’s

  • Java (Beta)
  • Unity3D (Beta)

Planned Client APIs

  • HTML5 (Javascript)
  • Flash

You can view my poorly written documentation over at http://ogserver.net/documentation/

could you give some stats (num users connected, lag millisecs, type of application ran, size of packet, packet freq, etc.?)

The networking is built upon Netty, which you can find over at http://netty.io/ however I can’t really give you any statistics on lag/users connected. The amount of users you can have connected completely depends on your hardware, and network connection as-well as the code you use in your game logic. The amount of ‘lag’ you will have greatly depends on the connection between the client and the server, as-well. If you’re asking how long it takes to process logic, it depends on the amount of logic that’s being processed. (For example, getting a players name is certainly faster than looping through all connected players and sending out packets).

As for you’re questions about “Size of packets, and Packet frequency” - In my tests I was using minimalist packet sizes; However they were definitely optimal for my game. Packets such as movement should be sent over UDP (Depending on movement type) while other data is handled by TCP.

Consider the fact that the minimum Ethernet frame is 42 bytes, and a UDP packet’s header is 8 bytes, and a TCP Header is anywhere from 20~60 bytes. Knowing this information can greatly lower the amount of packets that you send, by “Mashing” packets. Granted this is all at the hands of the developer, not the framework. With my test what I had done was created a basic game that handled animation states, and 3d positioning. (X, y, z, rotation) and around 2,000 remote bot clients. These clients would all run around at random. I then logged in locally to see the results, in which I saw numerous clients moving around the world smoothly. The of-course, was a few jumps here and there, due to not handling smoothing for lost UDP data, however it was functional all the same. All of the data relayed via TCP was all consistent as-well, such as health, player names, their identification numbers, and so forth.

Packets can be however large you want them to be; However I’d recommend being smart with it.

As for frequency, I was sending the movement updates every quarter seconds, then relaying information to |all| clients immediately. The packet size was as follows

(Opcode - Integer - 4 bytes, Float x - 4 bytes, Float y - 4 bytes, Float z - 4 bytes, Float r - 4 bytes, Segmentation Buffer - Integer - 4 Bytes)

This served for a total of 28 bytes of data in the packet; The operating system handled the extra 14 bytes (required to reach the Ethernet frame minimum) and we never have to worry about it.

Let’s do some basic math,

(28bytes * 4) = 112bytes/second.
112bytes * 2000 = 224,000 bytes/second (or 224 KB)

So the server is receiving 224kb/second in data (from a total of 2,000 clients moving around). Granted this is only movement, not to mention the chat spam I had going on at the time

Here’s where things get interesting, for every client update, an update is sent to every other client. So there’s 2,000 cleints sending an update to 1,999 clients each, 4 times a second.

2000*1999 = 3,998,000
3,998,000 * 4 = 15,992,000

So you’re looking at almost 16million messages/second being sent to a total of 2,000 clients; With the target-traffic being around (447,776,000 bytes) or 447Mb per second.

So instead, what we do is we cache the updates, and send them all in parallel, instead of on-demand, this brings our total message/second count from 15,992,000 to a much more efficient and believable number: 8,000 messages/second. – Which is effectively the same exact amount of messages the server is getting in (For movement).

This kept my processor at a lovely 70%, while running pandora, Unity3D, a Unity Game rendering 2,000 clients moving around, my Java IDE (Eclipse) and running the server. I don’t have a king processor either, just an AMD A10-5800k APU 3.8GHz with a 10Gbit NIC.

Not exactly “simple and easy to use”. Just from reading the docs there’s a lot of stuff designed for certain kinds of games and not others. Such behaviour is good for single projects but not for libraries.

Also, “poorly written documentation” and closed-source don’t go together. Nobody’s really going to be able to use this.

Not to mention that a closed source networking library is not very trustworthy. There’s no way for us to know if there are vulnerabilities, intentional or not.

The plan in the future is to either go with open-sourced development; or a closed structure such as SFS - http://www.smartfoxserver.com/

Currently the people using this are all following a Online RPG tutorial series that I’m creating, and I don’t have any intention of creating vulnerabilities, considering that would put my name on the shame list. It’s true that vulnerabilities could appear, but they can also be reported and patched; This isn’t the only scenario in which there could be problems that you can’t fix yourself due to it being closed source. I don’t see how you say that nobody is going to be able to use it, either. It’s designed for extreme ease of use, and after a tiny bit of fiddling everyone I’ve ever handed it to has had perfect understanding of how to use it.

“there’s a lot of stuff designed for certain kinds of games and not others.”

Currently you’re correct; There’s some stuff designed for games that hold inventory systems, or would like to have an easier time creating an online RPG, this is mainly because online RPGs are the starting point of the project, and what most of my following base will be using it for, this is not to say that systems for other games cannot be implemented ontop of it. You’re not required to use any of the features that are offered, they’re just there for you if you want them. I’m planning on adding more functionality for multiple game types in the future that can be built upon at any time.

I can personally say that I’ve used this in freelance work for multiple kinds of games. I’ve done a trading card game, a platforer, a 2d top-down shooter, and a multiplayer 3D RPG all with the same code that’s available in the documentation. The idea isn’t to give people something they can just download, set a few values and run, it’s just a stepping stone to make things easier.

As stated before, smartfoxserver is not open sourced, and thousands of people use it. It’s also fairly big named. It’s also a pain in the ass for beginners, which is why I’ve taken the time to write this. If I’m able to teach people how to create multiplayer games that have no programming experience, then I would think that it’s fairly simple to use. — Even if it’s only good for a single game type, which you seem to think? Could you elaborate on why?

“Such behaviour is good for single projects but not for libraries.”

I don’t exactly understand what you’re trying to say here;

Cool ideas, this reminds me a lot of common RSPS practice. Sorry if you don’t know what that is, but either way I’m interested in contacting you. PM please!

Heh. Minus the thread per client / other infamous design flaws :stuck_out_tongue: ( I’ve used OP’s code in my own Online 3D RPG )

Great project! What about the progress now?

Progress is still continuing, however I’m working on some much more important tasks right now.

Your community forum is quite literally 99.9% spam.

http://ogserver.net/forum/forumdisplay.php?fid=8

At least I know where to look if I have erection problems.

bahaha I cracked up in class at the thread called “titty webcam”

OP should clean that up else no one will take the library serious.

I’ve been cleaning this forum up at-least once a day, and it just keeps getting nailed with spammers, I’m not at the point where I’m wanting to take this seriously right now, as I’m still working on some very important tasks.

I’ve purchased IP.Board and IP.Content, however I’m working on getting my forum set-up on another domain (My master-domain, if you will) in which the forum link is just going to redirect to a subforum on my master-domain.

I’ve disabled the (Currently useless) forum for the time being.

I already watched porn this morning so those tits did not interest me. But seriously, you should put security on the registration form. But enough about that. I still would love to make an MMORPG some day (and I am dead serious about it) and this looks interesting. However, those entire list of classes ‘scare’ me off a bit. I do not really care about those item systems and such but I do care about something that can handle like 1000 http requests at once. When I tried to make an mmorpg prototype, this is what I got stuck with. It slowed down my game a lot which is quite a shame. Having a library to handle that stuff would be awesome. And if I’m right, you have done that.

Please continue your tutorial series for unity :smiley: