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!