Postmortem and Reflections

In our final presentation, we presented a handful of lessons we had learned along with successes, challenges, and even some plans for the future. This post will recap some of them in greater detail.

Lessons

First, the lessons. Over the course of this project we framed the development process as an exploration of up and coming VR platforms. The HMD Odyssey was our platform of choice and working with the Windows Mixed Reality system was something new to many of us. Integrating with SteamVR was also something we had to figure out. Here we had more expertise, but every game is different and understanding what tools are useful is part of the challenge. Some things we began to learn about specifically for the game are catapult physics. We calculated how two points across a distance will be connected by an arc of a certain height. We also worked a lot on how to make the arrows launched by the player stick realistically into the environment. We started the process by understanding how to get a collider to stop an object, but we had to figure out how not to lose the rotation, and how to constantly have the collider aware of an arrow. We then decided to expand this to the rest of the world. So buildings and the ground also recieved their own colliders to ensure that arrows stick in them.

Two more items of learning we encountered as a team were related to the environment and mechanics of our player’s navigation. The first is smooth transitions over scale. We have the player going from their normal height dow onto the game board at a height comparable to the toy soldiers they are fighting. If this is done poorly we could have a lot of individuals getting sick and nauseous in the VR. We first tried to tackle this by using SteamVR’s teleportation system. However, this lead to more issues than it resolved. We eventually built our own diving system that scaled and transported you down to the correct size and place. The second piece was the idea of immersion. We were putting people into a small room to make them feel like a child. However, the brain is a funny thing and we had to take in people’s expectations of the real world to ensure that they would not be overwhelmed by the VR world. The lesson of immersion was not one we tackled until the last leg of the project.

Successes

In terms of successes, we had quite a few impressive ones. Our team dynamic was strong and we had really flexible and reliable scheduling. We had no permanent artist on our team so free assets became a blessing. We think we were pretty successful in creating all we needed using free assets that seemed to fit together in a congruent style. While Windows Mixed Reality and SteamVR are relatively new concepts for us they functioned well and we had few issues. Finally, our biggest success is our core mechanics. They were incredibly solid and polished and were the basis of our game concept. We spent the majority of our time ensure they were a success and that made our concept of diving into the towers and defending the castle more salient.

Challenges

Our challenges matched well with our successes. For the most part our aesthetic components became after thoughts. We focused so much on making the game work well and fluidly that we paid little heed to creating a unified art style. We also had a very bottom-up approach going from the minigames up to the metagame which meant we did not fully expand on our game design thoughts and ideas. We also attempted to modify SteamVR content rather than build our own system. We spent a long time trying to strong arm existing systems into our game instead of using existing systems to inform our development process. Immersion and art were left to the end as well making that a challenge for us to completed during our final push.

Future Plans

Finally,  to review some of the things we thought about but were not able to add yet. We wanted even more minigames. We had planned out a spear throwing game, multiple enemy variants, and of course the infamous HORSE pitch. In connection with our biggest challenge we had plans for a more advanced wave system. It would include multiple paths, a difficulty progression, and some enemy variants. We also wanted to have a nice UI. We moved from having floating text to having it on a chalkboard by the game board, but we believe we could polish it up some more. This would also tie into us having a distinct menu and even a clearer endgame state.

We also had the big idea of having partial goals. We have on our map a cave, a small town, and then the battlefield in front of the castle, and then the castle itself. We considered using these to a greater extent by having players defend or fight off enemies at each stage and expand outwards or fall back towards the castle. This was ultimately scrapped due to the time it would take to develop it all. However, we have considered continuing this as a side project. The final thing we also considered adding was a tutorial mode. We currently just have some instructions available in game for players to read, but it does not always appear obvious.

Conclusion

In conclusion, this was a massive success for a class project. As this final report shows our team learned a lot throughout the project. Our challenges spurred us on and using the things we learned we were able to have a handful of successes under our belt by the end of the semester. We also not only learned things within the context of the project and the course, but we have clear thoughts and plans on how something could be expanded or improved. The learning supports our future attempts at game design and the feedback and experiences from the course will continue to bolster our future games.

