Where to start?

First I would suggest using integer arrays for each piece and their individual attributes. So you would declare something like this in the h file...

int Piece[20];
int pieceX[20];
int pieceY[20];
int pieceStrength[20];

(no property or synthesize is needed for these)

then in the m file you could set the pieces like so...

for (int count = 1; count <= 20; count++) {
Piece[count] = arc4random () % 5; //5 types of piece for example
pieceX[count] = count; //piece's X co-ordinate (column of the board) is the same number as 'count' variable
pieceY[count] = 20; //piece's Y co-ordinate (row of the board) is 20, for example
}

So piece number 1 would have a random type, and be located at column 1, row 20 etc etc.

 

It depends on how really "simple" the pieces are - if they really just have 3 variables (attack, defense, health) it would be very simple to store them in an array. You could actually get pretty far this way, but once you start adding in x/y location, graphics/animation, "type" of piece (knight, king, bishop), speed, currently equipped weapon, etc, your array is going to get out of hand. The other aspect to this is that you will end up with all the code for your objects mixed in with the code for your main game loop which isn't the best way to stay organized.

I would really reccomend using objects (here is an ok overview). Although you can just use public variables in the Piece class for things like taking damage and providing armor ratings, you might want to have methods responsible for giving commands to the graphics that represent it and playing sounds. It is easier to keep these in a "DieNow" method rather than calling all those moving parts in the main loop as they usually contain long if/case statements.

If you're just looking to test out some basic code, do it with arrays to start, iterate until you have the quirks worked out, and then build it out into its own object.

 

What Allenp said. Unless you really don't like object-oriented programming, I HIGHLY recommend using objects instead of the above approach. For instance, in the above, approach, what do you do if you want to remove a piece from the board? You're going to have to update every single array. Your game piece has 10 variables? Congratulations, you get to update 10 arrays.

Instead, an object oriented approach would be a lot better. I'll assume you defined a class called 'GamePiece'. Then when you create a new GamePiece, you do something like this:

GamePiece* piece = [[GamePiece alloc] initWithData: 2 y: 0 strength: 4 defense: 3];

Ignoring the fact that it looks kind of ugly, now all your data is contained in one single object. You only have to update data in one place, you get to use methods for that object, etc... There's a lot of advantages.

Then, you'd maintain an array of these pieces. There are different ways of doing this, but I prefer the NSMutableArray class (this just means an array which you can change). You'd do something like this:

[pieces addObject: piece];

And then to iterate (loop) over all the pieces:

for(Piece* piece in pieces) {
NSLog(@"My position is %d, %d", piece.x, piece.y);
}

This isn't meant to be a tutorial that shows how to do everything, but something that allows you to get the 'flavor' of using an object oriented approach. You'll have to do a lot of work to figure understand classes, methods, etc... but I feel like it's worth the effort.

PS: Hi Allenp

 

im a bit of a noob, but i would like to offer my 2 cents...

i dont think this is something you want to do in your main.m file. your main.m file should only be responsible for setting up the game loop (i think), and call the gameboard class. the gameboard class should be responsible for all the game elements, it should create the gameboard and the gamepiece and update the view based on messages it receives.

dont know if this helps or makes things more confusing, but if you put everything in your main.m file you are asking for trouble.

 

That is what I meant. It MIGHT make sense to make a class for each unit -- you can Google a technique called 'inheritance', where you create a base class (let's call it GamePiece) and then you create additional classes that 'extend' or 'inherit' from GamePiece, and give it new functionality.

For instance, I might declare a GamePiece called HorziontalMoverGamePiece. It has a lot of stuff in common with the GamePiece -- health, strength, defense, etc... but it can only move horizontally on the gameboard. Then, I might want to have a VerticalMoverGamePiece, which acts just like a normal gamepiece, except when it moves -- then it can only move up and down.

Another important concept is the idea of 'overriding' functions. For instance, I define a 'move()' method in my GamePiece class that allows the piece to move in any direction. In HorizontalMoverGamePiece, I 'override' the move method, and restrict it to horizontal movement. What makes this nice is say that you have an array of GamePiece objects, of all different types: HorizontalMovers, VerticalMovers, etc... When I call...

[piece move];

... it will automatically do things depending the move() method I've overwritten. If you didn't inherit from a base class, I wouldn't be able to do this.

This is a pretty common case. If all you're changing is stats and everything else is the same, stick with the one class model. Again, you'll need to do some learning to fully understand all this, but I hope this helps