iOS Default Stategies for simple game development

[Nicsoft]

Hello,

I am a new to iPhone development. I intend to do a simple game just to learn and kindly need some help just pointing out the right direction.

The game should be some kind of bric-game and the only thing the application will do (from graphical point) is keeping track of where the brics are, color, moving them and remove them from screen every now and then. The brics will be removed after touching them on the screen. I have different theories of directions:

1. Just create an array of rectangles and repaint them in drawRect when updates are needed.

2. Load image files and create images of the rectangles in the application.

3. Sprites.

4. Represent each bric by using buttons (I assume it is possible, but this is not my favourite theory...).

Perhaps there are other ways to do this in which I should look into?

If anyone could just point out which direction I should go I would be really gratefull. If there are several options that's viable, pros and cons is appreciated as well.

Thank you in advance!

/Niklas

 

[PatrickCocoa]

I'm not the guy to answer this . . .

but I will anyway.

I'd guess Core Animation would be the way to go.

Also, note that performance on the simulator will be much better than performance on the iPhone iteself.

 

[PhoneyDeveloper]

I'm not a game developer but I did write a sliding tile puzzle game as my first iPhone app. It seems it might be similar to your game in some ways.

There are certainly different approaches and all can be made to work. There is a limit to how small a view can be if you want to be able to touch it. Apple suggests 44 pixels square as a minimum size for buttons. You might be able to get away with a size a little smaller than that but probably not smaller than 30 pixels square.

There is probably an effect to having a lot of views on screen at one time that might slow things down. I don't know the limit. Probably having 100 views or less is fine.

When I started to implement my sliding tile game I thought I'd use one view and have some kind of objects that weren't views to represent each tile. I quickly realized that using views for each tile made the code much simpler. I ended up writing a UIView subclass for the tiles and that worked well. Each tile draws itself and manages being touched. I think something similar will work for you also.

I wouldn't agonize too much over your design. Just get started with it. You'll figure out in a little while if it's working.

 

[PatrickCocoa]

There is probably an effect to having a lot of views on screen at one time that might slow things down. I don't know the limit. Probably having 100 views or less is fine.

In my (very inefficient) app, the simulator handled about 100 UIViews with no slowdown, but the iDevice itself showed significant slowdown with about 10.

But I agree with Phoney - just do it, get it to work, and keep asking people how they would do it so you can make it better.

 

[Nicsoft]

Hej,

Thank you for your answers.

PatrickCocoa, does it mean that the simulator doesn't properly simulate the actual performance of the iPhone-hardware? (Well, I guess I can guess the answer....)

My strategy now is to create images for the brics in photoshop and import them. I am creating a 2darray (13 x 9) containing objects with a reference (retain) to the images (four instances of UIImage that are referenced in a random order).

The drawback is that I cannot use animation in this case while "deleting" the brics from the screen, can I? Any considerations regarding performance of this strategy?

I'll come back and post my findings after I have made some succesfull tries.

Cheers,
Niklas