Since the Oculus Go is so constrained, we were able to focus all of our time on making the kite mechanic feel intuitive and rewarding. It especially took many iterations to mitigate motion sickness, since acceleration in VR is difficult to reconcile with sitting still in reality. We settled on a kite that has somewhat tight mechanics, but is slow enough to react that avoiding obstacles requires foresight and strategy, especially as the player speeds up and obstacles spawn more frequently.

We made record time with fleshing out mechanics and asset creation, and were able to put three distinct environments in the game. You start in a retirement community, dodging old women crossing the road and cars backing out of driveways. After a couple miles, you transition to the city, a bustling street with crazy drivers, billboards, and sewage geysers. Finally, you reach the forest/swamp, where you’re dodging rocks, trees, storks, and alligators.

Each time you crash, you’ll spawn in a store, playing 70s pop music and littered with candy you collected on your run. Here, you can purchase upgrades, like invulnerability time, hit points, boost speed, and kite speed. Then, hit the door to roll out the kite again.

Trailer:

In terms of development advancements, we’ve accomplished:

• Fake rabbits can now be picked up
• Rabbits can now see the farmer (Gesture Synced)
• UI text for VR players
• Added main menu + Winning/Losing condition
• Grass clipping
• Added Moving scarecrow
• Added more indications
• Added different types of veggies
• Added animations for rabbits + synchronized

Our play-testing was vital in informing these development changes, and even more instrumental in creating the following design changes. We learned that users wanted better UI indications, more variability in the space, the ability to see the farmer better (if playing as the rabbit), and more challenges in the scene to make the gameplay more dynamic. The following changes to the design of the game address these needs, and further iterate on previous builds.

New farm design:

Level design features:

Feature 1: Staircase

• Purpose for rabbits: A more hidden path to the vegetables, but it takes longer to move through.  The grass on both sides helps disguise where rabbits are hidden.
• Purpose for farmer: The farmer can go up the staircase to get a better view of the layout of the area (and a better view of the close part of the garden maze).
• Concerns: The current prototype model has rails, but the professor said to avoid things the player might lean against in VR.  Additionally, I’m envisioning the staircase collider to basically be a ramp for the farmer, but I don’t know how vertical change will work in VR. There also needs to be something blocking the house porch, so the player doesn’t try to continue up it.

Feature 2: Garden maze

• Purpose for rabbits: Basically the same purpose as the hedge maze, but with more  diversity in graphics. Stretch goal: rabbits would be able to take some plants (herbs, edible wildflowers) for bonus points, but at the cost of less cover.
• Purpose for farmer: Basically the same as the hedge maze.  Plants on the path shake as the rabbits pass through, alerting the farmer that something is there.  Using the current leaf vertex shader, the farmer can look into the area by dragging the net or shovel through it.  Stretch goal: pots and other obstacles able to be knocked over; knocking over pots or watering cans makes a sound, further alerting the farmer.
• Concerns: Needs to be playtested to make sure it’s not too claustrophobic for rabbit players.  Heights of plants will probably need to be adjusted.

Feature 3: Stepping stone path

• Purpose for farmer: A visual indicator for the area the farmer can walk within VR.
• Purpose for rabbits: Not anything planned in particular.  This is the area the rabbits can dash across easily, but also the most visible, most dangerous area.  Stretch goals: could possibly make stepping noises when rabbits walk across if the rabbits are too OP.
• Concerns: Nothing in particular.  Need to playtest to make sure rabbits don’t just always run across.

Feature 4: Tall vegetables (tomatoes)

• Purpose for farmer: Easier to detect rabbits going after than ground plants.  Having far-away tall plants allows stage to feel bigger but still playable to the farmer.
• Purpose for rabbits: A change in gameplay from just picking up ground vegetables.  Rabbits would have to jump to grab the vegetables, making them more visible.
• Concerns: Would have to code additional vegetable pickup/networking.

Feature 5: Rabbit safe zone area has a hill

