Inspirational Game Development Blogs for Entrepreneurs

Before I made the leap to start my own game development company I was thoroughly inspired by the writings of other developers who shared their lives on-line. Here are some of my favorite blogs that I still follow. Tread carefully, because reading too many of these will make you quit your well-paying job too!

Cliff Harris

Cliff is founder of Positech Games, a one-man operation that has done very well over the years. Cliff’s blog is very insightful for anyone trying to strike out on their own. He shares details of his finances, his work process, and the idiosyncrasies of running a game development business from your own home.

Jonathan Blow

Jonathan is most famous for his smash-hit game Braid. He’s a very inspiring and smart man, who really lives and breathes the indie gaming spirit. He believes games are a medium for exploring important life issues, just as books and films are. He also gives tons of interesting talks, and his blogs often delve into the technical details of his games. He’s working on another game now called the Witness, and the blog can be found here.

Jeff Vogel

Jeff is the founder of Spiderweb Software, which is essentially a  one-man operation that has been making hard core, niche, RPG games (such as Avernum) for a very long time. His blog posts are often revealing, and always funny. Check it out here.


Deejay is owner of Binary Tweed. He’s been involved with different gaming initiatives, such as IndieCity, he has run Indie Marketing Workshops, and is overall a very nice guy. His latest posts on Indie Advice give tons useful information on marketing, funding, social networking, branding etc.. etc..

Steve Pavlina

Steve started his own game development company many years ago. After struggling for a few years, he had some hit games and made lots of money. Along the way, he’s offered tons of advice to other developers, not just about making games, but about being more productive, networking, marketing, and just generally becoming a better person. He enjoyed giving advice so much, that he quit game development and became a self-improvement guru instead! His blog gets millions of visitors per day, and he’s a runaway success. I found his early postings very useful and inspirational, but lately he’s been getting a little crazy. However his archive is a goldmine for aspiring entrepreneurs.

A Simple Solution to Game Serialization Nightmares

If you’re a game programmer, you’ve almost certainly written code to save the state of a game to disk. Basically, your code has to convert every important aspect of a game entity in a format that makes it easy to load the entity again. This is called Serialization. I’ve written many games, and this problem always seems trivial to start when the entity being serialized is not too complex as shown in this code snippet:

// assume the file stream is already open etc..
void Entity::SaveToFile()
  Filer.Write(this->ID); // save the entity ID
  Filer.Write(this->Position); // save the position of the entity

void Entity::ReadFromFile()
  ID = Filer.ReadInteger();       // read the entity ID
  Position = Filer.ReadVector3(); //read the position of the entity

No problem right? This is easy enough but this method breaks down if your game entities are constantly evolving as you get further in development… which is almost always the case in a complex game. If you add another property to your Game Entity that must be saved, you have to create a new save format and you break any levels that have been previously saved. The easy solution is to add version numbers to your save/load routines, but this means after a couple of iterations your code looks something like this:

// assume the file stream is already open etc..
void Entity::SaveToFile()
   int version = 3;
   Filer.Write(version); // save version number
   Filer.Write(this->ID); // save the entity ID
   Filer.Write(this->Position); // save the position of the entity
   Filer.Write(this->Name ); // save the name of the entity
void Entity::ReadFromFile()
   version = Filer.ReadInteger();
   ID = Filer.ReadInteger();
   Position = Filer.ReadVector3();
   if ( version ==3 )
     Name = Filer.ReadString();
   else if ( version == 2 )
      ReadInt(); // read an old deprecated property
      Name = "DefaultName";
   else if ( version ==1 )
      Name = "DefaultName";

Not pretty, and this is a simple example. A typical game will have dozens of different entity types or components, and you have to maintain new version numbers every time you add anything to your file format. This is a nightmare if you have to maintain backwards compatibility with your old levels.

Thankfully, smart people have solved this problem before, and thankfully I read a book written by one of these smart people. The solution is to use key-value pairs instead of just writing the values themselves to disk. So instead of just writing numbers to disk, you would write something like the following file to disk:

