The Impossible Dream #2

Previous: The Impossible Dream #1

Ground Rules

Mantra 1: The mechanic first, then the game.

It's no fun putting blood, sweat and tears into an unfun game. We structure the game around a solid mechanic - prototype first to find addictive key element(s) and elaborate. Tag is one key element we've identified.

Mantra 2: Build a game, not an engine.

I've seen a number of home and indie game projects go south stuck at the "let's build our engine" phase. Nothing overly general - we build into the code what we need to do the trick. I'm not saying there's no place for useful abstraction here, I'm saying that a general purpose rendering or game engine is not our goal.

Mantra 3: Fit the design to resources at hand.

Building an open world game at all is our first violation of this. Still, we need to embrace this reality instead of fighting it. Operating with restricted resources can force us to come up with creative solutions to problems we otherwise wouldn't have looked at. Of course, it may also prevent us from finishing anything ever.

Mantra 4: Don't underengineer or overengineer, but if you must choose one, underengineer.

Why? Because underengineering is easier to fix.


A Unflinching View

Let's start the impossible dream by looking, somewhat realistically, at our available resources and the strengths and weaknesses of our position.

Resources

• A few development hours a month divided among game design, software development and content creation.
• A powerful target platform (PC).
• Development tools - Visual C++ 2003.
• Direct3D and its auxiliary libraries (see No need for portability in Strengths, below) .
• Third party content creation tools - Milkshape 3D (registered), Unwrap3D (registered), POV-Ray.
• Open source and free resources on the web for game development.
• Free content from other sources that can be legally used in our game.

Strengths

• Strong software development skills.
• A powerful target platform (PC).
• No need for portability.
• A great deal of freely available software for offline and runtime use.

Weaknesses

• Poor content creation ability.
• Few hours to dedicate to the project - it'll be done in like one hundred years.
• Little monetary investment.

Strategies

Make the most of our particular set of resources:

• Simplicity - a simple, compelling core game. No minigames, nothing like that.
• Prototype the game mechanic first.
• Automation - machine generated content, mostly offline, possibly at runtime.
• Reuse/scavenge (to a point) freely available content generation tools and software.
• Reuse/scavenge (to a point) freely available software for the runtime.
• Seek out free content that we can legally use in game.
• Creatively adapt the game design, including character and plot, to cater to our strengths.
• Use a hooded figure for the main character, allowing us to skirt the animation issue for the main character. We can use a simple segmented model for NPC's. We can animate the hood & clothing of the main character with cloth animation, which is CPU-intensive, but nearly content-free.
• Use public domain (classical, folk music?) music for the soundtrack.

Oh, and yes, there's so much more to come.