• Register
Post feature Report RSS The importance of making your game flexible

Rob writes about how he develops games in such a way that it is easy to make changes and improvements. Hinting at future features to come.

Posted by on

Game Flexibility


One thing that I’ve noticed while working on games is that the more flexible the code and graphics are, the easier it is to include new features or change previous ones. What I mean by this is the ability to not get trapped in scripting something a specific way because otherwise the game will crash, or making it not depend on a specific string or number somewhere that might want to be changed. Recently I just scripted in a new Tundra Biome for our game Duck n’ Dodge in which all of the assets would have to be able to be changed out or edited so that it could look snowy. In this article I will go over why being flexible is good, and a little bit about how I did it in our game, and some ways to keep your game flexible.


image02

First off, there are a lot of reasons to build a game to be more flexible. It’s always good to have a solid grasp on where your game is heading and what features you want the final product will have, but it’s impossible to know if anything might interrupt that down the road. Maybe a new idea comes forward and it’s so perfect it must be added, but perhaps the way one of the systems is in place prevents it from being put in easily. An example is of when we converted Outland 17 from a 2D game into a 3D one. As we were building all of the systems, items, and sprites, it focused in on having a flat character and placing them in a scripted way that repositioned them without a smooth transition. When we wanted to change this, it took at least two or more months to just refine a new system to handle turning, animated 3D models, and even aiming at targets. And that’s not even including the asset building and modifications afterwards.

With Duck n’ Dodge, I built the game from the ground up to have assets able to be swapped in and out with ease. Even stats of the units had sliders that could easily be changed for testing. So when I was tasked with changing our previously only forest game to a snowy landscape, it took some new chunks of code, but the majority of the work was making new assets and then telling the game when to place them. Each level understands which biome it is in, so when it loads up, it references a list of tiles that every biome has versions of. For example: the forest biome would have grass, rock, tree, but the tundra biome would have snow, snow capped rock, and snowy tree. So I could very easily just make a new biome with new assets and have it reference the same list to find what it needs.

image00

I think the most important part about keeping a game flexible is not coding things in specifically unless it’s completely final. For example, If you only think you will have one character, don’t place it into the game automatically spawned, because if you wanted to ever swap it out you would have to code in a system and make sure the game still has links to the player that doesn’t exist at game start now. Instead, spawn the player in by default, even if you have only one, it could save time later on. Another good thing to note is making short and easy scripts that can be applied to a lot of elements in the game. When I built a gun for Duck n’ Dodge, I kept the script vague enough that it simply spawned an object and sent it in a direction. Later on when we added Logs, I could reuse the script because it was doing the same thing, just a different object to spawn. Another small thing people don’t normally think about are languages. If all of your in-game text is referenced in an external sheet, it makes it all the easier to translate it and plug it back into the game instead of making 20 checks to see what language it should use for each bit of text.

image01 1

Obviously you shouldn’t re-code everything in a game to be flexible, and if it’s easy enough to change then by all means hard script it in first. But keeping the game able to be changed is great when you’re building it because if you don’t account for any changes, an idea might be scrapped just because there’s no time to re-code a system to handle it. I know because I’ve given up on cool ideas before simply because they would cause development to move back a month. Nobody wants that, so just plan ahead and keep an open mind towards game elements.

For those who are curious, we have a free download here on indiedb.
Indiedb.com

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: