0
\$\begingroup\$

I am working with cocos2d.

All my objects are declared on the CCLayer that I'm using, I have the logic of the game there and all the CCSprites.

Should I put the CCSprite for the player and all it's related properties (HP, Velocity, etc) in a Player object and then have that player object in my CCLayer?

But then how to add the CCSprite of the player to the CCLayer? Should I put in the CCLayer this?:

[self addChild:[PlayerObject playerSprite]];

Or should I create a controller?

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

I think it's a matter of preference. Depending on the type of game, the MVC architecture might be a good fit, sometimes/mostly it will feel out of place though. I have used it for puzzle games before (eg. your board is the model, the controller handles user input and makes the changes on the board and a view that renders these changes).

Another architecture that works well for game development is the component pattern. Your approach even goes into that direction, because you have a Player object and add a Sprite component added to it. Depending on the scale of your game and flexibility you need, you might even want to go further and have a basic Entity class and components that define the entities look/behavior etc. And when you make this data-driven, then the real fun starts :)

Generally, I'd try to separate your game-logic as much as possible from your drawing API (in this case cocos2d). If you wanted to port your game to another platform/engine, then you'll have to separate all your code from the engine API anyway.

So instead of having a CCLayer that instantiates your player, rather have some sort of Controller that creates the CCLayer and your entities and adds them to the layer.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .