next »

[molikto]

Hello,

I am working on a two-player online game, turn based game, but unlike traditional turn based games, the game mechanic requires the players move their pieces simultaneously in one turn. So there is a problem that two player can move to the "same place" after one turn.

 In the beginning, I thought I can use a grid based map, and allow multiple pieces per grid, but it doesn't really works well (also because I prefer hexagons but it is hard to use hexagons in a city-building based theme)

So I am thinking use a continuous map, then I think to ensure that the game doesn't looks wired if pieces are too close, I  still need to do some collision detection and push the pieces back somehow (in server side).

Any comment, ideas? Thanks

(also highlighting the allowed area by length in a continuous map with obstacles is another problem)

[bateleur]

If you're running a complete game engine server-side this is pretty easy to do. The best way to avoid a horrible mess is to process the turn as a series of very short sub-moves (like video frames, except that you're not rendering to a screen) and correct collisions after each step. That way you'll never run into a situation where fixing collisions can lead to potential loops and/or moving in unexpected directions.

[AaronB]

If I understand you correctly, then the server is definitely the place to resolve this issue.  If it doesn't break the game mechanic, then randomly accepting the move of one player and rejecting the other would be the easiest solution. In other words one player would just not move for that game turn.

[molikto]

If you're running a complete game engine server-side this is pretty easy to do. The best way to avoid a horrible mess is to process the turn as a series of very short sub-moves (like video frames, except that you're not rendering to a screen) and correct collisions after each step. That way you'll never run into a situation where fixing collisions can lead to potential loops and/or moving in unexpected directions.

There is a problem with intermediate states. The final state might be a valid one with no collisions, but they might collide in the "sub-moves"

[st33d]

Simplest solution I can think of is to define a legal play area for each player. You can play in those spaces only, not in ones that have clashing issues. If you do first come first served then you create a meta-game where people where mechanics favouring playing first are affected by server lag, and mechanics favouring playing last result in both players stalling the game because doing nothing is optimal play.

The trouble with rejecting either player's move is that unless the reason for a failed move is transparent to the player then what they experience looks like a bug. At which point they will stop playing your game because it is "broken".