What do you hope to offer that existing, high-quality, vetted and debugged libraries don't already offer? What I see there is even less than what is offered by non-game RPC libraries.

What makes this better than the competition? What do you hope to offer by building this? Or is it a project for you to learn from?

I hope to offer more simplicity and less lines of code to write for developers. Different from Raknet, the event loop should be hidden in the lib. The user will just call update per frame.

Further, functions needed by all games will be included, which is not the case for most libs.

As it will be enet based, performance is expected to be better that raknet e.g..

"fast (no SQL database)" seems like the wrong approach.
You should let user validation be up to the integrating application.
When an authorization request comes in, you hand that off to the application, and keep on processing packets.
When the application knows about authorization (which may be an asynchronous network request, check in some file, always succeed, etc) then the application calls back into the library to let it know the result.

Further, functions needed by all games will be included, which is not the case for most libs.

I expect most applications use a separate library for those kinds of functions, like perhaps web services for user authentication, for example.

Enet and RakNet both use UDP.
I know of no big performance differences per se, although depending on how you integrate, you will of course perhaps see differences.


Anyway: Have you already built a networked game with these functions?
If not, then I'd suggest that you're probably better off actually doing that, first, and then extracting the bits that actually work well into a public library. From-scratch libraries that are not based on significant previous experience tend to not get a lot of uptake, in my experience.

>>"fast (no SQL database)" seems like the wrong approach.
>>You should let user validation be up to the integrating application.
>>When an authorization request comes in, you hand that off to the application, and keep on processing packets.

Maybe this has been misunderstood. SQL was not meant with regard to login information. What I wanted to say is, I dont want an SQL database for the player positions, in game items and stuff, as used in MMORPGs. If the developer wants to use an SQL for the user logon data, thats possible of course. For the login, the lib should still provide a simple optional logon functionality.

>> I expect most applications use a separate library for those kinds of functions

It will be basic stuff as mentioned, number of players and such. The lib is not intended to be used in the next AAA game as all major 3d engines obviously have all networking functions already. The target is indie developers that want to get started quickly whitout studying a libraries documentation for ages and type lots of code.

>> Enet and RakNet both use UDP.

>> I know of no big performance differences per se, although depending on how you integrate, you will of course perhaps see differences.

Well there is a difference: http://networklibsbenc.sourceforge.net/static_gallery_mirror/

>> Anyway: Have you already built a networked game with these functions?

No. Thats another reason for writing the lib. I need it for my game.

I dont want an SQL database for the player positions, in game items and stuff, as used in MMORPGs.

MMORPGs don't use SQL databases for real-time gameplay information, only for character persistence.

Well there is a difference

Hmm. Not sure how to read or trust or translate those graphs. Anyway, if you believe it will make a difference, the best thing you can do is to set up a hypothesis on what that difference is, and then set out to measure to strenghten or disprove that hypothesis. In the end, measuring what actually matters to your application is the best way of making sure you get it! (And selecting what matters most among all parameters is an important part of design/engineering.)

I need it for my game.

Making a library that works for your game seems like a great way of going about it.

I presume that you already looked at the Torque Network Library? It's a bit older (as is Enet,) but has lots of good bits in this area.
http://opentnl.sourceforge.net/doxydocs/

Ok, short summary:

Everyone is completely satisfied with the existing libs in every way and nothing needs to be improved.

Well I see this different.

no.

Bad Idea.

you can only offer a Connection API and a Acceptor type API

only wrappers around the core sockets any thing else is app specific and will clutter the APIS.

Like Direct Play tied a player structure to its networking which was maybe one reason no one liked it much.

there is no one way to do it only sockets.

Well for low level stuff, enet would be sufficient, so I dont want to write another low level lib.

The purpose is to create a framework that makes it easier to sync structures with the server and support optional prediction.

Therefore, position, direction and velocity are required to be stored in the lib for certain objects.

I cannot understand why everyone just complains about the general idea rather than coming up with ideas of your ideal wanted usage of a network game lib.

You could say like "lib xy is good but I am really missing to have it more simple in this or that way"

Perhaps everybody misunderstood my purpose of this thread.

I did not ask for things I should not do. I asked for good ideas.

A library specifically targeted at FPS/Action games would be pretty cool. Most libs are either too low-level to be used out of the box, or have a high-level RPC/replication mechanism that isn't at all suited to FPS games.

Is this what you're planning? What kind of replication architecture will it use? Something like the counter-strike model with server-side game-state rewinding for lag compensation? Something like Quake 3's reliable replication via unreliable state diff patching?