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).

Game Dev 5: Character Animation and AI System

After a bit of a break, I've made substantial progress on building the game engine I'm developing. I've developed a geometry modeling scheme for units within the game, complete with hooks into an animation system. Currently each unit can have animations specified, and those animations can be called at any time. I've also developed a utility-based AI system, which enables external stimuli to trigger certain behaviors from a unit.

The end goal is use these high-level modules to make a game. To test, I've used to create 1024 template characters that use basic AI to move around the screen. The animation system is shown via the movement of arms and legs on the models. While the characters are simply boxes for now, the power of the engine is starting to come to light. Note that I've thrown in a FPS meter below... 31 FPS is not bad at all! Further optimization can come later.

Learning from other game devs 6: Alpha purchasers being ignored

Treat the alpha purchasers of your game well. It should be obvious, but sometimes it may be hard to remember some good business practices and prioritize. We are all human, after all. Lately, I've been reading stories and comments all over the web that contain complaints from players about the lack of developer progress on purchased alpha and pre-alpha indie games. This is incredibly alarming for a number of reasons, but the main concern is that such bad business practices that may be in play here could actually can hurt the indie community in general. I've listed two issues below that I've been thinking about and want to ensure I don't make the same mistakes.

1. The developer is not staying in contact (or "disappears") with purchasers of the game.

I've read a number of places about developers going AWOL and leaving players of the game completely in the dark. The players simply don't know what has happened to the game or if it has been canceled. I've read that the developer of  somewhat known indie game seemingly disappeared with no contact for a few months. Players were genuinely concerned that the developer had ran off with their money. They were furious, and I would be too.
My take: Even if you aren't actively developing (art, music, code) the game, you owe it to the purchasers to let them know that you're moving, dealing with legal issues, dealing with personal issues, whatever. You should also let them know when you expect to be back at it. Another suggestion is to not "update the game in bulk", but instead offer smaller but more frequent feature updates and bugfixes. The purpose of these smaller updates is to keep contact with players.

2. Not giving purchasers a "playable" game.

From the game buyer's perspective, the idea in buying an alpha is to buy a playable game with more features to come; not give the developer money for a game that doesn't work. I've read that some developers sell a game in alpha, only to work for months on tuning graphics while the rest of the game is unplayable. Imagine paying $20 for a game that crashes upon start, but the developer won't fix the bug because they are too busy working on character models for the game. I would be furious.
My take: You need to get a playable game in the hands of alpha purchasers. These players will likely form the "core" group that not only gives you bug reports and feature feedback, but they will likely drive your later sales. In the simplest terms,  a developer should never sell a game until it is reasonably playable in some form.  


To conclude, I believe both of these situations are hurting the developer in addition to the purchaser. Without positive feedback and a positive following, you can't expect your game to succeed. If you don't treat the people that buy your alpha well, things likely won't go well for you. On the other hand, not treating the customer well hurts the entire indie game development scene, as fewer people will risk paying for an alpha. Once they feel they've been "fooled" or "taken advantage of", they are increasingly less likely to buy another alpha. To finish on a positive note, connect with your target audience and alpha purchasers every chance you have. Prioritize them... and give them a (playable) game that you're proud of!

Reflecting on Existing Games 1: Fetching Rocks

Something has been bothering me lately. I've been playing a lot of games lately, and since I've working on my own I've been paying more attention to game design. What has been bothering me can be summed up in the phrase "fetch that rock". In other words, someone standing next to you either notices or throws a rock, and then asks you to get it. Getting the rock is initially slightly satisfying, as you feel somewhat useful. However, when you are asked again "fetch that rock", how likely are you to go get the rock? Certainly, you would be less likely and willing to go get it.

In many role-playing games I've been playing, it seems that many side quests (and even mainline quests) are essentially "fetch the rock" adventures. You are asked to go get an item, go kill a monster, or go do blah and then return to the quest giver to claim your prize. Not only is this a boring exercise, but there are no repercussions to completing the adventure other than being awarded a junk prize. If I was asked in real life to kill a monster that was destroying a village, I would expect a parade in my honor, the keys to the city, and enough gold for me to retire. I would probably feel good that helped out and saved these people as well. Of course, I would expect it to be hard as nails to kill such a monster, and there would be a lot of risk involved.

In other words, there needs to be a legitimate reason for doing anything in the game, and I should be given the option to make a choice on the matter. I need not be persuaded to help a city in trouble, if I know the city will otherwise be wiped off the map. There truly needs to be implications for everything (or nearly everything) I do in the game. As a player, I need to care, I need to feel the weight of calculated risk, and I want to be the hero. If I want to be a coward and not help a city in trouble, when that city is destroyed, I want to be shamed publicly. Let me make that choice! What I don't want is another "rock" to fetch, so that I can claim a junk prize.

Game Dev 4: Basic Lighting and Water Stand-in

I am still pushing forward on terrain generation. It's pretty interesting, so why not?

Until now, I didn't have any lighting in the engine I'm building. In fact, I had a hack to color each side of the cube a slightly different shade of color to give the perception of depth. Obviously, this is not a great stand-in so I added normals to the cube and got basic dynamic lighting working in OpenGL.

You can see the current result in the picture. It still needs to be tweaked a ton, and looks rather ugly. Specifically, It looks really dark and The difference in color between the sides is entirely too much. Another issue is the (up to) 30% hit in FPS that I'm seeing, dependent on the complexity of the scene. I'm not sure if I'll stick with dynamic lighting; I may add in static lighting instead at some point. However, at least I've got a baseline lighting model working!

You may also see blue in the picture... yes that I supposed to be water. I simply added blue cubes about half the way up each chunk along the y-dimension. Instead of having crazy slopes I thought I would have some crazy islands instead. The goal is to play around with alpha channels to vary the opacity in order to make it see through.