Is it easy to make a Turn based Game?

Yes, but Turn Based Strategy. Strategy on it's own would cover both turn based and real time strategy genres.


Personally I'd say turn based games are much more complicated than real time games, but there are many variables that could make such an assumption wrong. I mostly only create turn based games as they are my favourite genre, I wouldn't recommend them to someone starting out, though.

Also AI, (I expect to get heckled by real-time AI programmers over this point, but hey) turn based AI is extremely complex if you want it to be genuinely challenging (and not derivative). The reason I'd say that's a sticking point in particular is that although there are solutions for turn based AI bending existing techniques to a unique set of gameplay rules can be much more complicated than in real time systems. When using techniques such as bitboards, or transposition tables, you can run into a lot of issues very quickly when trying to add new rules.

However, as the OP states a battle style of FF, the AI is significantly easier and in fact is historically not very intelligent at all, so that bit is easy, at least. But I stand by the point that turn based is hard simply because you have to work against an engines need to deal with frame by frame output for the logic of the game.

 

Lets settle in the middle and say they are Turn Based Strategy games

You are right on FFT, it would take a decent sized team quiet a while to make. One day I hope to be at a point I can make a cut down TBS game (nowhere on FFT scale), but here is hoping!

 

Honestly, by the time it's cut down you lose a lot the grandeur that makes those games so appealing. I wonder what casual, small scale, decently paced and fun turn based strategy looks like, is it a thing, and if it's all that inspiring.

 

There's a lot of stuff that makes TBS ... hard isn't the right word. Limiting is the right word.

I'm currently working on a tbs, the fighting side of the game has been pretty much the same and was always the easiest part. I've rewritten the strategy side like 100 times and it's taken the vast bulk of the development time.

The next title I do, I will not do hex/grid based. The big problem is positioning, hex or large grid based games require somewhat strict control over the positioning of characters and that comes with a lot of restrictions.

I would rather make the positioning more freeform and be able to use physics liberally as well as more natural animation (people tend to physically move around when they swing a sword, tbs animation almost always look like ass because the characters cannot truly move naturally).

I use coroutines everywhere to drive the tactical. Doing this is almost absolutely required if you want strict control over timing (which you need if you want to do many varied effects in sequence). I also use a pub/sub system for other notification in conjunction with the core coroutines that handle animations and sequencing.

In terms of AI - I would disagree, I think turn based AI is way easier than more freeform. All things equal, the range of option in a turn based is way, way smaller than in a more freeform game.

 

Then you think about real-time and somehow... real time is easier to get your head around. The physics work with you, the update-every-draw-call thing is there at your disposal. Honestly I think turn-based, grid-based combat was a solution to large-scale battles in the old days when they just couldn't realistically update the logic for all of those characters, they didn't have the juice to redraw that many sprites and run that many logic routines each frame. We take this stuff for granted, but in ye olden times you know every line of code cost a lot more.

Now, we're spoiled, we can simulate logic for every character in real time. I still think turn-based combat is cool because it paces out combat and lets you make battles very tricky and challenging, with smaller margins for error... because you've given people more time to think about their next step.

That game looks pretty cool. I wouldn't mind watching a "let's play" of it. That's about all I have time for these days.

 

The problem with not having turn based is that you can't have challenging multi character combat without it.

If your game has multiple characters and permadeath, you absolutely need the player to have full control over what happens. Otherwise they won't own the consequences.

Like, you tell a guy to move somewhere, something moves into his way, he takes a stupid path around the obstacle and gets himself killed... you can't have a game with perma death where thats possible.

 

True that. You need to make sure the player has total control and understands what choice they're making if you're going to punish them harshly for making mistakes. That's another cool thing about turn-based games, there's a finality to them, like chess. You take your hand off that piece and that's it.. There's no gray area.

 

I suppose this just depends on the complexity of the AI you are trying to create, I can only really draw on the games I've attempted, being mostly turn based strategy with a few real time strategies here and there. Chess AI, for example, has many many options to evaluate, and not much time to do so, I actually spent near on 4 months just tweaking evaluation scores for the engine to make it more effective at judging scenarios. Something like Final Fantasy doesn't need to make much of a decision at all, and much of the time doesn't even take into account what the player is doing, it can largely get away with picking from certain sets of actions almost at random, with that set being altered by game logic.

I think the difficulty of AI in both genres likely covers the same scale, so it would just depend on the type and depth of game, and in fact, the challenge wanted, from the AI.

