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?

Subversion Revisited

A while back I wrote about moving to Subversion for revision control. To this point it has worked well for the little I have needed it. But as I begin ramping up my development efforts I find that I spend more time on my PowerBook than I previously have. This has introduced a new wrinkle into my development process.

I initially only setup the Subversion client tools which support local code repositories, but do not provide any mechanism for remote or networked repositories. So, I set off to remedy this problem.

After some effort tracking down the right order to do things, here are the steps that I took:

  1. Remove any existing installations of subversion client and server (svnserve)
  2. Download and install the subversion Mac OS X binaries from Martin Ott [SubEthaEdit]
  3. Add the subverion binaries to your unix command line path. I did this by adding the following to my .profile file in my home directory.

    export PATH=$PATH:/usr/local/bin
  4. Open the ports TCP:3690 UDP:3690 through the firewall properties. You’ll probably need to add a new service.
  5. Run the svnserve daemon
    svnserve -d --root=/Volumes/CodeVault/Subversion/
  6. Create a new Repository

    svnadmin create --fs-type fsfs //Volumes/CodeVault/Subversion/[repository name]
  7. Configure repository for remote access by following the steps outlined in the Built-in authentication and authorization section of the Subversion Docs.
  8. Import project into new repository

    svn import ./[project name] svn://localhost/[repostiory name] --message 'Initial repository layout'
  9. Verify repository locally

    svn list svn://localhost/[repository name]
  10. Verify access from remote machine

    svn list svn://[machine name]/[repository name]

Game Project Plan Update: Describe Game Idea

I’ve marked off “1. Describe the basic game idea” in the “Write a Design Document” section of my project plan. I’m now working hard on the next three sections:

2. Define the game play (players, enemies, goals, etc)
3. Define game engine requirements (view, player movements, controls, save & load, etc)
4. Sketch graphics ideas (players, enemies, world levels, scenery, etc)

More to come on this soon.

Fruitful Weekend

I entered this past weekend with the goal to spend a significant amount of time on my game project, working on the game design and prototyping a simple game engine. With a ton of coffee, some loud music, and plenty of time, I was able to get a rough first draft of my game design completed.

The design still needs more work, primarily fleshing out the details of game play. But, I did complete most of the general game look and feel — enough that someone could read the design document and get a real good idea of what the game will be like.

I plan on working on the design over this week and then posting at least part of it on this site. Hopefully, it will garner some feedback and suggestions on improvements.

The interesting decision I have to make now is how much of the design to post and in what format. I don’t think I need to worry about people stealing ideas, but the notion does nag at me. Maybe, I’m too paranoid. After all, the idea and the design are only a small part of the picture. Programming and completing the game is the hard part.

Thoughts? Suggestions? Comments?

Game Project Plan Update: Language and Framework Selection

After completing the book “Game Programming All In One” as a tutorial on game development — review coming soon. I’ve been evaluating my options for moving forward. As simple as the Allegro Framework made learning the basics of game programming, I was not entirely happy with the performance that it gave me on the Mac and not entirely pleased with the overall feeling that it was primarily targetting Windows and the other platorms were later added.

I have no idea if the developers conciously did this, but the idea of using graphics content in the Windows bmp format for my game content doesn’t sit well. Especially, since Objective-C and Cocoa have plenty of image manipulation functionality of their own using newer and more Mac friendly formats. The drawing routines seem to be rather slow, I’m not sure what the framework uses under the hood, but I believe that I can get better performance directly using CoreGraphics and definitely using OpenGL.

I did find that there are several plugins to the framework that would add the functionality and possibly the performance I’m looking for. For example there is a plugin to allow for the use of JPEG images and also a complete OpenGL framework plugin. The problem with these is that they are not part of the main Allegro framework and would require two more individual builds and would represent at least two more libraries that I have to constantly monitor for updates and patches.

Given my desire to target the Mac and the benefits of using XCode and Objective-C when it comes to a smooth transition to MacTel or x86Mac or whatever it will be called, I believe my choice has been made.

