uDevGames 2004 Macintosh Game Development Contest

Chris Burkhardt writes "iDevGames officially announced the start of the uDevGames Game Development Contest yesterday. The contest challenges participants to create a Mac OS X game in three months time, which will then be subjected to public vote, peer vote, and a panel of judges, with the best in a variety of categories receiving prizes. iDevGames has issued a press release." Previous winners of the competition include the rather smart Argonaut 2149.

Comments

Re:Agree

[ageitgey]

The parent post is correct in that modern games are much, much harder to create than old side-scrollers from the 80s. And you are correct that despite that fact, it would be possible to find everyone with the correct skills to form a team and still produce a quality product even today.

But there is another piece to the puzzle. Most games are played through only once or twice by a player. iD software put 4 years into Doom 3 and many people went on to finish the game in a single day.

The artists at iD probably put hours and hours of work into each and every room, pipe, box, etc in Doom 3. The art/level development process probably goes something like this:

1. Design a level on paper
2. Get the rough rooms modeled
3. Start texturing the rooms
4. Start adding decorations, crates, etc.
5. Populate it with monsters, supplies, etc.
6. Revise many times.

Now, just like testing software, they would have to test each level to make sure textures line up, actions trigger, difficulty is appropriate, and so on. It works just like testing versions of software, from development, to debugging, and then release.

Unfortunately, "content-based" games are pretty much a one time experience. You can't experience a game on an emotional level if you are playing through the same level hundreds of times to see minor improvements and new features. That works for spreadsheets and word processors, not games.

In other words, the open-source development process pretty much does not work for "content-based" games. In an application, a user will send you a patch to add a feature they really needed and took the time to create. And if the program really helps them do a job, they might keep working on it to make it better. In the case of a game, a game player is going to say "this game sucks", not send you a patch to relocate decorations in a level in order to increase the moody atmosphere. Or atleast they won't keep sending patches over any period of time. They will quickly lose interest, because they have completed the game experience.

Open source/Free/etc software makes sense because it allows the very intense, but globally tiny work of a few people to benefit all indefinately. If you create a really useful spreadsheet, businesses can benefit for years to come. The benefit of the work is ((users * useful_lifespan) - work_to_create). That model just doesn't make sense for most game development because the useful life span is very short.

The only case where it does work well is in multiplayer games. In those cases, the games can be fun for months or years. And that is exactly were projects like this have succeeded wildly (Counterstrike!).