Introduction
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!
I have worked with all of these guys in the past on several projects, but most notably our Production II game, Simple Sandwich. Working with them for nearly a year prior has helped me understand their workflows and how to work with them, so I can help to foster an environment where they can all do their best work. We decided to form this capstone team, Holo Hexagon since we trust each other to fulfil their tasks, work well together and most importantly create something we are all proud of.
The capstone structure has each team going through stages, from initial conception and ideas to a more fleshed out, featured vertical slice.
Steps to Development:
Step 1: Choosing a Starting Point
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.
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.
Step 3: Defining the Core Experience
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.
Step 4: Proving the Final Concept
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.
Step 5: Polishing & Presenting the Final Concept
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.
Now, this first blog post is about the initial 4 weeks of development, and the things that I personally learned, as well as the challenges we came across and how we worked through it, reflections on our own decision making, learning, collaboration and general results.
During the first week, we were excited and ready to hit the ground running on our first concept and project, and actually met before we went to our first session of class. As the Producer for the team, I was running the meeting (and all of those that came to follow) and making sure we had a set agenda to follow. As a team, we meet on Monday Nights and discuss how each sprint went, discussing what went well, what didn’t and how we see we could improve that. If there is enough time, we also get started on some early sprint planning, since Tuesdays are the end our our sprint. I believe that by working together with the team like this, it gives everyone a clearer product vision, and a sense of trust since we are all being involved in the process. As a manager, it’s not my job to oversee the team as some sort of fanatical tyrant (despite what our presentation says).
A Week in the Life of a Producer:
As a producer, I’m always busy working on something or helping the team with something! Here’s what an average week consists for me as the Producer of the team:
Discuss in-depth the sprint: what went well, what didn’t and how can we improve
Take notes on what the team said, and also make inferences based on the notes that I took during the sprint and meetings during it. Give feedback and discuss each point w/ team
Begin Sprint Planning (if there is still time left in the timebox – 8:30pm to 10:00pm)
Document meeting on team wiki
Meet in class and present each sprint’s progress, or challenge a step to move on to the next one
If we present, I take notes on feedback people give to discuss with the team and possibly integrate into the presentation, build, etc
Sprint Planning at the end of class, finish planning that was started on Monday
Quick stand up / update to what the team did that day
Take notes on progress the team has made
Team works independently, and posts updates in Mattermost
- Team works independently, and posts updates in Mattermost
Work Session (either in labs or in 194) from 12pm to 4pm
Week 1: Concepting / Brainstorming Game Concepts
The first week had the team brainstorming 50+ ideas, and then narrowing that list down to 10 potential ideas that we considered working with. This was our easiest week, since we spent our meetings rapid-fire brainstorming concepts and discussing them. When it came time to narrow that list down to 10 we wanted to explore more, we began to discuss the feasibility and viability of each idea.
I personally wanted to know if each game had a market that we could release in, and if it was viable to do so. Making sure that the concepts that the team had suggested were feasible within our time constraint was important as well. This was established through analysis of the resources on our team, as well as what they would be able to accomplish during the roughly 10 weeks of dedicated development time remaining in the semester.
This sprint was extremely simple, since we were just letting the creativity fly and coming up with some incredible ideas. Here’s the list of the 10 games, with a quick description of them:
Player fights with a sentient USB stick that refuses to get plugged into a PC. It gets crazier as the game goes on, with more and more wacky stuff happening (it grows arms and legs, runs away – etc)
The player is in a large, big box hardware store looking for a good deal on some wood. He slowly uncovers a seedy, underground wheeling-and-dealing black market of goods.He would have to trade goods for better goods (imagine trading a sink knob for a shower curtain, to give to the guy who has an Oak 2 x 4).
The player is a robot that can sever limbs and then repair itself with the stolen limbs. Players engage other players in a combat arena. There is magic, guns, and melee weapons for the player to choose from.
Real-Time Strategy game where you control a Nuclear Power Plant. Players must keep the power on at all costs, regardless of the employee’s needs. Build and expand the plant and manage each worker for maximum efficiency.
Gesture based VR object control, where players can spawn objects through hand motions. Enemies can be decimated through objects pulled through portals, or thrown into them. Solving puzzles using these powers is also key to completing puzzles.
This concept was a meld of three separate telekinesis games, where players would play as a horror-movie inspired villain attempting to escape a lab. The game would center around using your powers to maim and kill your enemies – with the more you use your powers, the stronger they become.
This concept is based off of the old ‘BattleBots’ TV Show, where teams would build a robot combatant and engage other bots. A 3rd person 3D game, players would customize their bots with different pieces and destroy their environment and players.
Players are inside a getaway van that’s peeling out after a big score. Use a variety of wacky weapons to shoot, blast and smash your way through enemy forces in order to make your getaway. Realistic weapon handling and funny weapons are key parts of the player experience.
Setting up toys and creating large battle scenes like when you were a kid now comes to life in this game. Set up toys and objects to create a scene, and watch it come to life! Players are able to upgrade the stats of their own toys to improve their chances of winning the battle. Played like a Reverse Tower Defense, using units and objects to attack an objective
A Player vs Player vs Enemies sniper dueling game. Players track and try to locate their assassination target, while also trying to hunt the rival sniper. It’s a race against time to take out the target, or each other.
A Problem Emerges
At the end of the sprint our 10 ideas were documented we opted to create a VR Prototype that would include core features and functionality from most of the games that we wanted to test. We decided to start prototyping the game(s) in Unity, since that is the engine that we are most comfortable with. However, a massive issue came up – and halted all progress on the build until it was rectified. It turns out that Unity’s VR integration is sub par at best, and the build we were trying to create wasn’t functioning as Unity wasn’t recognizing some of the files we were pulling from our repository. We continued trying to work with Unity for another two days before I made the decision to do something drastic.
Karl had taught himself over the summer how to use Unreal for a person project. After having a team meeting and weighing our options, we decided to make the switch to Unreal. I can say that is without a doubt the best choice I have made so far this semester, since it’s practically out-of-the-box ready for VR. I only wish I made that decision sooner – since it would have saved us a lot of suffering and we could have gotten more done.
The reason that I wanted to try and stick out Unity was because it was the tool that the entire team already knew. Karl offered to teach Emmett and Josh how to use Unreal, and they caught on fairly quickly, but the lost time spent trying to get Unity to work was on me, since I should have realized after the second day that we were in trouble. It’s a good lesson for me as a producer has made me become more decisive and spend more time on risk analysis.
Week 2: Prototyping VR Concepts
First Prototype – A Schmorgus Board of Mechanics
After the issues with Unity were solved and we decided to work with Unreal, we were able to get a working prototype made that featured mechanics from our ideas. We included things like guns (lots of guns) to test how shooting, loading and reloading would work. We wanted to delve into how the gunplay should feel and test it as a proof of concept.
We also prototyped a sword that can slice cubes where a player cuts, to demonstrate how destructible meshes could be implemented into any of the concepts, as well as their ease of use. There was a destructible wall added as well for players to interact with (by either slicing or shooting) to test the functionality of either of these features. There was a space for players to pick up and grab static objects and interact with them to test physical object play, and a teleportation system for player movement.
In all, we had 5 separate mechanics that overlapped with the 10 ideas we came up with. The prototype went well despite it’s short development time due to our issues with Unity. Now that we had tested concepts and worked with and discussed as a team the list we had, we boiled it down to an even smaller size. From 10 games, to a final 3 we would spend time prototyping.
This prototype was time well spent, since it helped us decide on which 3 games we wanted to go with. By choosing to develop a sandbox type prototype, it helped us make our decisions, but we did end up being put a week behind a lot of our class in terms of the steps. The criteria for step 1 states that we had to select 3 concepts and have a basic timeline to explain what we wanted to achieve in each sprint. Since we decided as a team to spend our time getting familiar with VR and Unreal, that 1st week where most teams had moved forward and challenged the step, we were prototyping our concepts to make sure they were feasible. I’m happy we took an extra week before moving forward with the 1st step – since the extra time helped us to prototype and test what we were capable of and our general interests. I now think that the team is more committed and better prepared to work on the three projects we selected!
Decision Time - The Final 3 Concepts
After we rectified the issues with Unity, and prototyped a basic tech test in VR – and we were ready to make our decision on a final 3. It’s important to note that of our 10 ideas, 7 of them were pitched as VR Titles, which is a large part of why we created the VR prototype. When we boiled down this list, we met and discussed each game’s viability and feasibility of being realized within a semester. After deliberating for two days, the team came to the final 3 that we would be prototyping, being Cash Force, Robo Charge and Toy Deploy. We decided on these three games as they were the most appealing to us to work on.
Cash Force satisfies the team’s need to work on a dedicated FPS game with kinetic handling of weapons. Robo Charge focuses more on experimenting with destruction physics and PvP elements. Toy Deploy is our most experimental concept, with the game exploring how moving objects in VR and their interactions with one another will work. All of these projects are something we are excited to work on – each presenting their own risks, challenges and payoffs.
For the third week of classes, we decided to work on Cash Force first, based on a lot of our initial prototype being focused mainly on guns. This included the shooting, loading, and grabbing / interactions. We wanted to flesh these concepts out further to test their functionality, as well as prove our proof of concept with a functional, more established and mechanically functional prototype.
Week 3: Challenging Step 1 + Cash Force Prototype
The third week of Production had the team working hard towards the first prototype dedicated towards one of the three ideas that they wanted to test. As mentioned earlier, the team wanted to test Cash Force first due to a lot of work already being done on the guns in the initial VR Prototype that had been made. The core elements of the game that the team wanted to nail down in this Prototype include the implementation of new gun (SMG, Grenades), as well as reloading and handling of the SMG. (Slide Handle, Magazines). The already existing shotgun had it’s physics retweaked a little bit in order for it to handle better, and the sliding of the pump was reworked from the initial prototyped version in order for it to function better when players worked the action.
Work was also done on creating a compelling world, with repeatable tiling of the road to create an infinite loop, simulating the vehicle driving down a busy street. Human dummy targets were added to vehicles, as well as shootable discs. All of these were to test the weapons functionality and to make sure players could actually shoot at what they were aiming at.
On top of developing the Cash Force prototype, the team was making sure that they had all of the required documentation and tasks complete for challenging step 1 of the Capstone Production process. If you remember from earlier in this post, the first step required teams to “Create multiple game concepts, and begin to boil them down into a top 3“ – which the team had already actually done. When that milestone was met, the team wanted to test the viability of VR development by creating the test scene during the second week. This was really important to figure out early on, as Karl was the only developer on the team as of this point that had worked with both Unreal Engine and VR Development. Making such a drastic shift to the norms that the team was used to, which was developing in Unity and creating either 3D or 2D games in that engine. This change could have been extremely detrimental to the teams velocity if not approached with caution and given ample time to adapt and learn the new tools.
By the end of the sprint, the prototype was finalized with the core functionality that we intended to get in working. The presentation that the team gave was a combination of the challenge of Step 1, as well as a recap of the Robo Charge sprint. The team was able to deliver on all of the tasks that it set out to achieve, and made substantial progress on their understanding of Unreal Engine. On top of this, the prototype was received well not only by the class, but by QA Testers who played the game the following Thursday (9/19). The team was approved to move on to the second step, which will have us choose between one of our three concepts to develop for the rest of the semester (and possibly the rest of the year given the team passes through the Mid-Mortem cuts). After we’ve finished prototyping all three of the concepts, we will be allowed to select one and move forward with it. This next week will have us prototyping and testing Robo Charge, which will finally be followed by Toy Deploy the following week.
Final Thoughts!
With the first prototype down and moving on to the next, I’m excited to start work on Robo Charge and to see where it leads. We’re planning on getting the core functionality out of the way, which will make developing the concept further easier if we decide to move forward with it. The past four weeks have been an excellent experience so far, and I’m excited to see where the team ends up by the end of the semester.
I’m the most excited about Cash Force personally, but time will tell how I end up feeling about the other games. Either way I’m excited to be back into the swing of game development! I’ll be back with my next post, when the team clears the second step!
Talk to you then,
~Austin