Learning from other game devs 7: Developing game ideas

GAME PROTOTYPING: TIMESINK PITFALL?
Before any developer starts investing a ton of time into making a game, they ask themselves two basic questions:

• What kind of game do I want to make?
• How can I make it fun?

Both of these questions aren't particularly easy to answer, as they generally require creative ideas and some ability to evaluate "goodness". I've been reading online articles and listening to podcasts over the past year or so, and I've found that the process of developing a game idea appears to be the following:

Step 1: "Oooo... hey FRIEND_DEVELOPER it would be cool to have a game that lets the player do AMAZINGTHING. If could be inspired by and be similar to GAME A and GAME B. "
Step 2: "Let's prototype the basic mechanics of the game in a day or two and see if it's fun"
Step 3: "This wasn't fun... let's add the prototype to our collection of prototypes on the dusty shelf and come back to it later"

Looking at the end result, it seems commonplace that game developers make tons of prototypes that never make it past a week of development. I think there are a few pitfalls with this approach, that I would summarize as "The risk of throwing game ideas at the wall to see what sticks". There seems to be a huge temptation to generate lots of little ideas and immediately try to prototype them, without much thought or discussion on whether the ideas truly have merit and are worth the time. In other words, there is a large risk of "spinning" in a state of creating prototypes, wasting valuable time. A developer should try hard to ensure that any idea is a good one, before going to make a prototype.

PRIORITIZE THE BEST GAME IDEA
It seems clear to me that a developer should spend a great deal of time developing the ideas, before any coding takes place. The end goal? I feel a developer should try to prioritize the best idea they can come up with.

As a small example, a few years back I had several ideas for projects I wanted to work on at my place of employment. I was quite young, and I was trying to choose my first independent project. The projects looked like the following:

1. A small extension to existing project I was currently doing, with minimal risk. Offered a 10% improvement to the larger project my group was working on.
2. An idea related to work I was currently doing, with minimal risk. Offered a 10% improvement to the larger project my group was working on.
3. A brand new and exciting idea that had a ton of potential but completely unrelated to my current work, with significant risk. Offered potentially a 200% improvement to the larger project my group was working on.

The new idea with significant risk (#3) scared me. It would take longer to develop, and only after a significant period of time would I know if it was successful. I told my boss it seemed that I should choose one of the projects with lower risk. What he asked me changed my perspective completely:
"Why don't you want to work the exciting idea?". It seemed clear to my boss that the other ideas weren't interesting, when directly compared to #3. I ended up choosing #3, and mitigated risk by continuously evaluating whether I could reach that goal of 200%. In the end, the project worked out, and I was able to get roughly a 80% improvement. Below the 200% percent I had hoped for, but well above the 10% of the other ideas.

This situation was a life lesson that taught me: Prioritize the best idea you can come up with, and rigorously re-evaluate to mitigate risk. It takes a lot of time and effort to come up a great idea. Not an hour, not a day, but weeks and months. A good idea should make you scared to reveal it to anyone. Why? Because you're paranoid someone might steal it.

PROTOTYPING A BIG GAME IDEA
So that's the challenge: Can I (as a developer) come up with an amazing idea? Looking at some of the games that I find amazing, the vision for the games is so grand that it is difficult to prototype in a few weeks, let alone a few days. For example: How can you prototype any Zelda game? What makes and RPG fun is the immersion, the dungeons, the imaginative landscapes and characters. Prototyping mechanics is not going to let a developer know if the game is fun or not. For example, the original Final Fantasy has great game mechanics for a turn-based RPG (Feel free to debate). But, despite all the rage for 8-bit looking indie games, many players today would not find it fun as it is missing crucial elements (story, characters, immersion, etc from above).

So how can one prototype a big game idea? Start with developing all the high level ideas. Some examples:

• What is the game world like? (i.e. Is it a realistic setting, or a setting with supernatural elements?)
• Who are the main characters? What are they like?
• What is the rough outline of the story?
• What emotions should the player feel (fear, happiness, sadness, etc)
• What actions in the game should cause these emotions?
• What is the purpose of NPCs and other computer characters?
• What are the innovative and cool ideas that make this game different?

I would imagine that if you can write a sentence or two for each of these topics, you're off to a good start. Of course, other concerns like graphics style, control are also important. Once you've got a baseline set of ideas, then the next two big questions to answer are: Can I support all these ideas and features from a technological point of view? How long to I expect it to take to make the game? In other words, when the game is complete, will it run at 60FPS on most people's games? Will it take me 10 years working by myself to make the game the way I want?

When all these questions are answered and written down, a developer can manipulate and plan accordingly to mitigate risk. Or of course, if game seems to not be feasible, for time or resources or otherwise, the game can be pared down or (heaven forbid) scrapped. The most important part is that coding effort is not wasted if there is no initial perceived benefit.


Well, these are my thoughts on developing game ideas. Comments are always appreciated!

Game Dev 7: Getting new objects (Houses, Trees) quickly into the game, and a Skybox!

Leveraging the infrastructure I've already created, I decided to see how easy it would be to add new objects into the game world using my engine. Each object consists of models, animations, and bounding boxes for collision. I roughed out what was needed for a house and trees in less than an hour. I added in an animation to make the trees "wiggle" every now and again. To say that I'm happy with the ease I could add such objects in would be an understatement. I can tell that the modularity I've baked into the engine will pay off in terms of reduced programming time down the line. Additionally, all that modularity allows me optimize code and improve performance later, such as in the ability to plug and play different graphics rendering modes to display the object.

I also decided it was time to get rid of the black background and build a simple skybox. A skybox is simply a cube, with the top half representing sky and the bottom half representing sea. The skybox's purpose, of course, is to mimic the sky and the horizon. The game world (really only the player to some radius) exists within the sky box. Of course, the skybox isn't restricted to being a box and can be a semi-sphere or another shape entirely. Choosing a cube however is cheap and effective.

Already, a game is starting to take shape from the 3d engine I'm working on. I'm not sure how I like my lack of lighting and texturing for all these models, but that's something to decide later.

Game Dev 6: Collision detection and basic physics (+ Player Controller character!)

I've completed another large update. I've used the voxel terrain and character modeling and AI I've developed previously and developed collision detection and basic physics. Another big change is that there is now a player-controlled character! The player's character is viewed in 3rd person.

For collision detection, basic AABB is used for now, with the thought that this can be improved later. The NPCs jump when they collide with the voxel terrain (using the AI system), and Physics is implemented such that each unit has velocities and accelerations in xyz directions. Rather than having the inputs (e.g. Keyboard) directly affect position, "forces" are set by modifying these velocities and accelerations. Similarly gravity is modeled using an acceleration.

Note that in the video below, I used a 2010 laptop with integrated graphics. Thus the game engine runs slow (31 FPS).