Updated: Apr 8
Hello everyone, my name is Taban Lewis Producer and Designer of Run N' Gun. I am back to talk about the second half of the development for Run N' Gun and we have a lot to cover. First off if you missed the first blog post you can find it below.
Part 1 of the Run N' Gun (RNG) development cycle lasted from September 2021 to November 2021. We made a game and established our core gameplay loop we had one enemy working, two weapons, six augments, and, one level. This would be our vertical slice and it ended up looking like this.
Since then the game has bloomed into something wonderful and in this blog post, I will be discussing the changes, Eureka moments, and failers. sadly this blog post will have fewer behind scenes looks into development because we were all so focused on the game itself and will take a different approach to format unlike the first. why this post will also take a look at some of our documentation you can find and look at all our documentation including our Game Design Document(GGD) below.
Winter was our holiday break and during this time we spent a lot of time planning and reworking the game for when we started back up in January 2022. So winter took place in December 2021 and the second half of development took place from January 2022 to March 2022 you can get a quick rundown of changes to the game in the video above.
Why the first half focuses on the gameplay loop we still had things we wanted to add and with that in mind content was going to be a big focus for us. So I got to work starting with a production plan we wanted a second Level, more augments, add our three remaining weapons, a new enemy, and to re-add the drone, Voice Lines, more sound effects, new ways the player can use the environment, rail grinding, more visual effects, and finally a boss fight. Why all of these features did not make it into the game like the boss fight most of the features did but before I continue to talk about more of my work and show off some of the documentation let's talk about what small changes happened over winter.
Collin our 3D modeler made a new pistol model and Sally our artist textured it. Carlos our programmer made drastic improvements to the game as you can see in the winter video adding wall running improving AI and tweaking movement. They also changed the level making it flat instead of a dome as we found why looking at playtesters the dome was just not working. We also finally got some arms/hands in and a lot of improvements were made based on feedback we received.
In winter I had meetings with all my team members and learned my lesson and came to some new revelations. The first is that my artists need references to work off of. Concept art helps us, so I talked to sally and sent her some references to make concept art. Collin got to modal the Sniper Rifle and our powerful weapon the Sword. The second was that I wanted to stylize the game. Borderlands, League of Legends, and even new games like Elden ring all have their style and that makes people recognize their games. RnG needed that boost in the art department so talks began on how to achieve that.
In the first week, Sally got back to us with the concept art of the Sniper and the Sword. However, knowing that we are adding a lot of new content that needed to be designed for our programmer to implement I had to update the GDD with a new section on how the new weapons work, and what fantasy they fulfill the same goes for for our new enemy.
Because this section is going on longer than I anticipated and I will talk a lot about these new systems in upcoming sections this will be brief. Above you can see a page for our boss fight, three-level blueprints, a trap design sheet, the augment sheet, and a page from our GDD. Learning from level 1 we need a layout for level 2 and I wanted to be more like an FPS map than a skate park. So I came up with three blueprints and had a meeting with Tommy our level designer. I also reworked augments which would be reworked again mid-project and sadly like the boss fight a lot of the new augments did not make it to the final build.
As you know our enemies are a big part of our game. They provided the challenge and in return make the game fun and it has been an epic journey (mostly for our programmer) to make fun engaging enemies. Carlos our Programmer spent a considerable amount of time on enemy AI it was our main challenge and I think you can see how it has evolved through the first blog post and the videos for the game.
First, let's talk about old enemies why I may not be the best at explaining the technical side of our enemy I do think I have a good understanding so here we go. Old enemies' lifespan was from our prototype to patch 0.60 of our beta. Our first enemy added to the game was the Drone which was then taken out and was not re-added till patch 0.80. The Drone caused major performance issues and had major tracking problems so we were not happy with it in the game instead we focused on the Walker.
Old enemies in terms of scripting were one big script that was checking multiple things at the same time this is why AI was very slow and did not allow us to use cool tricks to make them smarter. All they did was chase you around and flee when they got low. As a designer, I also did not have a lot of debugging options or control over the AI as seen in the tooltips above. The flee state needed to be added for the new enemy the Trapper and why it worked, it was buggy and needed consistent tweaking.
Why old enemies were fine and fulfilled the purpose of our game they were limited in what they could do. They acted as basic zombie AI and we could have stopped there but we wanted our game to be the best, Carlos through trial, error, and research found the way modern AI is done.
In patch 0.60 we add the new and improved enemy AI. Now enemies will chase, flee, wander, flank, and make the player's life difficult by using its new and improved intelligence. So how did we do it well instead of running all that code in one big scrip we split it up into a state machine.
State machine work using Enums in Unity3D C# scripts a state would be for example as you can see in the photo chase. In chase is all the code to tell the enemy to chase the player down and when the player is in range to attack the state then switches to attack but when the player looks at the enemy the state will switch to flank and it just keeps going from there.
As a side note, I probably should have known this is how you do it since one of my previous projects used enums and states for a turn-based game. Here's the tutorial I followed it's very well done. However, the new AI came with a new set of problems with our animations. Carlos and Collin had to go back and rework old animations to fit the new AI we had to go back and fix a lot of mistakes we had because we now have the knowledge to do it properly.
moving on, having this new AI improved gameplay and control as a designer. It allowed us to set up nicely for our there and final enemy.
Welcome the Trapper bot added in patch 0.70 this little guy was designed to be a pest. Why the game has a weak flying Drone to horde and overwhelms the player as well as the Walker to act as the main calvary, I wanted some type of support unit. This Unit would never attack the player would help the bots out, and drop a variety of traps in its wake. I Designed this enemy in the winter and you saw pictures in the winter section all of the art concept and visual design was done by Sally and Collin.
Overall all enemies saw major overhauls and the trapper was a fun addition that made players switch up how they play the game. I am super happy with the state of enemies and if we were still developing RnG I would add new enemies and improve their behavior even more. However, I can say that about all aspects of the game and I only dream of what the boss AI would be like.
Weapons for a Champion
At the very start of development, our pitch included five Weapons and the shotgun was modeled and textured In the first half of development. The other two weapons were of course already had concepts so we just had to make them and implement them. Because of all the prep we already did getting the weapons in-game was relatively easy the hard part came from getting our weapon to fulfill their desired fantasy.
General Weapon mechanics
Medium fire rate
High fire rate
Does bonus damage to armor
High damage when close
Medium damage when far
Medium fire rate
Fire in a cone
Does bonus damage to armor shields
Low fire rate
MB2 zooms into the scope
When out of charge the player must pick up a new powerful weapon. The power weapon does not recharge like other weapons.
it is removed from the player and it can't be equipped until the player picks up a new one
MB1 to swing/attack
Above is our weapon fantasy from our GDD and I think we nailed it with each weapon fulfilling a role. During playtesting, players were switching between weapons to deal with their current situation and why some lean more towards the Shotgun (like in any game,) the Sniper was used for long-range and the Assault rifle was used more mid to long-range and people found the sword super fun to use.
A lot of QoL went into the weapons, Carlos and Colin got a liquid shader to work instead of the normal lights to tell the player the ammo count. I worked on the animations and feel/balance of all of them to make sure they meet our standards. Originally the player was only going to have one weapon and the Pistol and had to swap out between the Assault Rifle, Sniper, Shotgun, and Sword but based on feedback and how the waves ended up being balanced we decided to scrap this feature.
Breathing Life With VO
First off shout out to Drew who mixed and engineered all the audio for the game and a shout out to Alex who did all the voiceovers. With the help of these two making our audio was super easy (implementing it not so much.) We had systems in place that worked very well. for this class, the audio team worked independently of the other game dev teams. They were more like contractors than members for us. Whenever we need a new sound all we had to do was let Drew know and update our SFX asset google sheet. We ended up with around 100 to 50 SFX in our game and I don't think we used all of them.
At this point the game had audio but it felt dead, It needed life. You were in a stadium but had no announcer, Robots ran at you but they did not feel menacing. (we also had a crowd cheer but no crowd more on that later) The game needs Voice overs and of course, at the start, no one was thinking about how to do it. We and one other team had VO in our game and I know they had problems recording at first. Depaul is not very good at cross-media( like at all) why do we take classes like audio 101 or animation 101 we don't get access to the motion capture studio that they have (I think they have one) and the recording studios. You have to be certified to even use that equipment and the teacher can't supervise you.
As a side note this class, our final thesis capstone class is only twice a week for an hour and 40 minutes. It is worth 4 credits the same as a normal class and is the only class I have taken where you need to be approved to do the second half of it by the teacher in the next semester. In short, we made this game with little to no resources from the school the only thing I thank them for was version control Perforce.
Getting back on topic VO was a breeze for us because I came prepared. In the first half of development, I saw the GDD talk Breathing Life into Greek Myth: The Dialogue of 'Hades' this video help me plan out what VO lines we needed. So like anything, I made a google sheet outlining the lines and how to integrate them. Next came recording and I have been recording voice with my podcast It's Not A Sport for five years now. I called up my friend Alex and we got to work, we ended up recording maybe about 100 or so VO total. Why the announcer VO was more planned the Robots were completely Improvised when we were done I sent it to Drew to mix and we ended up with the final product.
Reworking Level 1 Arena
I touched on a bit on level 1 in the winter section but the first major change we made was to remove the dome. The dome why cool made it so the player would just kite around it and never interact with the skate park. It also causes problems with the collision and AI navmesh. The next change is making the catwalks not holographic as we recived a lot of mixed and confusing feedback regarding the catwalks.
From here the level is split into two parts, reworking the play space and building the world. In Patch 0.40 we added grind rails it was something to add the skating feeling and so the map need to complement this new mechanic. The level became bigger to complement the removal of the dome and Collin, now been done with modeling took up the mantle of reworking level 1 based on feedback.
Finally Using the power of the Unity Asset store and working with sally I started to build the world for level 1. it was going to be a night-time level based in a futuristic Tron-like city with an arena atmosphere. One problem we ran into is that most assets on the store are not made for Unity's new render system URP this issue arose much more in level 2 than 1 but we could work around using our holographic shader. Sally made a crowded cheer animation and Collin/Tommy continued to make tweaks. from there it was just about polishing the look of the game.
Stylizing Run N' Gun
One day I was consulting with my father and he said the game need a style later that week I was Playing Genshin Impact (questioning Life and thinking about how bad that game's design is and why anyone plays it including me) and I got to thinking. I know that that game is made in Unity and I wanted to know how did they get this Zelda: BoTW/anime look to their game so I did some research, enter the world of shaders, and post-processing.
After about two weeks I find a very well-developed toon shader called Unity Toon Shader (Unity-Chan Toon Shader 3). Toon Shaders or Cel shaders are a very popular type of shaders that come in a variety of versions. Some make the game look more like a cartoon while others make it look like anime and we are leaning towards a cartoon look. A toon shader interacts with the game's lighting and adds an outline to the object you can see it in action with our enemies and weapons.
I spent about two weeks looking into and making my toon shaders and what I learned is that they can be simple or super complicated. At the end of the day, Unity Toon Shader (Unity-Chan Toon Shader 3) Is cool and I wish I had more time to experiment with it. The next big thing I added was post-processing. Post-processing adds all the camera effects, for example, vignette, bloom, motion blur, and field of depth. I and Sally spent hours tweaking post-processing for both levels 1 and 2 to give the game the look and feel we wanted. One lesson I learned is that post-processing is your friend, in our dev team members had issues with effects like bloom, motion blur, and field of depth. I also when playing games turn off post-processing effects mostly because I never understood what those effects do. However, when I got to experimenting with post-processing and all the other effects I haven't mentioned you can see how post-processing affects the game and enhances the art and player experience.
Wastelands of Level 2 Facility
Level 2 was a challenge mostly for me it was planned from winter with the blueprint/layout was already made as seen in the winter section. Due to poor planning and miscommunication within the dev Team, level 2 almost did not make it into the game. Why level 1 went through maybe 10 iterations level 2 went through about 3 and was made almost entirely within the last 2 weeks of the project. This is why I think players find level 1 more "polished" and suitable for gameplay than level 2 but find level 2 more pleasing aesthetically.
I want to focus on the word polish it was a word said a lot during this development cycle because from our vertical slice the gameplay was already there. All team members spent the majority of their time polishing the game from bugs, code, art, level 1, game balance, animations, and so on. However, as we got closer to our final due date of March 15th and members' anxiety and fear started to show because we are all trying to make the best game possible. The word polish became a bad word for me because people would say it without questioning what it means to polish a game and what needs to be polished. As the producer, the final weeks leading up to the deadline are our most stressful times. We have to make sure everyone is doing their job and that each aspect of the game is finalized.
At this time in the project, I was stressing out that Level 2 was no were near completion and I had members fighting me on the final vision of the game. The producer has to manage the project well and at some point, start to become an ass you can't please everyone, that is the lesson I learned.
The idea for level 2 was that it was an overgrown abandoned facility or lab. The map would be more in line with a traditional FPS map Inspired by Valorant, CS: GO, and CoD. Tommy our level Designer augmented the blueprints and got to work blocking the level. Blocking(photos above) is the part of the level building prosses where we place the building is in the play space to see if they work, It's like building the frame or foundation of a house. After blocking we start to model the building, add art and populate the world/level.
However, due to the issue stated above the responsibility of level 2 fell on me. Why other members wanted to cut level 2 or wait till it meets their standards, I was hard set on having a second level and so level 2 never received the level of "polish" that level 1 did. I spent 2 weeks remaking, tweaking, looking for assets, and building the navmesh, among other tasks. I did receive help from my team especially my artist Sally. She helped a lot by doing a lot of the texturing and props. My friends also help by telling me how they think I should improve the play space since I lack feedback/playtesting, the top tunnel was my friend's idea.
At the end of the day, I think level 2 was a successful learning experience for me. I learned new things both in and outside the game engine. The level itself has its issues regarding performance and gameplay but it is something new and different. All the other games in our class had new levels and I still think our game needs more content. we could keep polishing the game but Riot Games has been Polishing League of legends for 12 years now, nothing is ever perfect.
Steam has been a goal of mine since the inception of this game and like anything you just have to do it. To have a game on steam means that your game is legit the real deal and why anyone can achieve this, the process of publishing was pretty easy. At this time development was over Digitial Delights has disbanded and the Final version of RnG 1.0 was released to our classmates. However, I did say to my team that I wanted to publish the game on steam, of course, they were on board because it's all good for our resumes and pursuing a career in this field.
First I had two obstacles the first was the legal side of the game. I had to look into licensing for all the programs and assets we used to develop RnG as well as Valve's legal contracts to publish on Steam. This did not end up becoming an issue because I planned to release my first game for free. The second issue was Steam's 100 dollar fee which was also easy to solve since everyone wanted it on steam.
Steam requires a build and assets for the store page, Sally was nice enough to help me with art assets for the store. The store did fail their requirements a couple of times but steam works fast and this took maybe 2 weeks to complete. The build of the game required me to go back into the pit of research to add Steams SDKs to our game. The SDKs lets the game integrate with Steam and luckily for me some nice people made a unity version of their SDKs.
With that, I am proud to announce that on April 14th, 2022 Run N' Gun officially comes out on steam for free. It has been a long journey but I hope you all enjoy Run N' Gun. Look forward to my next game.