Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
Follow these tips and techniques to create an epic-scale game on an indie budget.
I love epic-scale games! I love exploring a new world, encountering strange civilizations, and of course, amassing wondrous artifacts to fight a variety of deadly enemies. But as a small indie game studio on a very limited budget, I can’t afford the army of artists, level designers, and programmers needed to create something like Mass Effect, Skyrim, or Fallout. Fortunately, there are several techniques and best practices that have helped me get the most out of my limited resources. And while you’ll always face compromises, there is nothing stopping anyone from creating a vast, engaging, and epic-scale game on an indie budget.
This article is based on my experiences creating Transcendence, a game of space combat and exploration. In Transcendence the player commands a spaceship traveling through the galaxy, encountering various human and alien civilizations, and (usually) fighting enemy ships to obtain fuel and upgrades. In a sense, the ship is the player’s avatar, and it experiences the normal progression that a player character in a more traditional RPG would undergo. Nevertheless, many of the techniques in this article apply to more traditional, character-based games, with only minor modifications.
There’s lots of game developer advice out there, and most of it emphasizes one point: start small. Every indie developer who started out with dreams of building Skyrim (only bigger!) never finished. Yet here I am telling you to build an epic-scale game. What gives?
The trick is to think of an epic-scale game as a small game with a lot of content. This sounds either incredibly obvious or totally contradictory, but my point is to distinguish between the core game loop and the actual content of the game (the units, items, missions, and environment). The core game loop takes work and iteration, but you can build one in a month. Building the full content of the game could take decades. For example, ten years after its original release, I’m still adding new missions, encounters, and items to Transcendence.
The best way to create an epic-scale game is to build a fun and expandable core game loop, and then progressively add more and more content. Start small: Build a playable game with the minimum amount of content possible. Then, over multiple releases, add more and more content until you’ve created your very own epic-scale game!
Of course, some core game loops are better than others. If the core game mechanic is too simple, then you won’t be able to create lots of diverse content. Conversely, if it’s too complex, then players will find it hard to learn.
I learned a lot from studying games like Magic: The Gathering and Dungeons & Dragons. In both cases, they have simple rules with lots of exceptions. The core game mechanic is simple to learn, but specific cases (monsters, spells, etc.) bring in special modifications to those rules.
In Transcendence, for example, the core game loop is simple:
Aim your ship towards the enemy target.
Fire a projectile.
If the projectile hits, it does damage to the target.
After sufficient damage, the target is killed.
This is a simple (and common) core game loop, but it allows for an immense number of modifications, enhancements, and exceptions. For example:
Aiming: The simplest mechanic is to aim your ship towards the target, but there are a number of obvious enhancements. The maneuverability of the ship affects aiming, so we can create upgrades that increase speed and turn rate. We can upgrade weapons to aim automatically. We can even add mechanisms for slowing down the enemy target (thus making it easier to hit).
Firing: How many shots can we fire per second? Is energy consumed? Is ammo consumed? Is there recoil? Is there a chance of misfire? Every one of those questions can be used to design new and innovative weapons. For example, we could create a weapon that fires very quickly, but has a chance of misfire.
Damage: Different weapons can have different effects. For example, perhaps one weapon is particularly good against certain kinds of armor. Or perhaps the damage depends on where a ship gets hit. Ships, of course, can have innumerable upgrades to deal with damage, from regenerating shields to anti-missile defense. Moreover, weapons can have different effects other than plain damage: momentum (pushing the target), EMP effects (disabling), radiation (poisoning), etc.
Killing: Once damage has exceeded a certain threshold, the target is dead. Again, though, we can add various modifications. Perhaps some ships explode violently (and risk damaging the player). Other ships might deploy escape pods. Or perhaps they split in two, and now the player has two more enemies to deal with.
Another important (and related) property of epic-scale games is that they have expansion joints. Think of the iPhone for a second: Apple didn’t build a phone that does everything. Instead, they built an app platform that could support a wide variety of apps. In the same way, your epic-scale game should be a platform supporting a wide variety of content (missions, dialogues, etc.).
This means thinking about every feature of your game in general terms. For example, in a hack-and-slash dungeon crawl, you might have potions for the character to quaff. Do you therefore implement a quaff command? What happens later when you introduce food? Do you have to implement an eat command?
A better system is to generalize the concept. A player can use or apply an item. If the item is a potion, that means quaffing. If it’s food, that means eating. A slightly more advanced system would change the user interface label based on the item. Thus the player would still see “quaff” vs. “eat.” The difference is that you implement a platform that supports a wide variety of items. Then, when you decide to implement tobacco pipes, you can easily integrate them. You’ve just created an expansion joint into which you can fit a wide variety of items.
In Transcendence, one of the main expansion joints is the dock screen system. The player can pilot their ship and dock with a space station. Once docked, they see a screen with different possible actions, depending on the station. For example, at some stations the player can buy and sell merchandise. At others, she might upgrade her ship. (There are even some stations that let the player volunteer for medical experiments, but that’s a different story.)
Having a consistent interface for interacting with stations helps the player to learn the game quickly, but also allows for an infinite variety of interactions and encounters.
Creating a platform will make it easier to create all the content you need. But more importantly, it also allows your players to create content for you. If you want to create an epic-scale game, I strongly encourage you to build a modding system as soon as possible.
The simplest modding system supports adding new static content. For example, many games define enemy units (monsters, etc.) as records in a table. Each record contains fields defining the monster, such as name, armor class, damage, etc. You can implement a system that imports new monster records from an external file.
Eventually, however, you will want to support scripting. In Transcendence, you can define new weapons and use a scripting language to program the result of firing the weapon. This allows for a much wider variety of weapons.
Running scripts inside the core game loop can be challenging. First, there are performance issues if your scripts get too complicated. But more importantly, you need to handle interactions between scripts and the rest of the engine. For example, what elements of the core loop do you allow scripts to modify? The more power scripts have, the more variety you can support. But too much power leads to complexity, bugs, and instability.
In Transcendence, when a projectile hits a ship, we run an algorithm that allows both the projectile and the ship to modify the result via scripts:
Run the OnAttacked script on the ship. This allows a ship to react to attacks. For example, the ship might decide to run away or to counterattack.
Run the OnSystemObjAttacked script. This allows other objects in the vicinity to react. For example, a friendly ship might intervene.
If the ship has shields, we run OnDamageShields to give the projectile a chance to react to the shields. For example, some projectiles might go through certain kinds of shields but not others.
Let the shield generator handle the damage. We run OnShieldsDamaged to give the shield generator a chance to react. For example, some shields could consume extra power from certain kinds of damage.
If the projectile gets through the shields, it hits armor. The projectile gets to run OnDamageArmor to alter its properties depending on the kind of armor it hits.
Lastly, the armor gets to run its OnArmorDamaged script to react to the hit.
Notice that we allow both the projectile and the target to react to the interaction. This lets us create special weapon and armor types. The more events you have, the greater the variety of special items you can support. Of course, that also increases the complexity of your engine, so you should use your best judgment.
Once you have a fun and expandable core game loop, it’s time to release your game. Wait, what? What about all those missions, wondrous artifacts, and fiendish enemies? Shouldn’t you actually finish an epic-scale game before releasing?
No. Indie developers don’t have the luxury (i.e., the money) to work on a game for years before releasing. Moreover, you’ll find that the sooner you build a community of passionate players, the greater your motivation will be to continue working on your game. As long as your core game loop is fun, and as long as you have enough content to give a taste of your awesome world, you should release it and start getting feedback.
Dwarf Fortress is a great example of an epic-scale game supported by a passionate community. Tarn and Zach Adams have been working on Dwarf Fortress for more than ten years and (as of this writing) they’re only on version 0.4.
Think of your game as an episodic TV series instead of a movie. Your first release is like the pilot of a series. It should give players an idea of what the game is all about, and it should have enough mysteries and motivations to entice the player to continue playing.
Subsequent releases should have more and more content to fill out the world and continue the overarching story. Depending on the nature of your game, you can even group your releases into seasons with a common theme. For example, maybe the first ten releases are all about building your world’s main city. And maybe the next ten releases explore the countryside or a totally different city.
Creating an epic-scale game is a massive undertaking, but the results are worth it. I hope this article has inspired you to start your journey.
Are you working on an epic-scale indie game? Let me know in the comments!
Read more about:
Featured BlogsYou May Also Like
