Game Engine Design and Implementation: A Semester Post Mordem

It's been a long, hard semester but it's finally coming to an end. The past month has been overwhelmingly busy between programming Gamma Gears and wrestling with course work and the like. In this blog, I'll talk about a few of the lessons I've learned this semester and a bit about what I've been up to.

Lesson 1: Gamedevs Don't Do Documentation.

At the start of the semester we were required to use a pre-made engine, despite my requests to use our Dungeon Boy engine from GTFO: The Double Dungeon Debacle. My professor felt that by using a third party engine (in our case Sony's Phyre) we could get straight to the making the most important part, gameplay.

Yeah I mad.

I didn't believe him for a second. We had a pretty good workflow with our existing engine with working combat, and all necessary game engine components working in acceptable capacity. Getting set up with a new engine would take time. There would be so much troubleshooting and failure ahead, with no merit to what we had previously accomplished.

A wise prof once said: "Gamedevs don't do documentation". I thought he was kidding before I met Sony's Phyre Engine.

When using a tool as extensive as a game engine for the first time, there is a lot of uncharted territory. In some cases it's like being given a bag of futuristic Alien tools with little to no instructions on their intended use.

Samples like these were our primary means of deconstructing Phyre.

To clarify, the engine does come with some documentation that will get you started, but there are many common tasks that are not detailed or covered. The instructions are often incomplete and downright negligent. In order to get started making a game with this tool, I had to deconstruct the few sample projects I was provided with. Unfortunately none of these sample projects contained any form of combat, so this left me with very little reference for that aspect of the game. Chances are if you didn't help make Phyre engine, you're going to run in to some issues.

Thankfully for some of the more technical issues (like how to create a phyre base project) we were able to get help from one of our fellow classmates. His blog can be found here: http://mikedaprogramma.blogspot.ca/

Lesson 2: Choosing an engine should be about the right tool for the right job.

To make a long story short, development on Gamma Gears was slow and often confusing. Due to the intense learning curve in working with Phyre and minimal of availability of assets early on, getting the basics up and running took much longer than expected. Once we managed to get our skeletal animation system working, we had decent animation and locomotion with environment collision detection. All of these features were implemented in script as recommended in Phyre's documentation and demonstrated in the samples. We took this approach so that we could build our game scenes using the Phyre level Editor which we thought would make things easier. Not to mention the samples were implemented in this way. Once the game is constructed in the level editor, the assets are exported and the scene can be loaded in code.

We ran into problems when trying to access data between our script (lua) and code (c++) platforms. This was most likely due to our own inexperience with the tools, but as a result we were unable to implement certain "code only" features such as GUI and audio.

To make matters worse, despite my best efforts at implementing combat in script, things just weren't coming together.

I knew I had to present some form of gameplay to my Game Design professor today, so last night I coded a combat prototype using our Dungeon Boy engine in about 12 hours. Many new systems had to be added (multiplayer input, chain combos, multiplayer camera), as well as countless adjustments to movement, collision, animation states, and assets. This was only possible because I was working with tools that I had created.

Working Title Screen: Check

It may not look like much, but this is gameplay. There was very little time for visual adjustments.

I can't wait to sleep after this blog is over. 

In 12 hours we achieved fully functional 1 on 1 multiplayer combat (I wouldn't say it's super fun yet but you can beat eachother up pretty good), with GUI, sounds, and a basic restart event. This build is sadly, more playable than our Phyre build, which I've spent at least 10 times the hours working on.

If there's a point I'm trying to make here, it's the one about getting right to the gameplay. Sometimes the right tool for the right job is the one you made yourself.

Lesson 3: The Shawarma effect

Mmmmm Shawarma.

The shawarma effect is a term that refers to the continuous stripping down of an idea or project.

Often when designing games, the initial scope is set too high. The process of refining the idea is usually very much about simplifying it into it's most important parts. Over the course of the semester, Gamma Gears has been many different things. The Gamma Gears (both prototypes) you see in this blog is nowhere near as complex as planned in the design document. It's meaty bits have been trimmed down until only the base is present. This is a natural reality when creating early prototypes of games, especially when running on a tight schedule.

To deal with the shawarma effect, it's important to strip your game down early rather than later when it's time to actually implement your design.