Follow me on Twitter

I wrote this as I realized a few teammates haven’t had to wrangle with Unity and GitHub before so here’s a step-by-step for how to set up a relatively easy to use environment and how to share your work with others.

Choosing a name for this game, has been an interesting ride. The previous city game project I worked on, City Clicker, started as my love of the ‘clicker’ genre of games. These simple games that took the idea of scaling to an impossible level. You would start by manually collecting currency, but quickly begin automating collecting currency faster and faster until you were automating the production of automation of currencies. These games were ridiculous and I wanted to make a city building game that captured that ridiculous expansion. The name City Clicker played perfectly off of games like Cookie Clicker or Clicking Bad.

For this game, I started with the name of a book by ___, A Machine for Urban Renewal. Even though I couldn’t use that as the name for the game, I wanted to set my expectations for the tone of the game. We had been covering what might be the primary mechanic of urban development, Urban Renewal, for better or worse. At this point, I wanted to explore Eminent Domain in SimCity. Yet once I got closer and closer to the first big development at HackNYU 2016, I decided to switch towards something that would play more off of the process of placing tiles in the city.

Urban Tetris was the working title I had when I came into HackNYU. It played on the rigid, square grids of Los Angeles and, by extension the first SimCity. I didn’t imagine the game playing exactly like Tetris, but where the layout of the city could resemble the chaotic mishmash of zones. Once I was down to the last few hours of HackNYU, I threw together the name Urbaniniminoes at the last moment. I was going for Urban + Dominoes, but the name ended up being this nearly unpronounceable mess.

Over the next few months, I shrunk the name down to Urbanamino based on feedback I was getting from classmates. This new name, though closer to Urban Dominoes, was still fairly confusing and when I presented at the NYU Tandon Senior Capstone Competition the confusing name became more of a problem. Though fun, confusing names make people feel uneasy, especially if they know they’re getting it wrong. One of the suggestions I got at the Research Expo was to change the second A to an O in the name, to make the name Urbanomino, taking as much as possible from Urban + Dominoes. Dropping the plural also made it shorter to pronounce or write.

I’m kinda lucky that I’m able to make this last change before the game has had a formal release, but for now I’ve got to correct a few places where the old confusing name is still around.

This new logo is made up of the top-down views of several of the more recognizable tiles in Urbanomino. It’s not the final logo, but arranging the tiles like an S shaped Tetrimino is a pretty neat play on the game.

Urbanomino won first place at the NYU Tandon Senior Capstone Competition! This was a competition across the whole school for engineering and business projects. Urbanomino was the only solo team as well as the only digital-only project.

It’s been a long run, but it’s finally been released! I had to make a few last minute changes to the URLs, the exact wording, and branding. I’ve learned a bunch about the iOS build and publishing process as well as how ridiculously easy it is to publish to Android. This version 1.1 also comes with a new app icon that better explains that the app is from NYU and is a VR app.

Tandon Vision was created for Google Cardboard due to the incredible accessibility of VR experiences in Cardboard. Because Cardboard experiences don’t demand, and can’t create, the kind of high fidelity experiences of more expensive headsets, it allows a kind of low-fidelty yet immersive experience. The lack of cables tethering the phone mean that the user can turn in any direction. Because the cardboard only has one button, interfaces need to be primarily gaze controlled and more complex experiences need smarter interfaces capable of interpreting what users want.

For the robot driving sequence, I ended up testing several solutions. The first idea was a first-person control scheme where you would see from a robot’s onboard camera. Any time you turned your head, the robot would turn too. To move forward, you would hold down the button. Trying it out, it started falling apart where users couldn’t see where they were going and would be very prone to motion sickness.

The important change was switching from a 1:1 control scheme to a waypoint and route scheme with the Unity Nav-Mesh. Instead of the user piloting the robot’s every action, they would gaze and click to set their desired destination. The camera would follow from a 3rd person perspective, but would never turn on its own, so the player’s physical sense of 3D space while wearing the headset could be partially saved.

To let players know where they were going, I added a simple compass to the UI that would point to their next destination. In addition, I used the unique aspect of Unity UI canvases that they’re not affected by lighting or fog so they’re visible from great ranges. Though it removes some of the exploration, it means no one has to aimlessly wander the sands looking for magical soil samples.

For future virtual reality projects, I really want to move away from d-pad style controls with WASD keys or thumbsticks. Room-scale, like with the Vive or by using the Kinect are really fascinating and tricking the body’s sense of movement is an open frontier for experimentation.

Though it’s probably too early to dream of a thriving modding scene, I did need to work on implementing a better system for the ingame balance. It turns out that serializing C# objects into XML files is quite straightforward. The key is that Unity Monobehaviors can’t be serialized, meaning that you need to make a few custom classes for the system to handle serialization. Plus, by building out the game’s balance into custom objects, it makes it quite easy to build out an ingame interface for exploring what’s going on.

My dream with this is to let players easily change the core rules of the simulation without digging into HEX editors or decompiling source code. Imagine if you could fiddle with the factors influencing RCI in SimCity or change how land values are impacted by pollution as easily as you fiddle with the ingame taxes.