Common Component Syndrome

If I never see another sortable database bound grid again, it will be too soon. This “GUI control” seems to be the favorite item of every corporate coder. It is the catch-all to creating reports, data entry screens, and general data viewers.

I’m currently finishing up a project for a financial firm that involves a huge amount of processing and data moving from logical business tier to logical business tier. There’s a ton of work going on. The problem is that all this work needs to be monitored on a periodic basis. How does the user watch all this “stuff” in a useful and pleasant user friendly way?

I don’t know what the “right” answer is, but I can imagine plenty of approaches that would not use a sortable grid. Part of the problem is that on Windows, Microsoft has for years provided a simple generic Excel-like grid that is easy and cheap to use. It just needs to be dropped on a Windows form in the design tools (Visual Basic, Visusal Studio.NET, Delphi, PowerBuilder, etc) and set a couple of properties to attach it to a database table and allow the data to be viewed, edited, sorted, and printed.

It’s so cheap and easy to implement that it has become the defacto-standard corporate application GUI. The problem is that the ease of use and the built in power encourages lazy interface design (read that as no design). The nature of corporate projects and their tight budgets and schedules certainly doesn’t encourage creative interface design and reinforces the use of this easily pluggable generic tool.

So, what does this have to do with game design? Indirectly, it makes me me think about the dangers of using the same generic tools and frameworks that all your competitors use.

There’s been a ton of press and buzz going around about the recent release of the Unity Game Engine and the use of Torque from GarageGames. In one sense, this is great stuff. It helps small developers build their games with out the cost of building their own tools and engines. It can turn a two year project into a few months. It can transform a game from an outdated 3D “also-ran” to a modern high-tech market competitor, all for a few bucks. It can actually enable projects that would never even had the chance of getting started.

Have you ever compared all the games released by the same small developer? Usually, to save money and time the team will reuse their existing code base and tools. This is good, no reason to reinvent to wheel — It’s too expensive. But, it’s likely that those games have a similar feel or style to them. You get the feeling that if you cut out the graphics, sound and story, you have the same game. Again, not inherintly bad — to a point.

What happens if this occurs throughout the indie games industry? If all small developers are using the same game engine?

If a team is working on a new title and they have just dropped $1000 to $2000 on a game engine are they more likely to spend their time coming up with new ways to present information on the screen or are they going to use the already paid for super duper easy to use genericly-designed game tools?

Addmittedly, these tools save thousands of dollars in the budget that can be used elsewhere. They can spend their time developing better stories, better graphics and sound. They can spend their budget on improving other aspects of the game. But, will they?

Will we enjoy a wave of inspired game design encouraged by all the money saved using a “standardized” widget game engine? Or will we all be temped in to lazy game design because we don’t have to worry about the technical aspects of putting ideas on the screen?

Granted, I’ve yet to produce a game or even anything of consequence, but I’m just getting started. What I’ve experienced so far though is that when I’m thinking about my game designs, I don’t worry about the technical aspects. I try and think about the game play. Once, the game play has been decided upon, then I decide on how to implement it. Then while working on the implementation, more game play ideas emmerge and the cycle continues.

This back and forth leads to good things. It takes me in interesting directions that I did not anticipate. As long as I don’t get carried away or lost in feature creep, I see this as fluid design and development. If everyone does this, wouldn’t we have a greater variety of games? Wouldn’t we avoid the “common component syndrome”?

Doesn’t it make sense to make the technology fit the game, not the game fit the technology?

5 thoughts on “Common Component Syndrome

  1. Agree 100%

    I had always thought of coming up with my own engines. Your last sentence says it all.

    “Doesn’t it make sense to make the technology fit the game, not the game fit the technology?”

    I see those “all purpose” engines are, all though great for the various reasons you listed above, just missing something. Something that only an engine made for the game would have.

    I just finished playing Darkwatch from High Moon. Great game and all, but when I saw in the beginning credits that they were using RenderWare I was a little disappointed. Graphics great and all, but of course reminded me of those games that use RW. Great game over all though.

  2. Pingback: Make Mac Games » Blog Archive » The Escapist on The Games Industry

  3. Using Unity as a game engine does not lock you into any certain kind of game. (Well except it has to be some kind of 3D game :P) It just removes the tedium of writing your own game engine and provides a glue for your own game code and assets. It makes common taks easy, hard tasks possible and near-impossible tasks within reach.

    Please take a look at OTEE’s widget challenge contestants. There are 13 very different games. (Even a 2D board-game one.)
    (http://www.otee.dk/widget-challenge.html )

    The analogy to the database grid view is in my opinion unfair (even to Torque.) Game engines are complex extensible products with focus on releiving game developers from common tasks. You wouldn’t want to write your own compiler or 3D modeller, would you?

    Most software devolpers suffer from a ‘Not invented here’ syndrome once in a while. A good manager will save a lot of development time and money recognising and avoiding that syndrome.
    ( http://en.wikipedia.org/wiki/Not_Invented_Here )


    Keli
    PS. Yes, I work for OTEE.

  4. Hi Keli! Thanks for reading and leaving your thoughts. I’m glad to see someone from Unity (OTEE) chime in.

    You are absolutely right. It is unfair to compare Unity and Torque to a database grid. But, it was only to make a point.

    I have a whole bunch to say on this topic and my reply is turning out to be too long for a comment, so I’m turning it into a post that should be added to the site later today.

Comments are closed.