Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Advice on how to structure my turn based RPG?

Discussion in 'Getting Started' started by CGEworks, Feb 6, 2017.

  1. CGEworks

    CGEworks

    Joined:
    Dec 16, 2013
    Posts:
    12
    So I’m a newbie dev, I’ve got basic coding skills, I’ve done a few “build a game by following these steps” type tutorials and now I’m looking to tackle my first real project. The game I want to make is a dungeon crawler in the style of x-com, so turn based and using a square grid for movement.

    While I’m fairly sure I could cobble something semi-functional together, I’m certain I’d end up with a mess of unmaintainable code because I’ve got no idea how a turn based game should be structured.

    A few details about what I’m trying to achieve:

    • The game is 3D but uses a square grid for movement (ideally with elevation, but that’s not strictly necessary for the prototype, but it’s probably a good idea to include it from the outset right?)
    • The player controls between 1-6 heroes, fighting a number of AI enemies
    • Each unit (both heroes and enemies) has a number of action points which they can use to move, use a skill, use an item
    • Combat is turn based, with one side taking their turn, then the other side (opposed to a more DnD like system, where turns would be taken simultaneously)
    • Each unit has a race that determines their base stats, a character-class that determines their skills, a level, and an inventory which includes things like weapons, armor and consumables
    • Each skill belongs to one of three skill trees (Warrior, Rogue & Mage, although some skills will probably be universal)
    So there’s two things I really need advice on: first is how do I control my game? Is there a standard way of doing it for turn based games? And how would I go about finding out how other turn based games have handled this?

    I was thinking of using a finite state machine but is that the right design pattern? (Is ‘design pattern’ even the right term?) If a FSM is the right thing to use how do I go about setting one up in unity? Would it just be a script that I attach to every unit?


    The second thing is how do I organise my classes? Again is there some standard or obvious way of doing this? What classes should I have? I know I probably need some base classes but I’m not sure what they should look like.


    Any help you can offer would be appreciated, I really just need a nudge in the right direction. Any links to relevant tutorials or books would also be helpful.
     
  2. Schneider21

    Schneider21

    Joined:
    Feb 6, 2014
    Posts:
    3,512
    To get this out of the way first: You're taking on quite a bit for your first "real" game. Anyone who's ever finished a game will tell you to start small with your first game. If you're not inclined to listen to this advice, you do so at your own peril. At the very least, find a way to define a minimum viable product that consists of the basest of elements of the game and aim for that. You've been warned.

    Now on to questions.

    How do I control my game?
    I assume you're talking about general application management things, like a system for controlling which scenes are loaded, saving game data, saving preferences, stuff like that. I recommend looking into the Singleton pattern to create an Application class that you'll instantiate when the game initializes and do most of your management tasks from there or an attached class.

    Is there a standard way of doing it for turn based games?
    Not specifically, no. If you're planning on incorporating online play, you'll want to get that working earlier rather than later, as how you manage game data will be dependent on what type of networking system you use.

    And how would I go about finding out how other turn based games have handled this?
    It depends. What platform(s) do you want to release on? If you're targeting only iOS, for example, Apple has a great guide on its turn-based API that gives you a ton of info. Other platforms may do things differently. In general, though, the theory should be the same, so learn anything you can from wherever you can.

    I was thinking of using a finite state machine but is that the right design pattern?
    That could be part of it, sure. That's a stylistic thing and not really an answer to the problem, I'd say. Sort of like how owning an impact driver isn't the solution to building a house. It may make certain tasks easier to accomplish, but it's not an answer in itself and it's also possible to get by without it, if you're so inclined.

    Is ‘design pattern’ even the right term?
    Design pattern is a popular buzz term that applies to FSMs and other stuff, yes. If I were you, I wouldn't get so caught up in that kind of stuff, though, and just focus on making something functional. You're still extremely new to development, and your focus now should be on building things that just work. They don't need to be pretty, or "best practice" or super efficient. Chances are you're going to throw 90% of your early work away when you think of a better way to do it later. That's how learning works. Focus on writing code and understanding why you're doing the things you're doing.

    If a FSM is the right thing to use how do I go about setting one up in unity?
    There are plugins available that have nice GUI interfaces for setting up FSMs and Behavior Trees. Playmaker and Behavior Designer are two that I own. Again, instead of worrying about those yet, though, I would just start writing lots and lots of code.

    Would it just be a script that I attach to every unit?
    There's no way to answer this properly, as you'll see once you really get into development. There are so many different ways you can and should do things, and it's all dependent on the details of your game. You may end up with GameObjects representing units, sure, and you could build it so that you have one or more Components attached to each one. Or you could have one game object that represents all units and handles all their movement logic. There's no single right way to do it.

    The second thing is how do I organise my classes?
    This is only the second question?! You can create new folders in your Assets directory and sort your scripts that way, if that's what you're asking.

    Again is there some standard or obvious way of doing this? What classes should I have? I know I probably need some base classes but I’m not sure what they should look like.
    Oooooh, you're talking about inheritance and class structure.

    You may be able to guess the answer to this one by now. There's no right answer to this. You'll have to figure out what classes you need and what properties/methods those classes should have. This is an essential skill in programming that you need to build up, and the only way to do that is to just write code.

    Again, just start doing it. You'll get to a point where you say to yourself "Self, I seem to be using this collection of properties pretty often. Maybe that should be its own class!" And you may try doing it and realize why that's a stupid idea, or maybe it was a great one! This is the kind of thing you can only learn through experience. Stop worrying about getting it all right the first time and just get to work!

    Example of how it could play out: You make a class to handle an NPC the player controls, called "Soldier". You give it properties like Health, Damage, and Movement Points. Then you create a class for enemy NPC called "Soldier". You quickly realize it has a lot of commonality with Soldier. So you decide to make a parent class of NPC and Soldier and Enemy both inherit from that. Alternatively, your soldiers and enemies are all just instances of NPC that have a property indicating if they're a Soldier or Enemy.

    Then you realize that damage shouldn't be dependent on the NPC itself but on what weapon they have equipped. So you make that its own class. You try the same strategy as before and change the class to Equippable so you can use it for armor as well. But then you realize the use cases are different enough for the two, and decide Weapon and Armor should be children of Equippable. Or you just make two classes Weapon and Armor that implement an IEquippable interface.

    The point is that there is no one right way to do it. Some people prefer one way over another. Some ways are more efficient in all cases, others only in a technical sense that may never impact your game one way or another. Others are absolutely more correct, but could be beyond your skill level enough that trying to use that methodology would slow your development progress down to the point where you get frustrated and quit!

    Always go with the simplest solution until it no longer suits your needs!
     
  3. CGEworks

    CGEworks

    Joined:
    Dec 16, 2013
    Posts:
    12
    Thanks for the detailed response, it's really appreciated.

    Okay but is the best way for me to do that really to go in blind and just keep failing until I happen to figure out something that works passably well? Would it not be more sensible to talk to a seasoned developer, say "This is the model of how I want to set up my units and skills, what's a reasonable way of going about it?" and go from there?

    I can see the merit in the "Just write code" approach, but with a bit of guidance I could avoid having to reinvent the wheel.
     
    Last edited: Feb 9, 2017
  4. Schneider21

    Schneider21

    Joined:
    Feb 6, 2014
    Posts:
    3,512
    I get what you're saying. It's a difficult line to differentiate between, though. On one hand, you have your reinventing the wheel argument. But I'd compare it more to marksmanship; I can talk to you all day about the fundamentals of marksmanship, but it really doesn't mean anything until you get out there on the target range and start putting the the words into practice.

    Advice is good and all, but you already have enough to focus on for now. Once you master the basics, then you should tap the seasoned developers for more advanced topics and discussions on "why". Part of the reason is because a lot of this stuff is stylistic. I may prefer the Singleton design pattern and tell you that's the only way you should do things. Others might argue the Component Swarm is the only legitimate way to work with Unity. And others might say you should use standard C# classes and only use MonoBehaviors when absolutely necessary. You won't know which advice is best for you until you have that early experience under your belt.

    And that is one of the biggest reasons we always recommend newcomers start with very small games first. It gives you a chance to get that critical experience in a smaller, easier to manage environment. If you go down one route and kinda hate it, you can still finish out the project without having to deal with it too long. Or you can abandon ship and not be out all that much time, unlike if you've already 6 months into your dream game.

    If you want some general advice on structuring of a tile-based game, I'm keeping a devlog of my current project here. One of the posts contains a description of the classes I'm using, which may point you in the right direction. I'm not saying it's the best way to do things, but it's how I'm doing them! May be of some interest to you.
     
    Ryiah likes this.
  5. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    I did some turn based RPG work. I can pass on some tips. Turn based structure is somewhat tricky. You can't just go with the normal swarm based 'Unity way'.

    Create a TurnManager class that handles turn management for you. This class then distributes out an turn tick to whoever turn it is. It also tracks start of turn, end of turn, and the like.

    On the characters themselves, you won't have any of the default Unity messages. Instead you'll get your calls from the TurnManager. Despite this the characters should still be self contained.

    You'll also want to tokenise the characters, because you'll be referring to them a lot. A nieve approach is to simply hold an array of all the characters and pass around indexes to this array. Don't do this. It leads to a nightmare of indexing hell. It also couples everything to the class with the array. Instead pass around tokens that contain the key references you will need.

    UI is another special nightmare. Each character will have their own UI needs. Try and make your UI system as generic as possible. The best ones I've seen use reflection and attributes to grab data off the target, and then build up a UI based on that. Another option is to constrain your design, every character has exactly four attack, and so on.
     
  6. CGEworks

    CGEworks

    Joined:
    Dec 16, 2013
    Posts:
    12
    Thanks BoredMormon, that actually helps a lot. I looked into turn management in more detail and found a tutorial that fits well with what I'm trying to accomplish.