Meet The Team!
Austin Roorda
That’s me! I work with the team as the Project Manager to keep things running smoothly!
Karl Lewis
Karl is our resident Systems & Audio designer. He works like a madman to get our game to work & sound amazing!
Emmett Friedrichs
Emmett is also multi-disciplined as a designer, working with both Systems and Level Design. He helps lay out our levels!
Josh Grazda
Josh is the Programmer for our team. He specializes in Gameplay programming and makes the game work!
Adam Streeter
Quoted as saying how he wanted to create “The most aesthetic capstone game ever created” Adam is our artist. His work makes even Picasso jealous!
Recapping the Steps of Development:
Just in case you haven’t read my first blog post, or if you’ve forgotten how the step system works (believe me it’s a mess for us to negotiate too), here’s a quick recap of the system and the criteria for each step. The team has currently completed the first step, and have challenged the second step meaning that we have a concept that we want to move forward with for the rest of the semester. You’ll hear more about that soon!
Step 1: Choosing a Starting Point (COMPLETE)
Create multiple game concepts, and begin to choose what games you may want to develop in the future. Our team ended up coming up with 50 separate and fairly unique ideas, and boiled that list down to 10.
The team completed this stage of development the last time we spoke. This was when we decided on the 10 or so ideas that we wanted to consider, and then flesh that out to the 3 we want to go in depth with and prototype.
Step 2: Selecting a Concept
Choose one of those concepts to develop for the rest of the semester and give a presentation to the class explaining the rationale behind it as well as it’s feasibility and viability.
This is where the team currently stands, having challenged the step during last week’s class period!
Future Steps
Here are the future steps that the team is going to have to take in the future. I figured that if you don’t care too much about that you can skip on into how the decision making process went for the second step! Click on the titles of each Step if you’d like to read about the criteria for it.
Shape and define the core experience of the gameplay. This includes refinement in the needed documentation from each discipline as well as iteration on the prototype with game testing results.
The coming sprints after we pass the second step will focus mostly on the criteria of this step. It requires that the team really focus on on what the gameplay experience will be for the player and how we can refine enough to have a somewhat polished product.
Fully develop a proof of concept prior to the final presentation. Demonstrate the intent of the concept through a demonstrable prototype, iterated documentation as well as game testing results.
In this stage (closer to the end of the semester) the team will have a mostly feature-complete iteration of the game that was initially pitched. This includes a working prototype with most if not all key functionality working within it.
When teams reach this step, it demonstrates a fully realized vision of the initially designed idea. Not many teams make it to this stage, but those that do usually pursue release of some sort.
Many teams don’t reach this point, so it’s not required. However, the team and I have been speaking on the steps we want to take with this project and the future of the game so long as our team isn’t cut – and this is a possibility we are considering!
Moving Quickly!
It’s been a little over a month since the team challenged the first step and began working on the three prototypes that we laid out. The reason that the other games were dropped in favor of these three comes down to two main concepts: Feasibility and Viability. If the project is out of scope, not original enough, doesn’t hold our interests, or is more of a mechanic than an actual game – it will be cut. It’s all about if we can make the project with the time and resources that we have. Of the ten that we had proposed, we met and decided that we liked the concept of Cash Force, Robo Charge and Toy Deploy the most.
As a refresher for you – I’ll list the three we chose below with a quick explanation of each!
Cash Force:
Cash Force is a single player VR first-person-shooter where players defend a moving getaway van from pursuing cars and helicopters with a variety of different weapons and objects while earning in-game cash to purchase upgrades for both the weapons and the van itself.Robo Charge:
Robo Charge is a 3D, single player, third-person robot fighting game where you take control of a customizable battlebot to partake in high speed physics-based combat against your robotic opponents in a trap-infested arena.Toy Deploy:
Toy Deploy is a VR single player tower defense game where players use toys spread throughout a virtual room to mount a defense or attack against enemy forces.
Prototype 1: Cash Force
Like I had mentioned in my last blog post, we developed a rough prototype of Cash Force as we challenged the First Step. Despite the issues with Unity we faced and the general unfamiliarity with developing for VR, the team was able to create a good demo that showcases the core pillars of the gameplay. These are:
– Realistic VR Gunplay
– Engaging AI Encounters
– Plausible Game World
The team build a prototype that positioned the player in the back of the getaway van, with a few police cars within their path. We added human targets in the vehicles, as well as target discs on top of the cars to enable people to shoot at them (You can see this in the GIF to the right).
We brought the game to Game Testing to test several different elements of the game, with most of the questions revolving around how it felt to interact with the weapons and shoot them. Below are some of the Testing Results we gathered!
Game Testing Results
We wanted to know how easily players could interact with their weapons. We asked pretty simply if they could just load the weapons. It’s important to note that we had a demo of the game running with a screen projecting the game onto the wall behind the players. This way, other testers could observe a developer showing off how to do things in game and comprehend it better than us just telling them what to do. This approach seemed to work well, especially considering many of the testers hadn’t had a lot of Virtual Reality experience.
Testing the shooting mechanics as well as how easily players could shoot at targets is a large part of Cash Force’s gameplay loop. If players can’t hit targets when they aim and shoot at them, that presents a large problem.
The results indicated that the shooting was mostly where we wanted it to be – with a little more work needing to be done to get the shooting where we want it to be. Testers were noting about the slow travel speed of the projectiles, requiring them to need to lead their targets a lot further than they should be.
Bugs are the friends of developers, right? While bug testing while getting close to the release of a game can be tedious and exhausting , the early stages of prototyping and testing result in a lot of bugs that help influence development decisions.
Many of the bugs we found and were informed of were related to several key issues we already knew about. Getting the reinforcement from the testers where they tell us ‘yes, this is the issue and it impacts the gameplay negatively for these reasons’ helps us identify what we need to work on next, as well as why. We can use their testimonial to help justify changes in the design, etc.
Lastly, we wanted to see how many users would feel motion sick while playing our game. Players are seated in the back of a moving van, with buildings going by them in their peripheral vision. This effect in real life causes some people to get car sick, so we wanted to test and see if the effect would translate in our prototype.
Luckily for us, there was only one tester who felt sick, saying that they started to feel sick when they moved around. It’s important to note that this specific tester had never played a VR game before.
Overall, the first sprint for Cash Force went really well. We were able to expand on the weapon systems as well as the map movement, which allowed us to test our scene in the Game Testing labs. We tested for just basic functionality, which luckily showed that our game was functional and working as we intended. The reception for Cash Force was really positive. People loved the idea of a high-octane FPS game set in a somewhat wacky 1970’s city. The concept, as well as how the game played were key roles in this positive reception.
Even though there is still a lot of work to do – the team knows what needs to be worked on and how to go about doing it. Because of the need to prototype all three of the projects I mentioned earlier before we can choose one to develop, we’re leaving Cash Force behind for now. The next prototype that we want to work on is Robo Charge – the 3D Robot Battle Arena game!
Prototype 2: Robo Charge
Robo Charge is a 3D robot battle arena game where players pilot custom build battle robots and fight to destroy other bots. Every robot has destructible meshes that can be manipulated and destroyed by the players, making it so players can gauge their health not by a status bar, but through diegetic UI. Since this is a 3D game and not VR, the team was able to dive right in based off of their experience working in 3D before. Just like with Cash Force the team wanted to focus on fleshing out those three pillars of gameplay as we build the prototype. Those pillars are:
– Physics Based Movement and Destruction
– Robot Customization
– AI to Battle and Destroy
The team moved forward on creating a prototype that had included a battle arena with several smaller units driving around that they player could smash. To the left you an see the arena that was build by Emmett, as well as the player’s robot smashing a bot into a million pieces.
This was done using Unreal’s built in destructible components. As you can see, it’s really satisfying to smash the other bots with the hammer!
Game Testing Results:
The team wanted to make sure we nailed how the player could control their robot while playing. Integrating physics based movement was a key decision in making the movement feel like it had weight and presence in the game world.
Players were able to smash the enemy bots (like the one shown in the gif) with relative ease, with most players having no trouble smashing all of the bots to pieces!
There were several other parts of the Game Testing that I want to mention here but don’t have a good graphic to go with. Many of these questions have no definitive answer, with the interpretation being left up to the player. Some key questions we asked were:
– What did you think of the Springboard Trap? (Trap that launches both the player and an enemy into the air)
– Tester feedback and ideas for new weapons, traps and or map elements
– Feedback on concept art / artistic mock-ups of the UI screen and a possible gameplay screen
In terms of these questions we received pretty good feedback! The springboard trap, while an instant death-sentence was received well by the players for the most part. They thought it was fun to be launched, even though if they landed on their top they were stuck like a turtle on their shell. When a player lands on their back, they are unable to right themselves, which is something we overlooked.
In terms of ideas for new weapons, traps and map elements, we were given lots of inspired weapon types such as flamethrowers, buzz saws, flippers and projectile launchers. All of these things were things that we had considered from watching the original Robot Wars TV Show, which was a large inspiration for this concept.
Displayed to the Right is a mock up for the general art style and potential perspective for Robo Charge. The style that Adam wanted to go with for the general aesthetic was received well by the play testers. They stated that they liked its bright colors as well as its ease of readability, and that it fit the industrial theme that we were considering going for.
Here is the UI Mock Up that was created to help demonstrate how players would customize their robots. This was also well received due in part to it’s simplicity and how easily it can be read. Movement determines how fast you move and how you move, armor can weigh you down while keeping you stronger and the weapon determines how you deal damage. Blunt weapons bash and crush, while blades may slice and slash their way through enemies.
This was the first sprint where we started actively asking our players if they would like to play the game again. We were happy to see that all of the people who tested our game were willing to come back and play if we went through with this project.
Robo Charge’s Sprint went pretty well I would say. We were able to prototype the movement system + camera control, destruction physics as well as the AI Systems. If we wanted to go through with this concept, we have the groundwork laid out to keep moving forward and working on what we’ve created.
On top of this, we have a small but curious group of players who have opted into playing our game again! This means that if we decide to go forward with this game, we have a group of people who are willing to test the game and give us detailed feedback on the game.
Prototype 3: Toy Deploy
Toy Deploy was our most challenging concept to develop I would argue. This isn’t really in terms of it’s technical risk or even it’s genre but instead its identity. This game started out as a loose fusion of Tower Defense and Real Time Strategy, where players would put toys on a table and watch them come to life and battle it out for your own amusement. The concept needed more than that, and the team quickly got to work to give the game an identity
Josh Grazda, our Programmer and Product Owner of this idea worked for most of the sprint coming up with the gameplay design and systems with the other Designers, Karl and Emmett. By the mid point of the sprint, we finally nailed down what this game was and how we planned to go forward with it.
After the work was put in to help define this concept and work it into something a but more substantive, the team got to work on what we were bringing to the Game Testing Labs – a presentation. This presentation was a condensed pitch of the game that explained how the player would interact with everything, how units worked as well as upgrading and combat. Since we wanted to spend the first half of the sprint refining what this game actually was, that didn’t leave us enough time to actually work on a prototype for the game. This is why we opted to pitch the concept to people first, rather than crunch to try and create a demo that would convey the same information. The presentation was brought to Game Testing, and we asked players a series of questions to determine their interest in the concept and understanding of how to play!
One of the first questions that we asked to our testers was if they played virtual reality games. Many of the testers said that they didn’t – but were also curious on purchasing a system for their own personal use. People were also considering playing more VR games if they had a system, which is important to note for the barriers to entry to the VR market.
We also asked our testers what types of games that they played. We were assuming a lot more MOBA + FPS games based on the demographics here at Champlain College, but were surprised with the results. A majority of the players were playing RPG games or Action Adventure games, which came as a surprise to us. Luckily, there was a decent amount of testers that were playing games within the Tower Defense genre, which was of interest to the development team.
It’s also important to note that the core concept that lies behind Toy Deploy is well received by those who tested it. All of those who were testing were at least somewhat interested in the concept, with many stating that they wanted to learn more about it and how it was going to function.
On top of what was stated above, it seems like taking the time to refine the concept really worked! The testers loved the concept and wanted to learn more. The graphic (right) shows that all of the testers were interested in the concept of the game. This is a good sign, considering the possibility of future development.
Toy Deploy is by far one of the team’s most interesting concepts. Between a fusion of Tower Defense and an Auto-Brawler and making a compelling VR game – Toy Deploy seems to have a lot of promise to both testers interest and the feasibility to the team. Making sure the project is feasible and viable is important, and is something that the team must make sure before an outright decision is made.
This was the last prototype that the team decided to work on before choosing one to develop for the rest of the semester. With that being said, let’s jump into the decision we made as well as the rationale behind it and see where we’re at!
The Final Choice!
The team was tasked with choosing one concept from the nearly fifty that they had come up with to go forward with for our Capstone game.
While there was many things that the team had considered and debated, we managed to come to a unanimous decision on what game we wanted to create together. In the end we decided that the game that met our own personal criteria, as well as the game that we believed to be the most viable and feasible for the future was Cash Force!
Before I discuss we chose Cash Force, I want to discuss all the games and their merits as well as the rationale behind why we decided to not go with them. Let’s start with the 2nd game that we worked on over the course of prototyping – Robo Charge
Why Not Robo Charge?
Robo Charge was the 3D Robo Battle Arena game that the team worked on during the 3rd sprint. While we really liked the concept and how interesting it could be to create that experience – there were several large reasons for not going with it.
As a team, we wanted to create something that we hadn’t ever created before. Virtual Reality was something that only Karl had experience with in the past, but now that we had all taken the plunge and learned how VR worked, we wanted to keep working with it!
We were also made aware of the amount of market saturation there is for games of this style. Considering how many 3D Robot Battle Arena games there are on the appstore, PC’s and Console markets it would be tough to make a game that competes with these titles. It’s also important to note that many of these games have the same selling points as Robo Charge, telling players about how they can destroy enemies piece by piece, customize your loadout with new weapons, wheels and armor pieces, and so on.
The scope of the game was also extremely small, considering how much potential time the team has given a second semester of development. We made the choice to not go with Robo Charge because of it’s limited scope. We estimated how much content we would want in the game and came to the conclusion that we could get pretty much everything into the game that we wanted before the Mid-Mortem cuts.
We decided to cut the project not due to an issue with scope, or issues with feasibility – but because it was less viable. Given the lack of content we could add after an entire semester of work, we started to realize that this game had no real future after this semester of development if we went through with it. There was also dropping interest in the concept after working on it during the course of this sprint, with a lot of the team craving to do something more akin to what was achieved with the first VR Prototype that we worked on, as well as something like Cash Force. We decided to leave Robo Charge behind, and forward to our next game!
Why Not Toy Deploy?
Toy Deploy has been something that I personally didn’t know how to feel about pretty much all the way up until the last minute. While not a bad concept, the way it was initially pitched never really captivated me or engaged me as much as the others. However, once the team dove deep into figuring out what the game actually was and what it needed in order to become viable – it became clear what the game was.
As the team worked, the more we all realized how large of a scope this game had compared to the others. The AI System(s) as well as unit and item balancing, two separate and distinct interactable spaces. We came to realize that the scope of this game (especially from a programming / technical side) was very large.
As the team currently stands, Josh is our only programmer. If we wanted to achieve even a lower fidelity prototype, we would need additional team members to make that happen – which we can’t get unless we move past Mid-Mortems. On top of this, the systems needed are complex AI systems like I mentioned earlier. We couldn’t realize or achieve the prototype we wanted with just one programmer, so we made the decision to shelve Toy Deploy due in part to it’s scope and being shorthanded on relevant staff.
That Leaves Us With...
So why did we go with our first idea? We ended up discussing both the feasibility and viability of each project and realized that we all had a shared interest in Cash Force. It was also the game that helped us to achieve our own, personal goals for the semester. Karl wants to work on the realistic weapon interactions and sound effects. Emmett wants to hone his skills as a level designer, Josh wants to work with AI and AI Interaction.
Adam has been quoted saying that he wants to create the most aesthetically unique capstone game to come out of Champlain College. I personally wanted to create a game that I know that I would want to go out and buy for myself if I didn’t make it. Shooters have always been a go-to type of game for me, since I love the fast paced and frantic action that comes to life during gameplay.
As the producer for this project, I couldn’t just say that I liked the concept and that’s why we should go with it. I needed to work with the team to help figure out what game was the most viable for us to approach and the rationale behind it. After close to two hours of discussion we came to a conclusion.
The concept behind Cash Force has yet to be explored in VR, with only a few games actually coming close to the experience we wish to deliver to players. The engaging gameplay that could be made using the weapons and weapon interactions was another thing that interested the team. Making the weapons engaging and entertaining to use is something the entire team is interested in as well. That interest carries over to every aspect of the project, from the level and weapon designs, the needed programming infrastructure and art style. As the producer for this project, I’m excited to see what the team creates!
Final Thoughts!
Overall I’m excited to see where this project goes over the remaining duration of the semester. After finishing our sprint planning earlier in the day today before I posted this, I was really excited to see what we were all working on over the course of this upcoming week. I’ll keep everyone updated on that and plan on posting to this blog a lot more.
These last few weeks were a lot of fun, experimenting and prototyping vastly different concepts but I am glad that it’s over and we can just focus on one project. The constant switching from concept to concept between the projects was really confusing and made for a hectic atmosphere. On top of that, we weren’t able to use agile as much as I personally would like to since there’s no way to plan for a future sprint that doesn’t exist yet an may not.
Here’s to the next sprint, and all of the awesome content that comes with it! I’ll be posting back here soon, once we challenge the next step towards the end of the month.
Talk to you then,
~Austin