Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (808)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (872)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  OGServer -- A simple, easy to use, Game server framework/api.  (Read 14678 times)
0 Members and 1 Guest are viewing this topic.
Offline CTucker1327
« Posted 2014-12-29 04:27:55 »

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/
Offline GreenLantern101
« Reply #1 - Posted 2014-12-29 14:32:50 »

could you give some stats (num users connected, lag millisecs, type of application ran, size of packet, packet freq, etc.?)
Offline CTucker1327
« Reply #2 - Posted 2014-12-30 00:26:49 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline HeroesGraveDev

JGO Kernel


Medals: 383
Projects: 11
Exp: 4 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #3 - Posted 2014-12-30 00:34:12 »

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.

Offline CTucker1327
« Reply #4 - Posted 2014-12-30 00:53:24 »

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;
Offline Jire

Innocent Bystander


Exp: 8 years



« Reply #5 - Posted 2015-01-06 05:20:33 »

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!
Offline minigame

Senior Devvie


Medals: 14
Projects: 1


LWJGLException


« Reply #6 - Posted 2015-01-06 07:56:21 »

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  Tongue ( I've used OP's code in my own Online 3D RPG )

while (!deadFromWork) {
    if (hasItem("Dry Erase Board")) {
        chanceOfSuccess++;// Based on a true story..
    }
}
Offline dzungpv

Innocent Bystander





« Reply #7 - Posted 2015-01-14 08:41:30 »

Great project! What about the progress now?
Offline CTucker1327
« Reply #8 - Posted 2015-01-31 04:27:20 »

Great project! What about the progress now?

Progress is still continuing, however I'm working on some much more important tasks right now.
Offline Riven
Administrator

« JGO Overlord »


Medals: 1371
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #9 - Posted 2015-01-31 10:09:49 »

Your community forum is quite literally 99.9% spam.

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Gibbo3771

JGO Kernel


Medals: 128
Projects: 5
Exp: 1 year


Currently inactive on forums :(


« Reply #10 - Posted 2015-01-31 11:12:10 »

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.

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Offline KudoDEV

JGO Ninja


Medals: 79
Exp: 6 years


Game Dev Hobbyist


« Reply #11 - Posted 2015-02-02 13:36:55 »

Your community forum is quite literally 99.9% spam.

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

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.

Offline CTucker1327
« Reply #12 - Posted 2015-02-03 03:58:25 »

Your community forum is quite literally 99.9% spam.

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

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. 
Offline TheBoneJarmer

Junior Devvie


Medals: 6
Exp: 1-3 months


hi!


« Reply #13 - Posted 2015-02-09 00:25:17 »

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.
Offline Andit

Innocent Bystander


Exp: 2 years



« Reply #14 - Posted 2015-02-21 13:23:36 »

Please continue your tutorial series for unity  Cheesy
Pages: [1]
  ignore  |  Print  
 
 

 
Riven (849 views)
2019-09-04 15:33:17

hadezbladez (5813 views)
2018-11-16 13:46:03

hadezbladez (2616 views)
2018-11-16 13:41:33

hadezbladez (6230 views)
2018-11-16 13:35:35

hadezbladez (1503 views)
2018-11-16 13:32:03

EgonOlsen (4738 views)
2018-06-10 19:43:48

EgonOlsen (5796 views)
2018-06-10 19:43:44

EgonOlsen (3281 views)
2018-06-10 19:43:20

DesertCoockie (4178 views)
2018-05-13 18:23:11

nelsongames (5513 views)
2018-04-24 18:15:36
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!