Name="My Entity Name"
Position= 18.2,3.4,1.6

Then when loading the data, you read the ‘keys’ (eg. ID,Name, Position), and determine if you have a use for them in your current format. For example, if we got rid of the “Position” property, we would just simply ignore it the next time we read and old level from disk. You can easily encapsulate all these concepts into a separate Property class, that holds the name, type, and address information of each property. So when you’re all done your code looks like:

      PropertyTable.Add("Object ID",&ID);
      PropertyTable.Add("Name", &Name );
      PropertyTable.Add("Position", &Position );



This code is easier to read, and more importantly MUCH easier to maintain. You can add/remove properties at will, and you don’t have to maintain version numbers. As long as each property’s key is unique, you will be fine. Another nice side effect of this system, is you can use the key/value pairs as data for your in-game tweaking system. In our games, clicking on a game entity automatically brings up it’s properties and allows the level designer to change them at runtime.

Our level editor. The properties on the right are edit and saving-friendly.


Yes saving everything as key/value pairs is slower and more memory intensive. But usually the difference is not noticeable during development, and is worth the amount of time you’ll save not dealing with save-game version issues. When your game is ready to ship, you simply ignore the keys and save the values in binary format as you always have, with no performance hit to speak of.
Happy Coding!

Why Procedural Worlds have More Drama

I’ve always wanted to create a Role Playing Game. Mostly for financial, practical, and sanity reasons it is not going to happen any time soon. You see to make a vibrant, rich, fictional video-game world takes an insane amount of content creation (art, audio,scripts) and that sounds very expensive.  This doesn’t prevent me from fantasizing about the type of RPG I would make, and so I do.

Procedural Goodness

My ideal RPG world would be entirely procedurally created. The story, the characters, and the landscape would all be created by a computer algorithm instead of by a game designer. I don’t know exactly why I think this is a good idea, but I think one of the main reasons is the unpredictability of the world, and the drama that this causes.

oblivionIn normal RPGs, you enter a dungeon, or a boss fight, or an enchanted forest,  and you know you’re going to beat it eventually and receive a reward. Even if you’re not powerful enough now, you know if you level-up enough and you have enough patience you’re going to beat that part of the game one way or another. There is no drama because the end is a foregone conclusion, you will be victorious.

In a Procedural World, there may be a forest, that is so full of tough enemies, that it is literally impossible to beat. The key is that you don’t know if it’s beatable. That’s what makes it interesting. You’re fighting and it’s hard, and in the back of your mind, you might think this is literally impossible. That’s what makes it dramatic when you actually achieve your goal. You could be the first person ever, including the game’s developers, who have ever done what you have done.

Procedural Worlds will have Asymmetrical Rewards

Maybe if you fight through that dungeon w/ 1000 monsters in it there is no treasure at the end. Why did you go in there in the first place? In the real world, danger doesn’t equal treasure. I don’t jump into a river full of Piranhas expecting an extra large pot of gold do be buried at the bottom. This adds more drama of the situation. You don’t know what’s going to happen at the end.

Creating a procedural world that actually works, and is interesting is a mind-boggling, huge, programming task which is why it hasn’t happened yet. But it will happen. It’s already happening on a smaller scale with Indie games like Dwarf Fortress, Minecraft, and Spelunky. As computers become more and more powerful, these types of procedural games will become more common, which is a Good Thing.


Are Single Player Games Going Extinct?

I’ve been a gamer for most of my life. I live, breathe, and even work, games. There’s nothing I like more than coming home from work, firing up my console, and playing a great game to relax. Years ago, one game could last me about a week. Now, one game lasts me two days, tops. Why is this happening?

