So this semester is practically over. However, throughout this semester we’ve come to realize that Game Development at UOIT is a lot more than just going to class; rather it’s about doing well on your GDW game and making an epic game. So with Game Con wrapping up yesterday, here’s a long post wrapping up the development process of SHFT during the semester.
It seemed like a long time ago, yet at the same time it felt like just yesterday that I wrote our very first blog post. Looking back, we were kind of naïve and too overly ambitious at that point, we just started the semester and had a ton of ideas for our game, many of which were just out of our scope. It also kind of amuses me too how we labelled Alex as a programmer when we found that he was much more effective as a modeller. Definitely glad that we have another 3D artist though; getting through all the art assets was definitely one of the things we had trouble with this semester.
With the intro out of the way, the following blog post delves deeper into our game design ideas for the semester. We wanted to turn SHFT, last semester’s RTS game, into a 3rd person RPG by ripping out the RTS elements and just reusing the engine. We actually managed to do that! Except of course we just rewrote the engine instead.
We also wrote that we wanted our trademark character Jack to explore many areas of Fantasyland and to have over an hour of content, unfortunately that didn’t pan out as much as we wanted to. We got hit pretty hard by the time constraints as well as other distractions and obligations so we couldn’t do as much as we could. Looking back at that discussion we had with the Gunblade, almost seems silly how we got worked up over something so trivial to the actual game design of our game.
One of the things that slowed down our game’s progress was the programming issues I had that I mentioned in post number three. My computer completely died that week and that meant I couldn’t program for a week, which really hindered my progress in getting any work done. Fortunately though all our other members could continue working on the game so Branan was able to test out rigging and animating a humanoid character while all the other members continued to work on creating the assets for our game.
Some of our preliminary art assets were shown in the next blog post. Rachel made a sweet wolf model that I really wanted to use, but we couldn’t. I feel kind of bad about it actually, but we had to cut out a lot of what we wanted to do for the semester, and although we planned on having animal enemies in the game, we had to ultimately remove those since it was easier to rig and animate a bipedal creature. Mack also had a preliminary sketch up of a level too. It had a lot of the elements that we incorporated into the final version of our game, but it had slopes which we just couldn’t figure out. We really wanted slopes in the game, but again, time limitations led to technical limitations.
It didn’t help that we also had the shader homework questions in our graphics course. We mentioned that in the fifth blog post of the semester. That distracted me and Gordon a lot from actually working on the game. Fortunately though we got them all done early so for the rest of semester we were able to work soley on the game itself. Not to mention we now had a pretty good understanding of shaders so we were able to use that knowledge in our game too.
Since we had so many time constraints, we also decided that we would hold “Team Overlord Game Jams” (TOGJ) where we would just meet up for twelve hours on a weekend and just work. It worked reasonably well too as we were able to get a lot of work done, but they slowly fell out of style later in the semester. However me, Gordon and Branan often found ourselves doing impromptu TOGJs while trying to get mesh skinning to work in our game.
At the start of reading week, I remember working a lot on the math classes we needed for our game. Naturally our engine would need to be able to do a lot of math, so I worked on doing that and getting matrix and quaternion classes done and also getting skeleton and bone classes done so we could parse a BVH file to do skeletal animations with.
By the end of reading week, Gordon managed to get skeletal animations done. That was a huge milestone for us since it meant we were finally on the way to being able to do actual realistic animations in our game. It was one of the most ambitious technical game design elements we wanted in our game, and seeing that red skeleton displayed on screen was a huge relief for us since it meant we were on track to getting it done.
We were getting worried by this point since it was essentially halfway through the semester, yet we didn’t really have much to show. This was really the point where we decided that we had to cut things. We all loved the original ideas we had for our game, but at that point it just wasn’t feasible or realistic to stick with what we had. We decided to focus on getting the core gameplay done and working from there, but in hindsight we probably still didn’t cut enough; we didn’t realize that until even later.
By post nine, we were still in the process of getting the game together in terms of programming and art. I was working on the basic mechanics of our game like the collision detection and movement, Gordon was working on finishing up mesh skinning and our art department was getting to work getting sounds and other art done.
As sound and audio is a vital part of any game (Plus they’re requirements for our class), Mack, Branan and Alex went and recorded a bunch of sounds for our game. We ended up getting a bunch of really awesome sound effects that made it into the final game such as running, water and pole-hitting sounds. We recorded a bunch of sounds that we didn’t even use, but figured we’d record them anyways. We even recorded a sound effect of Rachel slapping me. It was pretty painful.
The following week didn’t really see too much of an improvement either in terms of game completion. We mostly just worked more on the things we had, whether it was finishing up pieces of code, creating and improving art and editing and recording sound effects. We didn’t really have much direction in terms of what we were aiming for anymore; we just kind of kept making and working on things.
The week after was a bit more productive. At this point Gordon finished his mesh skinning code, so we decided to implement it into the game I had. The game itself was starting to come together at this point since we actually had art and programming assets to work with instead of just creating the parts. It was a pretty brutal integration session trying to get Gordon’s algorithm into the game, but we ended up getting it into the game and it was a glorious feeling.
To celebrate getting mesh skinning done, Branan bought a Kinect. We learned that the Kinect could be used to record skeletal animations which could be parsed into our game so we spent some time recording animations. It was fun, but we unfortunately could not get those specific animations in our game, so it really served as another distraction.
Finally, we get to the post we made after attending Level Up. The game was picking up steam at this point. I would say that the last two to three weeks before the game is due is the most stressful, yet the most satisfying parts of game development. It’s the most stressful since the deadline is looming so very close, yet at the same time everything is coming together.
We had a nice engine working that we wrote from scratch, animations and models were being created and then put into the game, sound and music were constantly being improved and tested in game and we just spent a lot of time polishing and improving our game. Our game changed a lot from what we planned, but we had a respectable game at that point. We were confident enough in our game that we even brought it to Level Up where we showed it off and got a lot of feedback which we used to improve our game.
Speaking of which, we did a lot of extensive testing the last two weeks or so to polish up our game and ready it for Game Con. We had three main sources of testing, from ourselves, from our professors and from other developers and people at Level Up.
Naturally we were the main source of testing since as the developers we’ve played through the game many times while integrating pieces of our game and debugging glitches. As a result we’ve contributed many pieces of feedback that we’ve used to get our game up to the “release” stage. Most of our feedback for the game came together in large chunks that determined the overall result of our game, such as the way the combat system works, the way the player moves and navigates through the world, etc.
By playing through the game during the development cycle, we naturally got to learn about all the little things and tricks that are present in the game, such as knowing when or where to jump to make getting around easier or how to easily kill enemies. This made us naturally biased towards our game because we designed it, thus we are experts at the game and a lot of gameplay features and mechanics would not be fully tested since we would end up skipping a lot of the content ourselves and generally followed a single path through the game since we knew where everything was.
Our first attempt at getting some external feedback came from our professors. The first professor we showed our game to was Ken Finney who played our game as part of our fourth milestone. At that stage in the development cycle a lot of the core mechanics of the game was complete, but many of the aesthetics were not finished and a lot of the dynamics were not polished.
The first thing he did when he played the game was try to walk around a platform that we have at the beginning of the level. When we tested the game we’ve always jumped on top of the platform, so when he tried to walk around it and we saw that our character somehow ended up below the platform (and thus below the world), we were kind of surprised.
He didn’t play the game for long, but he told us to remove some of the invisible walls we had in the game and to fix up our sword icon before we went and showed off our game at Level Up. We took the feedback he gave us and ended up fixing the issue with the collision detection system that cause it so when you collided with the left side of a platform you fell through the world. We also fixed the issue with the sword icon that he pointed out. We actually didn’t even notice that the hilt was too long until he pointed it out.
Later that week we also showed our game to Dr. Hogue and Dr. Nacke for their feedback as well. We showed it to Dr. Hogue first and he didn’t really give us too much feedback in terms of actual gameplay but he ended up telling us that we should have more shader effects in the game to really make it more interesting and to pop. We didn’t have that many and considering how me and Gordon were the first two to get to 65 experience, I think he expected a bit more in that department.
He told us that going for a realistic feel was not very realistic at this point in the development cycle and told us to consider going for a non-photorealistic effect instead. He told us to experiment with a Gooch shader with some edge detection to give our game more of a cartoony look since it would make our game more interesting looking and would also be a lot more feasible to do than a realistic looking game.
We at first did not want to do a non-photorealistic shader effect since a few members of our group did not like the look of cell shaded objects. However once we realized that the Gooch shader did not leave sharp colour drop-offs, but rather a smooth gradient, we decided to give it a shot. After seeing how our game looked like with a Gooch shader and edge detection, we decided that we liked the feel of the game and kept it in for the final release.
After talking to Dr. Hogue we also showed off our game to Dr. Nacke who gave us a lot more general feedback on a lot of things in our game. Some of the main things that he talked to us about were: the background song got annoying, some of our 2D HUD elements should be changed, we should consider using a controller to play the game, we should make the level design more interesting and that we should definitely make our game look nicer.
It was a lot of feedback, but we considered each point he pointed out and we found we agreed with a lot of them. As a result we got Mack to fix up the background music, Alex to redesign the level and Rachel to remake some of the 2D elements and Branan creating new animations, textures and setting up controller support while me and Gordon focused on polishing up some of the core mechanics of the game and integrating all the new assets.
With all the assets created and changed, we put everything in the game and noticed a definite improvement to the game. The game felt more complete and interesting as the world wasn’t just flat with random floating platforms anymore; there was actually a “story” to the level. The background music wasn’t as annoying anymore, and the aesthetics of the game improved dramatically. A quick overview of the level redesign could actually be found in our latest blog post.
Following that we also showed our game to Derek Fullerton as well to get some of his opinions on the art of our game. He said that overall the game didn’t look bad but there were some inconsistencies with the art style of the HUD with the rest of the game, and a few textures looked out of place. We definitely agreed with his points and worked on fixing as many of the things we could.
Overall, talking to the professors made us realize that although we had a “game”, the difference between a game and a good game was good polish. Even though mechanically our game is pretty much the same it was a few weeks ago, it’s a lot better because it looks and feels like a much more complete game. Going into Level Up, our game definitely looked and felt a lot better.
At Level Up we had a lot of people play our game. It was the first time we were at an event like this so we didn’t really know what to expect in terms of reaction to our game. A lot of people played our game, and we gathered a lot of feedback for our game and team. A lot of people were impressed with the fact that we wrote the engine from scratch which really made me personally feel kind of smug. Granted I think the engine could be a lot better.
We also got a lot of feedback towards the gameplay of the game, which was important because so far we mostly just got feedback on core mechanics from us playing the game and feedback on aesthetics from our professors testing the game. As such the gameplay of our game wasn’t fully tested as much as it could be and as a result we got a lot of feedback from the people that played our game.
The biggest points that we received from the people at Level Up was that the main character could move faster and that the big enemy was too hard to kill. In addition to vocal feedback we also got a lot of feedback by just watching people play our game since we noticed player tendencies that we would not be able to notice when people from our team play the game.
We noticed that a lot of people didn’t really have a sense of direction on what to do since they often skipped the introductory cutscene. We also noticed that a lot of people were naturally drawn to the big soldier enemy and tried to fight him all the time. In addition to those we also discovered a few bugs and exploits in our game such as geometry getting in the way of our camera and being able to essentially not get hit by any enemies when the player was standing on a tree or rock.
We took a lot of the feedback and tried to tweak our game accordingly. We sped up the main character and allowed him to rotate faster, therefore making the gameplay less slow. We nerfed the HP of the big enemy so that he was easier to kill. We fixed a few bugs in our code so that backface culling worked appropriately so that when the player is close to a wall the wall doesn’t get in the way of the camera.
A lot of the feedback we got were actually pretty simple fixes on our end, most of them required just a change in numbers. However they made our game less frustrating to play which is always a good thing. There were a few things that we couldn’t change though, such as the ability to swizzle the camera around the character.
A lot of the technical changes that we would need to implement would take too long for the time we had left. A lot of the core mechanics such as the camera movement was too locked in place at that point so changing it would take time we did not really have, so we couldn’t fix those issues. However we fixed and changed as many as we can which all worked together to make our game better and more complete.
As a result we were left with a cartoony, third person action adventure game where you play as Jack as he explores a mountainous forested area of Fantasyland in order to gather the five magical shards to restore peace to the land.
DEVELOPER PROFILES
Gary Ng
@Drayxs
Team Leader, Team Manager, Gameplay Programmer, Engine Programmer and Narrator
Gary is the team leader and manager of the group. As a result he was responsible for distributing work and making sure everyone did their part while setting up group meetings and internal deadlines.
He was also one of the programmers for the game and focused mostly on the gameplay and engine of the game. The game was built from the engine that he wrote from the start of the semester and aside from things like mesh skinning and AI was written entirely by him. All the art assets were integrated into the game by Gary and all of the gameplay elements such as collision detection and combat were also designed and programmed by Gary.
In addition to that Gary also is the narrator of the game, providing the backstory of the game in the introductory cutscene and throughout the game. He recorded
Branan Sarveswaren
@Branoodles
Lead 3D Artist, 2D Artist, Animator and Sound Artist
Branan is the main 3D artist for the game and focused mostly on the creation, rigging and animation of the character and enemies in the game. He created the models from scratch and then UV’d, textured and animated the characters while working with the programmers to make skeletal animations possible.
In addition to creating the characters and animations Branan also had a part in designing miscellaneous models of the game such as the platforms and shards. Branan also was one of the sound artists for the game as he helped record and edit sound effects for the game such as the spell sound effects.
Gordon Tan
@GordonTan4
Engine Programmer and AI Programmer
Gordon is the second programmer of the group. His largest contribution was the addition of GPU Mesh Skinning which he worked closely with Gary and Branan to get it completed and integrated into the game. After it was integrated Gordon continued to work on creating classes which would wrap the animation functionality neatly so that it could be used by Gary easily and effectively.
Gordon also worked on setting up the AI mechanics of the game which was used as the base for the game’s enemy’s AI. He programmed the algorithms that made seeking, fleeing, wandering and facing possible and linked it together in a manager class which was used to control the enemy’s AI patterns.
Alexander Best
@Qbbllaarr
Level Designer and 3D Artist
Alex is one of the main level designers of the group and as such was in charge of modelling and texturing many of the environmental assets in the game such as the rocks, mountains and chests.
With all the assets, he was also tasked with designing an interesting level and putting all the pieces together. Once the level was assembled, Alex also exported every individual object and worked closely with Gary to integrate the level into the game and to make changes when necessary to polish and improve on the level.
Rachel Fung
@r_fwc
Lead 2D Artist and 3D Artist
Rachel is the main 2D artist of the group. She worked on creating many of the 2D elements of the game such as the HUD and logo of the game. She was also one of the main concept artists during the planning and development stage of the game and contributed many pieces of concept art for the game. Rachel also created promotional art for the game such as a poster showcasing the main character Jack.
Rachel also worked on the modelling and texturing of many 3D assets as well, responsible for 3D models such as the fish and plants that are present in the game as well as the main level texture and the tree texture.
Mackenzie Sturrup
@Cieroceramics
Lead Sound Artist and 3D Artist
Mack is the lead sound artist for the team and as a result was responsible for many of the sound effects present in the game. His largest contribution would be the background music that is played during the game which he created from scratch for the game. Mack also worked on the recording and editing of many sound effects that were used in the game such as the water sound effects and the weapon swing and the shard pickup sound effects.
Team Overlord 