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
\$\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\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.