GameDevMike

Some time back in 2001 or so, Scott Bilas of Gas Powered Games made a post to the sweng-gamedev mailing list describing the game object system his team had implemented in their game, Dungeon Seige. The GPG guys had ditched the traditional object inheritance tree hierarchy for a more flexible component-based system. The ensuing discussion showed that GPG was not the only company doing so and also prompted other developers to adopt component-based systems in their own code. Mick West of Neversoft has a great post on his blog detailing how he worked over two years to refactor the codebase used in the Tony Hawk series of games from a bloated, top-heavy hierarchy to a more streamlined and flexible component system with great results. Since that first mailing list discussion, there have also been a couple of articles about component-based game object systems in the Game Programming Gems series of books.

Development on Smoothie and the (as-yet-unannounced) other project I’m involved with has been going well. But in both cases the design is based on the traditional object-inheritance model. Thus far, where I’ve seen component models discussed in the game industry it has nearly always been in reference to game objects. I suppose this is because of all the systems that comprise a game, the game object system stands to benefit the most from a component-based design. Most large-scale games have a tremendous number of game objects and functionality to deal with, making the game object system the most susceptible to bloat and rigidity. Yet I can’t help but wonder, would any other systems in a game engine benefit from a component-based design?

Two areas I’m looking at right now, specifically, are the GUI system and the renderer. I don’t think a component-based renderer makes much sense for Smoothie, but it seems it would be an excellent solution for the other project (which I will talk more about after it is officially announced). As for the GUI, Smoothie already uses a hybrid inheritance-component model. For example, it’s designed such there is a root GUI object which contains default event-handling and such, but the rendering of backgrounds and borders is handled by components. Only the rendering of the window content is handled by a member method. What I’m considering is how much farther it would make sense to take the component design. For example, how would a pure component aggregation model work in the GUI system (i.e., a model where there are no concrete GUI objects, just collections of components that provide specific functionality).

I think over the weekend I’m going to move beyond the speculation phase and see about prototyping a component-based GUI. I’ll also need to make a decision on the renderer for the other project real soon as I’m aiming to have a functional prototype of the whole system completed by next weekend. That may mean less work on Smoothie this week, but that’s OK.

One thing I’m really enjoying about working on Smoothie is that I’m not pressured by any deadlines. I did set milestones for myself in a project management application, but since I’m working for myself I can spend as much time as I want in R&D mode, trying out new ideas and switching things around. To an extent, anyway. I do want to get a usable framework released relatively soon, but I’m not going to hold myself to any concrete deadlines. I’m not working alone on the other project, though, so I have to be a bit more disciplined with that one and give it priority when I need to. I really am enjoying the absence of contract work, though, even if my wallet is a bit lighter right now.

Technorati Tags: game development, devlog, Smoothie, component-based design, object oriented programming, game engines