I am planning on working on a game this summer. I’ll probably start in July. Anyways, I am planning on to code a game turned based tactic game like “Fire Emblem” but with a twist; both players give commands to their units (I’m calling it the “command phase” for the mean time), and then, the units from both sides will execute the commands simultaneously (I call it the “action phase” or “live phase”. I realized that there is a game similar like it called “Shellshocked Live 2”. In one of the game modes, every player select their target and aim first and then all tanks shoot simultaneously once.
I need help on planning the framework of the code. Firstly, I would appreciate help on setting up the game board. I want to make clear that the game board is going to be like “Fire Emblem” not “Shellshocked Live 2”. I might be able to figure this out through the Unity Rouge-Like Game Tutorial but other input is appreciated.
Then I need to code for the “command phase” where players can give orders to multiple units. And then somehow, I need to transition into the “live phase” where all the action are executed. I was thinking of keeping the commands from the players as variables and which would cause the execution in the “live phase”. What are your thoughts?
If you read it this far, Thanks. Just some information about my game development experience: I am a beginner in game development, I recently went through a YouTube tutorial on how to code a game in Java. I had just taken AP Computer Science/Programming this last school year. I definitely would like to write the code myself; I just would like some guidance on how to make my game concept come true.
One way you can tell I’m a total noob is if I placed this thread in the wrong place. I’m sorry if I did and in that case, would anyone be kind enough to put this thread in the right place?
A few search terms come to mind. I believe this kind of gameplay is usually called “synchronous turn based”, you might find some articles about how to build something like this on the interwebz.
You might also consider looking at the “command” and “command queue” design patterns to store the “chains” of instructions that have been given to the entities in the game. How complicated are the instructions going to be per turn? just “move”, “shoot” or can it be “plan: move here, enter cover, throw grenade there, overwatch pointing that way: go!”
For the phases you’re probably looking at a really simple “state machine”, with user input handled in the “command” phase, and the instructions being carried out in the “action” phase.
I haven’t revealed this detail yet, but in the live phase, it is not exactly simultaneous. A unit will be chosen at random, from either side to carry out its order until every possible command is carried out (maybe the unit dies before he can execute his order).
As for the collision brought up by Mycroft, I never thought of this event. Thanks, for the heads up! With that in mind, I think I would like to make it so that if a unit tries to move into a spot with another unit, they will engage in hand to hand combat with the victor claiming the space and the loser dying.
The reason I brought up the collison (other than the fact that it’s a problem) is that you’re going to do better if you know what happens in every situation (to a reasonable degree) before you start planning the code.
You’ve just added a totally new element to your design. Does it reinforce your project goals or divert you from it?
Do your best to understand the core of your project and avoid these un-expected additions as much as possible. These are tasks that when looking back, you identify as feature creep, that slowed development and kept you from your goals.
That’s going to be hard for players. If you’re telling people that it’s synchronous, but it’s really a random order. This means that the same board/unit/actions will have different outcomes.
Not only does that make it difficult for players to develop meaningful strategies, it makes it almost impossible for you do debug.
@steadmuffin , you should play Frozen Synapse. It’s an excellent example of turn-based-but-simultaneous gameplay.
It’s very hard to lay out the entire design of a system like what you’re proposing. It’s not something that can be known, you have to find it through trial and error. The best advice I can give you is that you should not be afraid to try an architecture, and then throw it out and start over if it becomes unwieldy. Do that early, not half a year down the line.
Oh, and following up on what @Mycroft , I don’t think I would play the game with randomized unit order. It prevents the player from making plans. Doesn’t sound fun.