A lot of studios are starting to turn away from the concept of a single player game and opening up to the possibilities that the Internet provides: online multiplayer and social or mobile games. Sure, it’s the wave of the future, but why do single player games deserve to die because of it? I, personally, don’t think they will completely disappear, but I am worried that less and less attention will be given to the production of them. Already less time is being spent on single player games and more time is being spent on creating content and communities for the multiplayer aspect. With this trend we’re also seeing a reduction in quality and length; single player games rarely top 7 hours nowadays, some of them are buggy, and others aren’t living up to their potential.

I’ve been quiet about my discontent for some time, until I played Warhammer 40K: Space Marines, that is. The game was incredible, but only about 8 hours, tops. This is nothing compared to the RTS versions of the game, (which has also gotten shorter thanks to Dawn of War II). That being said, the game could have been so much longer! Instead, it’s getting a sequel—which is another terrible trend. If you have enough content for two games, why not just make one incredible game and make your fans happy?

When we were first shown teasers a few years back, Warhammer fans around the world were promised a revolutionary game with breathtaking environments, awesome characters, and the ability to shoot or cut up orks at close range. It was going to be completely different than the RTS, and insanely better than the action games that came before it. In a lot of ways, it did live up to it’s promises, but by offering an online mode, did Relic/Games Workshop/THQ truly give us something different? I don’t think so; online multiplayer has always been a feature of the RTS games, and I guess they couldn’t just stick to an offline game. I guess they were afraid that their countless fans would somehow be disappointed without this option. It’s not Black Ops; I didn’t expect it, nor want it.

I think what’s most damaging about this trend is that a lot of players aren’t even touching the single player campaigns if there’s a multiplayer option. I know a lot of people that haven’t even glanced at the single player campaign in Black Ops, for instance. And this is a terrible shame; a lot of work goes into making the story and narrative great and entertaining, and the levels fun and challenging! At the same time, a lot of players are avoiding games because they have multiplayer. Personally, I stopped playing Assassin’s Creed after 2, and I loved those games so very much. But I hardly wanted to continue playing the franchise after so much attention was put into its oh-so-amazing multiplayer mode.

There was a time when the core of a game was its story, but now it seems the core of any game is: how can we make this multiplayer? The bottom line is that single player and multiplayer games are two different games. I think that if a studio wants to create both, they should create them as two separate products, as they’re intended. I also think studios need to realize that not everyone can, or wants to, play online. Not everyone has incredible internet connections, or the courage to face the raucous community, or the patience to respawn endless times when you first get started. There is still a huge audience for single player games, and I sincerely hope studios in the future will realize there’s a potential there to make their games great again—and to justify the $70 price tags. I also hope that  Hitman: Absolution never gets multiplayer, else I will lose all faith in humanity.


A Simple Custom Animated Crowd System

All 4 of our previous games so far have featured some sort of crowd cheering on the athletes or fighters or office workers during gameplay. As a result, I’ve had the task of programming 4 different crowd cheering systems, making adjustments and improvements with each new game. Our last-released game, NLL 11, had the most refined fan system and I’ll describe it here so you can get some ideas in creating your own screaming fans.

The Problem

Suppose you want 10,000 animated fans in your stadium. If you attempt to use normal vertex-skinned models, you’ll quickly become limited by both the CPU and the GPU. The CPU will have problems updating 10,000 different animations (updating the transform of each bone in each model), and the GPU will have problems rendering and blending the bone weights of all those vertices.

The Solution – Billboard Fans

In a nutshell, this solution requires animating and rendering a full-sized model, but instead of rendering it to the screen, you render it to a texture. You then place that texture on a very simple piece of geometry, in our case a quad, and render the quad so that it always faces the camera. Finally you render the same quad again for all 10,000 fans that you want to draw. I used this approach for our Lacrosse game as well as our Beach Volleyball game (which used XBox 360 Avatars as the models). Below I’ve rendered part of our stadium with and without the billboards showing.