I actually find that the most difficult bit of AI in strategy is making it stupid. The chess engine I made ended up far too smart for me to beat, and trying to add a handicap to the engine to create difficulty levels was a difficult task that I gave up on in the end.
In some of the other turn based games I've done, the AI was a little easier to make 'stupid' due to the addition of randomised factors that the AI couldn't predict. But the issue then was trying to make it not seem like the player only got one over on the AI when it had a bad roll of the dice, I never succeeded there either actually...

Making an AI believable is one thing I've never gotten the hang of. That's one thing that is probably much harder in real-time games I imagine, but the actual intelligence of an engine I've always found more difficult in turn based games. Perhaps my real time games haven't had enough depth to them to make the AI complex enough.

Though this post goes on a bit and kind of digresses from the topic at hand, so I do apologise.

 

I think Fire Emblem was a great example of how great permadeath an turn based work. I lost count of the amount of times i restarted some of the GBA versions because I lost a character

 

Don't forget X-Com, that has always been one of my favourite turn based games and had brutal permadeath, especially Terror from the Deep

 

Surprisingly, real time game is easier to do than turn based one. You don't have to worry about making AI pause until player's turn is done or blocking player's controls until AI/another player's turn is finished. But of course, despite the difficulty, it can be still done relatively easy, especially when you'll generalized AI model (like e.g. monsters in RPG Maker series), where each unit/enemy has differences only in parameters (type/number of attacks, strength, defense, hp, etc.).

So, while harder to do than realtime game, it isn't nearly as hard as people here make it out to be. The main difficulty is with making interesting enemies/units to go with it, but basic system (one unit/enemy) can be made relatively easy.

 

In terms of AI - I don't think it's possible that turn based (with well defined 'squares' or 'hexes') is harder than more open ended position based. The more constrained the options, the smaller the set of possibilities, the easier to deal with it.

Just take chess for instance and remove the sequence rules. Say that any piece could move at any time in real time. The entire way you approach AI changes here, since you can no longer even begin to evaluate out all the potential choices or possibilities.

Chess has a lot of permutations, but at the end of the day, chess has a finite set of potential positions or results. When you're dealing with something that has an infinite set of potentials, the complexity of the solution increases.

My AI routines for instance will generate out all the possible moves for a given character at a given time, then just select out the 'best'. The AI routine itself is just a call to 'sort' - the sort criteria is just a heuristic that evaluates the resulting position. The evaluation process can be simple or complex, but the actual AI is literally just a sort routine, the same basic approach drives most chess AI.

Getting equal quality decision making out of a realtime ai without the constraints of a finite set of choices is just going to be more complex and difficult by definition.


Just look at the complexity involved in crowd pathing algos and stuff, just dealing with how multiple moving characters might potentially collide or how they'd potentially avoid eachother alone is really crazy complicated. And that's not even a high level decision making process, that's just basic motor skills!

 

As someone who started tinkering with ai really early on, and sort of became obsessed with it, I'd like to weigh in on making AI seem dumb.

I'm not sure how others program AI, but I keep it extremely basic. I don't even try to pretend that they are thinking. They just have to behave correctly in the context of the game.

I like to add a little fudge to them. They shoot exactly at the player, plus a random vector range. You can even randomize the low end of the vector range, for extra hilarity.

The AI has a huge advantage if you've already figured out how to make it perfect without cheating. Just make it do the wrong thing, sometimes. Not always. Not something that makes no sense, just something slightly off.

This means figuring out what slightly off means, of course., for your game. It could be choosing an attack that isn't their strongest, or forgetting to heal by a low chance, or taking a step back when they had a clean shot. Just think of common mistakes players might make in that situation and try to emulate the end results, but don't make it too noticeable.

 

To clarify I'm really not even talking about making smart decisions. This is just stuff like having a bunch of guys walk around and not bump into each other or get stuck...

 

