Entity class best practice

(14 posts) (6 voices)

Started 1 year ago by Nial
Latest reply from Jugibur

Tags:

Nial
Member

I've spent a day or so reading over the Sparrow documentation and experimenting with the codebase and am suitably impressed. I just have a few questions regarding 'best practice'.

In terms of creating a Player class, how should I be going about doing that? In my mind, I would expect to create a subclass of SPSprite that maintained a list of SPMovie objects for the entities various animation states ('walking', 'running', etc). My SPMovies would be generated from frames loaded by an SPTextureAtlas (player.xml). Switching between animations would simply be a case of adding the appropriate SPMovie as child to my SPSprite object (removing any existing SPMovies where appropriate). But this seems slightly backwards, given that the SPSprite exists to display texture data.

Could anyone give me any clarification on how this is handled correctly?

Posted 1 year ago #
Daniel
Primary Feather
I think your approach is a good one! That is a simple and effective way of doing it. Actually, that's quite exactly the method I used for the penguin sprite in PenguFlip.

Here's what it looks like:
```
@interface Penguin : SPSprite <SPAnimatable>
{
    SPSprite *mFlame;
    SPJuggler *mJuggler;

    SPMovieClip *mActiveMovie;
    SPMovieClip *mStandardMovie;
    SPMovieClip *mRotationMovie;
    SPMovieClip *mFlipMovie;
    SPMovieClip *mBoostMovie;    

    float mBoostTime;
    int mFlipCount;
}

- (void)flip;
- (void)boostForTime:(float)time;
- (void)playPossum;

@property (nonatomic, readonly) float boostTime;
@property (nonatomic, readonly) int flipCount;

@end
```
As you can see, there are 4 different movies for the different animation phases, and 1 movie that points to the active movie clip. That one is advanced once per frame, in the "advanceTime:" method (thus, I implemented the SPAnimatable protocol, just in case I want to add the penguin directly to a juggler.)
Posted 1 year ago #

//
//  LTRunner.h
//  jumper
//
//  Created by Seivan Heidari on 12/21/10.
//  Copyright 2010 LITH. All rights reserved.
//

#import "chipmunk.h"

@interface LTRunner : SPSprite {
    SPJuggler *juggler;
    SPMovieClip *runningMovieClip;
    SPMovieClip *activeMovieClip;
    SPTextureAtlas *textureAtlas;
    BOOL isJumping;
    cpShape *shape;

}
@property(nonatomic, assign)BOOL isJumping;
@property(nonatomic, retain)SPJuggler *juggler;
@property(nonatomic, assign)SPMovieClip *activeMovieClip;
@property(nonatomic, retain)SPMovieClip *runningMovieClip;
@property(nonatomic, retain)SPTextureAtlas *textureAtlas;
@property(nonatomic, assign)cpShape *shape;

-(void)advanceTime:(double)seconds;
-(void)setupPhysicForSpace:(cpSpace *)space;

#pragma mark Events
-(void)jump:(SPTouchEvent*)event;

@end

Posted 1 year ago #

Nial
Member

It's good to know I'm on the right path. The only remaining confusion for me is how mActiveMovie, which (as I understand it) is acting as a pointer to the currently active SPMovieClip, is updated.

Here's my first attempt at a base Player class:

@interface Player : SPSprite {
	SPMovieClip *mActiveMovie;

	// Animations
	SPMovieClip *mWalkMovie;
	SPMovieClip *mJumpMovie;
}

@property(nonatomic, assign) SPMovieClip *mActiveMovie;
@property(nonatomic, retain) SPMovieClip *mWalkMovie;
@property(nonatomic, retain) SPMovieClip *mJumpMovie;

- (void)setAnimationState;

@end

Which is setup like so:

- (id)init
{
    if(self = [super init]) {
		SPTextureAtlas *atlas = [SPTextureAtlas atlasWithContentsOfFile:@"player.xml"];

		// Load our animations
		mWalkMovie = [[SPMovieClip alloc] initWithFrames:[atlas texturesStartingWith:@"walk_"] fps:12];
		mJumpMovie = [[SPMovieClip alloc] initWithFrames:[atlas texturesStartingWith:@"jump_"] fps:12];

		// Set our active animation
		mActiveMovie = mIdleMovie;
		mActiveMovie.x = 0;
		mActiveMovie.y = 0;
		[self addChild:mActiveMovie];

		[self addEventListener:@selector(onAddedToStage:) atObject:self forType:SP_EVENT_TYPE_ADDED_TO_STAGE];
		[self addEventListener:@selector(onRemovedFromStage:) atObject:self forType:SP_EVENT_TYPE_REMOVED_FROM_STAGE];
	}

	return self;
}

This works fine, and my idle animation is shown as expected. However, to change the animation I'm forced to remove mActiveMovie from my Player SPSprite, along with the scene's juggler, and then add both of them back:

- (void)setAnimationState {
	[self removeChild:mActiveMovie];
	[self.stage.juggler removeObject:mActiveMovie];

	mActiveMovie = mWalkMovie;

	//[mActiveMovie play];
	[self addChild:mActiveMovie];
	[self.stage.juggler addObject:mActiveMovie];
}

