During my time at Northeastern University I chose to make a game for my capstone project. Gate of Redemption was a large, open-world 3D role-playing-game made in the (then) new game engine Unity, and written in a combination of JavaScript and C#. It was an attempt to incorporate as much as I could from what I learned during my time at Northeastern and NMSU while featuring many of the things I personally enjoy most in video games — exploration, deep lore, and strategic combat . 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.
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. When I wasn’t working a part-time job, training at the gym, or running (I was really into long-distance running at the time), I split my time between texturing, animating, 3D modeling, sound design, 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 and the art style of the game.
So…What exactly was Gate of Redemption?
Basically, this was 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. I wanted to recapture the excitement I felt exploring the vast open worlds of games like Everquest, and the thrill of uncovering secrets in games like Zelda. The art style was influenced by my own painting style, and by gothic-themed games like Castlevania.
The game not only looked pretty (in my opinion), but it was filled with many secrets, rare items, strange monsters, action combat, and a story involving a fantastical afterlife world. 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 the combat system allowed for a fair amount of strategy.
The action combat system was inspired by the Elder Scrolls series of games, so timing attacks and blocks was important. I also incorporated an “elemental weakness” system in the vein 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 or beneficial healing spells.
A World to Explore
What I always loved the most about MMORPG’s and RPG’s in general was the exploration. I loved finding new secrets, spotting rare creatures and finding unique equipment.
Here’s a little more about the specific gameplay mechanics I built to help facilitate exploration:
–Destructible environments and objects. Smashing open crates could produce coins or items, and chopping plants and trees would grant you healing herbs or crafting 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.
–A fluctuating world. Aside from normal day/night cycles, the landscape itself shifted to a hellish nightmare at midnight. Peaceful creatures despawned and were replaced with demons and skeletons, trees lost their leaves, and lakes shifted into treacherous lava pits. Night time had its own secrets to find and places to explore.
What I Learned
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 and designing video games professionally. However, it was never a realistic project, and now comes the part where I talk about what went wrong, and where the game fell short.
As a student, I really had no idea what I was getting into. One person, no matter how driven and ambitious, can only do so much. Work became more demanding, bills needed to be paid, and I had not been aggressive enough at seeking funding. After all, trying to do this took time. LOTS of time.
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 sub-par and only fairly new gaming computers could even run it at a reasonable frame rate — a big ask for a game that was playable in a web browser. I had more or less ignored this entire aspect of development, as I had no professional game development experience at the time, and never had to work with hardware constraints.
Winding down…
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 on Kongregate 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.
I’d done a lot, and created some mechanics that I was very proud of. Ultimately, however, the game wasn’t what I wanted it to be and essentially died before I had the opportunity to get it to a place where I was happy with it. The Unity game engine was also changing quickly, and I reached a point where I’d open the project and a large portion of it was broken. I decided to focus on other aspects of my life and my new career at the Learning Games Lab at NMSU, and finally lay Gate of Redemption to rest.
Now that I’ve had so much time to reflect. What would I do differently if given the opportunity to work on this project (or a similar project) again?
What I’d Do Differently
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. The story should have been titrated throughout the gameplay, and presented in a way where it wasn’t just an exposition/lore dump.
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 to users so they can change more rendering settings, making the game more accessible for lower-end sytems.
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. 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 blinked in and out of existence and only a handful of people at Northeastern University, a few of my close friends, and smattering of Kongregate users even noticed. Just like that, my dream game was gone. Poof!
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 (as I outlined earlier) 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 through crowd-funding or some other means, and hired a small, dedicated team, it could have morphed into something really special.
Of course, while it is easy to dwell on what could have been, negativity doesn’t benefit anyone. I’ve since come to think of Gate of Redemption as a learning experience. An invaluable and immensely beneficial 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 upcoming novel. The religious themes, the moody and atmospheric fantasy environments, and stories involving inter-dimensional travel and/or monsters has continued throughout much of my personal work.
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