Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

larswik

macrumors 68000
Original poster
Sep 8, 2006
1,552
11
I have a very general question. I have always struggled deciding when to create a Class or just make a Method for something.

A game I started last year for fun (to learn) I picked up this last weekend again. It's like Asteroids where you have rocks floating on the screen. I could create a simple method that would return a UIImageView with the rock on the screen or create a rock Class that I can use to to do the same thing? But creating a rock it would be created in the viewController for the screen which is not the MVC design, if I even.

If I decided to create a rock Class to populate the screen with rocks, the rock Object it's self would not be responsible for moving the rock on screen, it would just return the rock every time I needed a rock object? The game engine would be responsible for moving and rotating the newly created object?

Now creating a Rock Class it would be a subclass of NSObject? But that feels wrong since it is a view but even in NSObject I can have a method return a UIImageView for the rock.

I would think after all the reading I have done and testing this subject would be second nature to me after all these years now.

Any help is appreciated as always.

Thanks.
 
To answer your question I would most likely create a class for rock and here is why.

With a game engine you essentially keep two versions. One is the geometric data/textures on the gpu-side. The second is an abstract version used to keep track of properties like its position. This is stored on the cpu-side for running physics doing collision detection and drawing updates etc.

With the graphics data you keep that as a shared library so you aren't storing redundant copies of the same data like textures and vertex data in gpu memory. You reuse the same assets for drawing. So you might have 5-6 rocks but they all reference the same texture and vertex data. You just modify the position/rotation/scale during the draw call based on the different properties in your rock objects.

You might try looking at sprite kit instead of using views, but if you must maybe add a view as a property of the rock class that you can then add and remove from the game view. Track the properties of the rock separately with a cgpoint. Then update the view when you have to.
 
First off, look into using Unity. Walker Boy Studio (use Google) has free tutorials on how to make an asteroids game in Unity. Game engines have already been made - are you looking to make a game, or an engine? If the answer is engine, what do you think yours will do that Unity (which is free if you make under $100K/year) can't?

Anyways, you should have have a Rock class, which stores things like the position and speed of your rock (it's a model object) and a RockRender class, which draws your rocks (it's a view.)
 
Thanks guys. I had not considered the CPU / GPU. I have Unity already and played with it 6 months ago. I am just wanting to learn more about the IOS and how things work together. But more importantly trying to find the best time to create a class for something of just do it with a method.

Thanks
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.