Is it easy to make a Turn based Game?

Hi, so I have recently started work on a Turned based RPG with the same battle style as Final Fantasy, but I'm having problems keeping the combat Turnbased and 3rd Person. Anyone have any tutorials or source codes that they know of which could help? maybe a Chess game or a Soccer Penalty Shoot Out?

I'd love to hear what you have to say and love it even more if you had some tutorials that you made or know about that you would like to share with everyone here


Thanks In Advance!

-Mystic Works

 

How are you having trouble keeping it turn based? Simply give control to one and only one character, when he finishes give control to another one?

 

Hes not, hes just asking for someone to do it for him.

 

I'm not asking for someone to do it for me, I'm looking for tutorials, a source code would be great but thats not what I'm looking for 100%.

 

It just follows a simple event driven flow.

 

These are some basic tutorials from PlayerIO. They are geared toward Flash, but the concepts apply to Unity, too.

http://playerio.com/documentation/tutorials/building-flash-multiplayer-games-tutorial/turnbased

http://playerio.com/documentation/tutorials/building-flash-multiplayer-games-tutorial/examplegame

http://playerio.com/documentation/tutorials/building-flash-multiplayer-games-tutorial/example-turn-based

 

Said it all.

 

I don't know of a methodology for scripting turn based gameplay, but it shouldn't be to hard to just make up your own!

In your script you should have an integer in charge of keeping track whose turn it is. For example a turns variable could be equal to the player turn's number. If it's player 1, turnsVariable should be 1, if it's 2, then 2, and so on.

When player 1 finishes moving his units, he should somehow input that he's done with his turn, maybe with a "next turn" button, the button's script should increase the turns variable value, with ++, so now it's player 2's turn.*

*++ is the same as += 1

If player 2 is cpu controlled, every unit should follow their routines, and when all unit have been moved, you should ++ the turns variable automatically.

If there're only two players, after you've ++ the turns variable, you should check if it's equal or larger than a playerAmount variable (in this case it's 2).
If so, that means all players are done for that round, and it's time to reset the action points or move points or whatever you use to quantify the turn based units' movement, also set the turns variable back to 1 so player 1 gains back control.

 

actually turn based games are kinda hard, Ive tried several and they have their own nuances and difficulties. Its harder than you think.

 

It is insanely hard! seriously its much much much much much much harder then just not turn based (no joke chess is ridiculous )

 

I could happily do a fully networked implementation of chess in less than two days.

The key is knowing the right paradigms, once you're familiar with them there's no challenge in the programming, just implementation.

 

Without cheating by downloading code and writting your own competitive AI?

 

AI? There's a reason I said networked - no point reinventing the wheel if it'll cost a lot in dev and add very little value!

If I *had* to do AI, then I'd certainly be looking to existing code as it's not my forte.

That said, I could create a chess game with a simple AI in 2 Days - and it might be a tad better then you'd imagine at first guess

 

i had similar problems and similar answers, no one will help you , not for turn based, cause for pro's is too simple. You need to learn . but someone did a chess in unity and provide the code

http://www.youtube.com/watch?v=R8f_wHzh1Vk

try this and give a like !

 

Turn-based is too simple for pros? That's not true, there are many very profitable turn-based games. I already told him how you go about it.

Look, let's make this simple.

Grab the manual of any basic game, take Candyland if you like or even Snakes and Ladders. Code those rules into C#. Turn-based game.

It is just event-driven programming. If you can't get that, then you need to go back to studying very basic programming. Something happens, it triggers the next event, which triggers the next, and so on.

 

This is actually harder in Unity that many people think.

It takes understanding of specific commands out there (like how to properly use the yield command and IEnumerators) to set it up, and most people out there don't do tutorials on things of this nature.

