Component based entity systems « cocos2d for iPhone

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

Component based entity systems

(16 posts) (7 voices)

Started 2 years ago by russtbarnacle
Latest reply from h.hamm

Tags:

russtbarnacle
Member

Maybe a little Off Topic but i was wondering if anyone is using a component based approach when writing their games. For those unfamiliar with this, the following is often pointed to:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Here is a pretty good explanation of it in terms of code (actionscript):

http://pushbuttonengine.com/docs/04-Components.html

This architecture has been gaining popularity in the big commercial games and unity3d also uses a component based approach but is anyone using this with cocos2d-iphone?

Posted 2 years ago #
ob1
Member

Looks very interesting. I will check that out.

Personally I push MVC as much as possible in my game. Makes it really easy later for persistance (save games) and stuff like this.

Unfortunately cocos2D needs some inprovements in this regards. As far as I have seen, everything is a node and most developpers put the model, the view and the controller in a single "Scene" object.

Posted 2 years ago #
slipster216
Moderator

Cocos is really not designed for MVC, and personally I'm not a big fan of script MVC coding. It can make your code a lot bigger without much gain, especially in games.

Personally, I think cocos needs to support NSCoding for save. It wouldn't be that bad to thread through the engine, and it would open up all kinds of doors for things like scene editors and content layout tools. For now, my games objects all derive from a 'GameObject' class which serializes out most of CocosNode, which gives me most of what I commonly need in terms of save state on an object. I split my initialization for an object into two sections, one for things which can change state and one for static state (child sprites, etc). Unfortunately you still have to serialize out your game's Layers by hand, which can be a bit of work. That would be eliminated with NSCoding support.

Components are definitely a cool way to go. I think they'd be overkill for cocos, but in heavily editor based environments like Unity they make a lot of sense.

Posted 2 years ago #
ob1
Member

With all due respect, I disagree strongly.

Most people I see who complain about the "complexity" of MVC just don't see what they gain in the end. And frankly, I don't even see what complexity or size it adds to my game.

I designed my game like this:

Instead of scenes, I have gameControllers. The director gives control to the game controller, who inits a model and a view. The view has a callback delegate to the controller for managing events, touches, quitting the level etc. The gamecontroller has a game loop to update the model. The view has a rendering loop to move sprite and animate (schedulers to be clear).

I always start coding without a view, just thinking my game is on a black and white 80 columns terminal. Therefore the model really only has the state of the game and nothing else.

So I really don't understand what you mean about serialize by layers and how MVC adds complexity. Here is my savegame code:

- (void) encodeWithCoder: (NSCoder *) coder
{
[coder encodeInt:kSaveFileVersion forKey:@"Version"];
[coder encodeObject:ents forKey:@"Ents"]; // NSArray with all the entities
[coder encodeObject:level forKey:@"Level"]; // Basically saves level number
[coder encodeInt:score forKey:@"Score"];
[coder encodeFloat:timeLeft forKey:@"TimeLeft"];
}

And loading everything back ?

aModel = [[GameModel unarchiveFromFile:[GameController archivePath]] retain];
// Load layers and create sprites back according to model entities
GameView *view= [[GameView alloc] initWithModel:model delegate:self];

I really fail to see how MVC made my code bigger and complex. On the contrary, it made everything clean, short, easy to manage.

Posted 2 years ago #
coolman
Member

Well MVC is now fashion. ;)

As for the NSCoding it gave me tons of problems, problems that I cannot remember now. I just did some methods for saving in SQLite (with simple SQL sentences) what I wanted and work very fine.

Posted 2 years ago #
ob1
Member

What do you mean by fashion ? I you mean that people advocate now because it is hype and used by Cocoa, I disagree.

I am learnt MVC at engineering school 15 years ago and have been using it since then.

Posted 2 years ago #
GameBit
Member

ob1, could you write bit more how you doing things? How you realized logic to going from menu to game and back? Some kind of tree would be rly nice :)

I was trying to use MVC best practices also (actually most of the part still using) but ended up by using singleton "GameModel"

Posted 2 years ago #
ob1
Member

