Post date: 20-Dec-2013 02:27:41
I noticed recently that Mozilla are running a competition to create JS games with Goo Technologies' new toolkit, so I thought I'd try it out. (It has a lot in common with Unity3D, so I thought I'd be able to adapt a few ideas across and have *something* in a single, time-bounded session.)
It was great practice for my JS skills, and I learned a lot about serious web apps - but mainly I learned the difference between a good JS library and a *great* JS library.
My experience with Unity has always been - if I need something, there's documentation for it, and MonoDevelop can autocomplete for me in C#-land, giving me a super easy way to explore the API. The Goo Engine, on the other hand, only seems to be available a minified JS file, and the documentation is sparse to say the least, making discovery incredibly difficult. This was thrown into strong contrast when I decided to fold in a physics library, and chose CannonJS (which is actually bundled with Goo): Cannon has significantly more readable documentation, and is also available unminified, so I could just jump into the code to unpick some misunderstanding or bug. (This is a habit I've picked up from Ruby on Rails - learning and debugging by just digging into the library code directly.)
Goo, in their favour, provide some recipes for various common tasks - but these are inconsistent, and if your problem isn't covered, you're out of luck. It all points to a library that has grown incredibly fast - they have an impressive amount of functionality (a substantial chunk of the core Unity stuff, I suspect) but the rest of the project is struggling to keep up with the rapidly changing code. I'll certainly be following their progress, and look forward to playing with the Goo Engine again when it's a little more mature.