Stealing from Indies is Good

Some people are doing some great stuff in the indie games sphere!

However, the main stream game industry shouldn’t feel they need to experiment as much as the indie games world does.

What they should do is just steal learn from all the good ideas that come out of it that they feel would work in their titles.

Let the indies take game play risks, they’re in a better position to do so. Let the AAA polish the game play and presentation, that’s what they’re good at.

That’s my take on it.

What’s yours?

Coding Conventions: Boolean Function Parameters.

Here is a coding convention that I have recently adopted and wish I would have adopted earlier. I would recommend it to all without exception. It is:

Use enumerations instead of boolean values as parameters to functions when there is more than one parameter.

For example these are okay:

Show(bool value);
Setup(ShowState showState, Orientation orientation, CollisionState collisionState);

These are not okay:

Setup(bool showOnStart, bool orientLeft, bool enableCollision);
Serialize(string filename, bool save);

Consider reading:

Setup(true, false, true);
Serialize(“myfile.bin”, true);

Vs. something like this:

Setup(ShowState::Show, Orientation::Right, CollisionState::Enabled)
Serialize(“myfile.bin”, SerializeOperation::Save);

Another advantage is that this opens things up later if you decide to add in more than one state for a variable.

For example, let’s say we wanted to add “Forward” and “Backward” to Orientation, or a “LoadAndWriteBack” to Serialize.

So there you go. A little gem to make your code better and your life easier.

1 Comment more...

When is your game done?

I recently read a quote from Gabe Newel in Game Informer on “When it’s Done” (Game Informer, issue 187, pg. 70). He said “I think most games in the industry, across the board would benefit from an extra six months of refinement”. At first when I read this I thought “yeah, that would be nice”. And then I thought “wait a minute, that would be wasted time! adding a little polish here or there won’t make a difference in the end”. And then finally I thought “Ah, well, depending on where you spent the refinement, it could be a good thing, a very good thing”. If you spent your refinement time fixing legitimate issues, then it would help your game immensly. However, if you spent it on slightly better AI, improving those textures just a bit, adding a little more bloom or depth of field here or there, then you’ve wasted your time… if those were not “legitimate issues”.

So what are “legitimate issues”? “Issues” are what people complain about when playing your game. “Legitimate” is weather or not they are pertinent to the vision of the game. I’m assuming your game is already fun because you built it around a fun prototype and created a distinct experience for your player (if you didn’t do that, then you had better do it now). The only thing left since it’s fun at it’s core is to remove the “unfun”. Remove all the dirt and impurities to provide your player with pure gold. You don’t want anything to detract from the fun in your game. To get an idea of what these things are, go and read any review for just about any game. Read what the reviewer complained about in the game. Most of the time these complaints are legitimate, sometimes they are a matter of taste or preference. Deciding weather or not they are legitimate is up to the visionary for the game. Some common examples of legitimate issues that can taint an otherwise fun game are:

  • “Poor camera controls”
  • “Confusing Menus”
  • “Text that is difficult to read”
  • “Poor or missing tutorials”
  • “Confusing, complicated, or non standard control schemes”
  • “Muddy textures”
  • “Choppy animation”
  • “Bad save game system”
  • “Bugs in the game”

When I first sent out Caster for review by some of my friends, I got back a nice list of feedback. Most of it I had noticed before, but had considered to be minor issues. However, hearing it from my reviewers told me that it was significant enough that they would notice it and make mention of it. Things like “the font looks too aliased”, “the UI textures seem low res”, “I can’t use an inverted mouse configuration or remap keys”, etc. These became legitimate issues to me because even if I didn’t really care about them, the other people playing the game did! When I sent the game out again with these issues fixed, I got a lot less feedback. I guess it’s like being a car mechanic. You know you did a good job because you hear less noise.

At any rate there you go, Your game is done when all the legitimate issues have been resolved. Once all these are resolved, you’re good to ship! Notice, this is a very attainable goal! It is NOT adding new features, it is NOT making slight modifications to this or that. It is resolving real concerns that make a difference to the player’s experience.

Comments Off on When is your game done? more...

Super Fast Anti-aliasing… FOR FREE!… well almost.

Nowadays everyone is looking to get that last bit of polish in the visual presentation of their game. One big thing of late is anti-aliasing the image to remove the “jaggies” that the polygones produce when rasterized to the screen:

For example consider this text:


See how much smoother the anti-aliased one looks!

This is typically an expensive process that is usually accomplished by rendering the image at twice (or more) its size and then shrinking it down and averaging the pixels together when the image is dumped to the screen. Since the fast “render to” memory is limited on many graphics cards, the image is often divided up into strips and each strip is rendered separately into the fast memory and then copied out to the more abundant not-so-fast memory. After each strip or “tile” has been rendered, they are combined together on the screen. This method is called “tiling” and is a common method for handling anti-aliasing.

Since it is expensive, it makes sense to try and do something cheaper to achieve the same anti-aliased look. This lead us at Hidden Path to investigate some other ideas and what we came up with is pretty slick.