Ensure you use a custom built infinite loop that checks the game's state to determine where to be. (Using a while(true) or for(; will do the trick). Start your loop inside Start or Awake in your main controller object. Then, inside that loop, ensure that every time it comes to a new player's turn (NPC's included) that it waits until the current process is done (use yield to proceed your function call). The yield statement forces Unity to wait until you are done with the current function completely before moving on to the next command in any way.

Using if statements based on turn/game state can tell it when to display things like menus.

Hopefully this helps you build what you need, as some people assume that with their experience with the system, it's better to badmouth you for not understanding specific keywords and their functionality. My college courses certainly haven't gone over this portion, and it took a while for me to figure it out as well because people that know it frequently consider it too easy to do to worry about discussing, and those that don't know it can't find it to share it.

 

No it isn't. Really. It's just like writing any other game. As JRavey says, it's all about event-driven programming.

Real-time games update the game's state every frame, but you don't have to do it that way.

It's a common misconception that a game must be tied to the camera and the Update() / LateUpdate() cycles. You need to decouple the game logic from the updating process.

Think of a game as three separate components: the "Model" (which represents the gameplay logic), the "View" (which displays the game's state) and the "Controller" (which handles interactions with the Model and the View. (This is better known as the "MVC" design pattern. It's used heavily in traditional application design.)

The "View" logic can be nailed into the camera scripts.
The "Model" logic should probably live in its own master GameObject. It controls all the game's state and includes the Finite State Machine scripts.
The "Controller" logic may be better off added to the Camera too, although some "Controller"-related scripts will probably need to live in the master GameObject to help communications between the two.
I'd resist trying to throw everything into the camera GameObject as it'll just get very bogged down.

Also, if you're unfamiliar with creating your own standalone classes, I strongly recommend reading up on how to do this. Most C# tutorials will be able to help here. (I don't tend to use Javascript much, but that's an option if you prefer.)

Briefly:

You need a game state variable that keeps track of whose turn it is to play. If every player is sharing the same computer, the logic that changes that state variable would also throw up a "Get Ready Player [X]" (where "X" is the number of the player whose turn it is to play.) If playing over a network, you just prevent players who aren't playing their turn from interacting with the game's pieces. (But do remember to allow them access to the menus.)

Once a player has made his move(s), they hit an "End Turn" button and the client updates the game model, then cycles the "CurrentPlayer" state variable to the next player in sequence so they can take their turn.

None of this is particularly difficult. The fact that the graphics are updating every frame is irrelevant. Players can still be allowed to look over the board, spin the camera, etc. As long as they're not allowed to actually change anything relevant to the gameplay, that's fine.

 

Isn't programming about looking at circumstances and figuring out how to create code that recreates that virtually? I've never made a turn based game but how to do it seems painfully obvious. Like another poster said, event driven... that's the meat and potatoes right there. I'm sure there are some challenging aspects in the details but isn't that true about most everything? If not for the networking I don't see why a turn based game would be any more difficult than a Tetris clone.

 

Aha, now either you're a genius, or you're seriously underestimating chess games AIs (or you meant a really really really extremely simple AI)

Jokes aside, this would truly be an interesting challenge if more people participated: "make a 2-day chess game with AI - and graphics": I'd love to see the results and read the various post-mortem.

 

I know next to nothing about chess AI's - but I know a bit about brute force

Shouldn't be too hard to get an AI to see a couple steps ahead - more steps the fewer the pieces available. There already exists a simple value system for pieces won/lost - so that's easy to implement.

Simple yes, but it'd actually play.

 

same here

 

If you can't explain it simply, you don't understand it well enough.

At its bare necessity, you need a list that says who will go first and who will go next. In C# you can use a generic list. You can, for example, use a list of strings. Add values inside like "Human", and then "Enemy".

You'll need a separate class that will handle all this. Let's call is TurnOrderManager.

Then TurnOrderManager needs to keep tabs on whose turn it is now. He is like a referee, ensuring only the current turn owner will act. A simple int that represents the position on the turn order list will do.

Every time a player (or AI) decides to end its turn, it just needs to tell the TurnOrderManager so. Then the TurnOrderManager simply adds 1 to his int, which means the int is now pointing to the next guy in the list, until it reaches the end, where it resets it to the first position.

The rule is then, that only the current turn owner (determined by the int) can do stuff. (if its not this guy's turn, then disregard any of his requests/attempts to move his characters)

You don't need any infinite loop here.

 

Simply yes, just put together a simple turn based game guide/recipe here:
http://forum.unity3d.com/threads/12...al-combat-game?p=904731&viewfull=1#post904731

Should get you started, Unity is fun enjoy!

 

I wont speak to whether it's easy to make a turn-based game. Anything is easy if you know how to do it. Conversely, if you don't know how, it's hard.

An essential part of my turn-based game is the GameController class, which checks the game status every frame and reacts based on that. The state (a public static enum) can be set from any class and for a number of reasons. Here is how it goes when the state has been set to switch turns:

Code (csharp):

1. case StateType.TURNOVER:
2.                 print("Turn is over!");
3.                 //check if all players controls a goalpost,
4.                 //remove those that don't
5.                 if (CurrentPlayerHasLost())
6.                 {
7.                     print(nowPlaying.name + " does not control any Goalposts, and is removed from the game.");
8.                     GuiBuilder.infoText = nowPlaying.name + " does not control any Goalposts, and is removed from the game.";
9.                     sceneSc.lordList.Remove(nowPlaying.gameObject);
10.                     lordList.Remove(nowPlaying);
11.                 }
12.  
13.                 //Is game over?
14.                 if (sceneSc.lordList.Count < 2)
15.                 {
16.                     SetState(StateType.GAMEOVER, this);
17.                     print("Game is over. " + lordList[0].name + " is Victorious!");
18.                     GuiBuilder.infoText = "Game is over. " + lordList[0].name + " is Victorious!";
19.                 }
20.                 else
21.                 {
22.                     SetState(StateType.STARTTURN, this);
23.                 }
24.  
25.                 ChangePlayer(); //Do this from server!
26.                 AddEnergy();
27.                 break;

There's quite a few things going on here, but I think the gist of it is fairly clear. According to the thread, one function of interest might be ChangePlayer().

Code (csharp):

1. private void ChangePlayer()
2.     {
3.         numShots = 0;
4.         numBuys = 0;
5.         timeUsed = 0;
6.  
7.         int index = lordList.IndexOf(nowPlaying);
8.         if (index >= lordList.Count - 1 || index < 0)
9.         {
10.             nowPlaying = lordList[0];
11.             turn++;
12.         }
13.         else
14.             nowPlaying = lordList[index + 1];
15.     }

 

Sorry to (slightly) necro this thread, but you guys are aware that C# supports getters and setters, right?

I find them very useful in creating a poor man's event-driven system to avoid repeatedly polling the "whose turn is it?" state every game cycle. The following is pasted from my Tic-Tac-Toe tutorial:

Code (C#):

1.  
2.     public enum gameStates { Idling, PlayerX, PlayerO, VictoryAnimation};
3.    
4.     private gameStates _gameState;
5.    
6.     public gameStates gameState
7.     {
8.         get
9.         {
10.             return _gameState;
11.         }
12.         set
13.         {  
14.             if (value != _gameState)    // This ensures we only call GameStateHasChanged() if it's actually changed.
15.             {
16.                 _gameState = value;
17.                 GameStateHasChanged();  // call any code relying on gameState changes.
18.             }
19.         }
20.     }
21.  

This triggers an event (i.e. calls a function) automatically, but only when the game state has actually changed. From a coding perspective, it's entirely transparent: you set the "gameState" variable like any other variable. The variable itself uses its modified "set" function to provide the necessary 'intelligence' to call the "GameStateHasChanged()" function.

(NOTE: I can remember when we called them "subroutines" and would GOSUB directly to line numbers. It's the same damned thing, regardless of the fancy, la-de-dah jargon academics love to invent just to confuse people even more. I say, Bah! to your "methods"! Bah!)

 

@stimarco: use proper events! Us .NET devs aren't heathens with hardcoded function calls Handy if you also need to update the UI or what have you without extreme coupling.

(you may well know that already, it's just a little part of me dies every time I see a list of function calls in a setter...)

 

Actually sending an event from a setter is generally considered bad practice because it provides a poor mechanism for subclasses to control the property (i.e. subclasses have to subscribe to events, cannot send the event, etc). Instead you should provide a protected virtual function which sends the event and can be easily called or overridden by subclasses if required.

i.e

Code (csharp):

1.  
2. public event EventHandler GameStateChanged;
3. protected virtual void GameStateHasChanged(EventArgs args){
4.   EventHandler myHandler = GameStateChanged;
5.   if (myHandler != null) myHandler(this,args);
6. }
7.  

This may or may not not be what Stimarco is doing; the convention is to use the name On<PropertyName>Changed and for it to take the event arguments as an input.

In the end pick the approach that suits your project. If you are writing a simple tic-tac-toe game then you probably don't need events at all.

EDIT: Updated the code (namely avoiding possible race condition by making a copy of the handler).

 

Good to know, although one of my goals is to provide code that can be easily translated to Boo and Unity's flavour of Javascript, so I've deliberately avoided using too much code that might be too C#-specific.

Also, I've been learning Objective-C 2 on OS X, which is a very lightweight (and surprisingly elegant) implementation of OOP on top of C. I suspect some of my code may reflect that.

A fair point, but as it's not a true Event in the C# sense, I don't think it's a good idea to confuse matters by making my fake event look like a real one.

This.

My intention is to keep the code easy to read and to show how a simple turn-based game can be built in Unity. As my target audience may be at any level of proficiency, I really don't want to get bogged down in details like explaining protected virtual functions as the tutorial isn't meant to be a C# tutorial as well.

Also, while I'm happy to base my projects around common design patterns, I don't consider those patterns to be gospel. I'll happily tear MVC a new one if it saves me pages of code and layers of function calls. Does the code work? Yes? Job done.

 

Totally agree, that was meant to be my point I just took a long time to get there

 

Check this at timecode 3:00
This is a turn based RPG game, the turn based game is only the fighting part, the rest is adventure like.
This was sadly NOT founded on Kickstarter and was canceled.
I took part in the development of the whole prototype for the client (the game directors and writers).
It was made with Unity 4 in 6 months.

 

I suggest you to look at this project which lets you learn how to code a casual turn-based game play:

Snakes and Ladders in Unity3D for Android, iOS and Windows
http://forum.unity3d.com/threads/re...plete-project-for-android-ios-and-web.298216/

Hope it helps.

 

necroing, double posting, and advertising your own stuff. that's three awards in one. Good going.

 

@ Whippets,
Can you please kindly tell me what I did wrong with promoting a thing which can actually help starter (and others with the same problem) get what they wants? I read most of the posts above, and @ JRavey somewhere suggested that a S&L could be useful for such situations. So I introduced mine.

If you think I'm abusing this topic, I will remove my post immediately, as I'm just trying to help.

Thanks.

 

Hi, can you provide more code practice about this subject, Turn based game, event usage, state driven architecture?

This helps me, but I want to see more code and actual usage, benefit about it.

 

Holy cow, this really got you guys fired up... 3 years ago.

It's like Minecrafty voxel engine games, turn-based games and generic first-person shooters... those are the games that everybody thinks they can do for some reason.

Yes! It's all very easy and YOU CAN DO IT in one weekend. And you don't even have to write one line of code, because of our once-in-a-lifetime super spiffy XBOX live achievement lifetime achievement bananarific free-to-try, 100% guaranteed unconditional money back guarantee YOU TOO can MAKE THE GAME OF YOUR DREAMS without ever making that annoying Space Invaders clone all those old guys told you you should make before moving on to bigger and better games because YES, YOU ARE SPECIAL! Programming is for lesser people who don't have LEGENDARY TALENT that GOD personally loaned you.

...

No, turn based is not easy.

"Simple event-driven system".... wow. It's like, you can put "simple" before anything and it will just make you seem super smart, like you totally know what you're talking about.

Nothing is as simple as it first appears.

That's because underlying all that "simplicity" are actual, real-life details. Your mind abstracts away a lot of these details when you think of these things... you're not actually envisioning the entire system in your mind, you're just imagining what it would be like to envision the entire system.

What is simple about randomly creating objects and placing them in a field, then determining which objects should go first, keeping track of all of their hit points and other stats and animating all of the attacks and spells and items that can be cast, designing an entire inventory system that will be accessible only by certain characters only during certain actions, building in battle logic into AI units to make them interesting to fight, programming in all of the running-away logic, then there's the whole "what to do when a character dies" problem... and then there's the MASSIVE, MIND-BLOWINGLY thorough GUI you HAVE to make, and make it look nice, the HP and MP have to be animated, the gauges have to blink pretty-like, you need a boat load of sound effects, a boat load of art resources, a boat load of written captions and descriptions...

Then you get to add like 80-100 random monsters for variety.

Then you get to test it over and over and over until your eyes bleed.

And there will still be bugs. At least 17 major bugs in the final version. Crap like, this enemy doesn't die when hit with an attack from this character because of a weird class-specific thing that you put in for testing in the first week and marked with a

Code (CSharp):

1. // REMOVE LATER!!!

but since you haven't edited that .cs file in a month you forgot about it.

And so... you say simple. Yeah, simple until you find that there's a typo in your final build.
Simple until you realize there's a bug that lets the character duplicate items if they hold left while using them.

Stop underestimating games and start respecting the engineering feats that they are.

 

This is a pretty good summary of debugging software in general.

 

Its not hard at all, it just takes alot of work.

 

I know the feeling. Was trying to flush some errors out of SQL code at 2am, but the supposed erroneous line was being flagged about 30 rows above where the actual error was and with a very minimal description. Still, these trials are what make us the slightly unstable, slightly hyper people that society has come to love (at least that what I tell myself every day)

 

EDIT: My advice was not good enough...sorry for the post.

 

The difference between a working prototype and a finished game is pretty significant, not sure that you can call everyone else wrong based on that experience

 

And everyone here has a finished game? Your argument is just as valid as my argument

I never said anyone was wrong, I just wanted newer people to feel like they can accomplish the task with simpler tools instead of going out and buying playmaker, or copy/paste a FSM, or learning unity specific concepts such as coroutines. I am obviously learning the hardships of making a turn based "game", I don't understand the logic behind telling someone their advice is not useful based on not enough experience or based on a youtube video...I at least offered advice, and willing to delete it if people feel like its "not good enough".

I don't know why you like taking people out on every thread lately, but I will let your grumpyness be. You could have at least given some advice instead of getting offended on everything people say.

 

No, not everyone has a finished game... at least not one that they're proud of... and that's basically my point. We're all trying. We all have the dream. Yet success in our dreams remains anomalous for most. Why is that? Because it's not that easy. That's it, plain and simple.

Your advice is welcome. That's what makes the world go round. People sharing ideas and insights. Your opinions are welcome. I just said it was hard and you said it was easy, and you said this based on your experience building one prototype, and I said what I said based on lots of years of studying the ins and outs of game programming. And I think your one time experience with the prototype doesn't cancel out or minimize everyone else's.

Nobody told you to get erase anything, either.

When I began, nobody told me the reality of how hard this stuff would be. So I didn't apply myself as much as I should have. I underestimated it.

But if you know the reality, then you have a chance to succeed by making the right choices early on. But no, prototypes don't always turn into final products. Games fall apart just past the prototype all the time. That's because the critical engineering aspects of a complete game are left out of the "let's get something on the screen" prototype when it comes to games. You build the game loop in isolation, with no connection to other systems that you'll need... and then you need those systems, and your game loop isn't structured right for it. Happens all the time.

It's hard. Trust me.

 

Wow this post is old, probably too old to comment, but ahh well... slow day ...

@Azmar you don't necessarily need to use a strict or formal FSM but approaching turn based games like a state machine is generally a good idea. Mainly because they have a very obvious relationship to a state machine/nested state machines (i.e. they are for the most part deterministic* and game play is typically broken in to clear well defined phases).

@anselmo.fresquez most design patterns are pretty simple. Which is no to say the main thrust of you point is incorrect, its more that the complexity is in the scale, the exceptions, the edge cases, etc. One of the good things about turn based system is that you can automate (engine) testing pretty easily (due to the aforementioned deterministic nature).

@leegod No, but if you have a more specific question I'm sure I can give you my input.

* With the typical exception of a random draw or a random attack/defence roll or similar mechanic.

 

C'mon, everything is simple on paper!

It's when you get your nose to the grindstone that you start to go "hmm..."

The trouble with software is that once you're past a certain point of general structure and some fundamental systems, and you keep getting deeper into unique behavior, your pattern is invalid. You still have to be creative with where to put code, think on your feet. You can't sit back with a hobbit pipe every time you run into something unexpected and ponder it. Starting is easy! The middle is not fun, the last little bit is torture. That's the truth, kids.

The word "simple" should be required to be accompanied by a disclaimer.

 

Written in a weekend : https://play.google.com/store/apps/details?id=hu.twofish.spellchain&hl=en

The clients did add a little code over time but for the most part unchanged from the original prototype I did for them. This weekend included doing the UI code and graphics (not card art), the game logic, a couple of simple AI's, the card database, automated test cases, etc.

Obviously this is not Hearthstone, but its possible for a turn based game to be 'simple'.

 

Nicely done. But that requires experience... which beginners, obviously tend to lack.

Also, you wrote the code in a weekend, did that include creation of all the art resources, planning the game play, balancing the cards and so on? No.

Did you have a plan? Yes.

A lot of people start with nothing but a gleam of sunshine in their eye and a dream in their heart. There's a whole boulevard dedicated to what becomes of those people's dreams. I think it was Billy Joe Armstrong who sang about it.

 

I honestly have no idea how long Zsonlay spent on game balancing, probably quite a while as the game is pretty well balanced.

That said I think for the most part this thread is about code not about creating art or game design. My point is that an appropriate design pattern goes a long way.

PS Totally agree that these things are much more difficult if you are beginner, I think there needs to be a balance been diving in head first and stopping to reflect on the best approach (edit) and ditching your project for a simpler one because you are in over your head

 

This was the ultimate turn-based game.

This is what I think of when I hear turn-based.

I'm not sure where I'm at in terms of agreement/disagreement with other people, never been a gift of mine to know what other people's impression is of what I'm saying... but programming this game would be a lot of work. I think that people who come on here saying "I want to make a turn-based game" are overzealous and new to game design, so this is what I imagine they are thinking.

So maybe we're talking apples and oranges.

I just don't think the word easy applies. I mean, it's relative to begin with... what's easy for me is hard for someone else, and vice versa. But I don't think for most people this stuff would be easy.

 

See for me, that was be a real time game with turn based battle

Turn based game for me would be like Advanced Wars, Fire Emblem or FF Tatics where by all game play including battle is done in turns

 

To me, that's strategy. Lol. I think something like FFT would be one of the most complicated games you could attempt. There's just so much logic and content.