Today on Twitter, Robert Penner posted a couple of really interesting links…
http://theshyam.com/2009/08/is-inheritance-overrated-needed-even/
and
http://code.google.com/p/noop/wiki/ProposalForComposition
This got me in a researchy mood about inheritance vs. composition, and I dug up this great series of interviews with Erich Gamma (one of the original Design Patterns Gang of Four):
http://www.artima.com/lejava/articles/gammadp.html
http://www.artima.com/lejava/articles/reuse.html
http://www.artima.com/lejava/articles/designprinciples.html
Actually, the last one had the info I was more looking for, but the first two are chock full of interesting data and viewpoints. This post is about some of the data in the second article on flexibility and reuse. Gamma talks about three levels of code reuse:
Reuse of “classes: class libraries, containers, maybe some class “teams” like container/iterator.”
Design patterns.
Frameworks.
He goes into a lot of the pitfalls of frameworks. A lot of this really rung true to me.
A key challenge in framework development is how to preserve stability over time. The more miles a framework gets the better you understand how you should have built it in the first place. Therefore you would like to tweak and improve it. However, since your framework is heavily used you are highly constrained in what you can change.
And near the end of the article he talks about “frameworkitis”:
Frameworks abstract and provide higher level default functionality. To do so the framework needs to be in control. This loss of control can lead to what is sometimes called frameworkitis.
…
Frameworkitis is the disease that a framework wants to do too much for you or it does it in a way that you don’t want but you can’t change it. It’s fun to get all this functionality for free, but it hurts when the free functionality gets in the way. But you are now tied into the framework. To get the desired behavior you start to fight against the framework. And at this point you often start to lose, because it’s difficult to bend the framework in a direction it didn’t anticipate.
That really hit home. This is one of the big reasons I don’t dive into Flex more. Yes, you get a whole lot of functionality for free, but who has not fought against the Flex Framework?
I’ve also felt this quite a bit in the cocos2d framework for iPhone. Don’t get me wrong, it’s fantastic in terms of the free functionality you get, and I can’t think of a better way to get started in 2d iPhone game building, but eventually you do wind up trying to bend it to do something it didn’t anticipate. I spent half a day yesterday doing just that.
And although I’m not working with it personally, I think that some of the projects my company is working on are running into the same general thing with Unity3D.
Recently I’ve been doing and researching a lot about game development on both the iPhone and in Flash. So I’ve looked into some of the game frameworks that have sprung up for Flash, like flixel and the PushButton Engine. I looked more into flixel then PBE, but I can’t claim to know much about either one. But what turned me off about both of them was that very same fear of eventually getting a case of frameworkitis. If you look at the features of both, they contain a laundry list of items such as tile maps, physics, particles, rendering engines, pathfinding, AI, collision engines, sound and asset management, on and on.
While I’m sure this will get you up and running quick, I feel like before long, you’re going to be fighting against it in some way or other. PBE markets itself by saying you can build “modular pieces of gameplay instead of monolithic applications” and integrate your own libraries easily, so that may not be that bad. But Gamma also says, in the same article:
Because the bigger the framework becomes, the greater the chances that it will want to do too much, the bigger the learning curves become, and the more difficult it becomes to maintain it.
My feeling is that these frameworks just try to do too much.
I’ve been slowly working on making my own game framework – abstracting out pieces of commonly used functionality, making them reusable, and packaging them together. One strong feeling I’ve had about it though, was that I wanted it to be lightweight, and every piece be optional. After reading this article, I discovered that what I really wanted to build was a game toolkit. A toolkit would just be a set of building blocks that you can use as you see fit. Gamma has this to say:
Toolkits do not attempt to take control for you and they therefore do not suffer from frameworkitis.
…
With toolkits you create and call toolkit objects and register listeners to react to events. You’re in control. Frameworks try to be in control and tell you when to do what. A toolkit gives you the building blocks but leaves it up to you to be in control.
…
Also, if we do frameworks, we try to make them small frameworks. We prefer many small frameworks over one heavyweight framework.
…
If you really want to take the risk of doing frameworks, you want to have small and focused frameworks that you can also probably make optional. If you really want to, you can use the framework, but you can also use the toolkit. That’s a good position that avoids this frameworkitis problem, where you get really frustrated because you have to use the framework. Ideally I’d like to have a toolbox of smaller frameworks where I can pick and choose, so that I can pay the framework costs as I go.
This all made a whole lot of sense to me and gave me a lot more direction on where I want to go with my frame… er… toolkit. 🙂
Anyway, even if that all doesn’t interest you, read the three articles above. Fantastic insights to be had.