We are actually using cocos2d::Vector|Map for characters, etc. I came from cocos2d-iPhone so retain/release is fine by me and I enjoy that I mostly don’t have to think about memory management while writing c++ code, which is unusual.
One reason for creating ValueVector and ValueMap was for parsing PLIST files, and which we now use when parsing JSON (we used to convert all our source config JSON into PLIST, now we just use directly).
I liked the old __Array & __Dictionary, but I wanted to use the lot of other features in 3.x (namely c++11 improvements) and decided to just move away from all deprecated methods for a cleaner path forward with the engine. I’ve since gone forward using ValueVector for cocos2d::Value types, c++11 std::vector for non-cocos2d::Value value types like Vec2 and custom structs, and all Ref* derived classes with cocos2d::Vector like GameObject*, Character*, Sprite*, Projectile*.
We do have a common GameObject* that is the base for all Character, Projectile, Weapon so we can store any combination of those classes. We don’t store Vec2 in the same collection as string or GameObject*, however.
You could store a vector or map of Abilities like this:
class Ability : public cocos2d::Ref* {
cocos2d::ValueMap spellInfo;
cocos2d::Map<std::string,cocos2d::Ref*> spellRefs;
}
As you say it is “split”, but maybe it’d be the quickest way for you to finish?
I think the main rub for you at the moment is you don’t want any additional work beyond just porting code, so changing how you reference and access data and pointers is not wanted at this point.
We were essentially in the same boat 3 months ago when we moved from 2.x to 3.x so I am not trying to argue in favor of 3.x “split” functionality as you call it, just trying to advise on our path in case it helps yours.
Anyway, probably written enough discussion on it for now, but maybe I’ll go back and see how we changed from __Dictionary to ValueMap. I know that now I do feel like our code and architecture is better, but that also includes regular refactoring having learned within previous year.
If you have any other questions, definitely post them if you haven’t. It’ll help everyone who wants to migrate.
Last tip until then is I highly recommend commenting out large chunks of code with an easy way to know you did this whether through #warning pragmas or some unique word // C2D3MIGRATION: need to uncomment and migrate this method. Getting it to compile is a huge huge win!
It’d be interesting to hear about the post-mortem of sorts. Godspeed.