Swift + Spritekit Prototype Result

My latest prototype uses two core technologies: Swift and Spritekit.  This was an experiment to see how ready the language and games toolkit were for making games, quickly.

A caveat that must be repeated: I spent more, I mean significantly more, time with Photoshop.  And that tool has served me well.  A reminder that code is but just a small portion of what is a game.

Now back to the code.  Overall, I find Swift to be a joy to work in when it works.  A few times did I see the syntax highlighting crash and restart (it's nice it didn't bring down XCode).  Spritekit does what it is good at, displaying images from a generated atlas.

90% of the time I was in coding bliss.  The let for constants just forces me to be explicit about what is constant.

Now for the pitfalls.  The 10%.

Spritekit does not have an innate ability to display subsequent frames of animation.  I can do it in code, but it's something I'd expect the framework to handle and not the game.

Sure, we do have this nifty editor to set up a scene, but I can't create empty sprites and save them in the editor.  Rather, load a scene and rip stuff out?  The editor is really there for setting up quick and dirty levels.  I was trying to use it to build a character composed of various independently anchored and animated elements.  Not going to happen with what Xcode provides as selecting what's underneath a lot of stuff can be difficult, if not impossible.  In other words, the editor is cute but didn't prove useful in the cases that I needed it.

Physics is another sore point in the editor.  I wanted the container node to have physics and the children to animate.  Again, not happening nicely.

As for Swift, when it comes to prototype levels, I usually encode them in a string in a source file.  Accessing the contents of a string randomly is slow, so I had to cast that to an array.  However, the level was so large that Swift was timing out evaluating the cast from string to array (brownie points for the language since it was optimizing something at compile time which I naively would assume to be runtime).

What annoyed me the most is that I defined a class called Character at which point the compiler just said OK and didn't really complain.  Two Character classes meant casting something to a character was neigh impossible.  I wish the language would have errored once it saw my stupidity rather than try to work around it before giving up and throwing cryptic messages about types $r0 not matching type $r1...

In conclusion, the combination of SpriteKit and Swift are great to play around in, get something quickly running, in a side project where battling with the language is an option.  If not wait a bit for the language to mature with the API.  That has been my experience when doing a 1.5 day project (yes, you'll hit the limits in 1.5 days depending upon what you're trying to do)

And that was my opinion.  Take it with a grain of salt.