The idea is basically the same as the old accumulation buffer method that was used for creating depth of field and anti-aliased images on older graphics hardware. You take a shot of your scene, shift it by less than a pixel, and take another shot. You do this as many times as you like to get more samples per pixel. The results are weighted and added together in the accumulation buffer which is then dumped to the screen. However, by itself this really doesn’t buy us much because we will still have to render the whole scene several times. Our answer is to spread the creation of the accumulation buffer over multiple frames. We only render one accumulation pass each frame and then combine that pass with prior passes when we display the results on the screen. We’re currently only using two passes and we have gotten some really nice results.

To clarify the above, this is our process:

  1. SETUP: Draw the scene into textures A and B.
  2. START:
  3. Shift the camera projection matrix slightly (less than a pixel) in the positive diagonal direction.
  4. Draw the scene into texture A.
  5. Present textures A and B blended together at 50% each on the screen.
  6. Shift the camera projection matrix slightly in the negative diagonal direction.
  7. Draw the scene into texture B.
  8. Present textures A and B blended together at 50% each on the screen.

Here are some results from using it on my game Caster:

(Click on the images to see them at their full size)

And here is a section magnified (click to enlarge).

So now you might be saying “Ah, but texture B is lagging behind texture A. It will look blurry, you’ll see a double image”. And yes, that is correct. However, when the scene is still with no motion, we have perfect anti-aliasing. When there is very rapid motion or a low frame rate, you can detect blurring. However, this can also be looked at as a little motion blur of 1 frame for free (… okay, you’re probably not buying that last one)! Since Caster generally runs at a high frame rate (60 fps), this blurring is very small and makes sense when it is noticed like in the image below where the character is running around.

Now I haven’t tried it yet with 4 frames, but then you end up having 4 extra color buffers for your scene which can start getting just as expensive as tiling. Also, 1 frame of blur isn’t really much of an issue, but 4 frames might be a bit too much depending on what’s going on in the scene.

Weather or not this method is “free” depends on your setup. Some extra texture memory is required (or not if you don’t mind flicker or have a persistence of pixels on your screen… like old CRTs or televisions), to hold an extra color buffer of your scene. Either way, even if it’s not for free, it comes at a very low cost. Oh yeah, and no need for shaders for this so you can do this in fixed function too! So that means you can do this for… just about any 3D hardware out there right now!

This same technique of “temporal accumulation” can be applied to other things as well. For example, I’ve been using it in Caster for over 3 years now to blur my glow effect. Each frame I slightly change the position of where I render the glow effect on the screen and it is accumulated / blended in with all my prior renderings of the glow. I end up moving the glow texture in small circles to blur it out. The motion causes a shimmer of the glow and accumulating across all frames leaves motion trails. However, for my purposes this ends up being a feature that really like and want to keep.

So there you have it. Lesson learned: If something is very expensive to do in a frame and you can’t break it up into a separate threads, try thinking of ways to break it up across frames.


It only took about 30 minutes to add it to my game… like a quarter of the time it took me to write this article *sigh*.
Comments Off on Super Fast Anti-aliasing… FOR FREE!… well almost. more...

IndieCade and Innovation in Games (again)

So I just got back from IndieCade. It was interesting. I was able to meet some of the creators of a few games that I had played which was neat. It was also fun to play the you-know-a-guy-I’m-friends-with game with people on the floor.

It had a pretty sparse attendance today (and maybe in general) so I do not know that it will be happening in Bellevue again. It’s a little sad since it was only 4 blocks from where I work.

Today there was a panel on “why we need innovation in games”. I really didn’t like the title because it implied and misdirection from what I think is important (see my prior post on what games need).

So I sat and listened for a while until I had an opportunity to very loudly and outspokenly present my argument toward what the attitude about innovation in games should be.

I could tell I had supporters in the group, so that was good. I’m worried that I may have offended the people running the panel, but, well, it’s their fault for having a faulty panel topic…. and frankly, any being offended is your own decision.

To help back me up on this, here’s a rant from Jonathan Blow on the topic.

To sum it up:

Stop worrying about innovation! Focus on a vision for the game! Innovation should just be a word we use to describe the byproduct of new things that happened to be developed while moving towards that vision. The value is not in the innovation, it’s in the effective execution of the vision of the game.

So why is it valuable to make this distinction? Well, focusing on “innovating” ends up missing the point of a game. It produces games with new mechanics that do not produce effective experiences. Trying to adapt an experience to an innovation means that the innovation is in charge, it becomes the ruling factor in the game. It makes for shoddy and mediocre games with little or no depth. It’s like the artist that paints a picture because it hasn’t been done like that before rather than painting one that evokes an emotion or sends a message. In a single word, SHALLOW!

Yeah, so that’s fine. While people go ahead making games that focus on innovation, I’ll go forward trying to make games with a vision for an end user experience. We’ll see which ones are more significant in the end… And in fact, end up containing more… “innovation”.

Comments Off on IndieCade and Innovation in Games (again) more...

Copyright © 1996-2010 Elecorn ® : The Animated Coder. All rights reserved.
Jarrah theme by Templates Next | Powered by WordPress