Also, I have created a page dedicated specifically to my Project Plan which should make it much easier for me to update and for anyone interested to follow along.

So, now that this step can be marked complete, I venture forth in to the wilds of the “Write a Design Document” step.

Game Plan Update

This weekend I worked on Section 1 of my Game Plan. While seemingly not a huge step in the process, it is step one. I certainly can’t reach the last step without taking the first one.

Taking a look back, this is what my game plan had for the first step:

  1. Setup Development Workstation and Environment

    1. Select and install a Version Control System
    2. Select and install a reliable backup system
    3. Select and install development tools (compiler, editor, tools)

I was able to complete the first two sub-tasks and make a great start on completing the last. For the version control system I selected Subversion. I have used cvs for quite some time and nearly continued in the same direction, but given the current strong trend of migration from cvs to Subversion and that Apple’s XCode now has built in support (though somewhat buggy), it was time to adopt the newer tool. I installed Subversion using fink and created some sample projects to test it out and it seems to work wonderfully.

The second task, setting up a backup system was taken care of with two purchases: Two external 250GB Hard disks and Dantz Retrospect. I setup the external drives as a Mirrored RAID in Apple’s Disk Utility and setup Retrospect to do nightly backups of all my files to the external RAID. So this gives me two internal hard disks in my PowerMac G5, one is the system drive where I have OS X and all applications installed, the second is my Users or Home volume. This is were I check my code out to and actually do my development as well as all my other day to day work. I also have a single external drive where my existing cvs repositories and my new subversion repository live. And now my external RAID which stores my backup images. This gives me several layers of redundancy and makes me feel a bit more secure going forward and has been accomplised within a reasonable budget.

Finally, the third task of selecting the development tools. The obvious choice was to go with XCode and this is exactly what I’m going to use. It’s free, supports multiple languages, and seems to be under pretty aggressive ongoing development and improvement over at Apple. The reason I can’t mark this item complete yet is because I have not decided upon a programming language or framework. As I mentioned in my previous entry, Allegro Game Framework, I’m still exploring my options. What are the advantages of using a cross platform game framework written in C vs. using Objective-C? Hopefully, I can work this out in the next few weeks and feel comfortable with the direction I take.

Game Plan

Before starting, I need a game plan. Every software project should have one, so I’m going to fight the urge to jump in and start coding and actually put a rough project plan together. I’m not concerned about a business plan at this point, but a high level plan of action for leading me through the long and complex task of developing my first video game in nearly fifteen years.

Since I’m going to spend much of my time learning game design and the various technologies needed along the way, I’ll need to leave enough wiggle room to adjust and change this plan as I go. Given this need, I won’t include any dates in my plan but simply list the high level tasks I’ll need to complete. Additionally, I suspect that these items will not necessarily be sequential. I may be able to work on several in parallel and some of them will need to be revisited many times during the duration of the project.

  1. Setup Development Workstation and Environment

    1. Select and install a Version Control System
    2. Select and install a reliable backup system
    3. Select and install development tools (compiler, editor, tools)
  2. Write a Design Document

    1. Describe the basic game idea
    2. Define the game play (players, enemies, goals, etc)
    3. Define game engine requirements (view, player movements, controls, save & load, etc)
    4. Sketch graphics ideas (players, enemies, world levels, scenery, etc)
    5. Define sound requirements
    6. Licensing mechanism, demo vs licensed version
  3. Simple Game Engine Prototype

    1. Get a very simple version of the game working with developer graphics & sound
    2. Test that game engine idea will support game requirements
  4. Develop actual Game Engine

    1. Refine / Refactor Prototype Engine?
    2. Implement all required game functionality
    3. Implement all extra screens (load/save, help, options, demo screen, intro screen)
    4. Test, Test, Test
  5. Acquire professional graphics and artwork
  6. Acquire professional sound effects and music
  7. Installation Package
  8. Play Testing and Beta Testing
  9. Final Touches
  10. Release

Over time I’ll revisit this project plan to fill it in, refine it and hopefully improve my process along the way.