I am by no means an expert when it comes to game development but does anyone else think that when you mix (as you would when developing a game) all the class based GKEntity, GKComponent, GKStateMachine and GKAgent you quickly end up with a lot of complexity and confusion. I have spend a good few days this week decrypting the various supplied demos which seem to leave a void between totally isolated one line examples in the docs and vast swathes of interconnecting code that presents all the concepts together in a whirling blizzard. Don't get me wrong I like the concepts and some of them will be very useful, but on the whole it just feels a bit like Apple are trying a little too hard to conform everything to a class based model.
Complexity and possible confusion
I think it would really help if apple provided smaller, easier to understand examples. The robotgame example is great but overwhelming. Most other gameframeworks offer multiple example projects for each major feature.
Game development is complex. 😉
And what should those be if not classes? Structs? Stateless functions? There's just no way around a decent object model, and personally I find GK's class hierarchy almost too condensed.
I'm working on GameplayKit demos over the coming weeks/months. Don't expect big new tutorials and demos from Apple - what you see in the beta is usually what you get (ie consider how Adventure is still the main and almost only SpriteKit demo today). The community will provide the rest.
Currently I'm finishing a GKMinmaxStrategist demo. Follow TilemapKit.com or my Twitter account for updates.
FYI, this is what I'm working on (a GKMinmaxStrategist sandbox app for testing/debugging the AI):
Having spent a little more time digging through the supplied examples and the SDK things are starting to become a little clearer. I particularly love the GKAgent and Pathfinding, but at first glance I do find the state machine over complex. I have done state machines in a number of projects and they have always worked well and feel a lot less complicated to work with, I will have a better look at this aspect next week.
I once created an entire scripting language on the concept of statemachines, using Lua as the defining language (this got turned into C++ statemachines during map load).
The concept was simple:
- every state had a name
- every state contained 0-n "events"
- an event is a combination of conditions (ie "unit with ID x in range r") which, when all were true, executed the event's actions
- wrapped in the language itself was the concept of "one-time events" which were removed from the SM when executed. Other wrapped events included timers which had an automatic interval, and "toggle events" which were two events presented as one that mutually excluded each other through the use of variables.
- every event could optionally change state to any other state when the event executed
Each entity in the game could have one such statemachine script that defined its behavior.
There was also an unlimited number of "world" scripts which were prefixed with _ and ran without an entity, to provide level-wide gameplay (ie AI stuff, cataclysmic world events and such).
I'm tempted to implement that kind of system for GK Statemachines.
After playing with GKStateMachine over the last few days I am a lot happier and better informed as to how this works, so much so that I will more than likely replace my custom implementation with this in our next game. Having teased out all the information these things are relatively simple to implement, the problem I had was that you have to hit all the sources (WWDC Video, Code examples, Guides & Docs) to get a full picture.