A fast, easy to use, free, and community supported 2D game engine
djdrzzy
Member
Hey,
My problem is I want to construct Action instances at run time from a NSDictionary and the challenge is that there are different initializers for different concrete Actions.
I propose the following two changes:
1) No arg inits for all subclasses of Action.
2) Exposing the ivars as properties.
Then it would be easy for a tool, or code, to manipulate Actions without actually knowing what concrete Action it was dealing with.
If there are no objections I will prepare a patch.
djdrzzy
Member
The problem there is you're dependent on every action having that new initWithAttributes:(NSDictionary*)attributes method which would be a pain to write for every Action and means more code that could potentially break as you're depending on that dictionary being set up right. If you have properties then you're not dependent on a dictionary which is good for external tools and code as well.
josho
Member
For this to be useful for a tool to make use of you need a consistent convention that all action classes follow. No arg inits with properties are easy, it's just following the Key Value Coding paradigm established in Cocoa—I like it.
I disagree with ob1 above about supporting an optional init that takes a dictionary. The key reason simply being the 'Optional' part about it. Having an optional convention makes it difficult for a tool to support. While, requiring an initWithAttributes adds a fair amount of burden to authors writing new Actions that may not even care about supporting a Dictionary based initializer.
NSCoding would be easy to add; and I still advocate NSCoding support for the entire cocos framework.
Codemattic
Moderator
@djdrzzy, you want to bypass the designated initializer methods - require all Action classes to have at least an -init with no parameters - and then your code will set all the properties itself?
Check with Riq, but that sounds bad to me. If you want to start working on proper archiving functions to Cocos then work on that, but this sounds like a kludge that shouldnt be in the official Cocos.
I know this sounds like a pain, but maybe make a class that knows about the different actions you will be using, knows about your dictionary format, and takes a dictionary and outputs the actions.
@slipseter216: added NSCoding to roadmap.
http://www.cocos2d-iphone.org/wiki/doku.php/roadmap
josho
Member
I think we have 2 separate issues here. First is Key Value like support, and the second is NSCoding. I see the merits of NSCoding, and we don't need to discuss that further as Riq added it to the roadmap (thanks Riq!). So, let's focus on djdrzzy's proposal of Key Value Coding.
The goal is to create instances of Actions without knowing the particulars of the action being created. This is difficult today as each action has a custom initializer that does not externalize its state as properties, ie. Actions are a black box. The proposal is to decouple Action's initialization from its state by adding properties.
To address Codemattic's concern a correct implementation would respect the designated initializer. Let's make this discussion concrete and look at how RotateTo's initialization would change:
// Existing designated initializer
-(id) initWithDuration: (ccTime) t angle:(float) a {
// Nothing changes here
...
}
// New, no-arg initializer
-(id) init {
return [self initWithDuration: 0 angle 0.0]; // Essentially a trivial do nothing action
}So, we init with sane default values. Later when we know the values we set them using properties like the following:
RotateTo *rotate = [[RotateTo alloc] init];
...
rotate.duration = 10;
rotate.angle = 90;
[aCCNode runAction: rotate];So, we clearly respect the designated initializer. We add minimal complexity to the code, and break nothing. What we gain is the ability to create a mechanism to easily create Actions without knowing which concrete action we are creating. The specific use case that I'm sold on is creating a text file to load a bunch of actions, e.g.:
Explosion.txt
'TintTo' {
duration 10
red 1
green 0
blue 0
}
'ScaleTo' {
duration 9
scale 120
}
Then an artist can manipulate the explosion.txt file and see how their changes affect the scene. Eventually a more elaborate tool could be developed, so that Actions could be visually tested from a GUI builder.
If you know of a different way to achieve this then I'm all ears, but personally I'm sold on the idea.
ob1
Member
@johso Well, I don't really understand how my idea of an optional dictionary makes it difficult to support/work.
some of my class that are related but have different properties all have a designated initializer "initWithContext:(id)context" which can be nil, a dictionary, or anything else.
That's what UIKit does for UIView animations I think:
+ (void)beginAnimations:(NSString *)animationID context:(void *)context
The dictionary can then easily be put in a plist which seems to make what johso wants to do with his text file even easier.
I am not a pro of KVC, but I think my method is not very different apart that I find it in my case easier to have all my values in a dictionary.
josho
Member
ob1,
Thanks for pointing out the UIView class method beginAnimations, however, I'm trying to wrap my head around how it immediately applies here.
My concern with your proposal is that without defining what the context is, we get ourselves no further ahead than before. Who is responsible for implementing initWithContext? If we make this a part of the API and each Action implements it, then shouldn't the context be well defined (e.g. the RotateTo initWithContext requires a Dictionary containing angle and duration as keys). That approach doesn't seem to be your intent, so I must be missing something in your proposal.
On the other hand KVC makes supporting loading from a Dictionary trivial, given a Dictionary like the following:
[ 'TintTo' : ['duration':10, 'r':1, 'g':0, 'b':0],
'ScaleTo' : ['duration':9, 'scale': 120]
]We could load that Dictionary into a Sequence of Actions by the following pseudocode:
NSMutableArray *actions = [[NSMutableArray alloc] init];
for (actionName in [actionDictionary allKeys]) {
id properties = [actionDictionary valueForKey: actionName];
id action = class_createInstance( objc_getClass(actionName), 0);
for (propertyName in [properties allKeys]) {
[action setValue: [properties valueForKey: propertyName] forKey: propertyName];
}
[actions addObject: action];
}
Sequence *s = [Sequence actions: actions];So, making the simple set of changes to make Actions support KVC then in a few lines of code we can load a Dictionary into Actions. How does your initWithContext proposal compare to this?
ob1
Member
@johso I am not sure... I think my proposal is almost the same as yours. We must have a misundertanding somewhere.
Just your second "for loop" would be directly in the "initWithContext", making it more DRY (don't repeat yourself). The parameter to initWithContext would be your "properties".
Riq: Awesome, I'm a big fan of this idea, as it will make editors, saving and loading game state, etc much easier. We should start some discussions about this in another thread or something, because there are some very interesting decisions to make about how far to take it.
josho/obj1:
Really, this discussion could be about any constructor in cocos, not just actions. If we're going to invoke some form of convention to make constructing objects from a text file easy it shouldn't be limited to one type of object.
And I'd argue that that format IS NSCoding, which can save/load from a text based file just as easily as it does from a binary format. And in fact, that file is a plist, which is a subset of XML, which can also be loaded as a dictionary, array, etc.. So when you say you'd like to be able to create a class using an NSDictionary, you might as well be talking about adding NSCoding support.
So, if we add NSCoding to the engine, we get all of this for free. You simply use the initWithCoder to initialize your object and pass it the NSData object (which can be an NSDictionary from a plist) and it just works.
ob1
Member
@slipster216 What you say makes sense. Still I am a bit uncomfortable with it because NSCoding seems more to be about serialization. Well, I guess that for josho's case it's a very good solution for sure.
djdrzzy
Member
NSCoding would be great for archiving/unarchiving the state of an object and would be awesome for saving and loading levels so I'm glad that is getting included.
For changing the state of an object from any outside source (a plist, Inspector Window, etc) you are going to need a nice way to change the attributes of an object on the fly and archiving/unarchiving an object every time you changed the duration of a MoveTo would be really inelegant. I'm with josho in that these are two different things we are talking about here.
josho
Member
Let's keep this discussion focused on the 2 original points added by djdrzzy, not NSCoding. However, I'll join any subsequent discussions on NSCoding as I find that interesting as well.
So, the original 2 points being discussed are 1. consistent use of properties in the Action hierarchy and 2. support no-arg init methods.
1. The Action class hierarchy is largely inconsistent with properties, e.g. AccelAmplitude exposes rate as a property, but RotateTo does not expose angle as a property. So, do we agree that in the Action hierarchy we spend some cycles to ensure properties are consistently used? I'll volunteer my time for that effort.
2. Let's support No-arg initializers. The Objective-C Programming Language states "A class must also make sure that all inherited initialization methods work". The IntervalAction class breaks this rule by throwing an exception if its 'init' method is invoked. So, do we agree that supporting a no-arg init method not only is what we must do according to the language guide, but can be supported without causing any harm? E.g. IntervalAction's init could easily call 'initWithDuration:0' instead of throwing an exception.
djdrzzy; they are, in fact, the same; unless your talking about changing the state of an action while it runs from code, which is different from anything I've seen people talking about in this conversation.
If you simply want to construct an action from, say, a text-based plist file, NSCoding works just fine for that. That's because NSDictionary (or NSData) is both NSCoding compliant and can be passed to a static function on NSKeyedArchiver to construct an object; like so:
// construct with an NSDictionary from a plist
// first create an NSDictionary object and fill it out with the plist
NSDictionary * mydata = [NSDictionary initWithContentsOfFile:@"myfile.plist"];
Action* a = [NSKeyedUnarchiver unarchiveObjectWithData:[mydata objectForKey:@"myaction"]];This was typed from memory, so don't expect it to compile. But basically you can define a bunch of actions in a plist, then construct them from that data regardless of what type of action it is, or what properties/variables it has (since we're using the base class). This is exactly what several people have asked for in this thread, and has many advantages over any of the other proposed solutions.
Also, some of the proposed solutions just don't make sense to me. For instance, stripping the init methods of the required parameters which make an action useful not only makes them harder to use, but prevents the kind of in-line sequencing that's cool about actions. I also have to know their internal structure before I can really use them, because the init method will not produce anything meaningful on it's own. That's always a bad design, IMO, in that good API's make it easy for you to construct and use objects without knowing how they work. For instance, if we remove the arguments from the constructors:
// construct a sequence of actions in one go using arguments
id seq = [Sequence actions:[MoveTo actionWithDuration:0.5 position:ccp(0,0)], [MoveTo actionWithDuration:0.5 position:ccp(100,100)], nil];
// in a no argument world, this becomes a lot more to write
id action1 = [[[MoveTo alloc] init] autorelease];
id action2 = [[[MoveTo alloc] init] autorelease];
action1.position = ccp(0,0);
action2.position = ccp(100,100);
action1.duration = 0.5;
action2.duration = 0.5;
id seq = [[[Sequence alloc] init] autorelease];
NSMutableArray* list = [NSMutableArray array];
seq.actions = list;And if I only have the dictionary constructor it gets even worse.
In addition, NSCoding support gives us a ton more flexibility. For instance, you could save or load the entire sequence from a file as a single entity because NSCoding stores the object graph as well (in the non-plist cases). You could also store it mid-execution, and have it pick up right where it left off when you un-pause the game. We also get tools for handling versioning of objects, so if formats or data change it can load old versions and convert them into the new versions on save.
josho:
1. Yup, makes sense. Though it might make sense to write our own setters so that values are checked for validity.
2. I'm ok with this, though I kind of like blocking out init so you don't have actions who's state is invalid. We should, however, keep the current init functions for the convenience listed above.
And for a third, we should go back to the reason for these requests; the need to load actions from a xml/plist file. For that I think my last post lays out my thoughts quite completely.
Steve Oldmeadow
Administrator
From my experience actions can involve fairly complex object graphs when you take into account sequences, spawns, repeats and time modifiers like ease actions. Personally I rarely use an action that isn't in a sequence with at least one call func that will trigger a state change.
With something like a ScaleTo or MoveTo you often want to specify the starting values of the CocosNode you are going to apply the action to. So for something like Josho's example of an artist editing a text file the artist would need a mechanism to specify the starting values for the CocosNode as well as the "To" action.
Of all the proposals slipster216's is the only one that I see that can support how actions are actually used.
ob1
Member
I am now convinced that slipster's idea is good. One of the place I am using a dictionary I should really have used NSCoding (loading levels). I am still not so sure for the second place (passing various information between scenes).
But, from what I have seen in the discussion, part of the problem seems to be that making complex actions is ... well... complex (mesh of sequences, callfuncs...). Shouldn't we talk about a way to script or streamline complex actions ?
For me the really exciting thing about deep serialization support throughout the engine is how much it will help to allow a proper editor to be created. While I love creating games, I like creating and designing tools chains even more. I know, it's strange, but true.
Anyway, once you can serialize an entire scene to disk and cocos runs on the macOS, it becomes pretty easy to write a layout style editor for doing animation sequences, multi-part character animation, etc, etc. Not to mention saving game state becomes trivial. With a bit of inspection code, it can potentially place and save game objects unique to your game as well.
djdrzzy
Member
I should have clarified in my last post and also in my initial post. I do not want to replace any existing code, just add to it. I don't plan on taking out any existing functionality. I'm looking for an easy way to have some sort of tool manipulate an existing Action while it is instantiated. Constructing it from a NSDictionary was half the battle but I was thinking further along for when needing to manipulate it which is why I proposed the solution I did.
Adhering to NSCoder would make it easy for a tool to load any archived Action you had been working on and it would be great to have that. Once you had it unarchived how would you manipulate it though?
Looking at the cocos2d roadmap for versions 1.x/2.x it looks like what is planned is 2/3 of the way to what is needed for a full blown developer tool and all that is missing is an easy way to manipulate Cocos objects. You've got cocos2d Mac OS X support, easy archiving and unarchiving of Cocos objects through NSCoder which is close what Interface Builder does with nibs and then the missing part which is an easy way to manipulate already instantiated Cocos objects.
Consider the inspector window in Interface Builder. It manipulates existing buttons and views not by calling a custom init method or archiving/unarchiving every time the button or view changes but by modifying their properties directly. The easy way to do this is through key value coding and key value observing as discussed in previous posts.
To nicely implement key value coding and key value observing it is easiest to do it through defining properties.
I'm looking for a way to easily manipulate an Action which would get part of the way there for the missing third part. My proposal doesn't take any existing functionality away from Cocos, only adds to it. I'll submit a patch proposal into google code and start work on it right away.
obj1: I found a rather unique way to deal with that in my latest game that might work for you. Here's what I did:
- create the scene in photoshop how you want it, one layer per element
- use the export script to export all layers to files with clipping turned off
- import the textures into zwopple's tool, export the plist and atlas texture
- using zwopples atlas system instead of cocos's current one
- load the atlas and create all of your elements
- position all elements at ccp(240, 160) or whatever center is for your game
Because zwopples system (and cocos's in 0.9) stores offsets for each texture and clips the texture to it's bounds, placing the object at center will always put it exactly where it was in the photoshop scene. And with that, your whole scene is arranged for you without having to manually place things..
djdrzzy:
A lot of cocos nodes are already key-value complaint, and we should make the rest of them that way. My only concern with actions would be guarding the setters from bad values. When we get to the point of an editor, we can do some type of inspection to allow those properties to be exposed for editing in a property editor of some sort.
josho
Member
It sounds like we are converging on ideas, this is good.
@slipster216, regarding NSCoding and writing to a plist/xml. I looked into NSDictionary's writeToFile method, this only supports limited types (ie. instances of NSData, NSDate, NSNumber, NSString, NSArray, or NSDictionary). So, simply implementing NSCoding doesn't give us nice plist representation of CocosNodes / Actions for free.
So, if I'm not mistaken to persist Actions to a human readable format would require implementing a custom NSCoder. Has anyone seen a good example an NSCoder implementation that persists objects to a custom file format?
ob1
Member
@slipster216 Thanks, sounds interesting. Does that really work with LabelAtlas though ?
It'll only work with sprites created with zopples atlas system. Though I suppose you could create dummy objects to do the same trick and read the coordinates from the plist file..
You must log in to post.