• Purpose for rabbits: Using the current fence model, rabbits can see into the farm area from the safe zone, letting them strategize more.  Having the rabbit start area be a hill enhances this effect, and allows the rabbits to set up a surveillant in the safe area.
• Purpose for farmer: N/A
• Concerns: Needs to not be steep enough that the rabbits can jump over the fence.

Feature 6: Fence

• Purpose: two entrances prevents the farmer from just spawn-camping at the entrance points and getting the rabbits before they have the chance to play, like Tom mentioned while playing.  Achieves the same effect as the multiple entrances in the maze scene. The two rabbit entrance/exit points have flowers next to them to help guide the rabbits.

In terms of sound, we wrapped up the majority of the sounds and attributed them appropriately. The majority of the sounds had already been in the game before this build, but we spent the last few weeks polishing, and ensuring that each action was met with an equally balanced sound to represent it:

• “Brightly Fancy” by Kevin MacLeod for in-game music
• Original theme composed by Dean for main menu music
• Added in-game sound FX for variable wind chime, farmer scoring, referee whistle (game end), and ambient wind
• Sound FX for menu selection is in

We’re excited to launch Garden Heist today! Thanks for a great semester!

Since the last checkpoint, we’ve been putting a lot of work into polishing the UI, gameplay, and getting all the final assets ready for the main game. For example, we finally have a hat shop up and running, which wasn’t necessarily an “essential” mechanic but nonetheless one that kind of makes the game what it is. We also have now put all the games together into the metagame, and updated the UI to match so that it’s a full and playable game. New sprites and models for all the various functions we have are steadily coming in.

We’ve also begun actual playtesting, which has brought us valuable feedback on the playability and feel of the game. As such we’ve been hard at work bug fixing and tweaking the last (many) features of the game. We’ve been going over all the money-making games to make sure that the amount of money makes sense for the reward you get, etc.

For the last couple of days, we are looking to fix any persistent bugs and provide all the tutorials and UI necessary to play all the minigames. We’re also updating the look of everything so they are no longer placeholders, and just trying to make the game as polished as possible.

Let’s hope it builds this time!

This week, we mainly focused on implementing transitions and other integrational points between all the minigames and the metagame. For example, now there’s a flow from buying furniture at the store to building it in your home, and as a whole we’re really working more on fleshing out the world as a fully-realized pet game.

To that end, we’re starting to establish asset pipelines to replace all of our placeholders with actual animations and stuff. The Peppo (name still in flux) is steadily getting animations built for it — figuring out how to get the model to deform in the way we want, with all the cartoonish sprites, is still in progress — , as well as models for the world itself. Obviously, there’s some refactoring to be done in the game as we make the code more accessible to modularity.

Now we’ve also begun playing around with sound for the game, researching potential Peppo noises and background music for the world.

We’re at the point where all the building blocks for the concrete actions you want to do are in place; as such, we now need to focus on implementing the personality stats and Peppo customizability in full polish. We already have the framework built but we need the user to be able to see the rewards of keeping your Peppo happy, being able to buy it nice things, etc. So a lot of work now will be done on building UI and polish: for the economic system, for the character customization, for the stores and shops and minigames.

Also, we have a new logo for our team! Check it out:

In this post I’ll walk through the development pipeline we (Biweekly Entertainment) have been using in order to deploy to the Occulus Go. The Go is a self-contained VR device so it does not utilize any extra-unit computational power. As such the usual pipeline of deploying directly from the Unity Editor as you would with the Rift or the Vive is insufficient. We need to interface with android software to create a .apk to run from the go itself.

Set-Up:

The set-up process is a bit arduous, but once everything is correctly in place it’s easy to quickly test and iterate on the go itself.

Step 1: Install and set-up Android Studio:

The first step is to download Android Studio if you don’t already have it. You can find a download link here: https://developer.android.com/studio/

Once it’s downloaded, open it up and you’ll be greeted with this window. Navigate to the configure drop-down on the bottom-right of the window.

• On the SDK platforms tab, make sure that API levels 21 through 28 are checked.
• On the SDK Tools tab, check the box next to Show Package Details in the lower right corner of the window
• Under Android SDK Build-Tools 28-rc2, make sure the highest numbered item is check that does not end with “-rc1” or “-rc2”. As of this writing, that is 28.0.2.
• Also make sure LLDB, Android SDK Platform-Tools, Android SDK Tools 25.2.5, and NDK are all checked.
• Click Apply

