Dual Player

[ghost]

Could you please add a dual player mode? I'd like it to be through Wi-Fi.

[mjaun]

This of course requires a lot of work. How should this dual player mode exactly work? Both player are participating on the same game and both are able to place/control towers?

[ghost]

I know this would require lotta work. I was more thinking about against each other. Example gameplay: 1. Both players place some towers 2. Player 1 presses "Next Wave" 3. A popup asks what things to send at player 2, where each thing costs credits 4. Player 1 presses "Confirm" 5. Player 2 does step 2-4 6. Both players have now confirmed and the next wave starts

[zmk4]

Player 2 gets to load his offensive wave order. No upgrades. The only changes is to replace "ai" user.

I would prefer BlueTooth [pan] for less power consumption.

[ghost]

@ZmK: I prefer Wi-Fi, since Bluetooth is very buggy on my phone, but IMHO a choice between them would be good. So, you were thinking that player 1 gets a normal screen and player 2 only sends the enemies to player 1 instead of my suggestion? That'd probably be easier to implement, but I still prefer my own suggestion, so maybe we can have multiple dual-player modes.

[jkufner]

I see two multiplayer modes: Co-op and Duel.

Co-op would mean two players build on a single map with two entrances (north) and common exit (south). There may be three teritories, one for each player near their entrance and common teritory near exit. Goal is to destroy everything. Each player earns credit for destroyed enemies, so it includes competition too.

Duel can be done using two entrances and two exits. Each player sends enemies to the other player. The entrances should be somewhere near middle in form of a spawning point, or maybe from a side. Exits are in back. Player can spend resources to build towers or to send more enemies. Some amount of enemies will come anyway as it is source of credits.

[jkufner]

Ad communication: Take a look at KDE Connect. It has some auto discovery, key excange, and it is open source.

[ghost]

@jkufner: Nice co-op suggestion! But I don't fully understand your duel suggestion…

@reloZid: What'd be the best way to do this? I mean things like:

• P2P or server-client architecture?
• How'd a player discover the other player when on Wi-Fi? UPnP?
• What protocol will we use for connections when on Wi-Fi?
• In what format will we send data over a connection? And will that format be the same for both Wi-Fi and Bluetooth?
• How'd we integrate it into the current code?
• What libraries will we use? Or won't we use any libraries?

[mjaun]

I would go for this API:
https://developer.android.com/guide/topics/connectivity/wifip2p.html

Concerning format/protocol I would probably use XML over TCP because the project already uses a XML library.

Another idea for a game mode would be the following: The game sends very few enemies to both players. As soon as a player kills an enemy it instantly appears at the opponent's game (maybe a little bit stronger this time).

[nbcygh]

We need two mode,I prefer:
jkufner' Co-op mode. but should with the option to share the credits and the tower control.

and reloZid' Dual mode. simple and competitive. or more simpler: just share the control of the next wave. so the development effort can be decreased and still be funny and we play with friends soon.

[civyshk]

My thoughts about a multiplayer mode

From a player point of view

• The credits are shared.
• Each player has permissions about:

    Create towers         : Everywhere, on its own plateaus, nowhere
    Upgrade towers        : Every tower, its own towers, none
    Change tower settings : Ditto
    Sell tower            : Ditto
    Start wave            : Yes/no

From a developer point of view

Client-server architecture. One player (server) creates a game, awaits players to join (clients), sets game options and starts the game. I guess this approach could be wrapped with wifip2p or bonjour services for an easy discovery in a local network.

About game synchronization

• Key events
  Things that happen in the game (triggered by the player or by the game loop): Wave starts, tower is created, tower is upgraded, tower settings are changed, enemy dies, enemy exits the map, etc.
  From a client perspective, those events can be catched and sent to the server across network. The server will confirm that action and broadcast it to every client so clients can finally execute it.
• Important events
  More events: Tower spins, enemy moves, enemy is damaged, enemy heals, bullet moves, etc.
  These are related to movement and need to run smoothly. The client can/must run them even without informing the server. The server should periodically send these objects' state to clients so the game doesn't diverge.

Last note

Synchronizing a real time game across network is a tough task. Has @reloZid thought about whether this is a feasible task or not? My understanding of the code is little so I cannot tell. But it's well organized so I'm looking around trying to grasp how the things work.

[betsythefc]

For client/server models you could piggy back on the syncthing protocol, as it uses IDs and public keys to identify devices/users. This would mean that you wouldn't have to be on a local network, and there would be no need to host dedicated servers to run it, as it's completely decentralized.