Final results, from Team Object!
Public project pitch poster:
Poster designed by Grayson Freking
Question Responses:
What does your project do, and how does it work?
Our project is a hide-and-seek based game we call Object Encounter. It consists of 4 players, where one player is a hunter, who searches for the other 3 players who are hiders. The twist, however, is that the hiders have the ability to change in objects found in the environment, so they can disguise themselves in an unlimited number of ways to avoid being found. The hunter’s goal, then, is to find and shoot these players before time runs out!
Our game was built with Unity 5, and utilizes Unity’s built in Network Manager to handle all network-related data transfers. Information such as player and game state is constantly updated from the server to the clients, creating a single shared environment for all players. We have one player (the hunter) act as host of the match (thus their computer is the server in this model), and the other 3 players’ computers are the clients. In addition, we built the game to be playable with or without an Oculus Rift, so the game can accommodate a VR implementation, or just operate as a simple mouse-and-keyboard PC game. The gameplay itself starts when one player hosts the match and the other three players join, and after a fixed time of five minutes the game ends, where the screen fades to black. No score is kept, but the game can still certainly be competitive!
What did each team member contribute?
Grayson assembled the entire environment, mostly from scratch. He started with using basic cube, plane, and sphere objects to assemble the house and yard, then began adding assets (some purchased from asset store, others handmade from game objects) to give the world atmosphere and familiarity. He also implemented and corrected colliders and in-game lighting, so the game space would be pleasant and playable without performance issues. Lastly, he also looked into which props players should be able to turn into, and placed them accordingly in the game space with the correct object tags. Grayson also designed our poster for the project demo.
Sizhuo did a large chunk of the programming to implement basic-game functionality, such as creating the teams, allowing hiders to change into objects through raycasting, giving the hunter shooting mechanics, and creating a timer that ended the game at the correct time. Also, Sizhuo was the group member that was able to do the most debugging! On two specific instances, our game completely broke, and Sizhuo was the one to figure out either what the issues were, or find an alternate implementation that still worked. He also optimized scripts and environmental features when he could, overall making the game function much more smoothly.
Andrew was in charge of most of the overhead for the project, including the project posts. He created the template for the project, and set up the network manager for the game. He also created the player controller and motor scripts necessary for basic game movement (to work with the network manager), and created the main menu interface for creating and joining the match. He also was in charge of the Github repository for the project, which was a learning experience for everyone in the group. At times, someone’s push to the repo would not show up, or it would not copy all files correctly (Unity creates temporary files that can be troublesome in pushes/merges), and Andrew was the one that made sure this worked smoothly. He lost his work a lot (good thing we had backups!), and only once, when the repo was originally created, did he completely combine everyone’s files together into a single project by hand, which took a while but was successful. He also handled the Oculus Rift implementation, and ensured that throughout development the Oculus still worked correctly with the project. Lastly, he implemented in-game sound, to make the game more appealing.
How does the team feel about the project?
We are all very happy with the outcome, and for the most part, everything we implemented works correctly! Although there are a still bugs, and not all of our ideas came into fruition, we still are content with how the project came to completion (and the demo went great, in our opinion). If anything, we wish that we had more time, which then we could have addressed a few more issues and added a few more things to make the game operate a little more smoothly. But overall, we are all very satisfied!
What were your largest hurdles in the project?
Out of all the issues that we had with the project, they can all be related to one of two things:
1) Github
Although we all knew what Github was, we didn’t have much experience with it, so one of our earlier objectives was to learn how to use Github with Unity projects. Time and time again, either a push was either not push correctly, a push would not go through, or group members might not have been working with the correct working version of the project. This created conflicts with our individual files, and at first we had to resort to manually sorting things out to get it to work. Towards the end, however, we all got the hang of it, Github was ignoring the correct metafiles, and we all were able to version control our project.
On that note, however, on interesting obstacle we had to work with was that only one member could “check out” the project at a time. That is, if two people were working on the project simultaneously (both pulled the current version), then once the first person would push, the second person would push and overwrite the first person’s work! We thought about learning how to merge using Github, but found that some files such as the scenes still did not merge correctly. Thus, we all messaged each other when we were working on the project, and when we finished, so that no two people were working simultaneously, and that if we started working, the version we pulled was the correct one.
2) Multiplayer Networking
Since we wanted a multiplayer game, we had to work around the Network Manager in Unity. There is a Network Scripting API for Unity, but we didn’t become familiar with this until we were most of the way through the project. We were running the game through the Network Manager component, which is much easier to use, but is also very limiting. For example, we could not specify which players spawned where, or how to end the current match and return to the start menu. These functions are still possible to implement in conjunction with the Network Manager Component, but we were running short on time, and in addition by the time we implemented these function we would only need to add a few more lines of code and the entire Network Manager could be replaced with our implementation. We didn’t have the time to spend re-implemented something that is already working, so we just learned to work around the restrictions (In the spawning case, we just set spawning parameters to round robin, and ensured the hunter always spawned in first).
In addition, we learned that doing network implementation is much more difficult than a single player implementation. Something as simple as having four player in one Object Encounter match is difficult because players would need to be updated on all other players’ position, rotation, current model state (for hiders), whether they are moving or aren’t (including jumping), when they died, when they spawned, and more. Thus, we had to ensure that everyone received the information, and that the information was associated with the correct player (i.e. if one player presses jump, the correct player jumps in the match). Sizhuo was the one who eventually figured out an efficient method for synchronizing player states. We managed to learn how to do this, though in the end we still had a couple bugs, and we had to redo some implementations since others became incompatible with other game functions we implemented.
We also ran into some minor hurdles, such as:
1) Environment lighting either glitching out or becoming too resource intensive, which Grayson handled by changing some build and playback settings
2) Colliders not working correctly, so the player can walk though everything (and stairs impossible to use), which Sizhuo fixed by changing the player’s collider settings
3) UI elements not displaying on the Oculus Rift, which Andrew fixed by reworking the UI to exist in a world space, thus showing on the UI.
Interestingly enough, one obstacle we all though we’d have was learning how to use Unity. None of us in the group had experience with Unity, so we thought it would take time just to become acquainted with it. However, after the first two weeks or so we all were making great progress with our tasks of the project. All three of us are computer science majors, so we have experience with programming, and in addition we all are interested in new technology and video games, so we have some similar experience in this field, so we believe this to be the cause behind our fast learning.
How well did your project meet your original description and goals?
Our biggest goal was to end with a functional game. We planned on having most of the basic game implementation done by Thanksgiving so that we could focus on making the game visually and audibly appealing in the last few weeks. We met this goal, and was able to create a functioning game that wasn’t crippled by too many bugs and glitches. That is, after teaching the players how to play the game they were able to play without serious handicaps or instructions from the developers on how things work, or what they can or cannot do within the game. Essentially, we wanted a standalone result that other people could figure out and enjoy, not get a headache from trying to use. If anything, we didn’t implement some of the cool features that we though of from the beginning (object anti-camping mechanisms, such as player halos, shared camera feeds, or shaking effects). Although these features would be great to have in the final project, we wanted to be sure the necessary components of the game, such as player movement, interaction, and synchronization was working correctly and efficiently, which we were able to do!
If you had more time, what would you do next on your project?
We still had some collider bugs within the environment, and on a rare occasion a player could fall through the world. We would probably start by fixing that, and fixing a bug where players would respawn in place, instead of at the network spawn point. Other than that, we would probably work on improving the game in terms of features, such as adding the object anti-camp implementation, make a more appealing in-game UI (based on the limitations of what UI works with the Oculus Rift), adding an “End Match” feature so the game would not have to restart every time we need to start a new match, and possibly add different game modes, where players can choose teams or different environments to play at.
All in all, we all had fun making the project, and accomplished that which we wanted to. It’s been a serious learning experience, as we all learned how to work with Unity, Github, and Oculus, as well as what it takes to develop a game from the ground up. A lot more work goes into a game that what we realize, which makes us that much more appreciative of what games are out on the market today.
From Team Object, we’d like to thank Professor Ponto, as well as all other students in VR501 – Design in Virtual Reality, for the great semester! May our paths cross again someday…
In this reality, or another…