Hi everyone! This is my first foray into the realm of game programming. My goal is to make a simple, turn based game.
All I want to do is have two-six units on a board that can attack one another. These units will have attributes that will affect the combat (think of like a an old table top game with miniatures).
Where should I start? How do I make my own units have the attributes I want?
Thanks in advance for all your help!
Welcome to the most awesome site for help regarding Unity then! This is a very vast topic with many puzzle pieces but it's also a very good question. I'll try to answer as good as I can and hopefully you'll find some of the tips to come in handy.
Try it out before you even start
You might want to draw the game on paper or even do a live test with people you know who can act out the game. It's a bit unconventional but you'll get really good feedback from them and you'll see in a very early stage if your idea will work as a game. Now this applies to mostly all games or projects but perhaps even best for a turn-based one. You'd want to have all the rules ready before you try it out in an environment free from bytes, so try to structure the rules in a flowchart - If a player does that with these attributes it will affect the other players in this way, and so forth. This will come extremely in handy when testing, but mostly for the actual development process. I usually use Xmind as it gives a fast visual result with what's connected with what and it's easy to extend parts later.
This also forces you to elaborate with the elements of the game before even opening up your first script document, it's a huge advantage to have later! Too many times things gets added or reworked in the middle of the process which sometimes kicks back development for weeks, this happens all the time in the industry as play testing usually brings back some nasty results here and there.
It's important you ask yourself, who is this game for and what should it accomplish. Is it something that would target a wide variety of table players, beginners or more advanced table players or even if it's just a small project for you to learn scripting, then so be it. Once you have the answer to this, you know what level you should aim for in both graphics and interactions, nevertheless the feedback it would have to the player too regarding information on-screen.
Good to go
So perhaps you saw some flaws during testing and fixed them, hopefully you and the people involved also saw that this was a fun game - then you're good to go! You'll also have a first structure where the rules already are set and a workflow for the elements of the game. If this is a serious/live project, you would have a flowchart for the development process too where you'd have a timespan connected to each step. This is of course very hard to do in the beginning with next to none experience in the field, so therefore it's good to time everything you do for the first time. Have a document ready where you just put a number of hours next to the functions (in the bigger picture) and at the same time write down how you solved them, perhaps add some links etc so you can backtrack everything. Maybe this sounds really anal, but you'll thank yourself for doing so as you always can go back and look something up and continue on a breadcrumb path later. Doing this in the code isn't the best, comments in code tend to clutter everything up and it gets really hard to read after a while.
Make sure you start fresh, create a new project in Unity and be very tough on yourself when it comes to structure, where every component such as meshes, textures, materials, audio and scripts goes in their folders and subfolders. A project without structure won't be fun to revisit, think of it as a space where you'll live in the nearest months.
Scripting in Unity
It doesn't really say whether you have earlier experience in Unity 3D, so just in case, these places are good to have a bookmark on:
And not so surprisingly Google will help you with most of your answers before they become too detailed to your own project.
It is crucial that you cache your components, it'll also be easier for you to reuse them keeping this in mind from the beginning. Caching can look like this (UnityScript):
You can now reuse that from anywhere inside the level by calling
Some of the most common variables:
Keeping these babies public or private will have you all set for setting their individual attributes.
With that being said, a turn-based game would very early in the development process demand that you have an insight in how arrays work and what type of arrays you should use. Together with the arrays you will have to know how to iterate through them which most commonly is done with a for-loop or a while-loop.
So basically, to alter another objects attributes/variables, you use GetComponent (the more cached the better) and pick up its script then alter the variable,
Note that this is just a scripting example, this would differ widely on your implementation.
Which brings us to functions, you will most likely need to create your own functions immediately when starting to script a turn-based game. A function can also be static which is good to remember.
The function can now be used by calling this:
Yielding is mostly important in many aspects, sometimes you need to yield for a certain element to become true, or just wait for a certain amount of seconds or frames.
The boolean variable waitingForPlayersTurn could for instance be triggered when another player has made a move or has pushed a button.
It's also common to keep a script from continuing if a certain condition is or isn't met, for instance:
A player and/or unit should be defined in an array so you could add more or subtract at any time, then you could set up your code like this whenever you need to call a specific event for a specific player:
You most likely need a manager to your levels which keeps track of everything, the key here is to use an object with DontDestroyOnLoad(). A manager is simply a script with static variables and functions (mostly) on an empty GameObject that follows the entire game through and keeps track of such things as scores, number of players and other objects that is crucial to remember on level loads.
Make sure to bring your time machine
Always keep several backups of the project somewhere else. Dropbox is a quick and pain free way of doing so, where you could zip the project every week - or after certain amount of hours you've continued to develop - and just drop that in a folder. Never keep backups on the same hard drive as you develop (which kind of speaks for itself).
If you want to test out certain things in Unity, have a side project for that where it's ok if everything blows up. Duplicating the project is as fast as writing bytes to the hard drive, which can be good to remember. :-)
I hope, as this tended to become quite a massive answer, that you feel a little bit more assured in what direction to head. I wish you the best of luck and hope to play an awesome new turn-based game in the nearest future!