I guess the title says it all, someone told me to use stacks, but I really vision it. Could someone give an example?
Turn-based combat is a key part of many games and has a lot of components that need to be decomposed. An example of the kind of game you’d base your system off of would go a long way here, but I’ll use Pokemon as that’s something we’re all probably familiar with.
- A player interacts with an NPC (or presumably in your case, another player)
- The battle begins and the battle interface is revealed.
- Players select their moves and it is decided who goes first (In Pokemon, it is the Pokemon
with the highest speed value. - Attacks are performed. Return to turn 3 until the battle ends.
These are three separate modules that you’ll have to individually develop and test. There are a lot of questions to be asked here: what will the battle interface look like? How will we deal with other players trying to join a current battle? The list goes on. You can also break this problem down into a flow chart to make it easier to visualise:
Each of these modules can be broken down into their own flow chart, making up the decisions that must be taken.
In terms of the battle part, which I’m guessing is the main part of this question, the suggestion to use a stack is likely incorrect. A queue would be more appropriate. A stack retrieves the most recently added item (first-in, first-out), whereas a queue retrieves the first added item (last-in, first-out). The items being added to the table would be moves, in the context of a turn-based battle system.
To be honest, if we’re using a system like Pokemon where turns only end when users have both selected their moves, you don’t really need a data structure other than a variable for each player that stores their current move.
Data structures are only going to be necessary in a turn-based system where you can queue up your attacks, similar to this game (Star Wars, Knights of the Old Republic). You can see the user queuing up attacks in the red bar/box at the bottom-middle of the screen.
I could go into more detail about all of this, but I don’t want to risk answering a question you weren’t asking, so I’ll wait for more details on your end instead of info-dumping implying I haven’t info-dumped already
15 Likes
Thank you for the excellent response, just one more question, I presume doing this on the server is the right thing for a safe system, right? If so, would I just wait till there are 2 players in the server, when player added add it to the queue, and I guess… make the system from there? (Trying to make a join button rather then a World MMO game where you can just find a player and offer a battle.)
2 Likes
Yes, the safest way is doing the system on the server(Not all of it has to be on the server, of course)
1 Like
@StraightScared is correct - The standard benefit of handling on the client side is speed, which isn’t a necessity in most turn-based combat games.
It’s generally a good idea to do everything on the server side unless you have a specific reason not to. Every action taken on the client-side has security risks, so you want to limit as many of them as possible.
If this is a game similar to For Honor, where connection speed is a priority, you might want to reconsider this but remember that too much handling on the client-side nearly cost them their game. (I’m probably getting off-topic again)
The only thing you should need to grab from the client is combat input, such as which move the player wants to choose, such as clicking a button to attack. The attacks themselves should be stored on the server and applied to the player when called upon, so the user can’t access the properties of the attack to increase damage, for example.
As I mentioned before, the queue should really only be necessary if the player is able to “queue” up attacks like the Star Wars video I linked previously. If you’re thinking of using a queue for matchmaking, this could work but I would refrain from advising further on the subject as it’s definitely outside my area of expertise. Looking up how most modern games handle matchmaking would help plenty.
Lastly, what I want to stress most is modularity, which will save you plenty of pain and time in the long run. One module is not any more reliant on other modules than they should be, known as “loose coupling”. This prevents changes from one module affecting another in a negative way.
You’ve probably seen this joke before: 
This is the result of high coupling - where a change to, for example, your matchmaking system, has drastic effects on the combat system.
In a perfect world, these modules should be cohesive enough that you can swap different matchmaking systems in and out, like a mechanic swapping parts of an engine. You wouldn’t expect getting your car’s battery replaced would result in the wheels falling off.
If you’re interested in learning more about modularity, you can just google “Coupling and cohesion in software engineering” and you’ll find more than I could tell you on the subject.
8 Likes