The final section of our project before we present during finals week can be described by the game development terms of juice, oil, and windex. The idea here is that juice adds all the extra stuff to your game that makes users more immersed and entertained by the game. This can take the form of colors, environments, audio, and special mechanics. Oil is the process of making the game run more smoothly. Essentially it can be simplified to fixing bugs and system processing to ensure the players and users have a smooth and painless experience with the game. Windex is the idea of making the game state as clear as possible. This means we make our mechanics, gameplay, and UI easy to understand. While these terms are relatively well accepted they are vague until specifically connected to the individual game states we are describing. With that lets discuss some specifics.

The biggest thing we wanted to finish is the environment of the game. We intentionally focused on the mechanics and actual game board, but now it is time to create the extended environment our players will encounter. This type of juice we were adding to the game is essential for VR games. With just a sky box and something to interact with the player lacks the immersive experience we want them to have. So we need to make the child’s room to fit the theme of our game concept. This poses other challenges.

When making a room in VR there are things that need to be built in to ensure that a player does not feel trapped in a box without windows, walls, or other things they might expect in a room. With technology we need to consider the underlying psychology that players occasionally experience when immersing themselves into a game directly as both the player and the character. So we made the room as realistic as possible and then populate it with a child’s paraphernalia. In other words, more juice!

We also fully set up our Sound Manager with all the audio we needed to further expand the content of our game. We then test the audio repeatedly to adjust volumes and frequency. As we reviewed the gameplay with the audio we adjusted until it fit just right. Some SFX we kept and some we did not. One of the biggest issues was that our music volume was incredibly loud. We also had a weird audio layering happening where one audio file would constantly be called and played repeatedly over and over again causing an annoying buzzing sound.

We integrated our final major feature of the game, the catapult. It has a tower and functions within the scene. We had to adjust it’s orientation to point towards the enemies instead of the castle. We also had to change the targeting system to give users a better feedforward system. We then had to fix a small tagging issue that prevented the catapult for exploding  enemies on impact.

We had a node visuals update that expanded the development cycle slightly as we tried to make a more integrated environment. This meant we changed the art style of our teleportation and tower placement nodes. They now fit the fantasy theme through the design and particles used. On the topic of the towers we made a respawn system that brought the towers back after they were thrown, dropped, or placed.

We also shift the UI from floating in the air (unrealistically) to a chalkboard by the game board. This is further a part of the windex method which claims that the clearer and more understandable you make things for the players the better the game will be. One of our challenges will always be immersion, and floating text is generally one of the obvious differences between the real world and the digital world so we decided to fix this.

We also continued general bug fixing and post processing all for the final presentation.

We are in our final push to complete our game. With that in mind we are here to present a relatively short blog post as we continue to advance in our progress. For the most part we are completing some final polishes on various levels of the game. Things we have added to the game to make it more juicy include: Sound, dressings for the room, and some particle effects. We referred to various free music and SFX libraries to build up a folder of music and sound effects that increase the player’s sense of immersion within the game. Importantly we wanted to be able to contrast the innocence of the child’s playroom with the intensity of a battle, and wanted the music to reflect this contrast. The dressings for the room expanded the visual aesthetic of the game and rooted it more accurate settings. Finally, we wanted to balance the seriousness of the in person battles with the innocence of the child’s room, and so we added particles. However, rather than have gore and intense particles, we have cartoonish puffs of smoke that indicate collisions and the defeat of enemy toy soldiers.

We also have our third working game ready to integrate into the game scene. The catapult fully works with reloading, explosions, particle effects, and interactive levers. As soon as the proper art assets are made, the catapult will be in the game with everything else and playable by our audiences.

Ultimately, we have some strategy design work to polish. Specifically, we need to understand how best to balance the game over the course of multiple playtests. We know our enemies will be coming in waves, but there are still many questions to answer. How many waves? How many enemies per wave? Are there partial goals we want players to aim for? Can the enemies take multiple paths? All of these questions we are currently working to answer as we fiddle with various curves and paths.

On April 5th Studio Lighthouse had its most recent Milestone presentation and demo. Understandably, the check-in was a major display of our full concept and improved player mechanics. Some things we were able to demonstrate were the meta game scene, teleportation integration, polished sword fighting and archery, and a functional catapult game.Clearly we had a lot to show at this time, and received some valuable feedback on how to fix some bugs, polish some mechanics, and tie it all together. Without further ado, let us jump right into the updates.

