The observation
Isn’t it amazing sometimes how the things that we try to do to solve complexity actually add to the complexity – well at least when it come to the effect on the learning curve.
My son has asked me to write him a packman game where it is possible to control one of the ghosts ( basically he wants a 2 player version so I can be one of the ghosts and chase him – you gotta love children! ) – so I thought that this would be a good opportunity to learn some flash.
I came across PushButton Engine which is a flash game development framework that goes some way to making the effort in developing a game constrained to the game domain and not the mechanics of the flash.
An Example
Now using PushButton as an example of what I am talking about, they have the concepts of components - which are reusable behaviours that you can apply to any of your sprites ( which they call entities ).
Now it is not hard to see that any meaningfully sized game will have many many entities and components with relationships between them – which in the end would leave you with lots and lots of repeated boilerplate code to create and relate the entities and components.
To address this they developed an XML format that allows them to define entities and all the components that they use without having to write a line of “code”. ( aside: I maintain that xml or any other configurations like this is indeed code just not the compiled type ).
This sounds like a great idea – and is .. but interestingly it makes it somewhat harder to learn.
If you compare a worked example of a simple PB game which manually creates everything via code to the one that uses the XML, you find the pure code much easier to follow.
Why – simply because in the pure code case, everything that you need to unravel the black magic is right in front of you. In the XML case you have to context switch between the AS code and XML to try and understand a single new concept.
So the technologies put in place to simplify development is in fact they very thing increasing the gradient of the learning curve.
The picture I have in my head when I think about this is to imagine that you have some core technology and think of it as a sphere with a surface area of core API.
Now when you start to build on this technology you start to add new facades and interfaces which wrap your original core sphere. With each of these layers over time you are making your sphere’s surface area larger and larger – and clearly the growing surface area is the required domain knowledge now for your technology.
So what is the lesson ?
Well actually I am not sure - it is just something interesting – but I guess one lesson might be that you should always give new people access to the simple core that you have and then expose them to the cool technologies you have to make thing easier later.
That might be harder than you imagine – given how close you are to your product and how likely it is that you see the wrapper technologies as the real ‘selling points” of your technology.
What does this observation teach you ?
