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:

• Unity Scripting Reference
• Unity Forums
• Unify Community (where this article is just plain awesome if you use UnityScript)
• .Net framework
• and this place

And not so surprisingly Google will help you with most of your answers before they become too detailed to your own project.

You have to decide whether you're a C#-, UnityScript- or Boo-type of person, once that's established you're ready to create a fresh scripting document. C# and UnityScript is easiest to find documentation for and I would say UnityScript is easiest for a beginner. If you go with UnityScript (which is also referred to as JavaScript as it is quite similar) I would recommend you to always disable dynamic scripting using #pragma strict in the top of your document. This is crucial for development further on and it's best you learn to set the type (as in the type of component) for your variables from the beginning to make your code faster and more reliable.

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):

static var gameObjects : GameObject[]; //Type is GameObject where [] states that this is an array
function Start () {
    gameObjects = GameObject.FindGameObjectsWithTag("Player"); //Finds all GameObjects tagged "Player"
}

You can now reuse that from anywhere inside the level by calling TheScriptName.gameObjects; as we made it a static variable. Variables come in three types where they're either public, static or private. A public variable will show up in the Inspector and you can alter it inside Unity, a private won't show up in the Inspector and will have limited accessibility through scripting and a static is accessible from any other script. The most common use for a private variable is when an attribute for a GameObject shouldn't derive from anywhere, just live in its own space and handled from within its script separate from any other instances of this object. Static variables are most commonly used for singletons where there only is need for one variable which should be accessible from anywhere.

Some of the most common variables:

var floatingValue : float = 0.1337;
var integer : int = 1337;
var aBool : boolean = true;
var vec2 : Vector2;
var vec3 : Vector3;

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.

//This loop gets all Scripts from our gameObjects and sets aPublicBoolean to true
for (var i : int = 0; i < gameObjects.Length; i++) {
    var thisObjectsScript : ScriptName = gameObjects[i].GetComponent(ScriptName);
    thisObjectsScript.aPublicBoolean = true;
}

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, theScript.theVariable. For instance:

#pragma strict

static var theScripts : ScriptName[];
var strength : int = 10;
var health : int = 100;
function Start () {
    var i : int = 0;
    for (thisScript in gameObjects) {
        theScripts[i] = thisScript;
        i++;
    } 
}
function OnAttack (whichOne : int) {
    if (theScripts[whichOne].strength>strength && theScripts[whichOne].health>health) {
        health-=10;
    } 
}

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.

//This is a function that takes an int and returns a boolean
function IsThisTenOrHundred (passedValue : int) : boolean {
    var thisValue : boolean = false;
    switch (passedValue) {
        case 10: thisValue = true; break;
        case 100: thisValue = true; break;
    }
    return thisValue;
}

The function can now be used by calling this:

var zeroToHundred : int = Random.Range(0,100);
if (IsThisTenOrHundred(zeroToHundred)) Debug.Log("Yes I'm either 10 or 100");

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.

while (waitingForPlayersTurn) yield;

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:

if (waitingForPlayersTurn) return; //All script below this won't execute if waitingForPlayersTurn is true

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:

static var thePlayersTransform : Transform[];
static var currentPlayersTurn : int = 1;

thePlayersTransform[currentPlayersTurn].position += Vector3(10,0,0); //Moves player one 10 units from current position

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. :-)

Dont forget

• Use simple dummy objects to test your code with.
• It's easier and brings more life to the projects if you team up with someone, there's always good people looking for projects here.
• We will always stick around - keep in mind UnityAnswers is a specific-issue-Q/A site.

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!