We begin with our game overview scene. In previous posts and presentations we described our vision for this scene to be like a child’s playroom with a table covered in a tower defense scene made of toys. Next to this table is a containing holding towers that can be taken and dropped onto the table. These towers represent mini games you can teleport into on the table. Suddenly, the scene changes and you are on the table fighting the toys to defend your castle. During our demo we finally unveiled a working version of this game mechanic. Players could choose from an archery or sword fighting tower and place them on highlighted areas on the tabletop. Once the towers were placed, players can teleport down and begin fighting our little toy soldiers.

    The feedback we received about our game overview scene was ultimately positive. We did receive some feedback concerning the placement and position of the table. We need to figure out how to scale the table so that it sits at a more natural height for players. This also raises questions about where is the table? Does the table exist in space or out of it? Our upcoming task is to establish a better sense of atmosphere through decorations around the table, a unified set of assets, and audio design. This also impacts our teleportation system. However, by crafting a unique atmosphere the table size, teleportation, and placement issues will be solved.

    From our game overview our players jumped into our minigames. We have four completed minigames, two of which were integrated into the demo. These mini games were sword fighting, archery, spear throwing and catapult launching. We have an actual sword for the sword fighting game. We have also implemented a handedness trick that registers which controller players use in the game overview scene, and then records that for when they use the sword. Another feature we have successfully implemented is a haptic response when a player uses the sword against an enemy. Previously, we had implemented a system that deactivated the sword when it made contact with the shield and now we have a haptic feedback system in place.

    Related to the shield we also improved our archery game. Now arrows stick in the enemy shields and other places within the scene. Another major addition was the fact that now enemies roll away and disappear into cartoonish particles when shot with arrows or hit with a sword. Another thing we fixed was the handedness issue with the bow. Every time the players would pick up the bow it would be in the correct orientation, but as soon as the arrow was drawn, the bow’s orientation flipped. This was quite the annoying bug, but it has been fixed. We had some feedback that the HMD Odyssey headset sometimes forgets where in space the controllers are if the bow is drawn too far back. Nonetheless, we had a lot of positive feedback about the actual physical gameplay. It was described by one person as, “fun as hell.”

    The final update is concerning our next steps. We have two more games completed that still needed to be integrated as towers in the main game scenes. We have already mentioned that a unified set of assets is in our to-do list as well as a comprehensive audio design. Of course, taking the feedback and more playtesting we will highlight bugs and remove them proactively. Let’s get to work!

Done since last post

Our efforts since the last post have been concentrated on bringing everything together for a playable demo. We completed the zooming mechanic and combined the archery and swordfighting minigames into a larger scene containing enemies. The player can teleport into a minigame spot and use the corresponding weapon to fight the enemies. Currently the minigames are in fixed spots on the map. We intend to change this later by allowing the player to place down minigame towers in different locations, but for this demo it worked well as a proof of concept, and people were able to understand the mechanic intuitively.

For enemy pathing, we used the Bezier curve package discussed in our last blog post. It works well for this purpose, and the enemies twist back and forth along the path in a pleasing way. The curve is easy to edit, which we needed to do several times to keep enemies from clipping into level objects. We found that the path should turn around and wind back on itself in places to keep the enemies in view of the player and allow multiple opportunities for combat, particularly in the archery minigame.

The archery and swordfighting minigames themselves received some polish to be playable in the demo. Initially we placed the archery spot at the top of a high tower, thinking that this would give players a good vantage point to shoot the enemies below. However, through playtesting we discovered that it was too high, and players were unable to hit enemies that were that far away. We shortened the archery tower to about half of its original height and that was much more effective at facilitating combat. We also discovered that hitting an enemy’s shield (designed for the swordfighting minigame) with an arrow counted as hitting its body and would kill it. This does not make sense intuitively, but mechanically it makes archery a lot easier and more fun, so we will have to keep that in mind when designing enemy models.

While not implemented currently in our holistic demo, we’ve also developed a proof-of-concept scene for the manipulation and placement of towers in the strategy layer.  Towers can be attached to the hand and then locked to designated nodes on the table, at which point a prefab is spawned containing hooks for the teleporting logic that allows us to zoom to the tower and any game objects relevant to its corresponding minigame.

During some rudimentary testing of this proof-of-concept scene, we noticed a strange figure that none of us recall adding into the game.  This occurrence could not be reproduced. We would like to assure our playerbase that we have most definitely removed horse from this game as of this update, so the bug is likely unrelated.

