C2 is not a Toy, however I often feel straight jacketed. I often feel how C2 was put together was an after thought. I've spent hours digging through C2runtime.js to figure out how things work(and I only know a little bit). I can honestly say that the basic design scope at a root level is not as good as it can be. And the way C2 is designed there is just no way that "Toy" to Tool can be accomplished without breaking huge amounts of work.
Just four examples of design factors that A drive me nuts, and B drive down productivity.
1. World Objects are Plugins. This is wrong in a good design. There should only be 1 WorldObject.
2. World Objects should naturally be scene graphed.
3. Behaviours should be everything. Image drawer, animation controller, TextFonts... so on etc.
4. The SDK is bulky and straight jacketed. It's not really a very stream lined Plugin system. I've never worked with a Plugin system that was so heavy.
Those are HUGE development downers, and they drive me nuts. Because they require MORE work to do in the basics of C2 than say Unity, Anarchy, Unreal, jMonkey..... I can't speak for Styncil, GameSalad.
And then there is the implementations that just don't quit make the par. When I joined C2 collision was ONLY brute force.... huh? really?. Eventually we got collision cells, however there has been and was a call for quadtree collision. But spactial partition tree wasn't developed, it was just a brute force system, but worked in a grid area. There signs of these half measures all over the place.
Of course do your own Plugin/Behaviour. But let's take a look at collision. Let's say I make a Collision system based on QuadTree. Great. However Sprite, Solid... everything already uses the internal Collision system. So I need to turn that off in the options. Ok. So let's add Plaformer. Platformer is creme de la creme of Plugins. However guess what. Platformer can't work with my QuadTree. So now that iv'e turned off internal collision. Platformer is useless. So now I have write an entirely new Platformer behaviour. Now you kind of see where this is going.
If a core feature isn't done efficiently or flexible, then you notice it big time. It starts working against development. Then there is Pin vs a SceneGraph... so on etc. Function isn't part of the core engine, it's also a Plugin... wtf? There are a lot of features that we use, but just feel short of being a full tool.
However even though I have parts that drive me nuts, and I do work with Unity(at work). Most of my personal game projects are still C2. It's faster, there are less errors, the game api is the best I have ever seen(even flawed). It's the cheapest game tool ever for what it provides, and is still fantastic.
My only suggestion would be that for Ashley get the community involved in any new feature. Not just a call for a feature to exist. but a break down on how developers want to interact with the feature. What they want the feature to be flexible enough to do. A well structured feature that has community involvement, rather than the tool developer making the call how it works, and it's limitations.
As for storage. I've said this again and again. Do storage like any professional does it. It's easy, solves problems.
Use Local Storage and a Dictionary
saving data
1. store values in dictionary
2. save dictionary JSON to local storage
loading data
1. load json stored string from local storage
2. put json string into dictionary
using data
store and use data in the dictionary.
this is how professional development uses data. Takes advantage of asynchronous save/load, but the immediate benefit of using data. This isn't rocket science people.