Design of an Indie Action Game
During the development of Bain's Redemption, I had to wear many hats. This article tries to convey what works and doesn't work in the context of the design of a third-person action game.
What I Learned from Bain's Redemption
Reactive or Proactive?
There are two ways to design a game: reactive or proactive. They are just as they sound, we either think it out as we go, or we plan ahead. It's a good idea to plan ahead as you don't want your artists to be working on something that might be tossed out. But at the same time, sometimes you put in elements that you think will work well together on paper, but once they are implemented in the game it just doesnt' work. Learning from Bain's Redemption, I realized you can only plan ahead so much. We wanted to create a game that was as fun as Devil May Cry or God of War, all the while doing our best to maintain its authenticity.
Indicators, Indicators, Indicators...
If you ever want to reverse engineer the design of any game, the best place to start is the UI. The UI will tell you a whole lot about how the game works. Our game is no different. Observe the UI for our game. There is a lot going on, but everything has a purpose.
Balancing The Game
One gameplay parameter can be the difference between a well-balanced game and a poorly-balanced game. Gamers have a slang term for this: "OP." That move is over-powered, they would say. Consequently, when that move is revised, there is an over-revised effect that happens that calls for another slang term: "Nerfed." They nerfed that move, they would say. This happens in every game. It's not due to the formulation of a mathematical model of the game, but due to the trial-and-error nature of game design. When I see a move is over-powered, I will try to fix it but sometimes it's very off-balanced and its parameters need to be doubled or halved, other times it needs a subtle fix. Which one you will need for your game (big fix, or subtle fix) is an art form in itself. This is what separates good designers from bad designers. Good designers will keep tuning gameplay parameters until it feels right, while bad designers might tune it once or twice and assume they are done. I noticed in Bain's Redemption that insanity was OP. Insanity went from a value of 0 to 1, with 0 being sane and 1 being insane. When Bain goes insane, the player loses control of him and the player must wiggle the joystick to regain control. I noticed that between encounters the insanity would not decay sufficiently. So I adjusted the decay rate. Now consider that the object here is not to show off the insanity mechanic, but to penalize a player for over-using rage. In other words, we don't want insanity to kick in every 30 seconds just to see that it exists. Rather, we have a niche for this mechanic as all mechanics need a niche. Bain as a character is conflicted, so it makes sense that rage conflicts with insanity. This is what design is like. It's more of an art than a science I would say. Remember, form follows function.Conclusion
I have learned a lot from Bain's Redemption, in the context of design of an action game. Specifically, some things you just have to work out and see if they work well together. No amount of planning can guarantee good design. The design doc for a platformer might say the player's jump will reach 10 feet, but if the designers design a heavily organic environment and a cliff ends up being more than 10 feet away from another cliff, you will have to make adjustments. Humans are not machines and we can only predict so much. Why do directors have rudimentary recording equipment (in addition to the main recording equipment) when they film a movie? It's because the director cannot predict if the movie will look and play good without it actually being done (even with storyboarding the scene before hand!) Any good dynamical system has a feedback loop and as such, you can think of games as a dynamical system that requires feedback to be designed well. So in short, I don't have a magic bullet piece of advice for anyone getting into design. You will have to try it and balance it as you go. And even when you're done and you think it's perfect, beta testing will bite you and tell you that something needs to be revised. So keep tuning and tuning and tuning. And when you are done, tune some more. Still there are lessons to be learned from other games that have seen success. I talked about ability indicators that reward you for action and others that give you a quota for action. You will notice that the most popular action games incorporate different flavors of these two. Which you use will depend on the type of action game. The best designers are also gamers. Ever stopped and thought about why this is so? It is due to the trial-and-error process of designing games. Designers will spend a lot of time playing their game. Whether it's looking for bugs or testing parameters, good designers will know the most about their game. There is nothing extravagant about trial-and-error, but it is the path to a well-balanced game.Article Update Log
6 Jul 2014: Initial releaseRelated Tutorials
Lesson 1 — What C# Actually Is
Why is C# the language driving the production of thousands of indie games using Unity and custom engines all around the…
Steps to Make a Simple Game in Unity
if you’re diving into game development, Flappy Bird is basically the ‘hello world‘ of the gaming universe. It is the ul…
Automatic Tutorial Creation for Unity | No AI | No more time waste
Automatic Tutorial Maker (ATM) for Unity is a tool that automates in-game tutorial creation by recording developer acti…
Save and Load System for Godot 4 – Tutorial
Saving and loading game data is a crucial feature for any game, as it allows players to continue their progress even af…
Unity Finite State Machine Tutorial
Comprehensive tutorial on utilizing finite state machines (FSMs) in Unity game development. It explains the concept of …
Project Structure - Guide to Cocos Cyberpunk Source Code
In my previous post, I mentioned that I would be write a series of articles on Cocos Cyberpunk. So let's kick off with …
Discussion