Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 20, 2014
arrowPress Releases
October 20, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

6 Things I Learned From Indie Development
by Mike Shafer on 07/08/14 08:01:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.



In making Bain's Redemption, I came into the project as a programmer.  Eventually, I found myself doing design, business, marketing, and even some art.  Here are 6 things that I painstakingly learned that I hope can help other game developers.

1. Use a Project Management Solution

My dad tells me every successful project he's ever read about was lead by highly organized people. Game development is no different. You need to get yourself and your team some kind of organized project management package. Sounds expensive? Not really. Just pay for web hosting which you can get for under $10 a month and then install one of their free offered project management packages.

How about Bugzilla?

Bugzilla is good from a problem tracking perspective (i.e. you played your game and you found a problem.) This is not planning ahead. Planning ahead requires a project management solution, unless you want to mix your bugs with features to-be implemented, then you can go with Bugzilla. I rather keep them separate. Regardless of what you decide to do, make sure you have something and it keeps your team engaged.

We saw a boost in production after we installed our PM solution as you would expect. Ideally, you want to give your team tasks they like doing and that's what I tried to do.

Our project management solution

2. Don't be afraid to admit bigger companies can do something better

For Bain’s Redemption, I made a whole rag-doll system complete with a GJK+EPA collision algorithm just as Bullet, Havok, and PhysX is capable of doing (I think in the latter two, you have the option of using GJK+EPA). What I eventually learned was that this algorithm is nice for the plugging-in of different shapes for physics simulation, but some shape pairs require specialized algorithms. I assumed I was done when I implemented this algorithm because it would work with any convex shape pair. Unfortunately, box stacking is a measure of how well your physics engine works and mine took way too much CPU power to make a 10-box column stable. Why? Because you use something called box-clipping for box stacking. Furthermore, you need velocity as well as position solvers. I don't want to nerd anyone out, but that is the reality of what I learned.

So what happened to this algorithm? It sits there and gathers dust, because we decided to use NVIDIA's PhysX. PhysX was superior in terms of performance (an overlap broadphase test is absolutely required for any physics package which my custom physics lacked) and it was free for the PC. Well no duh, a package made by 20+ programmers that have been doing it since they were kids is going to work better than something you can cook on your own (usually). Still I learned a lot about solvers and physics collision and what not. And using any physics package is cake. Setting the parameters to a physics engine is very important for getting the desired behavior you're looking for. It's not trivial and I'm glad I did what I did, but could I have saved 6+ months of development time just accepting that I couldn't do it on my own? Absolutely.

3. Know your audience!

This one is a no brainer. Who are you targeting? Well duh, gamers. But what kind of gamers? What I like to do is think of other games that are successful and say "if they like game X, they will like Bain's Redemption." This is a good marketing metric and it needs to be decided early as you've probably read countless times. When we decided to make Bain's Redemption we wanted to implement something like a cartoon, but for adults. At the same time, we decided that we liked the mechanics of Devil May Cry (mainly the idea that you can have modern pistols with an archaic sword) so we made something that was the marriage of these two ideas. Who will like our game now? People who like comic books will like it. People who like hack-and-slash games will like it. Also, our models in our game are much simpler than what you see today. This is because we decided early on that every model shall be cuttable with sharp weapons. We're talking about the entire model being cut, not just a leg or an arm. Which means you can banana peel someone with a Katana. It's cool, but graphics will take a hit. Still it builds a niche for our product.

Cutting models in Bain's Redemption.

4. Custom engines are a lot of work

A lot of indie developers go with Unity as their engine or with the advent of the new pricing system for Unreal, they go for the Unreal 4 Engine. We decided to go with our own to avoid paying any fees to anyone. Our editor gets the job done, but there is a lot of work that needs to be done on it that we just put on the back burner because the game needs to be completed. So I'm not sure custom engine development is for everyone, but if you do go down that route, be very careful. It took us a week and a half just to implement god rays in our engine, for example. They come out of the box for the two aforementioned engines. HDR Bloom took another two weeks to implement, it comes out of the box for the other two. Every engine/editor combo has its quirks, but unless you're really self-motivated and want to learn how things from the ground up, go with Unity or Unreal.

5. Don't overdo data-driven development