Is this correct behaviour?

Posted 1 year ago #

seivan
Member

Apple docs says don't prefix your instance variables, there is no need for that.
Ergo you don't need the mActiveetc...
just name it without a prefix.

Posted 1 year ago #
baike
Moderator

I reckon Apple's wrong on that one. Just like that god-awful mouse scroll ball. It finally stopped working for the last time and I'm glad to be rid of it!

Posted 1 year ago #
seivan
Member

Sorry for hijacking, while we still are on the best practice talk

No they are correct on this one, and also it makes sense.
Apple discourages using an underscore as a prefix for a private instance variable.
In fact, the idea of a private prefix is largely unnecessary, as virtually all instance variables in Cocoa are protected anyway.

I use properties to get/set my iVars.
I like to use self.prop to show that I am not working on a local variable, but an instance variable.
There is hardly an overhead, properties are there for a reason. USE THEM.

"I tend to use non-prefixed instance variable names (note that "member variable" is a C++ism as it's suggestive of structures and classes being mainly interchangeable, which is not the case in Objective-C), and in cases where ambiguity arises, I use the Smalltalk convention of naming the parameter by its type with "a" or "an", e.g.:

- (void)setFoo:(SOFoo *)aFoo;
{
foo = aFoo;
}
(of course, in modern ObjC you'd use a property for this.)

Using theFoo instead of aFoo is also somewhat common; see the answers to this question.

Note that the Cocoa key-value coding guidelines pretty much assume either (a) you do not prefix/suffix your instance variable names, or (b) you implement (or synthesize) non-prefixed/suffixed accessors for them. As someone else mentioned, do not use the _ prefix; it's reserved for Apple's use in their frameworks."

Posted 1 year ago #
Nial
Member

Well, it's good to see members of the community getting so passionate about code formatting and other associated practices. Prefixing of instance variables isn't my typical style, I'm just following the Sparrow example conventions while I learn the ropes.

That said, if we could move back on topic: is my approach to switching between active animations correct?

Posted 1 year ago #
Daniel
Primary Feather

Nial, your approach is correct! However, you could simplify it even more if you remove the juggler and just call "[mActiveMovie advanceTime:passedTime];" in the classes "advanceTime:" method manually. That's just what the juggler would do -- and if he has nothing else to do, you can do that just as well =)

Seivan, I see your argument, and it's perfectly fine if you write your code that way. I might be a little old-fashioned in that respect, but I like it if I see from the variable name that it's a member (hence, "m") variable. Just like in Ruby, where member variables simply start with an "@". But like many things, it's just a matter of taste -- as long as you don't use the underscore, as that might cause problems with Apple's code.

Posted 1 year ago #
seivan
Member

Hmm you reference to ruby actually made sense and I can see why you'd want to do that now =) hehe.
But it feels unnecessary.
I _NEVER_ call instance variables directly, so I can tell that they are instance variables by using self.prop.

Also C++ has members variables, OBJ-C, has instance variables. Minor difference.

Posted 1 year ago #
alex_h
Moderator

I reckon it's none of Apple's business what I call my variables

Posted 1 year ago #
seivan
Member

Following convention is everyones problem, especially if someone is taking over your code after you.

Posted 1 year ago #
alex_h
Moderator

As long as you have an agreed system among the people you are working with then its irrelevant what Apple recommend.

Posted 1 year ago #
Jugibur
Moderator
My approach to this is to have a entiy with a "has a"-relationship to the displayContainer (the sprite).

The entity have an array of states.
Each state is an object and could be in a group with other states.
But only one state of each group is allowed to be active.

For instance, "Move", "Rotate", "Standing" are in one group an each of them is exclusive - no other state of this group ca be active in the same time.

But there may be some more states which can be activated additionally, like "blinking" oder "fading out".

To have a more clear separation of your code you can put all responsibilities and behaviors in the created state-object.
For a simple state it suffice to build once a State an inherit from that (perhaps for changing only an image).

As against the suggestion above the whole display-tree (of each entity internal) is already created -- but all sprites of an inactive state are hidden (alpha = 0)!
So once you have build the right order for your sprites you must not worry about it anymore after activating oder deactivating a state (and of course fading from one state to another is easy done by changing the alpha value).

Here the (simplyfied) scribble:
```
EntityState : NSObject {
  isActive
  Group
}
Entity : NSObject {
  ArrayOfStates
  DisplayObjectContainer (pointer to the graphic output)
  addStateWithKey:
  removeStateWithKey:
  removeAllStatesInGroup:
}
```
Unfortunately I'm not fully ready with this but a small piece still works.

Additionaly I want to implement a component-based approach which can for instance found in the torque game engine:
http://docs.torquepowered.com/torquex/official/content/documentation/TorqueX%20Core/Concepts/Component%20System.html

Here are some basic concepts (espacially "Component" and "Type Object":
http://gameprogrammingpatterns.com/

Juergen
Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.

Sparrow Forum

Entity class best practice

Reply