Three Weeks, Three Games
Over the past three weeks since the last time I posted, myself and the other team members of Holo Hexagon have been nice and busy working on rapidly prototyping three unique game concepts in order to find out not only what we want to get out of our capstone experience but also to ultimately use what we learned from the prototypes as well as our own goals to chose one concept to move forward with for the rest of the semester (and potentially the rest of the school year). Starting at week 3, we focused our efforts on rapidly getting the core pillars of each concept in a playable or easily conveyable form. We then took each concept to the game testing lab to receive feedback on the concepts and their gameplay pillars, as well as to help ourselves come closer to reaching a conclusion about which game we wanted to move forward with. It was a long and often stressful process, but now that we’ve protoyped each concept and decided on our final game to move forward with, I think we’re all very excited to get into the groove of working on one game again and going full throttle!
I’ll be breaking down each prototype, its core pillars, how we went about prototyping these pillars, and the results we took away from the testing lab as well as the prototype in general. Let’s get into it!
Week 3: Cash Force
Our first prototype was Cash Force, which is is a 70’s themed VR shooter where you play as the gunner of a fleeing van from a successful heist. With an arsenal of weapons at your disposal, protect your loot from a dynamic world of enemies trying to get their cut of your prize. With some smart planning and well placed shots, you just might be able to make it to your safehouse in time.
I talked about this week of prototyping in my previous post as well, but I’ll go over the core pillars again since we’ve updated them a bit since last time.
Gameplay Pillars
The first and perhaps most important pillar of Cash Force is the VR Gunplay mechanics. One of the things we all love about virtual reality is the increased sense of immersion it provides, particularly through the interactions players can make with objects in the world using motion controllers. With this in mind, we wanted to take the realistic weapon handling and shooting mechanics seen in other VR shooters and streamline it to be intuitive and easy to use for all users. In Cash Force, players will need to physically load their weapons with ammunition and then operate the action of the weapon to finish the loading/reloading process. These interactions will not only heighten the experience’s sense of immersion but also reward skilled players that learn how to quickly unload, reload, and operate the weapon’s action in between shots.
The second pillar is a Dynamic AI system that ensures that players of any skill level can easily pick up and enjoy the game. AI enemies that adapt to each player’s skill level will not only keep experienced players on their toes with exciting new challenges but also allow inexperienced players to naturally progress from novice to master. This will also keep repeated playthroughs fresh, as the AI reacts to the player’s individual performance.
The third and final pillar is Procedural Level Generation. Players will have a chance to plan out their route through a level before starting it, at which point the environment will generate procedurally. This coupled with the Dynamic AI system will ensure that no two playthroughs feel the same, increasing replay value and encouraging players to play through levels to earn more rewards and upgrades for their gear and the van.
Process and Testing
When planning our sprint around prototyping the concept, we decided to focus mainly on the shooting aspects of the game as well as some concerns about the reverse movement system. We created a basic shooting and reloading system for two weapons; a pumpable shotgun and a magazine fed sub machine gun. We also created a functional but buggy grabbing system for two handed weapons and movable components to test. After making a little test scene with cars and targets following the player in a backwards moving van, we took the game to the testing lab to receive feedback on our main concerns. We mainly wanted to see if the shooting was usable, or whether or not the testers could actually hit the targets, as well as some concerns about motion sickness for the reverse movement and the usability of reloading and grabbing.
We found that players were able to understand the controls rather quickly and didn’t have much difficultly picking up, loading, and shooting the weapons. Some of the testers were completely new to VR and were still able to easily use the guns, which is a sign that the game is simple enough to be picked up and played. A lot of the testers told us that they loved the concept and had a lot of fun playing the prototype despite its rough edges and brevity. The most important takeaway is that our players were able to not only understand all of the interactions but also easily use them to achieve the goals of the game. Overall, we all really loved working on this prototype and learned a lot about how to work with Unreal and VR in general, giving us confidence that we could actually pull off a VR game if we decided to pick this concept.
Week 4: Robo Charge
Our second prototype was Robo Charge, which is a third person arena combat game where players customize a a combat-ready battle bot to crush waves of enemy bots. Utilizing destructible robot components and environments, players can use their robot’s parts to smash, destroy, and trap their enemies with a variety of unique weapons, armor, and other parts to create a personally tailored playstyle
Gameplay Pillars
The first pillar of Robo Charge is the Destructible Physics robots. Using Unreal’s built in mesh destruction, we wanted to create a satisfying combat experience where parts of robots – both friendly and hostile – would react to damage physically, exploding into hundreds of little pieces after receiving enough damage. This would give players the feeling of power that arena combat games aim to provide. It would also create a layer of strategy, as certain components of robots could be targeted and destroyed to disable certain functions.
The second pillar is the Customization system that allows players to tailor their robot’s parts to their own playstyle. Players can choose parts that focus on more armor but reduced speed, heavier hitting weapons that provide less armor, or light armor that provides speed but leaves key parts exposed. Using information about the upcoming waves of enemies, players can also tailor their bots to exploit the weaknesses of their enemies, providing them with a sense of satisfaction from figuring out what parts work best against which enemies.
The third and final pillar is the AI system. Since the game is focused around smashing and slicing other robots to pieces, the game would need several unique AI enemies with their own behaviors and unique features to keep players engaged.
Process and Testing
We planned the majority of this sprint around figuring out how to implement the destructible meshes into the game, get the vehicle movement up and running, basic combat and AI, as well as a conceptual image of what customization would look like. We had to do a lot of research into Unreal’s wheeled vehicle component in order to get physics movement setup, but once that was done, we quickly made a basic hammer attack, a test arena, destructible meshes, environmental traps, and some basic AI to smash.
We took this scene to the testing lab to again test the usability of the mechanics, mainly the steering and the attacking controls, as well as feedback on what the concept offered in general. Focusing on usability in this early phase of development would allow us to see if our core pillars were in place correctly and if players could actually achieve the goals set by the game.
Testers generally reported that the movement of the robot was a bit difficult to control, meaning we’d need to do a lot of tweaking to get that feeling right. However, the testers did enjoy destroying the basic AI bots and seeing them explode into little pieces. As far as usability, players were able to complete the goal of destroying the bots and navigating around the arena despite the buggy controls and stiff movement. The testers also really enjoyed the concept and seemed to be having a good time when playing, meaning the concept had a lot of potential. Overall, we took a lot away from this concept in terms of learning how to best leverage Unreal’s features and tools for any of our games, not just this one.
Week 5: Toy Deploy
Our third and final prototype was Toy Deploy, which is a VR game that combines elements of the tower defense and autobrawler. The game aims to recreate the feeling of playing with toys as a child, with the imaginary elements being actually played out in real-time on a table within a virtual room. Players would walk around the room and pick up various toys with motion controllers, placing them on the table in order to attack enemy toys and defend their own base. Players could make strategic decisions about which units to use, with freeform combat allowing for units to be swapped in and out on the fly during battle.
Gameplay Pillars
The first pillar of Toy Deploy is the VR Object Interactions. The game would leverage VR technology to be as highly interactive as possible, with various different objects to pick up and use such as the toys/units themselves, weapons to throw at enemies during battle, and more. These interactions would be as streamlined as possible to ensure that the game feels natural despite its strategic complexity.
Speaking of strategic complexity, the second pillar focuses around the potential for player developed Strategies to emerge as players explore the room and find various new toys to use in battle. As new toys and upgrades are found in the room, players can make moment to moment strategic decisions about what type of units they’re deploying and react accordingly. The more players explore the room, the more they will be rewarded with an increase in strategic depth.
The third and final pillar is, similar to Robo Charge, a complex AI System. Having complicated yet predictable AI characters would keep players on their toes, causing them to constantly make strategic decisions about which units to use or whether to upgrade a unit or not.
Process and Testing
We had to take a different approach for protoyping this concept than the previous two. During sprint planning, we realized quickly that this concept has a lot of scope to it and would take more than just one week to get anything playable that would accurately represent the concept in full. We also didn’t have as clear of a vision about the moment to moment gameplay experience. To compensate, we decided to create an animated simulation of the gameplay loop and how players interacted with various objects in the game. On the upside, we had far more time to research how we would actually create these mechanics if we decided to go through with this game, including procedural map generation, AI, and VR UI. We took the simulation to the testing lab to get feedback about the clarity of the game’s loop and concept.
We were rather surprised with the results of this test; all of the testers understood the game and its systems after watching the simulation, with the majority of them saying they had absolutely no trouble understanding the game loop! This indicated that the concept does actually have a lot of potential and is easy enough to understand at a basic level, even to non-VR users which made up a large portion of the tester base. However, because of the immense scope of the game, we still had a lot of concerns about whether or not we could actually create a vertical slice of the core experience before the end of the semester.
The Decision: Choosing the Final Concept
After three weeks of rapid prototyping, research, and conceptual documentation, it came time to decide as a team which of our three concepts best met our personal goals for capstone as well as which concept was the most viable and feasible of the three. We deliberated about the pros and cons of each game at our sprint planning meeting following the presentation of our last concept, eventually deciding that we should pick the game that we were all passionate about creating; what concept got us excited to talk about? What concept did we keep coming up with cool new ideas for? What concept did we think seemed the most fun to not only play but spend hundreds of hours in the coming months working on?
We discussed these criteria on both a team wide level as well as an individual/disciplinary level. Each of the team members expressed what they wanted to get out of this project. My own personal goals for this semester involve designing systems that are highly interactive and feel good to use, with hopes to further refine my skills as a systems designer. I also set the goal of working with Virtual Reality, as I believe it really is the next big step for the game industry and think that getting experience working with it will be very beneficial as I break out into the game industry this coming May. As far as my game audio hat that I like to wear on the side, I wanted to create a very stylized sonic style for a game that made it stand out from the realistic sounding audio of most games nowadays. Finally, I wanted to work on something that would have a lot of complex and intertwining systems that work together with each other, e.g a progression system that is interwoven with a combat system. I’ve been dying to work on a really complex game since I got to Champlain, and there is no better time than right now to flex my skills as a game designer by creating systems that all work together in unison while still being integral to the experience.
With this in mind, I found myself most interested in working on Cash Force, as I had an absolute blast working on the prototype and could brainstorm endlessly about new systems like progression and upgrades that would make the experience really engaging and content heavy. It’s also not only in VR but also a first person shooter. My peers that know my game taste know that I’m a big first person shooter guy, so it was only natural that I decided on this concept. The rest of the team shared similar sentiments….as we all came to a unanimous decision to pick Cash Force as our final game!
Week 6-7: A Fresh Start on the Backend
While continuing to work on the documentation needed to pass out of this step of capstone, we had a week to work on our chosen project before actually challenging the step, I couldn’t wait to get started working on Cash Force again, so we wiped the repo and started with a fresh project so we wouldn’t be weighed down by our quick and dirty prototype code. I did a little bit of work on improving the grabbing system during week 6. Once out of step 2, I went full force this past weekend on making the grabbing system fully functional and feeling as good as possible. While there is a bug or two with it still, the weapons are easy to pick up, hold with two hands, and use! I also started working on some backend stuff for the weapon component interactions. Most of this part of the past two weeks was focused on researching the best way to do this feature, which eventually ended up being a custom scene component in the guns that moves when the controller is grabbing.
The next coming week will see us transitioning to working on the shooting and reloading aspects of the game first since they’re more important. Myself and Emmett will also continue fleshing out the design of the game on paper, with design documentation, systems list, and audio specifications being drafted.
Reflection
This step of the capstone process was extremely productive and exciting, although there were some parts that I really just flat out didn’t enjoy too much. As a team, collaboration was absolutely fantastic as always. Our communication and collaboration as a team has improved from the already great standard we had, with much more communication happening in person and in our online discussions. Meetings have been far more productive as well, with fewer and fewer distractions. We did have some difficulty with communication during the Robo Charge week since I was in San Jose for Oculus Connect and Emmett was at home, but that was the only real issue we had.
Our processes and decision making have continued to further improve. The deliberation we had when picking the final concept for example was extremely productive, efficient, and ensured that we were truly taking into consideration all the things we had learned over the past couple weeks from each of the games. I think the final culminating factor being about what we each want individually and where our passions lie was a really important part of our decision making, as it shows that we value each other as individuals instead of just simply people we have to work with on a team together.
As for the prototypes, for me personally this was a mixed bag. I loved working on Cash Force and thought the prototype came out fantastic. Seeing the testers laugh and smile while playing it made me super confident in the concept, as seeing players enjoy my games is really what I live for. I just love the idea of the game and the style we have going for it, and I think I’m gonna have a lot of fun both designing and implementing various systems – from guns to progression -, as the semester continues.
Robo Charge was very different for me, however. While I liked the concept in general and thought that it had potential, actually working on it was not fun for me. I felt Robo Charge was very safe and didn’t meet the goals I had for making really intractable and complex systems. It was also the only non-VR game, which while not really a problem, didn’t align with my goals. That being said, the prototype for Robo Charge did end up coming out rather nicely despite the fact that I wasn’t personally very passionate about it.
The same can mostly be said for Toy Deploy. While I found the concept really cool and to have a lot of depth, I didn’t really see many interesting interactions apart from picking up and moving the units around the table. I also had a lot of concerns about the use of VR for the concept; it seemed that the gameplay didn’t actually need to use VR and could easily work on a pancake* display. For this reason, I also didn’t find as much passion for working on the game than I would’ve liked. The simulation came out great and the concept was well received, but my personal goals weren’t fully reflected like they were in Cash Force.
As far as what I learned during these last few weeks, I think its safe to say that I learned the importance of knowing what myself and the team want to get out of the game and the experience we’re creating. With Cash Force, we all knew what we wanted to get from it; Josh wants to program complex systems, Emmett wants to experiment with procedural level generation, Adam wants to create, and I quote, “the most stylish capstone game ever at Champlain”, and Austin wants to work on a game that has a large market to prove that we can make a game that would be successful. Because we know what we want, it will allow us to design the experience around our criteria, which will not only result in a game that we enjoy spending hundreds of hours working on but also a game that we have a clear, attainable vision for. The more passion we have, the more fun we have working, which I learned has a huge impact on the end result of the product.
I also learned alot more about using Unreal, which to me is awesome since I’ve been wanting to keep using it as much as possible since my foray into it over the summer. I think its important to know as many tools as I can before entering the industry, especially since Unreal is so prevalent throughout the industry now.
That’s all for this post! I’m gonna really try to do weekly updates now that we’re in production of one game instead of a couple small prototypes, so I should be able to write small little updates every Tuesday after Capstone.
See you next time,
– Karl
