GameplayKit... First Thoughts

/

I'm quite familiar with game engines, I've written a few in my time (I started on the Commodore 64, but didn't "get paid" until the Amiga. Look 'em up kids). GameplayKit sounded very interesting so I was keen to get stuck in. After 24 hours, I've got some mixed feelings.

The Good

I think the right way to think about GameplayKit is as a Smorgasbord of useful technologies for modelling systems, that is focused on game engines. However, I think it's important to recognise that none of its features are fundamentally tied to games, or even any one game engine. 

The coverage is good, with most things covered

  • Entity Modeling Whenever you build a game (or a model of any system) you will have "things" in the world. Gamekit's Entity/Component system is intended to provide a basis and philosophy for agents in the world. This is not a new idea, but it's a common component of systems likes this (as has been written elsewhere)
  • We then want these entities to DO things, and really the rest of GameplayKit is targeted at providing a rich set of functionality to support Entities and their components. 
    • Randomisation - This is deeper problem than most non-game often realise. You are often looking for a specific distribution (if you haven't played AD&D, think about the bell curve you get rolling two six sided dice, the most frequent results lie in the middle). GameplayKit provides all you need, with a variety of cost models (how expensive it is to generate the next random number, versus how actually random it is). 
    • State-machines - Many things in a game have a state (and only one!), and managing the logic for transitions can be a real mess of if-then-else-or-maybe's. Starts out clean, ends up dirty. States can capture intent (am I hunting, hiding, fleeing) or overall state (running, jumping, waiting), and of course you may have more than one state machine. Explicitly modelling these feels constraining the first time you do (rolling your own or using a library), but three weeks later... you'll be glad you did it. 
    • Pathfinding - A fundamental of many AI systems. Search is easy, doing it efficiently is hard. GameplayKit provides support for both grid based and one open world like models. 
    • Minmax - A classic (and by classic I mean I was teaching it twenty years ago) AI algorithm that is well suited to turn-based games. Another nice addition, and can be built into richer systems if you stop thinking about turns and start thinking about state transitions (but that feels like another post). 
    • Agents - Modeling of actors in the world (really a sub-set of entities) who have goals and behaviours. There are some baked in behaviours in SwiftKit (things to model flocking behaviour for example), A lot of this seems to be focused on movement and I'll need to dig deeper to see if it is more generalised than that. 
    • Rule systems - Enables you to build game logic, fuzzy reasoning systems, and... forgive me here... "emergent behaviour". A note to the wise.... as soon as you have any non-liner dynamic system (you know like ANY algorithm where the results of the previous iteration form the inputs to the next... you know... ALL GAMES) you will get emergent behaviour. Any how. That's a feature. 

So, there's lots. At first blush one might think that it's a useful tool-box for the veteran (you'll never find a game developer whose written path finding algorithms once or more who wants to do it again), and a great start for beginners. It really is, but...

The Bad

Some elements of GameplayKit feel so open... it's tempting to just roll your own. Entities and Components really espouse a philosophy of composition with very little in the way of engine. It's possible to build just about anything from them... but the same is true of Swift. But Swift is carefully designed for clarity. I'm going to persevere, but there seem to be deeper problems for Swift developers that I'll cover later. 

The documentation (at this stage of its development) is pretty shoddy. There was more time spent introducing the concept of composition than was spent articulating the overall architecture of GameplayKit (that was more a case of here's a list of stuff in here). They seem to be depending on a series of example projects to illustrate the ideas. Which is fine, but example projects don't give you the overview. I kept looking for the image that painted the picture of "Here are the components of a game engine, and how you could plug-together GameplayKit's elements to achieve that". 

The remaining issues I see at this point (and I can't stress enough, these are some first impressions as I dig in, not a review) is that whilst something like path finding gets you something running quickly.... it doesn't really allow for much modification or injection. For example, I often gather the data for AI decisions whilst finding the path. Store path stubs for sub-goals you might want to achieve on the way if nothing else changes for example. However there is no way to plug in to these routines. Of course there are ways around it, but game developers hate throwing away cycles. 

As I say, I want to play more... build something. Right now, it feels like a beginners kit, not a GameplayKit. 

The Ugly

At the moment, it doesn't feel like a Swift API. I can't throw blocks in here and there to tweak behaviour. It's all very Objective-C (yes I'm looking at you GKEntity with your Objective-C only method). All of this can change, it's early days. However, I still remember SpriteKit shipping with features available on iOS that weren't on the Mac (and vice-versa). It all feels a bit iOS 7.0-rushed. 

There aren't tools like the great scene builder that's been released for SceneKit and SpriteKit this year (a refinement of last year's, and even that building from the emitter editor two years ago). State-charts are SCREAMING out for a nice visual editor. 

Maybe next year.

Worth Investing In?

I'm going to find out. I'm building a game, simple but more than PacMan and will publish (and be damned, no doubt I'll head off in some directions GameplayKit wasn't intended to go) as a growing Storyboard as it develops. Right now (one more time, first impressions), it seems like a hot mess. Great on the surface, but really quite shallow and a little screwed up underneath. A bit like SourceKit this time last year.