Opening

Hey guys! I’m Drew, game designer/developer/project lead/composer for Beyond The Tales, and we wanted to share some of the main lessons learned from the FIRST attempt of at this game. I hope this information helps future game devs with some big decisions! Some history to start with first.

History

Our team began the first iteration of the game in 2014-2015 and it lasted for approximately a year. During this time we made some pretty big decisions, like what engine do we want to build on, the style of game, style of artwork, style of music, and some other general things. Out of that we came out with a 2D RPG in the style of the older Final Fantasy / Zelda games, using Unity as an engine. Why? We love that genre of games and Unity seemed appealing. We were brand new to game dev, but not new to software development. I think that part is super important. We are NOT new to software development and game dev shares many principles that apply to software dev. Our team had 9 people. 6 of us are professional software developers with degrees in Software Engineering.. Now please do not assume that 1) you need a giant team to build a game or 2) you need a degree in Software Engineering to build a game. There are programs like RPGMaker and tons of tutorials online that can assist you in building your dream game.

Let us fast forward a bit from the beginning of the first iteration. We have some levels, some animations, some walking characters, basic battle, and some other features. Here is where we started to see tons of problems in our development process. Each new level was taking longer and longer to add. The longer the game got, the harder each new bug was harder to fix. The code was not designed to handle growing or scalability. Requirements were weak and scope was not at all set. Honestly, the game got so big that it became nearly impossible to keep adding to and we eventually called it quits. Solid year of work, we all were burnt out, and we quit. You might be saying “never give up” or “why quit on your dream” etc, but this decision was one of the best decisions that we made. Let’s go into the lessons.

Lessons Learned #1 : Define Requirements as far as you can go

Having an overall vision and concept of the game is probably the most important thing you can have. Without a vision, you really cannot begin to start doing anything constructive with the game. Once you have a vision of the game (what kind of game, style, etc) you can then begin to break it down into DIGESTIBLE parts. This digestible parts is important in order to not get overwhelmed and eventually have a game finished. Let’s take an example.

Say you want to build a game like Sonic The Hedgehog. First you will want to say what makes Sonic a great game? What do I love about that game and why do I want to make my own version of it? The answers might be like, the game has great music, I love 2d platformers, the mechanics of sonic are so simple anyone can learn, etc. You can break these statements down into digestible requirements. Let’s take “I love 2d platformers”. Well, what do you love about them? What are some of the characteristics? They have puzzles, they can contain traps/spikes, they have platforms that move, they have destroyable objects and power ups (super speed), they usually have something to collect, they have enemies that roam the 2d platforming land, they can contain multiple paths in levels to the end, they have an end, the levels are usually somewhat short (compared to open world RPGs), and the list can go on. You can then take these thoughts and turn them into workable, digestible components to build. And each of these components you can probably define more as well. The requirements might look like:

1. Must be a 2d platformer

   1. Must have traps

      1. Pitfall traps are instant kill

   2. Must have spikes

      1. Spikes when touched must damage your rings first

      2. Spikes touched with zero rings results in death

   3. Must have moving platforms

      1. Platforms can move up and down

      2. Platforms can move right and left

      3. Platforms can be jumped to from underneath

      4. Platforms can be walked on from on top of

   4. Must have power ups

      1. Super speed

      2. More rings

         1. Gives 10 rings

         2. Gives 20 rings

         3. Gives 30 rings

      3. Extra lives

   5. Must have extra live counter

      1. Displays in the bottom right of the screen

   6. Etc.

Whether you know this or not, you just defined some requirements for your game. In pretty decent detail too, where game devs could take this and start designing the game in code and then implementing it!

The more you can do this for your game, with all pieces, movement, menus, battle, save, load, etc, the easier your game will come.

Lessons Learned #2 : Build a LEGO structure

This is pretty important. RPG’s have many elements that are shared. For example, chests. Chests in an RPG pretty much all behave the same way. They open and give you an item, with a fancy sound effect and a fancy animation.

Believe it or not, our first game had a chest script for EACH chest that was in the game!

Now you might not see the problem with that but likes say we find a critical bug with chests. We have to go fix every chest in the game.

This was one of the core reasons why our game got impossible to maintain before. Going into the second iteration of the game we designed our scripts with this LEGO style in mind. Basically LEGO’s are reusable components that can be built on top of each other! Also legos can be changed around without too much hassle. We could apply bug fixes for the chest with a single change instead of one for every chest.

For our chests currently, we have one script that controls all chests. This time if there is a bug, we fix it in one spot and BOOM every chest is now updated! We follow this pattern alot with chests, doors, warps, sliding blocks, etc.

Stay tuned for part 2!