So in a game (or any other computer application), you have two things, you have data and you have code. Most games have a packed art file that is the data and an executable that is the code. This is why it's called a game engine because the code is running in a loop and it grabs the data and spits out pretty colors on your screen. It's well known that data-driven applications are cleaner, easier to debug, and just all around better. What sounds better to you? A special FX editor that you can load special FX into, preview them, and save them out as FX art files, then display your special effects in the game via code? Or creating customized code for every effect you have. The latter has been done and it's a logistical nightmare. There is a lot of copying and pasting of code going on and it's just not clean and organized. It's much better to be data-driven. Furthermore, when you work with designers, being data-driven is required, designers want to work with parameters, not code. And parameters are data. We have a state machine editor for our game (see below). Turns out, it works great for Bain's attacks and animations. I wanted to make every object with state in our game use the state machine editor. I soon realized that this was too much data-driven development. Why? Well, no designer is going to look at a complicated AI state-machine, instead they might say "that enemy shoots me too much, tone it down." Furthermore, we revamped our AI to use Selector/Sequence/Parallal constructs in Behavior Trees and I think it's too complicated to use for most designers (still it looks like there's a Behavior Tree Editor in Unreal's engine). Still I think most designers may find it cumbersome to use and will ask a programmer to at least help them (it has features like how often per frame something should run--just really nerdy stuff that designers would have trouble with). So in short, if designers need access to something, make it data-driven, otherwise you're free to make it code driven if it's appropriate.

State Machine Editor in the MEH engine.

6. Don't forget to start marketing early

Our Kickstarter for Bain's Redemption is slated to launch at the end of August. I thought I could just launch the Kickstarter and it would be a success due to the fact that the game looks and plays well. This was before I talked to my friend Andre' Lamothe. Andre' has written many books on game development and understands the process inside and out. He told me that I'd want to start marketing the game 2 months before the Kickstarter. You see, many people think they can just make a game and it will be successful. If nobody knows about your game, it will not sell, period. So humble yourself, accept that nobody knows (or cares, yet) and make them care. It's that simple.


While these 6 items did not comprise an exhaustive list of good game development tips or what I learned in making Bain's Redemption, it's a good start for anyone. Remember to plan ahead, be humble, accept changes, accept you can't do it better than big companies (most of the time) and hope for the best. The best may just come to you.

About the Author

Mike Shafer has been working on the MEH game engine for the past 7 years. He is the lead programmer on the project and also assembled the talented team that is working on Bain's Redemption. He has a B.S. in Computer Science from the California Institute of Technology (CALTECH). His previous credits include Ratatouille for the XBOX 360 and Return Fire 3 for the PS2. He specializes in graphics, engine, AI, physics, animation, and banging his head against the wall. He enjoys basketball, calm walks, and card games.

Bain's Redemption pre-alpha gameplay footage


Please pay us a visit:

Related Jobs

Cloud Imperium Games
Cloud Imperium Games — Austin, Texas, United States

Release Engineer
Filament Games LLC
Filament Games LLC — Madison, Wisconsin, United States

Game Engineer II
Filament Games LLC
Filament Games LLC — Madison, Wisconsin, United States

Game Engineer I
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Software Developer Analytics / Big Data (m/f)


Alex McCumbers
profile image
So, now that you've decided to use PhysX, are there any other programs you can see yourself using for your game? Will you develop other software for other aspects of the game? Or stick with what's only being used in the industry?

Mike Shafer
profile image
Well, everyone does it differently. Some people won't start a project unless it's entirely comprised of middleware pieces that presumably go well together. I like to do it on my own, and if it turns out a bigger company has a package that does it better, then I'll consider migrating to their solution. This way, I convince myself that at least I tried to do it from scratch and learn a lot in the process. Regarding your question, I am a firm believer of "if it ain't broke, don't fix it", and that applies here.

sean lindskog
profile image
All good advice.

On one hand, I would have told you you were crazy and wasting time if I had seen you writing your own physics engine.

On the other hand, I did write my own game engine for my first indie game, and I'm doing it again for my next one. (Although I do use as much middleware as possible for graphics, physics, sound, UI, etc). There's no doubt using Unity would be faster. But the thought of building a game on top of a closed source engine freaks me out. I would never want to be in a position where I had to support a complex piece of software built around closed source code. There's always the fear something internal to the closed source will cause problems. And even if the issue is in your own code, it's harder to debug within the confines of a closed source engine.