This approach has some huge advantages:

  1. Each fan only requires 4 vertices to be processed by the GPU.
  2. The CPU only has to animate one model.
  3. The animation can be as smooth as you want it to be since you are no longer limited by the number of models to animate.
  4. You can put all of the fans into 1 giant model, so you only have 1 draw call to render all of your animated fans.


All of our problems are solved! Not quite, there a few issues that need working out.

Camera Angles

When you render your fan model  it’s from a certain point of view, however the fans in the stadium are all facing different directions and should be rendered from differing camera angles. For example a fan on the baseline of a stadium (behind the net) should not be rendered from the same angle as a fan looking at the action from the sideline. In practice, I found that separating your fans into broad sections such as sideline, baseline, corner etc… and rendering the model from those 3 or 4 angles that you choose worked well enough. This causes some noticeable artifacts along the borders of the sections:


But depending on your game, it’s not too noticeable.

Animation Variety

It looks really goofy when all the fans are all clapping or cheering  at the exact same time. The solution for this is to render more models with different animations to get some variety. However, the more models you render the bigger the performance hit, so you have to find the sweet spot between quality and speed. This is still a problem that I’ve noticed in many AAA sports games, fans are often doing identical animations at the exact same time.

Color Shading Variety

Since you are not rendering each fan individually, they inevitably all look exactly the same. You can alleviate this by some GPU Shader trickery. For every vertex in every fan quad, in addition to the usual info (Position, Texture,Normal), you can also add a couple of extra colors to each vertex representing the pants, shirt or skin color of that individual fan. Then in the pixel shader you use those vertex colors to alter the colors of the original texture by multiplying them together with the original texture. You’ll want to separate the shirt/pant colors, so you’ll have to use some sort of mask in your original texture. For my implementation, the original texture had a red shirt and blue pants, so I replaced all the red texels with my desired shirt color, and all the blue texels with my desired pant color.Capture

Optimizations and Details

Texture Swapping

You will end up having a few different renderings of your fan model. If you have 5 different animations at 4 different viewing angles that’s already 20 times you have to render the model per frame. You’ll want to put all of the renders on one big texture, so that you can draw all of the fans in one draw call with no texture swapping.

Draw Order

All the billboards are rendered with alpha blending turned on, so that you only see the fans not the actual quad. This can lead to some funky draw-order bugs depending on your view angle. I found that if you order your fans top-down, so the fans higher up in the arena will be drawn first and the fans close to the field will drawn last, that solves most of these problems.

Given more time and more money, we could really optimize and beautify this fan system more. However, this approach is fairly straightforward (if you’ve done some shader programming before), and it will hopefully get you headed in the right direction in your own creations!

If you want more details or have any questions don’t hesitate to ask in the comments section.


-Andy K.

Normal Maps and nDo

by Vanessa Trepanier 


There are a few ways to make normal maps: Maya, zBrush, and programs like Crazy Bump for instance. While you can always let these programs do their stuff, adjusting a few settings here and there, you can always paint your very own normal maps from scratch with Photoshop and the nDo plug-in.

