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. Pingback: Make Mac Games » Blog Archive » The Escapist on The Games Industry

Comments are closed.