Okay, I dunno how that will work in a post. Everything is not totally MVC since Cocos2D is not really designed for it.

It's basically designed around the schematic there:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/images/app-archa2.gif

In my architecture, the model doesn't notify the view of changes since it's a game and I have game loops for that.

I have menus that are scenes. and a gamecontroller that is basically a scene too. The game controller (scene) has two properties and that's all:

@interface GameController : Scene <GameUIDelegate>{
GameModel *model;
GameView *view;
}

One method for init:

- (id) initWithLevelNumber:(NSUInteger) levelNumber;

And a few method so that the view can notify the controller:

- (void) saveGame;
- (void) timeOver;
- (void) quitLevel;
- (void) pauseGame;
...

The model also has a notification for saving on quit (basically calls pause and savegame:

- (void) applicationWillTerminate:(NSNotification *) notification;

Finally the controller has a game loop where it checks for collisions, spawns entities, counts score, moves entities ...

The view has a delegate (the controller, for passing touches) a reference to the model and of course layers and an array of sprites, animations, the pause menu, buttons etc.

When the user pauses or quits or does a touch, the view processes the event in a form that can be understood by its delegate and messages back. Only the controller changes the model or switches scene, the view only displays graphics and processes touches.

The view also has a game loop that goes through each entity in the model and updates its sprites accordingly.

The model is basically a bunch of arrays with NSCoding and a few floats and int with NScoding. No methods there apart from the initalisation for the entities:

- (id) initWithLevelNumber: (NSUInteger) levelNum;

- (void) addEnt:(Ent*) ent position:(CGPoint) position;
- (void) removeEnt:(Ent*) ent;

- (BOOL) archiveToFile:(NSString *)archivePath;
+ (id) unarchiveFromFile:(NSString *) archivePath;

Note that the position of the entities is not the position of the sprites. That's one of the advantages of MVC, the model and controller do all the work in cartesian coords, much simpler, and the view projects in isometric.

I am not very happy that the menus and the game controller have to switch scenes themselves. It would be nicer if we has a Worflow Manager or something that would manage all the scene flow that is a delegate to all the scenes.

I am contemplating making a MVC fork of Cocos if nobody is intersted in having Cocos for MVC compliant like Cocoa.

Posted 2 years ago #
ob1
Member

I forgot a little part:

- (id) initWithLevelNumber: (NSUInteger) levelNum;

Creates a "Level" instance using the factory pattenr. Level has various subclasses.

http://en.wikipedia.org/wiki/Factory_method_pattern

Posted 2 years ago #
ob1
Member

I took the time to read the "component based approach" article you posted.

Funny what you say about MVC:

> Cocos is really not designed for MVC, and personally I'm not a big fan of script MVC > coding. It can make your code a lot bigger without much gain, especially in games.

That's what the author of the article say is the usual reaction to the component based approach:

> If you are not particularly familiar with the idea of object composition and
> aggregation, then it can strike you as pointless, needlessly complex, and unnecessary
> extra work.

Posted 2 years ago #
slipster216
Moderator

That's funny, because I like component based approaches much more than MVC. But that is likely because they solve two different problems. Component approaches create abstractions between functionality of an object, making each functional element more reusable, with looser bindings between each other. In larger scale environments where you want a lot of content driven development (level design, etc), that comes in really, really handy. MVC doesn't really address that, it's more about seperating, well, your model and view, which has it's strengths and weaknesses as well.

In the end, I think you use what works for you, and what works for the particular code your writing. I don't think there's one paradigm that always makes sense, as when you extend any of these concepts out long enough you eventually reach some form of breaking point.

As for NSCoding, my save code looks very similar to yours, simply because every object in my game supports NSCoding, so I can just serialize out the entire Layer. You don't need to follow MVC to get that.

Posted 2 years ago #
ob1
Member

I agree with you and I even think that MVC and component based can be used together.

> You don't need to follow MVC to get that.

Of course you don't, but having a separate model allows to easily save what is necessary and only that, in a clean way.

Like my sprite don't support NSCoding, since it's view, not model.

Posted 2 years ago #
coolman
Member

@ob1

>What do you mean by fashion ? I you mean that people advocate now because it is hype and used by Cocoa, I disagree.

Ah sorry for not being more clear, but for Microsofties, yes It seems they discovered now the MVC

Posted 2 years ago #

I started with NSCoding support and now having some problems with timers and delegates.
Its all about my class : CCEntity:CCNode <NSCoding>

When reviewed by initWithCoder I call the same `[self
schedule:@selector(onUpdate:)];as in the "normal" init method. But whenCCEntityis beeing inited throughinitWithCoder` the selector gets scheduled twice (second time it stucks with an error: scheduler.schedule method already scheduled).

Another strange behaviour : my CCMenu also is not working when inited through initWithCoder.

Is there anything I have to notice when initializing the object with initWithCoder ?

My Code looks like :

@interface CCEntity : CCNode <NSCoding>
{
	CCActorManager * actorManager; // supports also NSCoding protocol
}
@property (nonatomic, retain) CCActorManager * actorManager;
@end

@implementation CCEntity
@synthesize actorManager;

-(void) registerSelectors
{
	// with default "init" function everything seems to be pretty
	// but when using nitWithCoder: this method will be scheduled twice
	// the second time it will lead into an error message
	[self schedule:@selector(onUpdate:)]; 

	// ..this is not yet a problem - code will continue
	// but exiting code, scheduler will try to unschedule it twice
	// and this time it will not only print a message but throw an
	// exception!

	// ok - another problem is with menues:
	// lets create a menu with one button, lets say to save
	// the game (dont't know - its just an example)
	// the menu will always be displayed but
	// when created by initWithCoder it will not function (not clickable)
	// if you create this object through init, everything seems to work properly
	CCMenuItem * button = [CCMenuItemBitmapFontAtlas itemFromString:@"SAVE"
																			fntFile:@"helvetica.fnt"
																			 target:self
																		   selector:@selector(menu_SaveGame:)];

	CCMenu * menu = [CCMenu menuWithItems:button,  nil]; // one button menu
	menu.position = ccp(160,240); // centered to the screen
	menu.anchorPoint = ccp(0.5,0.5); // centered pivot
	[menu alignItemsHorizontally]; // do we really need to align one item? ;-P
	[self addChild:menu ]; // add as subnode
} 

- (void) encodeWithCoder:(NSCoder *)coder
{
	// here I encode some stuff like :
	[coder encodeObject:actorManager forKey:@"actorManager"];

}

- (id) initWithCoder:(NSCoder *)coder
{

	if ( (self = [super init] ) )
	{
		// here I decode some stuff like :
		self.actorManager = [coder decodeObjectForKey:@"actorManager"];
		[self registerSelectors];
	}
	return self;
}

-(id) init
{
	if ( (self = [super init] ) )
	{
		// here I init some Stuff like :
		self.actorManager = [[[CCActorManager alloc]init]autorelease];
		[self registerSelectors];
	} 

	return self;
}

- (void) dealloc
{
	self.actorManager = nil;
	[super dealloc];
}
@end

Posted 2 years ago #

nsxdavid
Member

Have you tried a breakpoint to determine if registerSelectors is getting called twice, and if so... check the stack to see why.

Posted 2 years ago #

h.hamm
Member

my function registerSelectors will be called once - but the selector gets registered twice.

here is a log output :

2009-12-03 10:06:40.176 Application Name[25462:20b] registerTimer
2009-12-03 10:06:40.176 Application Name[25462:20b] CCNode schedule onUpdate2:
2009-12-03 10:06:40.194 Application Name[25462:20b] Scheduler.schedulerTimer: timer <CCTimer = 08426910 | target:CCEnemy selector:(onUpdate:)> already scheduled

When quitting the App :

2009-12-03 10:06:48.937 Application Name[25462:20b] Scheduler.unscheduleTimer: timer not scheduled
2009-12-03 10:06:48.939 Application Name[25462:20b] Scheduler.unscheduleTimer <CCTimer = 03D870A0 | target:CCGameScene selector:(onUpdate2:)> not found

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.