At Northeastern University I chose to make a game for my capstone project. The large, open-world 3D role-playing-game Gate of Redemption, sometimes referred to as G.O.R or simply Redemption, was made in the (then) new game engine Unity, and written mostly in JavaScript. It was to be published for the now defunct Unity Web Player and entered into a Unity game contest on the once popular online game website Kongregate. It was an attempt to incorporate as much as I could from the many things I learned during my time at Northeastern and NMSU while featuring many of the things I personally enjoy most in video games.
Overview
Working under my advisor Seth Sivak (now VP of Development on World of Warcraft at Blizzard Entertainment), I began work on this project about midway through my master’s program at Northeastern. Whenever applicable, I worked on different aspects of the game and accompanying website for class projects and spent a majority of my free time on it. I split my time between texturing, animation, 3D modeling, sound design, story, and programming. Because of the large scope, I utilized as many free and paid assets as I could, so long as I could retrofit them to suit my needs.
So…What exactly was Gate of Redemption?
Basically, my dream game. Influenced heavily by ARPGs and MMORPG’s I played in my youth, it was an exploration-heavy role-playing game with a medieval fantasy theme. The art style was influenced by my own painting style, and by gothic-themed games like Castlevania and the Diablo franchise. You see, each night, the landscape within the game would shift from serene and beautiful environments to a frightening hellscape full of dead trees, demonic monsters, and lava pits.
The game not only looked pretty (in my opinion), but it was filled with many secrets, rare items, strange monsters, action combat, and a (serviceable) story. I was going at it alone, and with a small budget, but I wasn’t going to let that stop me!
What I Did
The game contained all the general functionality you’d expect: Saving/Loading, Menus, Maps, Instructions, and a Tutorial. It was a full role-playing-game, with interactable objects, NPC’s you could talk to, items you can collect and equip, quests and more. Players could scroll with the mouse wheel to switch between third and first person views or zoom in and out. The character movement felt good, and allowed the player to sprint, jump, and scale hills and stairs realistically.
The action combat system was inspired by the Elder Scrolls series of games, and enemies had “elemental weaknesses” in the vain of games like Pokemon. Using number keys, you could change the character’s “elemental affinity,” granting you a different spell, increasing or decreasing your own elemental resistances, and causing your equipped weapon to do a different type of damage. This was all combined with a combo system where switching between elements, blocking, attacking, and casting spells in specific orders allowed you to unleash devastating attacks.
Each NPC had their own branching tree of dialogue with multiple choices for the user. I used a third-party dialogue engine called Unity Dialogue Engine, for which I built a custom UI. In addition to the NPC interactions, I created a few different types of AI behavior for the many monsters and animals that inhabited the world. Some of them moved along set paths, some wondered around aimlessly or went on the hunt, others were stationary. Not all were aggressive. Others, like the “Obligatory Giant Rats” would spawn around a nest every few minutes until the nest itself was eradicated.
The game also featured a full inventory system with items that could be collected, moved around, or equipped into slots. Armor and weapons modified statistics and changed the visual appearance of the character.
A World to Explore
An open world with destructible environments and objects, swimming, and the aforementioned “transitional landscapes” helped contribute to what I felt was the most important part of the game: exploration.
Here’s a little more about what I built for those gameplay mechanics:
– An open world built from modular dungeon meshes and Unity’s built in terrain. Once you finished the tutorial, you were free to go wherever you pleased, with only a few areas blocked off for story reasons.
-Destructible environments and objects. You could smash open crates or chop plants and trees to gather components. You could even blow a hole in the ground itself to deform the terrain, spewing forth debris would would sometimes contain valuable gemstones. Treasure chests could be found both above and below ground.
-Swimming. Because I wanted the game to be heavy on the exploration, I didn’t want the player to be hindered by too many invisible walls. It was important for me to make it so the player could swim and explore underwater. I spent a good deal of time just making the various swim animations for the main character.
-Landscape Transitions. As I mentioned earlier, the landscape itself shifted to a hellish nightmare every night. Peaceful creatures despawned and were replaced with demons and skeletons, trees lost their leaves, and even the textures of the landscape shifted. Night time had its own secrets to find and places to explore.
What I Learned
Scope.
One person, no matter how driven and ambitious, can only do so much. Especially when they have bills to pay. My strategy of adding just about every cool feature I could think of was not very practical. I had all kinds of systems in place, but they were not very well utilized or optimized. For example, I had added all the functionality to have in-depth conversations with NPC’s and receive quests from them, yet there were only a few NPC’s. Similarly, I spent so long making it so the character could explore underwater, that I never got around to actually populating the underwater areas with meaningful things to discover. I could go on and on about each of the many features that had lots of potential, but without more manpower and refinement, never reached its full potential.
Performance was also awful and only fairly new gaming computers could even run it. I had more or less ignored this entire aspect of development. At the time, I had no professional game development experience, and never had to work with any hardware constraints.
Although it wasn’t exactly what I hoped it would be, I wanted to graduate, so the project needed to be finished. I called it “done enough” and uploaded the game to Kongregate. My comrades at Northeastern University also featured the game on the department’s homepage. Gate of Redemption was played over a hundred thousand times and received a mix of high praise and harsh criticism. (Mostly harsh criticism.) I eventually took it down due to a steep reduction in page hits and complications with the Unity Web Player.
What I’d Do Differently
My experience working on this game was invaluable. I can’t emphasize that enough. It was a deep dive into almost all parts of the development process and served as my gateway into programming for video games professionally.
So, what exactly would I change if I was to do it all again?
Narrow the Scope
I’ve already mentioned scope, but I’ll mention it again. The scope of this game might have been suitable for a small or medium-sized team, and even then I’d still make cuts.
One problematic feature was the aforementioned switch to “Hellish Mode” that occurred every night in the game. Although a fun feature, it also meant nearly double the work for each area of the game, as I had to create many new monsters, meshes, and materials. I would simplify it so only a few things changed at night and would be concentrated in only certain areas of the map.
Similarly problematic was the destructible ground terrain. This meant each area had a destructible ground mesh and a “solid” mesh layer beneath it that could not be deformed. Although this was a unique feature at the time, it took a lot of the time to set up and also caused a dramatic drop in frame rate when the actual terrain deformation was occurring (which could happen accidentally from an errant spell). I also had difficulty saving the deformed configurations of the landscapes so the land would re-form upon loading a saved game. Although I would probably exclude most terrain deformation if I were to rebuild the game, I would definitely keep the destructible crates, trees, plants, and rocks, as those were rewarding and satisfying features that weren’t too performance heavy.
The amount of dialogue choices also needed to be narrowed. The first NPC encountered in the game had a long (and admittedly boring) dialogue tree, and that length of conversation was not reproducible with other NPCs within a reasonable time frame.
Optimize
As mentioned previously, performance of the game was not great. If I was to revisit this, I’d remove most of the plants, grass, particle effects, and trees, use lower-poly models for the monsters and characters, and remove any post-processing effects. I’d also add options users to change more rendering settings.
Focus on the Core Gameplay
Combat was…fine. Seeing your opponent’s strengths and weaknesses on screen whenever you targeted them really helped add to the strategy. Being able to switch between elements to exploit said weaknesses was also satisfying. Blocking and weapon attacks were snappy, responsive, and felt pretty good. The combo system had a lot of potential to add variation and strategic depth.
The main problem with these core gameplay features was how they were introduced. Within the first few character levels, players could switch between every element and already had an overwhelming amount of spells and combos – too many to keep track of. Leveling up and allocating skill points did not require any meaningful decision-making, as you’d get multiple new abilities at once, none of which you could preview beforehand. Many of the abilities also lacked variation, and the sheer amount of abilities made it near impossible to effectively strategize. Itemization had a similar problem, as players got too many weapon and armor items too quickly, lessening the excitement of finding new treasures. Progression, in general, was a letdown.
Summary
As the seasons passed, and as life, work, and all those other pesky little things consumed my time, the technology the game had been built in became more and more outdated. The market became increasingly saturated with games and expectations for QoL features, accessibility, controller and device support, and just about everything in this rapidly growing industry changed. Even the website, which had member forums, its own wiki and more, not only became outdated but was infected with malware from a malicious hacker. Gate of Redemption was a dinosaur, and it was time to accept that it was more or less dead.
I’ve had a lot of time to reflect on this game. I used to look back at it with disappointment, as there was so much missed potential there. I believe if I had focused my efforts on the more important aspects and scrapped those that weren’t working, it would have been a pretty solid game. I also believe that if I had aggressively sought financial backing to hire an adequate team, it could have morphed into something really special.
I’ve since come to think of Gate of Redemption as a learning experience. In the years following this project, I’ve mostly worked on games that are not only smaller in scope, but that have had the support of a whole team. This game not only helped get me into professional game development and really hone my programming skills, but it allowed me to explore many aspects of game development and have a more well-rounded skillset. Furthermore, the game’s story, although pretty barebones in its original iteration, has heavily inspired the story and world of my forthcoming novel.
All that being said, I look forward to one day making the spiritual successor to Gate of Redemption. But my “dream game” of today is not the same as the one I had over a decade ago as a (naive) graduate student. Sure, the theming might be similar, and it would have a lot of the same features. But the new “dream game” is more satisfying and rewarding to play, runs smoother and on more devices, and most importantly…it’s practical and attainable.
Credits: Game Design, Story, Art and Animation, Programming