The Big Three
- teejaydub
- Apr 29, 2018
- 4 min read
Another day, another game in development. I’ve put the previous title on hold and begun development to explore an idea that I’ve had for almost three years. It is a competitive turn based deck building game that relies heavily on the concept of stealth and deception. If it sounds like it would be a suitable board game, you won’t be surprised to know that I’m simultaneously exploring this game in tabletop form.
In the game, players control an elite combat squad with the goal of eliminating the opposing team. Players build a deck by capturing loot and purchasing equipment in the Armory. Those cards then get placed alongside squad members secretly positioned at any of nine unique locations. In the following Encounter phase, combat begins. Everything is revealed - traps go off, firefights ensue, and the loot belongs to the victor. Your surviving battle-worn squad members must get ready for redeployment as a new round begins.
Game development is just over a month in, and core gameplay is being established. The challenges this week (and for the weeks to come) are: AI, Online Multiplayer, and Replays. As you might imagine, this will probably be a multiple part post. I didn't separate the three of them, though, because I believe they can actually be coded together in such a way that each is built upon the other and utilizes the same infrastructure. This way, the individual systems won't be totally detached or discrete, making the written code cleaner and more efficient from the ground up.
An overview at the organizational system would look something like this:
The concept is a system that reduces the extensive inputs of a player into simplified, well-defined functions. There's no need to log and record a specific thing like mouse coordinates in a turn-based game for the purpose of AI, replays, or online multiplayer. Once this concept is understood, we can begin to classify the more generalized actions of a player into a significantly more meaningful set of actions.
The rule: Every action that a player can take that could influence the opponent or the board will be its own function.
Playing a card from your hand to a location? We'll have a function for that. Purchasing a specific card from the armory? Yup, a function for that. Moving a squad member to a new location? Definitely its own function. It would not, however, include things like: changing the camera view, a player drawing cards from their own deck, or shuffling their discard pile into their deck. Those are actions whose outcomes do not affect the state of the board, nor the decision-making of the opponent. The distinction is important, as it plays into how all three systems (AI, online, replays) will be linked.
Replays
The first system we'll take a look at is replays. Conveniently, actions that influence the board or opponent are the only actions needed for a replay. Visually, during the replay, it is not necessary to see a player's hand or deck - only what is happening on the board: squad members moving around, attacking, collecting loot, destroying walls. By implementing this focused function guideline and logging each function as it is called, replays become simple to generate. Matches can be re-created identically by re-issuing the list of recorded commands to the functions in order to literally play back the game as it unfolded originally.
AI
This focused function approach efficiently integrates with the AI system as well. When looking at how the AI is to be structured, we see a script with many conditional statements that incorporate weighted values related to aggression, survival, and current board states to determine what actions should be taken by the AI. After calculations are made as to what the AI should do, the system will make a decision and execute one of the aforementioned functions - the exact same as those used for replays. If the AI decides to purchase a card from the armory, it will call the function to buy the equipment and log it in the replay script. Having a limited list of predefined functions to control all of the aspects of gameplay will undoubtedly be useful when the AI has to carry out what it has decided to do.
Online Multiplayer
The interoperability of the systems is fully realized when looking at the final aspect of the game: online multiplayer. As many PC games operate, online multiplayer will be facilitated through the use of a lobby system where matches are hosted and can be joined by friends or strangers. In this system, network issued commands will take advantage of the functions in a slightly different way, but nevertheless conveniently. Actions taken by the client computer will be sent over the network to the host. Think of the client as your friend that joins your game that you are hosting. On the host's end, the client's action will be processed just the same as if it were an AI issuing an action. For example, when your friend takes an action to move their squad member to a new location, the command gets sent over the internet to your machine, where it ends up in that same script in which the AI exists (but isn't in use since we're in multiplayer mode) and calls the function to move a squad member to a new location. Which, how conveniently, is where the replay log gets called to record the action. It is important to note, the inverse applies as well. When the host issues an action, it travels over the internet to the client, where the action is handled as if it were an AI opponent declaring an action.
The added benefit to this focused function method is the limited bandwidth that will be generated when sending these actions to and from client and host, since only crucial actions are being sent, and no extraneous data or variables are needed to be updated every frame.
留言