Next we need to configure our PATH environment variable so your machine knows where the various packages are locates.

• Return to the homepage of Android Studio and once again go to Configure, this time selecting Project Defaults > Project Structure
• You’ll see a window that looks like this. Copy the locations of the Android SDK, JDK, and NDK into a text editor, we’ll need these in a second.
• Now, navigate to your environment variables. On a Windows machine you should be able to search “enviornment variables” and Cortana will pull up the correct window. (On Mac you can set your enviornment variables through the terminal. Here’s a guide: https://medium.com/@himanshuagarwal1395/setting-up-environment-variables-in-macos-sierra-f5978369b255)
• Set JAVA_HOME, ANDROID_HOME, ANDROID_NDK_HOME to what we just copied.
• Add JDK TOOLS to your PATH ie C:\Program Files\Android Studio\jre\bin

Step 2: Set-Up Unity to build to Android VR

Now we need to set up Unity to know how to build to the Go.

• Ensure that Android Build Support is installed with your version of Unity. If it isn’t you can redownload the Unity installer, run it, and make sure it installs the Android Build Support.
• In Unity, navigate to File > Build Settings. On the list on the left select Andoid then select Switch Platform. This part may take a little while for it to switch over.
• Go to Edit > Preferences and go to the External Tools tab and scroll down to the Android section. There set the Android SDK, JDK, and NDK to what you set them to in Step 1 (Unity comes with a built-in JDK so you can use that if you wish)
• Go to Edit > Project Settings > Player. In VR Settings, check the box next to Virtual Reality Supported.

• Make sure Occulus is on the SDK list. If it’s not, click the ‘+’ and add it.
• Head back to the top of this window and set Company Name and Product Name (in our case BiweeklyEntertainment and OldMenWithKites)
• Scroll down to Other and set Package Name to CompanyName.Product Name (so for us BiweeklyEntertainment.OldMenWithKites)
• Set Minimum API level to 21
• Last, you will need to get the Occulus Core Utilities for Unity. You can find these here: https://developer.oculus.com/downloads/unity/

Step 3: Set-Up the Go

We’re now mostly set up on your PC, we now just need to ensure the Go is set up properly by enabling developer mode.

To begin development locally for Oculus Go, you must enable Developer Mode in the companion app. Before you can put your device in Developer Mode, you need to have created (or belong to) a developer organization on the Oculus Dashboard.

To join an existing organization:

1. You’ll need to request access to the existing Organization from the admin.
2. You’ll receive an email invite. Once accepted, you’ll be a member of the Organization.

To create a new organization:

1. Go to: https://dashboard.oculus.com/organization/create
2. Fill in the appropriate information.

• Enable Developer Mode

To put your Oculus Go in developer mode:

1. Open the Oculus app on your mobile device.
2. In the Settings menu, select your Oculus Go headset that you’re using for development.
3. Select More Settings.
4. Toggle Developer Mode on.

Finally it’s worth noting that when you connect the Go to your PC via the USB cable that comes with the Go you will need to make sure the Go trusts your device. Connect the two then don the headset and acknowledge that you always trust your computer.

Step 4: Set-Up the Android Debug Bridge

The final step of the setup is to build the bridge that allows you to transfer APKS built on your PC to the Go for play.

• Head to this link https://forum.xda-developers.com/showthread.php?t=2588979 to download and install the ADB. Make sure you Run the Installer As Administrator!
• During installation say yes to each of the requested features by typing ‘y’
• You’ll need to add ADB to your PATH as we did before, finding the install directory and adding this to your PATH environment variable.
• Once all this is set up you should be able to run your command prompt (or terminal) and type ‘adb devices’ and your Go should come up if its connected!
• NB: your Go must be powered on on your computer will be unable to detect it! (Sounds obvious but its easy to forget this!)

Building:

Once all of the above set up is completed it’s possible to actually build to the Go by following these steps:

• Ensure the Go is powered on and connected to your computer via the USB cable.
• Head to Edit > Build Settings in Unity, and select Build

• Make sure in this window the Run Device is set to your Go! If your device does not appear try hitting refresh.
• Run your command prompt (or Terminal) in the same folder as the generated .apk file
• Now, to push your build to the go simply type adb install ___.apk

• Your command terminal should look like this if the install was successful.
• Put on the headset and navigate to the menu.
• Select Library
• Select Unknown Sources on the left
• Select your build from the list
• Test your game!

Note that these steps get slightly more complicated on repeat application because you need to first uninstall the package before you can reinstall.

• Type adb shell pm list packages into your command prompt (or Terminal)
• Find the name of your package (this is the same as the name you set in Unity so you can also get the name of the package from there)
• Type adb uninstall package name (in this case com.BiweeklyEntertainment.OldMenWithKites)
• Now you can install new apk builds as normal

There you have it! That’s the process for getting a build up and working on the Go. Hopefully this post can be of help to prospective future Go Developers.

In other news, Biweekly Entertainment and its project are going well and we’re excited to show off what we’ve got for tomorrow’s presentation!

Last week Sophia finished the old woman obstacles, environment art like trees and lampposts, and began work on the store environment the player visits after every attempt. Tommy and Thomas continued iterating on mechanics built, like controlling the kite, speed boosts, and obstacle generation. Harleigh began work on a soundtrack, aiming for 70s-inspired disco to keep the pep in grandpa’s step as he races through suburbia.

Things are coming together very nicely for Biweekly Entertainment. We should have a playable beta by Friday.

In our effort to come up with a narrative for Peppo, we totally reinvented the aesthetic of the game, and really shouldn’t even be calling them Peppos anymore (taking name suggestions).

We’ve come up with a much more toy-based version of the game. The idea is that you as the player are a kid with a beloved self-made sock puppet toy. Your parents are tired of it. It’s just a ball. They don’t understand your connection. Into the junk drawer it goes.

Unbeknownst to them, the junk drawer is where your Peppo truly comes to life. In a world made out of scraps and leftovers, you and your Peppo can play together and let your imagination run wild.

We are currently in the midst of building a totally new set of cardboard and junk based furniture and buildings to match this new story.

The Issues of Holoplay Capture and Unity Physics

The Issues of Holoplay Capture and Unity Physics

When designing a Unity project for the Looking Glass, it is always important to begin with the Holoplay Capture setup. Since the Looking Glass is essentially a high resolution display that splits the light in different direction, the Holoplay sdk mostly only handles output resolution settings. This makes it very plug and play, and the only thing a developer needs to worry about is the green wireframe box that dictates the volume of the Holoplay.

Bugs can occur when developing on other displays. The unusual settings for the Holoplay create a blurry, greyed out image on normal displays. This necessitates using a different camera, which means developers need to manually switch between cameras depending on what display they are using.

If a developer begins using a standard camera and then ports their camera to fit within the Holoplay Capture field, they will realize that the scale of the box is very small. This usually means that the entire project has to be rescaled. This can lead to problems depending on the origin points of every object. With our piano game in particular, the relative position of our key collider game objects became out of sync with the piano object itself. It’s an easy fix but the small size of the Holoplay Capture field can lead to unexpected behavior.

In our bouncy ball minigame, the tiny size of the field forces us to make an even smaller ball. Since the point of the game is to quickly bounce it around the field it travels at a fast speed. Its small size combined with its fast speed makes it interact with the usually small delta time of Unity physics. This leads to weird bugs such as sudden stops, and it tends to get stuck in corners easily. The nature of the bounce game is already likely to lead to unexpected behavior due to high speed interactions and the fudging of kinetic energy calculations. Also the rectangular field leads to corners that don’t play well with a bouncing ball shape. The ball’s spin also affects its bounce behavior so it needs to be restricted. When forced into such a tiny scale these bugs become much more prominent.

Next Steps:

Now is the time to pull together all of our pieces and rework the main project. We’ve already been integrating some of our minigames from last time, but we still have to put in some of the major transitions in the game, as well as import the updated animations and models.