Next steps

While we have proof-of-concept implementations of both, neither the spear-throwing minigame nor the catapult minigame has been integrated into our holistic demo, so this still remains to be done.  The spear-throwing game needs some polish, as currently the spears lack the special physics necessary to feel good to throw. While the archery scene and the swordfighting scene were easy enough to implement to satisfaction with the assets on hand, the catapult scene in particular suffers without custom mesh assets.  As such, generating these models will become a priority as well.

Enemy behavior will be particularly important for making this feel like a game rather than a collection of VR tech demos. We still need to refine our ideas on how specifically enemies are created, move across the world, and attack. Tower defense games are a high-level inspiration for this project, so we may do something similar where you can only allow a certain number of enemies across the board before you lose (The Lab’s archery minigame works like this as well and it is pretty effective). We also need to decide whether the enemies should attack towers directly or if they should ignore them and head straight for the goal. We also need to integrate the tower placement mechanic into the main game, and this will be relevant to how the enemies navigate, since for example a catapult should be positioned in a place where it can hit a large group at once.

As more of a long-term goal, sound sounds nice to have.  The archery scene currently has sound effects implemented, which adds a better feel of feedback to the physical actions.  One of our members is looking into options for the soundtrack; however, for most of the other sound design we are prioritizing art before sound.

Until next time: keep em’ hangin’ loose and tidy, crowd!

Initially, our design started as two separate concepts: a VR swordfighting game similar to the one in Wii Sports Resort, and a VR castle construction game where the player would build a castle to defend against attacking enemies. A misunderstanding resulted in these two ideas being combined into one, which led us to an even better idea: a VR game where you place down towers to defend against enemies, then inhabit them to play minigames where you personally fight off the enemies.

This week’s progress

This week we started prototyping our swordfighting minigame. With this one, we wanted to achieve a feeling of a horde of enemies rushing towards you, who you would attack with your skillful swordsmanship and fend them off. To make it more interesting than “anyone you touch with your swords dies”, we decided to add shields on the enemies so that you have to hit them in certain places. But this presents a problem: in VR, your controller always matches your hand’s physical location. If the sword is attached to the controller, then a virtual shield won’t do anything to stop the sword, since nothing is stopping your hand in real life. We could make the sword a simulated virtual object which could get separated from the controller, but this seemed weird and unintuitive. To solve it, we looked at the problem at a higher level. The player should avoid the shield in order to hit the enemy. The exact details of what happens when they hit the shield are somewhat flexible; we just want them to swing more carefully to avoid the shield.

The first solution we thought of was to make the sword rubbery and floppy, so it bends back whenever it hits the shield. However, this didn’t really fit with our planned aesthetic, which is wooden blocks and figurines. The second solution we came up with was to temporarily disable the sword if it hits a shield. The player can swing it around wherever they want, but it won’t do damage for a second after hitting an enemy shield, so they have to dodge it to do damage. This could be justified in our aesthetic by the fragile wooden sword breaking off when it hits a shield. We prototyped this mechanic and it felt pretty fun, so we will probably stay with it.

We also began working on the zooming in and out mechanic. The “meta-game” section takes place at a much larger scale, and the player will be able to place down towers on the battlefield. Each minigame is at a much smaller scale, as the player can get up close and personal with the enemies. This week we developed the zooming transition from large-scale to small-scale, based on SteamVR’s teleporting, and it is working well (and more importantly, isn’t nauseating).

In addition to our major contributions to the game, we continued to polish the mini-games we already had. This meant we began to make uniform visuals across all the small games, and even similar item spawn areas. As the the game begins to look more unified we begin to see new areas for improvement as some assets that work for one mini-game may need to be adjusted for the others. At the moment we have four functioning mini-games.

Finally, we started looking at how to do enemy pathing. Previously we just had the enemies move in straight lines, which was okay for prototyping but quickly became boring. We are currently planning on using a Unity package with support for Bezier curves to edit complex curved paths for the enemies to walk along.

Still to do:

The major thing we still have to add to our game is the major metagame area. The toy board our players start in and manipulate. From the toy board our player can drop down mini-games in specially designed spots and jump right into the defense games.

We also need to import our new 3D models to replace our current placeholders. This will give the game more life as we get to see our vision begin to take form.