Networking: Clone War

As a project we were tasked with working in pairs to emulate the 1985 game Spacewar in XNA. We had to maintain all of the core gameplay of Spacewar, although were were told to specifically not include a few aspects.

Overall, Lou and I did a pretty good job. My previous project in Networking already provided most of the core systems and elements needed to create the game. As such, within an hour or so of starting, we were quite far along.

One of the requirements the initially seemed like an obstacle was synchronizing "game mode" data across all clients. XNA doesn't provide an interface for automatically synchronizing settings or options that are not directly related to the network session. As such, I had to use a bit field stored in a byte to transfer game mode related data from the server to the clients.

Lou's blog: http://lounetworkingforgamesblog.blogspot.com/
Professor: http://prof.johnpile.com/

Production

Stage 1: Establishing the Foundation

As we slowly get closer to challenging Stage 1, our initial ideas have fallen away to leave one our Push mechanic. Although it is a single mechanic that we are focusing on, it leaves a wide range of possibilities to explore and iterate on.

Mobile Device Controllers

One of the biggest and most interesting ideas we are pursuing with the Push mechanic is that idea of a "Massively Multiplayer Local" game. The idea is that everyone has a controller in their pocket, even if they don't realize it, they would just need to download an app, connect to the game, and play.

The largest hurdle with this idea, currently, is designing and implementing a strong and reliable input setup. We have two iterations on the mobile controller currently, one with dual virtual joysticks and the other using tilt rotation and a throttle control. We have brought both to QA and received positive feedback on both, with some issues brought up that still need to be looked further into.

Production

Stage 1: Establishing the Foundation

As we have continued to meet and discuss our ideas, the concept of Coop-Push has itself been pushing to the forefront of our thoughts. On the other hand, we are concluding that the Space Combat concept leaves much to be desired and would quickly rise out of scope.

Coop-Push

Through the last week, we settled down on what experience we really want to promote with this concept. By focusing on the cooperative mechanic of the game, players will connect with one another and see each other of valuable to their own success, rather than an obstacle to be removed. This view is often lost in games which more often then not, put players on opposing teams or create huge gaps in ability and power between two players on the same team. We want all of our players to have similar, if not identical, abilities that much be amplified in power by working with other players.

GPS

Another idea that has risen over the last week is that of a GPS game. The initial idea rose from the idea of Hunger Games, where players must collect resources to survive. This alone, wouldn't make for a very interesting game, let alone any reason to use GPS, but the idea expanded to be a "hide and seek" type game. The initial concept is that players would be randomly assigned roles, Seekers and Hiders. The number of Seekers would scale with total players, but would generally be one.

Hiders would be given an initial amount of [resource] to survive on. As time progresses, their [resource] depletes and they must find and collect more. [Resource] would be shown on the GPS map to all hiders(perhaps seekers as well) for them to collect to stay alive. This would mean they have to stay on the move and would not be able to just hide away for the entire game.

Seekers would also use a GPS enabled device, their [resource] would be replenished by finding Hiders. Their GPS would also show "blips" on the map whenever a Hider made "noise", measured by the accelerator of their device.

Whenever any players' [resource] was depleted, they would lose the game, sending a message to all other players. The game would end when either all Hiders are found or deplete their resource, or when all Seekers deplete their resource, which would determine the winning "team".

Production

Stage 1: Establishing the Foundation

Over the last week, we have fleshed out, revamped and reworked our concepts. We still have a handful of potential candidates, but are more heavily focusing on two of them, dubbed Coop-Push and Space Combat.

Coop-Push

Last week, when we presented our cooperative space combat game, it was suggested that we take a better look about the actual cooperative experience and focus in on that aspect of the game, rather than on the combat side of it. We decided to do both, what we now call Coop-Push is what came out of the deeper look into the cooperative experience.

The core mechanic, as is currently envisioned, is a group of players working together to achieve some goal, generally by moving some object around as a team. Each player on their own would be unable to meaningfully move this object, but by working together, to either move obstacles out of the way or to push the object, they can progress through the puzzles.

Space Combat

While we were iterating on what the cooperative experience meant, and how we could focus in on players really working together and relying on one another, we didn't want to drop our idea of a cooperative space combat game. We have had further discussions on what directions we could potentially take it and how we can make it more engaging and fun for all of the players.

Production

Stage 1: Establishing the Foundation

With the start of our Senior Production experience, we have set out to develop a handful of concepts, one of which will eventually develop into our production target. Each of these concepts must be fully explored and properly planned before we decide on one to set our sites on. As of this week, we have two ideas that have been our initial focus, among a set of five.

Growth and Reduction

This idea is about size as a resource to manage. As a cooperative puzzle game, the two players must work together to manage and utilize their size as best as they can. Each player controls a character, one always grows when they move, the other always shrinks. They can, however, switch sizes with the press of a button.

This idea manifested while we were initially discussing possible mechanics that we hadn't seen before in senior games. We also threw around the possibility of it being a competitive puzzler, but decided that it would work better if they players worked cooperatively.

With each player depending on the other to provide them with the resource they need, their size, it will foster companionship and agreement between the two players. They will rely on one another to progress and will find that if they try to go it alone, they are either too small to handle the challenges or two big to achieve the finesse they need.

Cooperative Space Combat

Our second idea is about a team of players, we are unsure of the exact size, but are thinking around 5, cooperatively controlling a space ship. One player would act as the helmsman, and captain, which each other player would assume command of a turret on the hull of the ship. They would be tasked with completing certain objectives, while fending off AI controlled enemies and environmental hazards, such as asteroids and solar flares.

This idea developed from both Mitchel and my interest in space games and Mark's interest in imagining and modeling ships. The core of the game, a cooperative experience of controlling a space ship, also manifested from an interest in games like Artemis, while questioning their lack of real action, as they are much more often based on bridge stations, rather than players taking a direct role in the action.

One of the things I like most about this concept is how open it is to change, as the core aspect of the game is just the idea of cooperatively controlling something, in whatever form that may take.

Networking

TCP vs UDP

The question of whether to use TCP or UDP for a networked game is generally the first network related question that needs to be answered. Each have advantages and disadvantages to them, and some games use one, while some use the other. Overall, it is probably safe to say, most networked games use UDP.

None the less, there are some games, and certain genres of games in particular, that often rely on TCP for the guarantee that packets will arrive, even if they do take longer. Often MMO games, such as WoW and Rift rely on the reliability of the TCP protocol.

Why TCP?

There are certain aspects of the game that developers want to have much more control over, in regard to server-client interactions. In particular, Chat will often use TCP as when a player sends a message, they expect it to arrive properly and in full. Similarly, when a player uses an ability in any game, they have a certain expectation that it will be executed in the game world. These are places where the reliability of TCP trumps the potential loss in speed, in many cases.

What should use UDP?

Similarly to the uses of TCP in MMOs, they also rely on the speed of UDP for interactions such as movement between the client and the server. This is often done through the client sending its direction and speed to the server, which will respond with where the player should be located based on that information. The client, while waiting for the server's response, will do what is called Client Side Prediction, where it will use the data it sent to the server to predict where the server will tell it to be. In these cases, a missing packet will often have a much less noticeable impact on the player than the loss of a packet related to the use of an ability, for instance.

If movement used TCP, rather than UDP, it would likely increase the latency between when a player changed their input and when their character responded to that change, which would impact the sense of immersion in the world. As above, the reliability of a single movement packet isn't nearly as important as a chat message or a ability, but requires more speed.