Unreal is looking like a great option for 3D games these days. But my upcoming game is 2D, so I went with a custom built engine.

Mike Shafer
profile image
Lol. I learned a LOT from writing my own physics engine. A lot. Specifically, setting up joints for a rag doll is non-trivial and I had to do that even with PhysX. It was easier because I had the experience. Still, I could have learned in a more efficient way.

I'm with you 100% when you say "it freaks you out". I really does. I had to debug a bug in PhysX where extremely close-to-zero velocities made it crash. I didn't have the code, I got a stupid error in the DLL. It could have been ANYWHERE (it's multi-threaded and the error didn't occur on the line of code which was causing it). Well about 3 days later, I found the bug and I clamped our close-to-zero velocities to zero. So you can waste time with a package as well if you don't have the source, still I don't want to deter anyone from using Unreal or Unity. Especially if they're not very familiar with game programming. There are countless resources and documents on how to use Unity and Unreal so you're at least in good hands.

sean lindskog
profile image
Heh, yeah, I had some doozies with PhysX too.

For sure, as a learning exercise I totally agree - getting down into the nitty gritty of physics, graphics, or whatever is a great experience.

As long as you're honest with yourself that it is a pretty inefficient way to build a game. So it all depends on your priorities. Still, it has likely made you a better programmer.

About middleware - here's what I always ask myself:
Is there any available middleware that is:
- cross platform to meet my needs
- has decent documentation / source / support
- does mostly what I need it to do.
- is affordable (compared to the dev cost of making it yourself)

In my experience so far, I can usually find good graphics, physics, UI, input, and audio middleware solutions. Whereas AI and gameplay are custom written.

I think the main valid reason you might go with in-house code is if the *core feature* of your game requires some special functionality not available in any middleware. Disregarding that, it's probably a very inefficient route to making a game.

Mike Shafer
profile image
It is and it's nice to be able to know how to make the software that you are using--or at least have an idea of how it works under the hood.

That said, I highly recommend everyone to use middleware. Don't reinvent the wheel unless you want to see how the wheel works :).

It turns out our "*core feature*" is live online cutting of geometry and nothing had that at the time I started the MEH engine. The way the cutter thread interfaces with the other threads in the game engine is pretty pivotal. You have to replace the whole geometry with the cut geometry in the same frame and if you're using some multi-threaded package, you might have trouble integrating into it.

That said, I'm with you 100%, I made a custom engine, I can say that. Does it make it better than Unity or Unreal or OGRE? Probably not. Does it do what we want? Yes, so we're going to stick with it. If I had to do it over I'd probably go with one of those three though. It's not too late you say? Well, I'm a firm believer of "it ain't broke, don't fix it." Unless we hit a drastic pothole on our road to shipping, we'll stick with our guns.

Chad Wagner
profile image
Don't forget OGRE as an option ( - it has many of the features you mention above, integrates with PhysX and Bullet3D (et al), and is open source!
Might be a good place to start when building your own at least (ala Torchlight, and others).

Mike Shafer
profile image
Yes indeed. Torchlight 2 indeed had it in its credits. I was impressed to see it there. I would recommend OGRE for its animation functionality as well.

Filip Lizanna
profile image
Thanks for the tips man, really informative. Game looks promising as well, i'll be on the lookout.

Mike Shafer
profile image
No problem, my pleasure. It was actually Andre's idea that I share my troubles and successes with everyone. I'm happy that I did it due to the feedback I'm getting.

John Flush
profile image
For project management solutions, finding someone to host and then putting in bugzilla could work, but really JIRA, at $10 a year for a year (if you host) is a great alternative. It does bugs AND project management. And if you get fancy for another $10 you get their agile boards that can do Kanban and/or Scrum. $20 a year? Yeah, I don't know why anyone (in a small shop) wouldn't skip a lunch or two and get it instead of free solutions anymore. I should probably work for them or something... Just don't host it with them. They then would charge you $200 a year ($20 a month - SaaS power!)

Of course the other downside is that is for only 10 users... the second you get 11 employees, boom! $1800 :(