The nDo plug-in (which can be found here: is an Action in Photoshop that can convert your texture map into a normal map, using nDoexample2the information you’ve painted in to create bumps, scratches, and hard surfaces. If you have a layer that’s full of a rocky texture for example, nDo will quickly turn that into a bumpy surface for your model at the click of a button. It also allows you to adjust a number of settings, from the depth of the cracks in the rock, to beveling and embossing, and the smoothness of it. It gives you a lot of control, allowing you to create the exact look you’re going for. And of course it’s entirely adjustable, allowing you to continue to refine once you’ve already started.

Now if you have a flat texture, something like metal or plastic, and you want to add some lines for detail, nDo has you covered there too. You can activate nDo on a blank layer and paint symbols or lines, then convert that into normal map information. It’s a very advanced tool that even a novice can use.

nos tanks with a stone textured normal map


What’s especially great about nDo is that it’s  completely free, which is very useful for students, indie companies, or even portfolio work. I used it myself on personal models for my portfolio. In the example image, I converted a stone texture into a normal map with nDo for a few NOS tanks on a sci-fi gun I designed. The texture gave a rusty metal band a worn, weathered look. The painted bolt above the tanks was given detail with nDo as well.


So if you want to give nDo a try, go ahead and download it from There are also a number of useful tutorials for nDo out there, especially this one here.

10 Steps to Start Your Own Video Game Development Company

I’ve had my own video game company for 2 years now, and I think for a person like me it’s the best job in the world. For all you other nerds who would like to go down a similar path, I’ve simplified the process into 10 easy steps. Note: This is definitely not the only way to go, but it’s what worked for me.

1. Teach yourself how to make a video game.

2. Make a video game. A complete video game.

3. Use the game you’ve created as a way to get a job in a professional established, company in the games industry.

4. Re-learn how to make video games the better way.

5. Learn how not to make video games, and learn how to hate unpaid ‘crunch’ mode.

6. Leave your job in the game industry and get an easy job with absolutely no overtime.

7. Make your own game using your newly freed-up hours.

8. Realize working part-time means you will never finish your game

9. Get massive support from your spouse/partner/friend/family/dog  (including financial support)

10. Go full time!

Caveat: Steps 1,2,5, and 7 are really hard!

It’s all worth it because now we get to work here:


Instead of here:

Making Modular Models

by Vanessa Trepanier

Have you ever wondered how to make your own Skydome in UDK? Or how to make custom light maps that will really give your level its own, unique touch? Or what about learning a new take on modular building?

There are a few great video tutorial websites out there and today I’m going to be talking about one that I fell in love with a few months ago: 3Dmotive has a variety of tutorial video packages for free and for sale that can show you new techniques for UDK, 3Ds Max, Photoshop, and eventually Maya. While currently the amount of tutorials available is small, 3Dmotive is actively making new tutorials to share with the 3D community.

I first heard about 3Dmotive in November 2010 in a texturing class. We had been practicing modular building sets when my teacher mentioned he found a great tutorial with tips on how to do approach sets. I soon discovered that ‘great’ is an understatement; after watching their video on Modular Building, my mind was utterly blown. Before seeing that video I had a far different approach to modular building that sometimes left me with reams of useless reference images and frustration whenever I realized I forgot a certain useful part, or thought of something cooler. It was a little time consuming and while my models looked good in the end, if I had known about any other method to create modular sets, I wouldn’t have wasted my time.

The tutorial that the fine folks at 3Dmotive have created is incredible and I never considered approaching modeling the way they did. It made life easier for me to create assets for projects and even for my own portfolio. Basically, their approach saves time by getting you into the habit of building an atlas ahead of time, rather than just collect reference images you may or may not be using. It also encourages you to go out and start making your own texture library so you can customize your atlases and models.
Let’s say you want to make a basic warehouse. Instead of making a list of all the things you’ll need, finding references, building planes, and modeling individual pieces, all you need to do is find your favourite image for each part of the building: a door, a sign, a cement slab, a brick wall, a broken window.


If you arrange these properly on a grid in a Photoshop file, all you need to do is create a square in your modeling program of choice that matches the size of your atlas file, apply the atlas to your model as a texture, then start chopping it up.

Now what have you gained from this? A nearly fully assembled, already textured set of assets! After this step, all you need to do is add some detail (extrude window sills, ledges, frames, etc), remap the sides of your individual pieces and you’re done! You’ll have an entire modular set that you can use to create a number of different building styles, already textured for you and ready to go. And even if you don’t use UDK or Max or Maya, the tips in the video can be applied to any program of choice!

So why not go give a look! You might find something helpful like I did.

Welcome to the SFG development Blog

Welcome to our humble blog! Stir Fry Games is a small game development team, with 4 games under our belt, and we are now working on our largest, most ambitious project yet. We’ll use this blog to share the lessons we’ve learned along the way, and give you some insight into the development process.

You can find out more about our team members on our website.

Thanks for reading!