Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
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?
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.
