flare-engine-next
flare-engine-next copied to clipboard
dorkster
Multiplayer
A possible framework might be my "netLib" @ https://github.com/cgloeckner/netLib I completly reworked it: Now it's designed to some remote-procedure-call-like stuff based on method pointers, callback-IDs and an endianess-safe binary container class (included) for data exchange. It is based on C++11 and is independent referring the actual socket framework (example using SDL_net and TCPsocket is included). Check the README and example code for further information.
Just in case anyone wanted a good primer on how to do good game networking using a client-server architecture: http://gafferongames.com/game-physics/networked-physics/
I'm prototyping some stuff now using this architecture and it seems to work great in Python at least. Perhaps after I get some more experience under my belt I'll take a crack at this in C++.
Maybe we can summon @bjorn and @ablu who are most familiar with manaserv these days. The question, before starting to use manaserv would be, if we can model flare game mechanics using manaserv. Flare (the game) has lots of effects, the engine allows even more. We'd need to find out how good manaserv can work with such effects, at least I see that as a critical point. Movement, pickup/inventory should work fine although the inventory system is a little different in manaserv.
Hi,
what do you mean with effects?
Clientside effects?
We plan to develop mana as a mana server and a mana qml library. So basically you would do a client yourself and use our ready made components. Making the client should be relatively straight forward since you can reuse the qml parts... However this means that you can do whatever clientside effects you like (and want to implement).
Got some info about mana server/client? Well, it was mainly @Ablu consulting ;) Manaserv is mainly written on: C++, enet for UDP networking (http://enet.bespin.org/), libxml, physfs Mana client is mainly written on C++, Qt, enet. Qt gives ability to provide UI (QML based), also other basic types as QString to work with network. So looks like to use manaserv we need to depend on Qt. And rewrite data files handling to use manaserv xml format. Or fork manaserv to use our data format?..
And the last thing: mana client uses QML for rendering. So rewriting data file handling can end up with using QML code for rendering which is ready, and not rewriting current rendering SDL code to support new data handling.
Please share yout thoughts.
No need for fork for your own gamedata. We can generalise our parsers so you can write your own parsers plugins if it is required.
Also the main challenge imho will be with current game logic. Currently we handle changes in game every frame just checking if something has changed or not. Mana uses signals to process changes in game. I see the mana way much and much faster and do not like the way it's currently done in flare. Well it's done in SDL way in flare, and it's done on OOP way using qt in mana. The question is: can we use mana network code without changing current logic to signal-based? This will need mana code investigating...
I doubt that reusing parts of our qml client in your sdl client will bring you any benefit compared to the effort it will require to integrate the changes...
If you want to make a flare mmo i would suggest you to use our qml library, rebuild your flare ui over it and rely on our logic of libmana and the server. So you "only" have to maintain your game-data and the thin layer of clientside ui wirering (where you can reuse many of our components).