★ TouchArcade needs your help. Click here to support us on Patreon.

Where to start?

03-18-2009, 11:39 AM
#1
Joined: Mar 2009
Posts: 10
Where to start?

After reading though Programming in Objective C book by Stephen Kochan, I'm looking to start programming something scratch. I have an idea in mind of what I want this program to do, but I'm not sure where to start.

Lets say that I'm making a board game with multiple pieces, and each piece has an attack rating and a defence rating and hit point counter.

Should each piece be it's own object, with their attack and defence ratings as varibles? Or should I lump all the pieces in one object and define each of their attack and defence rating individually? I'm not even sure which methods they would need (if any), because then I'm thinking that I would have another object with methods of how each piece acted.

To start off, their only interaction with eachother would be one piece attacks and takes a specific number of points away from the other peice's hit point counter.

Right now i'm not interested in any GUI, but probably will want to have one later. I was thinking about calling up the results of one piece attacking another by using NSLog to display the resulting numbers on the console. Just to make sure it works.

I'd appreciate any help that can be given. I'm hoping that once I get over this initial hump that can get some momentum going. Thanks.
03-18-2009, 12:02 PM
#2
Joined: Sep 2008
Location: Birmingham, UK, dull corner of the world
Posts: 2,367
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.

03-18-2009, 12:02 PM
#3
Joined: Mar 2009
Location: Hanover, NH
Posts: 17
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.
03-19-2009, 09:27 AM
#4
Joined: Mar 2009
Posts: 10
OK, cool. I'm not too familiar with arrays, but from what I gathered by what you wrote, the int piece[20] makes 20 different pieces numbered 0 - 19. And the pieceX and pieceY are all the possible rows and colomns that a piece can occupy.

Now, on the strength[20], would I input my own numbers on what pieces have what strength rating? So, for example i could set it as " int strength[20] = {100, 150, 250, 300, 350, ect...} " and then I could pick out each individual number by naming the piece that I want? So I could say (maybe commented out) that piece 0 is a knight, and piece 1 is an archer and make a simple simple method where I have them "attack" eachother by just inputting their respective array numbers? A really simple example would be " int hitpoints[1] - attack[0] " So I'm subtracting the number stored in array hitpoints[1] (which is the archer's hitpoints) from the array attack [0] (which is the knights attack rating).

Am I getting this correctly, or am I just way off base?
03-19-2009, 09:56 AM
#5
Joined: Feb 2009
Location: San Jose, CA
Posts: 546
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
03-19-2009, 10:15 AM
#6
Joined: Mar 2009
Posts: 10
Ahhh, OK. So I should have a genaric Gamepiece class, then initialize an instance of each piece with all of the data I want withen the main.m file? I was trying to make each piece it's own class that had all of it's attributes in it, but I couldn't figure out how I used each of the piece's individual varibles.

And I actually feel more comfortable using the objects then arrays, so this way would be perferred. Thanks.
03-19-2009, 05:23 PM
#7
Joined: Mar 2009
Posts: 12
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.
03-20-2009, 08:38 AM
#8
Joined: Mar 2009
Posts: 10
Oh, no. I didn't mean I'm putting everything in the main.m file. What I meant was when I first started I was making each individual game piece it's own class. Instead what he's saying is to just make one class for all the pieces that have the stats that I need and instance out each unique piece from that class in the main.m file. Atleast that's what I got out of it and it makes sence to me, so I hope that's what he meant.
03-20-2009, 09:35 AM
#9
Joined: Feb 2009
Location: San Jose, CA
Posts: 546
Quote:
Originally Posted by Armchairpilot View Post
Oh, no. I didn't mean I'm putting everything in the main.m file. What I meant was when I first started I was making each individual game piece it's own class. Instead what he's saying is to just make one class for all the pieces that have the stats that I need and instance out each unique piece from that class in the main.m file. Atleast that's what I got out of it and it makes sence to me, so I hope that's what he meant.
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