Pillow fight.. which computer should handle the pillows?

[nrd]

Hi, can you tell me how you would solve this? Imagine you would want to create a pillow fight game. There are 30 or more pillows, and about the same amount of players.

I have one premise: Everyone is no cheater. Everyone is good and there is no hacking and no AI-bots either. My concerns are about saving resources and having a good approach in general.

I've made one decision already: The players send their positions and input. That was an easy one. Due to the premise (all are good), I just trust them, and it's ad-hoc.

But where should the pillows be handled, where are their positions stored? My first ideas are:

1) Server does everything. It accepts input that will move pillows (e.g. player throws a pillow) and it computes the current position of all pillows.

2) Clients (players computers) do everything. They ask the server for the right to calculate and decide pillow positions/speeds of pillows near the player.

3) Mixture of 1 and 2, especially "the Server will only broadcast certain decicions (pick up, throw) and turning points (pillow from now on just falls or so, server can calculate the position very easily from now on)

I have no really appealing approach. In fact I hate the problem so much that there will be no pillow fight game for now.

(my actual game would differ, but I think If i knew how I would write a pillow fight game, I'd knew enough for the other game I think of)

[nrd]

I try to improve my question. I think it might be a good idea to remove the premise. Then there would exist cheaters, and then finally I'd prefer to say the server has to handle the pillows fully. It would always calculate their physics. And in the development process, when I start making the clients calculate the physics too (which should look smoother than transmitted positions), then I could - but don't have to - free the server from calculations if they are not needed (for other clients etc).

In short: Neutral objects: At first the server here handles everything. Later: try to make physics look smooth in the browser. Even later: try to optimize the server performance.

I'm new to the subject, still knowing virtually nothing.

[Nesh108]

Heya @nrd, welcome to the community and very interesting question.

The premise of 'no cheaters' (although you later remove it), it's quite important as it changes stuff around. Let's quickly handle them both:

- No cheaters: the position of each player, their action and such, is shared peer-to-peer (either directly or through a 'dumb-server'). Each player sends their data and the receiving players apply those actions to their world. Done.
- Simple with cheaters: same as before but now everyone who receives also needs to check whether the new player data contains valid moves. This is done with common local constraints (e.g. there is no way a player moved more than X pixels in a single frame). This still works well until you start adding stuff that actually allow the player to do 'impossible' stuff (e.g. teleportation spell in RPGs or powerup kits in FPS, etc.).
- Complex with cheaters: now the server becomes intelligent and handles all the stuff. Now the server is the judge of everything and decides whether a move is valid or not. Similar to the local constraints but with less chance of people messing up the system by changing incoming packets (because weird things happen if my computer rejects a move that another player accepted).

This is a very brief and simplified idea of how you could go about handling the stuff. In my opinion, if you are aware of the tricky parts (allowing teleportation and normally impossible actions) and know your scope (the game you are making), you should always handle cheating, so you don't have to change too much stuff when the game evolves.

If you want to know more, this set of articles does a great job describing the idea behind Networked Physics: http://gafferongames.com/networked-physics/introduction-to-networked-physics/

[nrd]

Thanks a lot. The idea that players themselves check (some) validity of other players actions was completely new to me.

The link is a great help, too. According to the article I have (unknowingly) started with a snapshot-technique (in my prototype the player objects repeatedly do: snapshot, then step 1 of lockstep), which the author recommends for large player counts (and beside that for non-deterministic physics). I think I'm doing the snapshots to later save server traffic for out-of-reach-phases (times when distance between two players is too big for interaction, which would be the blog authors non-determinism maybe). Maybe that's why it's good for large player counts. Didn't really really read it.

He recommends UDP, which for HTML5 would be WebRTC and brings me into trouble. (Slither.io doesn't use it, does it?)

Kind regards

[Nesh108]

18 hours ago, nrd said:

He recommends UDP, which for HTML5 would be WebRTC and brings me into trouble. (Slither.io doesn't use it, does it?)

There should be a UDP extension for Slither.io, look into it  

Also remember that if you are not an expert in networking, using UDP badly could have worse performance than a TCP done well.

[nrd]

My main pillow fight problem has become that I'm a bad player at any game. It seems senseless to go on, I wouldn't know how to create a thrilling game for those who are good at playing games.

[Nesh108]

There are more people bad at playing games than there are good ones. I know so many people who aren't even aware of the WASD keybindngs and another set who swears by it.

Never forget to always start making games YOU would enjoy. Although we are intrinsically unique beings, each of use share many features with many other people. If you are bad at games then make it a very straightforward game, easy UI and no hardcore grinding stuff. Just pure mindless fun. And playtest it a lot (you are not, at any given time, a valid playtester).

Don't give up @nrd

[nrd]

thanks so much for the cheering words. and again i had missed these points totally..

it's pre-alpha. and i'm really thinking hard whether it could be fun. i doubted it and therefore didn't like to go on.