Introduction

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.

Conclusion

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: http://bainsredemption.com