RakGS is a networking plugin for 3D Gamestudio A7 / Lite-C. RakGS uses the RakNet library version 3.0 and adds a network event system, remote systems management and a C-style interface specifically tailored for 3D Gamestudio A7 / Lite-C.

RakGS was built with flexibility, extensibility, efficiency and security in mind. For this reason, the RakGS functions do not resemble the native 3DGS multiplayer functions as closely as other networking plugins. RakGS can be used to create anything from a small casual multiplayer game to a full-blown massively multiplayer game.

Major features:
- Based on the high-performance, proven and stable network library RakNet.
- Supports every thinkable network topology: traditional client-server, inter-client connections, inter-server connections and true peer-to-peer.
- Easy compression and decompression.
- Event callback system. Supply your own event functions that will be called when a certain type of packet is received.
- Send any type of data, including your own structs. Combine any number of data types in a single packet with the fast & easy serialization / deserialization functions.
- Send packets reliable or unreliable, ordered per-channel.
- Unlimited number of connections.

Planned features:
- Voice chat
- Autopatcher
- Remote procedure calls
- Secure connections and encryption with a single function call.
- Network simulator
- Statistics

>> Download << (make sure you check the whole thread for newer versions)

RakGS comes with a manual describing every function in detail and a simple demo project. To run the demo, open both server.c and client.c in your A7 / Lite-C SED and run them (server first). Enter a local port for the client (don't use a port that is being used by another program, the server uses 50000). Then you can send text messages to the server. This is just a small demo showing how to use the plugin. You can look at the source of the demo project to get an idea of how to use RakGS, and look up specific functions in the manual.

The manual contains further information on every function in the plugin and how to include RakGS in your project.

Even though this version is called 0.1, it already contains all basic features needed to write a simple multiplayer game. In the current version, the number of connections is limited to 4.

Please report any bugs you find in this thread.

Wow!

It finally happened!

Great job, Ex!

Tell me:

1) How hard do you suppose it would be to mitigate existing 3DGS MP code to Raknet?
2) As we both know, one of the more annoying things we've had to do is implement our own routines so that only relevant entities (ie within a certain radius) send information to a client (my Sphere Of Influence if you remember). Does RakNet have an inbuit solution to this or would we still have to program this in?

Honestly Ex, if this pans out, I would be the first to ask Conitec to make this their native network engine... seems to make more sense to use Rak than to use the Sunset DirectPlay as it does now.

Oh, and if I may, I would develop in this order... merely my opinion of course:

- Remote procedure calls
- Secure connections and encryption with a single function call.
- Statistics
- Autopatcher
- Voice chat
- Network simulator

Quote:

---

If you promise to write a little more sophisticated test app and let me know what you think

---

I can't.

I have a prototype to deliver by the end of this month to one of the grants. All of our code is in A6 and I haven't touched A7 nor C-Lite since neither fully support MP (A7's C-script might but I have a standing rule not to work with software right after it's released). As such, I cannot at this moment try or work with new software no matter how tempting it is. After our prototype delivery, I will be spending LOTS of time with business and gaming consultants to see what our next step is. Honestly, up until now the leading contender was to raise capital for full-blown production under the Multiverse platform... it's just too tempting and professional to pass up. I was going to then keep our developed work as a way to quickly prototype game ideas for ourselves or potential clients. However, if RakNet is "all that and a bag of chips", it could lead to the my original plan to stick with A6/7... not without it's risks since 3DGS' priority is not networking and Multiverses is, but I have to consider all possibilities.

In any case, regarding some earlier comments, I obviously was not thinking the "raknet" and we have lot's of code. How much of it is "workarounds" that can be avoided with RakNet I don't know but it sounds that, just like any other solution, you trade one workaround for another. We try to abstract as much as possible with our code so that we don't use send_xx() all over the place but have a other functions that do that for us (like send_to_client(), or send_to_everyone(), that sort of thing). My architecture is platform independent but that doesn't mean that I won't have to spend tons of time implementing it (or rather re-implementing it) As such, I think that it might not be hard to get our network traffic modified to work with RakNet but the event handlers we would have to program ourselves as well as any type diffences, and just understanding how RakNet works makes this a daunting task. I guess without you seeing my code nor I seeing yours that was a pretty silly question to ask but it was worth a shot anyways.

LOL why 4 connections!? Thanks for this release you've made my day

After quick test: server.c use 100% CPU. I'll have to try again with client, but if I type a string for the chat it is supposed to show error malfunction?

Got compressed serialization/deserialization done, and am working on RPCs now. What do you think, should RPCs be able to receive input parameters? Parameters for RPCs seem to make things much harder to implement efficiently and with a simple interface. Right now, gamestudio's RPCs (proc_client/proc_local) don't use parameters I think.. Not using parameters seems to offer very little improvement, though, since the event functions are pretty much Remote Procedures invoked by sending a certain MessageID.

Quote:

---

LOL why 4 connections!?

---

I might want to sell a full featured version, not sure yet.

Quote:

---

After quick test: server.c use 100% CPU.

---

You can set a higher ThreadSleepTime when initializing the network engine. This should decrease the CPU usage.

Quote:

---

I'll have to try again with client, but if I type a string for the chat it is supposed to show error malfunction?

---

Yes I use the error() instruction for quick & dirty output. This is in the Lite-C code, so you could obviously process the incoming chat message differently in a real application.

Forgot about that. Last year i've seen the solution on the raknet forums. Anyways thanks for the hint, it solved my problem with high cpu.

I've spent today thinking up a elegant way to implement RPCs, and I've come up with a really nice solution. It requires one call on the receiver to register the function. Calling the function is a single function call:
RAKGS_RPC(SystemID, RPC_ID, argumentCount, [arguments]);
The SystemID is the system to invoke the function on, ID is a number that is used to register the function on on the server (they must match on caller and callee). ArgumentCount is the number of arguments the function takes. [arguments] is an optional list of arguments. The number of arguments is up to you, and can be any built in type.

Got a party tonight and I'm going skydiving tomorow so I'll implement this thursday I think.

Seems like a good solution to the RPC issue: let the user decide if they want to send parameters or not. Talking with my programmers they confirm that most RPCs are parameterless (like our proc_xx) but they could come up with no reason for that except just easier code programming.

So is ID like our old fashion index or more like the handle?

The ID is just an integer number that you use on the receiver to register a function as RPC. Then you use the same ID on the caller which will result in a call to the function linked to that ID on the receiver.

It's probably best to use a shared header for client and server that contain defines for the IDs:

#define RPC_function1 0
#define RPC_function2 1 // and so on.

You can then register your functions:
RAKGS_registerRPC(function1Ptr, RPC_function1, function1ArgumentCount);

And call the function from another system:
RAKGS_callRemote(RPC_function1, function1ArgumentCount, arg1, arg2, arg3, arg4);


I've built my own RPC functionality, instead of using RakNet. Rationale for this is that RakNet requires you to initialize a struct containing a char* to a list of serialized arguments. This is pretty much the same as serializing your "arguments" with a BitStream, send them with a certain MessageID, and deserialize them in the network event. The way I've implemented RPCs it takes very little setup, and once that's done, all serializing and deserializing is done for you and you just have to call a function.