This is a little bit of an understatement, chess has huge amounts of board permutations*, and so many potential results that you cannot possibly store that information in memory (and just working out those results in the first place is the hardest bit to get right, see the horizon problem: https://en.wikipedia.org/wiki/Horizon_effect). And since you cannot have an infinite set of potentials, the comparison is rather void. Are there complex systems in real-time AI? Yes. Are there complex systems in turn based AI? Yes.

Like I said before, it really depends on the game as to how complex your AI is required to be, it can be complex or easy in either genre, game programming is all about finding shortcuts after all.

I wouldn't really class that as AI unless those movements are particularly important and have some weight behind the calculations, as in, the reason for them moving. The thing choosing why they move there is the AI, the movement is just navigation code, which is usually fairly straightforward, just my opinion there, I realise that they tend to get lumped together occasionally.

*it's around 10^120, which is an unfathomably huge number. To put that into perspective, we don't even have a unit name for the amount of data that would require to store in computer memory. Certainly an interesting figure, and that's not even the extent of the data a chess engine requires to make it's decisions!

 

Here's an example of good crowd pathing: http://gamma.cs.unc.edu/RVO2/ these techniques are used in many games and it's really, really far from simple.

My point isn't so much that chess AI isn't challenging, my point is that you're making an apples to oranges comparison and that on similar footing, the fewer bounds a ruleset has the more permutations are possible.

Sure, 10^120 is a lot. But let's say that you just remove the rigid turn sequence from chess. Now you have any piece able to move at any time with those decisions being possible 60 times a second, and multiple pieces able to move simultaneously. The possible board states within the first minute will start to exceed 10^120.

That's kinda the point. The more you restrict the environment, the fewer the choices, the easier the solution given the same level of expectation.

 

Ok I see where you are coming from regarding this comment, but this wasn't what I'm trying to infer at all.
I do agree that it is apples and oranges.
I'm not suggesting that a tighter ruleset introduces more permutations. I'm suggesting that in a turn based role, the extent of an AI's complexity becomes more necessary than one in a real-time environment.

You suggest that you would use the same kind of AI on a turn based chess game as if it were real time, but this is not the case at all, you would use a completely different system (apples and oranges, indeed).

And bringing this back to the Unity engine (since we're in this forum), the pathing system you mention is helpfully already implemented rather well in the engine for you
Your original comment using the phrase 'bunch of guys' didn't strike me as meaning a swarming system for whatever reason, so I took it to mean A to B navigation while avoiding things, which is pretty trivial (in the grand scheme of things). So I concede that swarming systems are an interesting problem to solve.

 

Take a look at a simple code example here: Turn-based Multiplayer Games in Unity3D using UNet – Divyesh Chitroda – Medium. No asset or framework required. Just using UNet make multiplayer turn based games in Unity3D.

 

I've been working on one for 2 years come October, not the battle system but the field module and menu module and data module so far....

I can say what is never mentioned about turn based systems or any rpg games whether action or turn based....What's never mentioned is the boring ol' management of data. It's not the battle system itself that takes up all the time, but rather creating and managing an organized database.

A battle system is just an extension of your data.

Here's an ability entry, and this is a very simple rpg I'm making:

Code (CSharp):

1.     [System.Serializable]
2.     public class Ability : Entry {
3.      
4.         public string IconFilePath;
5.         public int WhiteMagicCost;
6.         public int ManaCost;
7.         public int Power;
8.         public enum PerformOn { OneAlly, AllAllies, OneOpponent, AllOpponents, OneRandomAlly, OneRandomOpponent }
9.         public PerformOn performOn;
10.         public Element ElementRequired = new Element ();
11.         public List<Stat> StatsRequiredList = new List<Stat>();
12.         public List<Effect> Effects = new List<Effect>();
13.         public AnimationPrefab animation_Attack = new AnimationPrefab();
14.         public AnimationPrefab animation_Impact = new AnimationPrefab();
15.         public bool isThrown;
16.         public bool isSignatureAbility;
17.         public Guardian guardianRequired;
18.         public bool isAstralSynchronizationRequired;
19.         public enum PlacementRequired { Near, Far }
20.         public PlacementRequired placementRequired;
21.         public enum Character_Battle_Graphic { Stance, Block, Punch1, Punch2, Kick, ThrowProjectile }
22.         public Character_Battle_Graphic character_Battle_Graphic;
23.  
24.         public AbilityBar abilityBar = new AbilityBar();
25.     }
26.  
27.     [System.Serializable]
28.     public class AbilityBar {
29.         public enum BarType { None, Power, Agility };
30.         public BarType barType;
31.         public int Speed;
32.         public int Acceleration;
33.         public int Deceleration;
34.         public int Randomization;
35.         public int Time;
36.  
37.         public bool FoldedOut;
38.     }

To create an rpg you have to create almost like an rpg maker, or rather like a database editor. If you keep it simple enough I guess people go faster by using Excel.

Is it possible and how much time does it take, and is it easy? It's relatively easy and of course it's possible, but you have to understand how people go about making them. It's usually a stuffy team of bored out of their minds people working 9-5 M-F or long hours somewhere in some building in a crowded city in Japan. It usually involves a pretty experienced programmer at the helm because they have to fluidly understand data types.

It's definitely possible, though, and it's not insanely hard, just be prepared like with any game to be spending hundreds of hours on it.

The best thing to do by far would be to use a pre-made battle system and design an rpg around it, it'll save you a ton of time.

 

Yes it takes time and effort. I am working on a card based multiplayer game and yes I am pretty much bored too

 

Why this post was revived from the grave? Could a mod pelase, close it, I guess the answer was already pretty well answered.

 

Try this
https://www.udemy.com/course/turn-based-strategy-game-development/
Complete turn based strategy game course

 

Thanks for the link. I guess in this case, a necro was valuable.

I'll drop another tidbit of information.

I'm 5 years (part-time) into my turn-based tactics game, and in the past several months, I've been working on AI. A lot of my "first-pass-get it running" AI was tied up in MonoBehaviours and other Unity code. Basically, all of my gameplay was tied up in Unity code, which is naturally what happens when you use Unity, right?

Well, my lesson is try to decouple your gameplay code from Unity as much as possible. Have everything driven by interfaces and events into your gameplay code as a layer on top, using Unity.

In doing so, I am able to plop my gameplay code into a barebones C# application, and run tests and set up rapid test frameworks on it, outside of Unity. This way, I can rapidly iterate on my AI without even having to touch Unity.

What does this have to do with TBS/TBT? Your AI will make or break your game. If the opponent cannot even find or attack you smartly, your players will be bored. Rapidly iterating on AI is a must, and having to launch in Unity can easily kill your iteration time.

 

Use startcoroutine for turn based game, not in update.

 

Wouldn't this lock up the main thread?

Would running your turn based game logic and AI be better in a Jobs system, so it can use other threads. Especially if there are many units in your game.

 

I don't know what you mean.
How to do it then?

I mean, circulating game's scene change via state machine code, and at main game scene, starcoroutine for turn based logic. then stop coroutine if one game ends and go to lobby scene. (destroy main game scene or just main game object, then turn on lobby object)

 

The thing is a turn is just a state in your game code.

When it's the players turn the UI features available to them are enabled when it's the AI's turn the players turn UI is disabled.

But to get around the AI hogging the main thread (something coroutine would do, potentially pausing/locking up the game) you can launch it's planning it's move as a Job, then after it decides it's move update the game to do the move.

As far as the player is concerned Turns are just periods of time when they can use the UI and periods when they wait for other players or the games AI to take a Turn.

 

Turn based game should be built like every other game.

I wouldn't recommend coroutines because it sorta messes with your perception of the order of operations and debuging things. I personally would rather run timers.

I am not clear on the job systems but I would be weary of it as multithreading in general could mess up the order of your operations; either waiting on a return of a thread to keep things synced or skipping results which would throw everything out of whack.

 

Threads and Jobs are ideal for running your AI code which will be searching for optimal moves in a turn based game (even more so for RTS style games).

Otherwise you are will be interleaving updates that run ongoing searches across multiple frames and slowing down your games render loop.

 

That can be done during the Update per usual. Depending on specific needs may be beneficial to iterate over some things in chunks over multiple updates. Coroutines certainly wouldn't solve the issue though maybe making it simpler to construct. Multithreading might help speed the process with the updates just skipping operations while waiting for the return but I'm always skeptical of multithreading and ignorant to the specifics of the job system.

 

For instance just a general concept; AI's turn, frame one, find the next thing they want to do. Second fame AI decides which piece to move. Third frame AI decides where to move that piece; next frames waiting on the move to complete. Next frame AI decide if there is something they want to do with the one they just moved.

 

For complex AI multithreading is generally worthwhile, but the concept of chunking up over frames can work fine for simpler AI. Your example is a bit contrived, "deciding which piece to move" can generally be separated from deciding where to move, and is generally the hard (i.e. cycle consuming) part. You would need to split this phase across multiple frames (which of course requires an algortihm that can be easily split).

That said for a structured thinker, turn based games are one of the easiest to do. They generally map extremely well to a state machine: state + data + rules = outcome. Of course there might be a large amount of content, but conceptually thats just more of the same. The AI can be an exception, and can range from horus to Deep Mind ... that said it is usually not too hard to turn out a passable AI if you can come up with a reasonably good state evaluation funciton.

I've turned out quite a few such games for customers over the years, and with a clear rule spec the core engine is usually done in days or even hours for a smaller game. This game, for example, was done in a weekend: https://steamcommunity.com/sharedfiles/filedetails/?l=spanish&id=817596699 (it was never released to Steam but was released to the original mobile targets).

 

Multithreading is very complex and has many caveats that I believe a beginner would likely overlook. My example explains how it should be handled in any language without any additional tools; basics of how a state machine works so hardly contrived.

I believe that is just a preposterous time frame that the OP should not think is the norm. Just setting up basic screen transitioning or control scheme can take that long.
Games are very large and complex creation so don't feel rushed and just create at your own pace. Test everything you implement thoroughly to prevent problems as your project grows.

 

That's why the Unity Job system API is designed to make it easier https://docs.unity3d.com/Manual/JobSystem.html

It's almost as easy as calling a function once you set it up.

 

Kinda feel like I'm hijacking this thread for this so I'll keep it relatable.
So 'handle.Complete();' would force the program to halt at that line until my job has finished?
For example:

Code (CSharp):

1. //starting my job on the other thread to run iterations and calculations.
2. JobHandle handle = jobData.Schedule();
3. //while that job is working to give me a result I can do some other stuff unrelated.
4. anotherScript.DoOtherThings();
5. //now I need to wait for that data for my AI.
6. handle.Complete();
7. //now that I have access to my finished job data I can run the AI.
8. AI.Update();

And you have you ever had issues with it sometimes taking much longer to return then your generally expecting even if rarely?

 

I might be staying the obvious, but while you may be able to jobify some of the processing for one AI player at a time, you shouldnt multi-thread the decision making for multiple AI in a turn based game in the same way you would for a real time game.

This is because the order of events is important (otherwise it’s no longer turn based).

 

What if you AI scans for the best moves available while it's waiting for other players. Then adjusts it's list of available moves based on what other players do until it's turn. Possibly doing more work than is needed but would make for a very snappy AI turn time.

 

Only handle.isCompleted can be tested every frame for example:

Code (CSharp):

1. //starting my job on the other thread to run iterations and calculations.
2. if (!handle) handle = jobData.Schedule(); //setup new job
3.  
4. //while that job is working to give me a result I can do some other stuff unrelated.
5. anotherScript.DoOtherThings();
6.  
7. //now test if AI is completed and process results.
8. if (handle.isCompleted) AI.TakeTurn();
9. {
10.    board.Dispose(); // tidy up data AI uses.
11. }
12.  

 

I suppose it depends on the finer points of the game in question, there maybe some pre-planning you can do in parallel, but in turn based games like Civilization the vast majority of processing has to happen in sequence.

If Player 1 is human and completes their turn, AI Player 3 shouldn't make any final decisions until he knows the state of the game after AI Player 2 has moved.
Player 2 may have invaded Player 3's land or given them a massive gift, and Player 3 can't accurately evaluate unit positions and pathfinding until they know Player 2's moves. You simply don't know until the turn is complete, that's the very essence of a turn based game.

It would be very easy to introduce unwanted behaviour or strange AI decisions into the game unless you are always evaluating the current state of play.
Where parallel processing could help is to batch process things that need to be done for one AI agent (such as checking each unit to see which one is optimal to attack). That would be safe and a very good thing to do where possible.

 

Nothing final more like scan and make a list of available moves that can then be refined as more turns are taken. Think of it like working out all the moves available then pruning and/or searching more as the turns progress. In theory by the time it's the AI's turn it should be very fast at making it's move.

 

You still have to check the game state as it is now. All the calculations you did for one AI agent while another player/AI was making a move are redundant once they have made a move because you don’t know what they were going to do.

Has he fortified his base? Is he now at war with you? Has he blocked your path?

The AI won’t know the optimum course of action unless you run all the same tests over again.
Trying to multithread turn based AI in this way will lead to more problems than it solves.

Or at the very least results in the answer to the original question being “no”

You just want to concentrate on optimising a self contained turn as much as possible (and that possibly could involve multithreaded processing).

But trying to process turns ahead of time either makes the decision making process inaccurate (bugs), or exponentially increases the amount of calculations required.

 

The OP posted 8 years ago. I think they might have moved on.

---

The way you split the frames/states between step 2 "decide what piece to move", and step 3 "decide where to move" , was the contrived part. Generally you need to do both as part of the same calculation, e.g. you can't decide what chess piece to move without also considering what move you will do.

Or alternatively if step 2 and 3 in your example are tactical steps towards realising the strategic objective determined in Step 1 then Step 1 is likely the complex step and needs to take in to account what moves are actually available, and thus it is Step 1 that needs to be split across frames.

Its not that it couldn't work in some game somewhere, its just not generally how it falls out. Usually you have one heavy AI step that you need to break down in to passes. Fortunately the algorthmns typically do break down in to such passes pretty easily, for example by processing X amount of units per frame, or y processing X amount of hexes per frame.

---

Turn based games map very well to simple programming patterns. If you have a detailed game design with attributes and rules, then implementing the state machine, data structure and logic is not a hard task.

Of course it may be a large task: you could have 10 unit types or 1000 unit types, you could have 5 stats of 50 stats, and so on.

Of course you could spend days tweaking screen transitions, months tweaking custom shaders, or years tweaking your design, rules and AI.

But they are general game development problems. The question wasn't 'is game development hard'.