Games B4J web server for multiplayer turn-based games

[LucaMs]

First of all I'm writing this post to beat @ilan on timing

I would like to have a kind of template (basic design) to create B4J web server for multiplayer turn-based games.

For example, what can be the best structure for messaging, including any confirmations to be received by clients.

I write a lot approximately for the reason mentioned in the first line of the post ; eventually I will specify better in a later post.

 

[wonder]

That's a very good idea, I've actually thought about experimenting with it myself.
MQTT is a good candidate for the base framework.

 

[LucaMs]

Now, with more calm , i can try to explain better what I mean.

MQTT is a good candidate for the base framework.

"Unfortunately," I don't know MQTT (I know only the basics and I did not understand fully what is its main purpose, why it was born. Perhaps it was mainly created for "Internet of Things"); probably it is very suitable especially for a possible chat alongside the game, which is exactly what I would do.


Trying to develop a B4J web server for a multiplayer turn-based game, I have encountered many difficulties and, above all, you can think to implement every aspect in many different ways.

One of the many examples I could do is data exchange and calling routines between servers and clients (including in this case I had to also face the problem of obfuscated apps). The constant exchange between server and client call-answer and vice versa involves writing a lot of client's routines and many jumps from one routine to another.
It would probably be helpful to have a set of message types according to their purpose.
For example, when the server "executes" a routine on the client, the client may have a Select that executes the corresponding routine; but may this slow down too much communications?

Much of the project (projects) should be developed by creating classes that have well-defined goals and standards, with well defined relationships between them.

Not only that; I think that to obtain a good "template" should be very well done a preliminary study but by many excellent minds, better than mine


That said, I am afraid that this thread will die in this instant

 

[LucaMs]

I can not pretend that Anywhere Software develops this kind of project(s); we could do it ourselves, but how to organize the work?

 

[tpakis]

I think it's an excellent idea, but we should also consider firebase realtime db instead of b4j

 

[LucaMs]

I don't know even firebase realt time db; if it is only a db, I think that it is not enough. Perhaps a mix MQTT + that DB?

However, I would prefer to remain independent from various sites, including Firebase.

 

[wonder]

I didn't read any articles, I formulated this in my head, using my own intuition. Feel free to correct me.

Let's imagine multiplayer Pong.
First of all, we must decide what kind of implementation we wanna go with...

Server-based:
- The game itself (main cycle) runs on the server, receives input (keyboard, touch, joystick) from the clients (base64 string, for example).
- Both clients receive a "game state" or "snapshot" from the server, as an encoded string (paddle position for player 1 and 2, ball position, direction and velocity and score)
- Both clients render the given frame, based on the server information.
- You can use different renderers for each client, for example, LibGDX for Player 1 (B4A on Android) and Canvas for Player 2 (B4J on PC)

Peer-to-peer:
- The B4J server acts as nothing more than a message brooker
- Both clients run the full game (main cycle, physics, input, etc)
- Each client sends its "game state" to the server
- The brooker (server) determines the integrity and validity of each "game state"
- The brooker corrects and/or predicts behaviour (movement) in case of client lag
- The brooker then syncs both "game states" into one and sends the resulting frame back to the clients
- The clients render the received frame

Peer-to-peer (master/slave):
- The B4J server acts as nothing more than a message brooker
- One of the clients (master) takes the responsibility of running the full game (main cycle, physics, input, etc)
- The slave client sends its "game state" to the server
- The server checks (and auto-corrects) the integrity of the received "game state"
- The "game state" is piped from the server to the master
- The master processes the slave's "game state" and outputs the resulting frame to the server
- The output frame is piped from the server to the slave

 

[LucaMs]

Server-based. I'm referring to games like Zynga Texas Hold'em Poker, then a card game.

It is not so easy as you can imagine, @wonder.

Thinking to a WEB server, you need to use a websocket object, a websocket handler.

You need to decide which object you need; for example, having a websocket handler class, which contains obviously a websocket object, you might decide that this class represents a player but it could be a user, before he chooses a game-room, and he could be a "chatter" if he enters a chat-room. So, you might use a Role type, a simple variable, or you might use different classes (sub classes) for each role and assign the websocket handler OBJECT to them.

There are many BUT many things like this to consider, to establish, to organize.

Just to say, another example of the complexity.
The user chooses a room, GameRoomID; the client sends this ID to the server. At this point, many things have to be made and checked:
a) the availability of the room (in the meantime, another user may have chosen the same room or the room may have changed its status);
b) the position around the table;
c) the order of play;
and lots of other stuff which is not expected immediately (also, you need to choose what you should save "permanently" (db) and what can be simply stored in memory (property of some class)).

Everything is much more complex than it seems.

 

[LucaMs]

2016

Server-based. I'm referring to games like Zynga Texas Hold'em Poker, then a card game.

 

[ilan]

writing a multiplayer framework is something that I have on my list. the problem is that because of the lack of time I am not sure when I will find the time for that. but it is something that I definitely want to do.

this is the logic I want to use:

Peer-to-peer:
- The B4J server acts as nothing more than a message brooker
- Both clients run the full game (main cycle, physics, input, etc)
- Each client sends its "game state" to the server
- The brooker (server) determines the integrity and validity of each "game state"
- The brooker corrects and/or predicts behaviour (movement) in case of client lag
- The brooker then syncs both "game states" into one and sends the resulting frame back to the clients
- The clients render the received frame