4 Year Development Anniversary

Yikes! 4 years. Wow. Thanksgiving weekend 2016. I still remember Thanksgiving weekend in 2012, when I decided to try my hand at making a small game to learn Unity. At the time, I thought it would take 3 months (“How hard can it be to make a game!?”), and here I am 4 years later.

For me, Thanksgiving is always a time to reflect on the year. I don’t usually go into personal stuff here, but this past year has been pretty rough.

Past 12 Months

There have been a lot of setbacks with work. I had hoped to finish the game by mid-2016, or at least to be at a point where I’m focusing solely on level and puzzle design. Some of you might recall I had tried working with other programmers to make the game, but for one reason or another, things didn’t work out. I’m back to working by myself on the project now.

Programming has never been my strong suit (or something I particularly enjoy), so taking over the code base after it had been worked on by 3 different people, and which I had not looked at closely for almost a year, was a brutal endeavor. It seemed almost impossible to understand the code that was handling the back end level loading, saving system, and gameplay. The architecture was completely different than what it was when I stopped working on the code to focus on design.

It took about a month of me banging my head against the code, commenting every single line, going back and forth between scripts, before I understood what was going on. I’m past the hardest part though, and now have a clear idea of the underlying tech for the game. It makes fixing bugs much easier, as I can pinpoint what is wrong behind the scenes when I see a problem in the game. It’s also much easier for me to work with the code directly to make my designs happen.

I’ll talk more about the changes I’ve made to level loading and save system later in this post.

Besides work, also a lot of stuff happening in life. In June I went through a break up, and in October, a close family member passed away. During this time, I had also discovered a golf-ball sized tumor near my left collarbone. This was initially diagnosed as a swollen lymph node, which is very worrisome to find in the collarbone area.

In fact, the lymph node by the left collarbone is known as “Virchow’s Node“, and “The finding of an enlarged, hard node has long been regarded as strongly indicative of the presence of cancer in the abdomen”. To make things even worse, a lymph node is considered abnormal if it’s bigger than 2 cm. The tumor was about 4 cm.

As you can imagine, I was not very pleased to learn of this news. I had to have surgery to have the tumor taken out and tested for cancer. In the end, the tumor turned out to be benign, which was a huge relief. The entire experience took 2 months, from first discovering it, to seeing a doctor, then a specialist, then the scheduling, waiting for test results, etc. It was a particularly stressful time.

Anyway, things are looking up now. I’m thankful for the friends and family who have supported me throughout this period. Also thankful to have my health after the scare, and not have cancer. And even though Manifold Garden has taken way longer than I had expected, I’m thankful for the opportunity to work on this project. It’s really a dream come true in so many ways, to be able to immerse myself completely in a world of my imagination. And even though there are a lot of aspects of game development I don’t enjoy (management, low-level programming), everything has been part of a learning journey.

Onto the technical details.

Level Loading – Streaming and Stutter-Free 60 FPS

In Manifold Garden, there are multiple different areas that you can travel to. Each area is a separate scene in Unity. There are loading screens during gameplay, and no level select screens/

Here is a map of how the game world of Manifold Garden is organized. The blue circles represent worlds (main gameplay areas), and the red lines are hallways which connect the worlds via portals.


Here’s what it looks like to go through a portal hallway to get from one world to another:

moving through portals

The hallways serve 2 purposes:

1. It provides visual contrast of going from a narrow hallway to a large open area. Putting two open areas next to another doesn’t feel as interesting. The interior also has strong contrast to make the portal “look” like a portal (not seeing anything behind the portal contrast with the interior wall).

2. It provides time to prepare the next level before the player moves in (this is an old game dev trick)

For a while, the way level loading was handled was by loading all the levels at the beginning, then disabling all the scenes not needed, and then enabling / disabling them accordingly as the player travels throughout the game world.

In this image, everything with a yellow tint has been loaded.


The problem with this was that it had a really long load time at the beginning. Even with only a third of the game scenes loaded, the load time was about 30 – 40 seconds. It clearly was not going to scale for the entire game.

This meant that the levels needed to be loaded in dynamically in the game.

The first implementation of streaming loading used Unity’s async loading. The only control you have over this is choosing the thread priority to be low, below normal, normal, or high.

Every time a level is loaded, it would cause a very noticeable hitch. It was a fraction of a second, but with the game running at 60 FPS, it was very noticeable, and very jarring.

For dynamic loading, only the neighbor levels are loaded.

As you can see here, the player starts in world 1. Before the game begins, we already world 2 and world 3, as well as the hallways connecting them to world 1 loaded in.

Worlds that have a black dot means they have been disabled. So when the player is in world 1, only the hallways connecting to it are enabled. The hallways are staggered the main world physically. The gameplay worlds are always at origin (0, 0, 0). The hallways are far away, like at (600, 0, 0). When players change between gameplay worlds, we are enabling the new one, disabling the old one, and just changing the player camera culling layer.


When player moves int world 2, we load its neighbors. World 1 has already been loaded, so we don’t need to reload it. We load in world 4 and world 6. Note now world 1 is disabled. The only enabled levels are world 2 and its hallways.


I was getting a hitch when loading in new scenes, even using Unity’s async.

At the beginning of November, I went to Unite 2016 (the Unity conference in LA) and spoke to William Armstrong (who worked on Firewatch), as well as devs from Playdead (who made Inside and Limbo).

They both had really great suggestions for smoothing out loading.

Instead of loading the entire level using async load, I load in the colliders separately. In preparing the level, the colliders are separated into groups of 100, and each is made a prefab, then deleted from the scene. During gameplay, the scene (without colliders) is loaded in async during one frame. Then during the next frames, one collider prefab groups is instantiated and moved into the scene it belongs in.

Thus, an entire level is loaded into the group over the course of multiple frames, sometimes up to 20 or 30. This is perfectly fine as the level is fully loaded far before the player is even close to getting to it. This allows me to maintain a smooth frame rate even as new levels are being streamed in.

Save System

After I got the stutter free level loading working, I started to work on the save system. This turned out to be much more complicated than I had expected. I’m not even sure why this surprises me anymore. Pretty much everything related to this game has been more complicated than I had expected.

What makes the saving tricky is that Manifold Garden has persistent states in an open world. The levels are loaded in dynamically, so not all the playable objects are available to be referenced. Also, which levels are loaded depends on the current play session, not necessarily the history of the game. For example, if you visit world 4 in one play session, then continue that game in another play session, but don’t ever visit world 4 or its neighbor levels, world 4 will not get loaded. However, the objects in world 4 still have history.

There’s also the case of making sure the save file doesn’t get corrupted. To minimize errors, each save in the game is stored in a separate file on disk (so that corruption of one save doesn’t ruin all the saves). Also, when writing to disk, the game first writes to a temporary file. It then makes a backup of the original, then renames the original, then renames the temp file, then deletes the original.

This way, there is always at least one good copy of the save.

Here the load screen design at the moment (I still need to get the screenshot in save slot working):

load screen

Each save slot also lets you restore to an earlier save (basically backups within the save):

Restore1 Restore2

I got the idea for the restore from the Talos Principle.

What’s Next

Still a few things left with the save system. Also need to tackle object pooling, and the water mechanic has several problems.

The last remaining tech is a fast travel system, which is using the level loading system underneath. This shouldn’t be too difficult, but I’ve been wrong each time when I thought this.

After the tech, I want to go back into level design and focus on that.

Still need to work out audio design and music.

And then it’s just lots of tiny bugs here and there, and polish everywhere.

Oh, also working on the PS4 port (sigh).

Almost there! Definitely in the second 90% of development. It’s a real sludge to get through, and my productivity has been super low. However, I’ve been tackling things consistently, and definitely still making progress.

You walk over the highest mountain one step at a time, right?

Menu Progress

Posting some progress images of the menu over the course of last few months.

Here’s what the menus in Manifold Garden looked like back in August:

Start menu:


New game select menu:

August new game menu

Settings menu:

August settings menu
Level select menu (for debugging):August level select menu

As you can see, they looked pretty awful. They were all using the default Unity button design, which just didn’t fit with the rest of the rest of the art style. Also, it was very confusing when there were only 2 buttons shown, because one would be grey and one would be white, and it wasn’t very clear which button was highlighted.

In mid-September, I decided it was time to redesign this. Playtesters kept requesting features like button remapping, and being able to adjust mouse and joystick sensitivity. All of this had to be interfaced with via the UI, so I figured, might as well take the time to overhaul the system.

Here are some early drafts on paper:

early design 2

early design 3

early design

Here are some early mockups in photoshop:



screen_optionB_Translucent screen_optionC_centerOpaque

The opaque background one was my first design. The others were added based on people’s feedback as many thought the first one looked too empty.

However, I decided to still go with it in the end. It felt bold and striking. All the others felt like compromises. Also, while they might have seemed like good ideas in theory, they didn’t work that well in practice. For example, having a translucent background meant the menu looked very busy,  and if paused during game, it wasn’t always a guarantee that you’d get a good background. The design with the small box in the middle had to change in size to adapt to different menu screens.

Some more tweaks for other menu screens:


Menu_Settings-Gameplay Menu_Settings-Controls-Keyboard


Thought about other ways of showing button highlight:

highlight 1

hightlight 2

Lots of people liked the dashes on the side, but to me, they didn’t feel as consistent with the rest of the art style. Ended up sticking with the box outline.

Around this time, I was also starting to face a lot of problems with dropdowns. They caused a lot of problems visually with spacing that I just didn’t like, and the control for them when using controller or keyboard wasn’t very intuitive. You had to first select the dropdown, then go down, then select, etc.

dropdown problem

Ended up switching to cycle buttons:

cycle buttons

Added some more details to the cycle buttons. Notice the brief flash when you change the value.

Here’s pretty close to the final layout. Also got button remapping working:

button remapping

Also got the menus to adapt to different input.





Dualshock 4 controller:


Xbox 360 controller:


TwitchCon Thoughts


I went to TwitchCon last week. It was a very interesting and eye-opening experience.

Here are some my thoughts based on what I learned and observed. It isn’t supposed to be a guide to development streaming or anything. Most of it is specific to my situation, but I thought it’d be of interest to others.



I started streaming on Twitch in June of this year (here’s my channel btw: http://www.twitch.tv/williamchyr)

Initially, I did a few random streams to test out the water, and then decided to go full throttle and stream every weekday. I did this straight through from the start of July to TwitchCon.

My schedule was Monday to Friday, 8:30pm to 10:00pm central. I did mostly development streams, and on Friday, I’d do a “game design critique” where I played a work-in-progress game and spoke with the designer. These were really awesome and I enjoyed it a lot.

My main motivation in starting to stream was just to understand streaming culture and what it was all about. Aside from owning an N64 as a kid, I didn’t play video games prior to starting development of Manifold Garden. I also rarely play multiplayer games.
My online multiplayer gaming experience consists of: 2 rounds of Rocket League, and 1 unfinished game of Civ 5 with a friend. Oh, and Journey (does that count?)

All this is to say, I’m still relatively new to video games, and even more so to streaming. However, I was really curious about it so I decided to give it a go.


TwitchCon_03 TwitchCon_04

TwitchCon was very much unlike any event I’ve ever been to.

There were a lot of people with purple hair and purple clothing (Do people wear blue at facebook events?) It also took some getting used to with everyone introducing themselves with their twitch handles.

It was really interesting to learn more about the community aspects of Twitch. I heard it a lot, but I really had to see it in person.

For example, I met several streamers in the Crypt of the Necrodancer Speedruning community, and it was really amazing to hear of the events they’d organize. Definitely a large part of this was that the developers really engaged with streamers early on with events like the NecroThon, but the community also took on a life of its own. The streamers told me about different play modes they had invented, how they would exchange tips/strategies, and help each other out in different levels. They also told me about “leprechaun hunting” mode in NecroDancer, which was a mode that was actually developed after seeing what speedrunners were doing with the game (I think?)

I’m not really sure how this would apply to my game. Several people told me that puzzle games don’t really do well on twitch, because streamer don’t like to look like they’re stuck. However, I did also meet streamers who told me that they love puzzle games, and it gives them an opportunity to have discussions with their chat.

Interestingly, Crypt of the Necrodancer, is supposedly a non-streamer friendly game because it’s super hard to play and talk/read chat at the same time. And yet, a really strong streaming community has formed around it.

So, I don’t really know what to make of this except that there’s a pretty big variety of streamers, and they all have different styles and preferences. I’m not really sure the format my game will take on Twitch. I’m not going to change the game just so it’s streamer-friendly. Perhaps speedrunning it will be very popular, or maybe the level editor? Anyway, just stuff to think about.

Development Streaming

On Saturday, I went to a panel about development streaming.

The devs all seemed to be suggesting that you needed to focus on stream first and game second, and you had to appeal to people with giant alerts when people signed up (like explosions) or giveaways.

I’m not really sure I agree with this.

Some of my favorite development streams are Jonathan BlowHandmade HeroShawn McGrath, and Lisa Brown.

I watch these mainly for the content, and in order to learn from them. They all have very minimalist overlays. To me, the content alone is fascinating enough, and anything else would just be a distraction.

Of course, I’m not exactly the average gamer, and these are obviously interesting mainly to be people interested in game development or game design.

However, my game is also a slow, contemplative exploration puzzle game. For me to have explosions going off when someone follows the channel just doesn’t really make sense.

Anyway, this is just my 2 cents. Take from it what you will. I think I will continue with a very minimalist stream, and focus mainly on the game, as I think that’s mainly what people watching my stream are interested in.

New Streaming Schedule

After speaking with a few people at TwitchCon, I’ve also decided to reduce the number of times I stream.

This is not because I don’t like streaming. Quite the contrary. However, when I was doing it every day, I was always coming on to the stream at the end of a long day, when I exhausted, and the stream just consisted of me being frustrated that the code isn’t working.

If all you saw of me was what was on the stream, I would seem like a really angry and grumpy person.

There were definitely some really cool moments that were captured, like when I figured out how to solve the edge detection artifact that had been bothering me for almost two years, but those are pretty rare.

Instead of streaming every weekday, I’m just going to do twice a week. Wednesday evening when I do development and updates on the project, and Friday evening when I do the game design critique. This way, each stream can be much more focused and show a lot more content.

Quality over quantity.

Development Update – Box Acceleration and Split Depth

Box Acceleration

I finally fixed the box acceleration problem. You can now release and re-catch a box during free fall:

Previously, when you let go of a box during free fall, it would just fly up past you.

The reason why this was happening was that in a part of the code, it was setting the velocity and acceleration to 0. So the box wasn’t actually flying past you, it was having its speed drop down to 0, and so it looked like it was flying past you.

I’ve now made it so that when you let go of a box, the player passes on their acceleration and velocity to the box, so the box will continue to fall at the same speed.

Also, the box now has the same acceleration and terminal velocity as the player.

Split Depth Gif

I thought I’d try making one of those split depth gifs with one of the looping gifs:

This took me over an hour to wake – I was painstakingly drawing on each of 140 frames in Photoshop (because I had read online that’s how other ones like this were made).

Of course, as I was about to finish, I realize I could have just easily done this using a shader and a depth texture in Unity.

Basically, the shader would overlay the white bars on the camera, and any geometry whose depth is pass a certain distance, you render it above the white bars.

So yea, this realization made me feel like an idiot.

However, I can now I can create a system that will allow me to produce these gifs easily and with more accuracy.

Mechanics System Overview

I’m at a point now where I have an idea of all the systems in the game and what they are supposed to do, and it’s getting hard to keep track of it in my mind.

I decided to start writing it down, and thought I might as well share it here. That way, I don’t have a bunch of poorly named word documents cluttering my desktop.

Some of these points might seem confusing or unclear. That is because this is really more for me to remember.

Cube (Single Gravity)

-   Is active when player is on its respective gravity
-   Is inactive when player is not on its respective gravity
-   Player can lift it up and place it above things
-   Materials change depending on whether it is active, inactive, or illuminate (when it’s on an appropriate trigger – has active and inactive states)
-   Cube is illuminated when placed on trigger.
-   When cube is removed from trigger, it is no longer illuminated
-   Must fall downwards when player lets go
-   Must fall downwards when player tries to switch onto another wall while carrying object
-   Cube does not rotate
-   Player needs to be able to carry box through portal
o       Utilize phantom box renderer (that moment where the box goes into the portal first before the player
-   Player needs to be able to hold onto box while falling, even when going through the recursive world teleporter
o       Also phantom box renderer (that moment when the box goes through teleporter before player does, it will disappear)
-   When player lets go of box mid-flight, the box should fall at same speed as player
o               When player drops box, just take the velocity and acceleration of the player and apply it to box, so if player is stationary, box starts at 0 velocity. If player is falling, box will then fall alongside player
-   Cube should snap to grid (0.25 units)?
-   Cube should grow from trees
-   Cube + water + soil  = tree
-   When a cube is taken from a tree, the tree grows another cube
-   But when you take that new cube from the tree, the old cube is destroyed
-   Need a way to keep track of which cube is from which tree and if it has been destroyed or not

On Video Games As Art

There’s a discussion that surfaces every now and then about whether or not video games qualify as art. You get some pretty heated debates from both sides of the argument. Roger Ebert famously argued that video games cannot be art in principle, but later backpedaled a bit, admitting his lack of familiarity with the medium. Ebert’s original position was later supported by Brian Moriarty in a rather lengthy defense. Conversely, Kellee Santiago began her 2009 TED Talk by saying that video games already are art, and brings up the games Waco Resurrection, Braid, and Flower as qualifying examples in her opinion.

Waco Resurrection
Waco Resurrection

Braid Screenshot
Braid by Jonathan Blow

Flower Screenshot
Flower by Thatgamecompany

As an installation artist whose experiences have mostly been within the contemporary art world, but who is now using video game as a medium, the issue is very relevant to me. It might seem like I’m flogging a dead horse, but there are some sides of the debate that I have not seen addressed yet. So, here are my two cents.

To address whether or not video games can be considered art, one must of course first begin by asking “what is art?” Santiago combines the definition from Wikipedia, that “Art is the process of deliberately arranging elements in a way that appeals to the senses or emotions”, with a statement from Robert McKee, that good writing is “motivated by a desire to touch the audience”, to arrive at the following definition:

“Art is a way of communicating ideas to an audience in a way that the audience finds engaging.”

Ebert himself tried to arrive at a definition of art, but his attempt was unsatisfactory, even to himself. On describing the works that he considered great art, he wrote:

“Through them I was able to learn more about the experiences, thoughts and feelings of other people. My empathy was engaged. I could use such lessons to apply to myself and my relationships with others. They could instruct me about life, love, disease and death, principles and morality, humor and tragedy. They might make my life more deep, full and rewarding.”

I’m not going to refute the definitions that Santiago and Ebert have used. Both are valid in some ways, but also incomplete in others. What’s important here is that both Ebert and Santiago emphasize the capacity of art (at least when it’s good) to move people. However, a side of art that is rarely brought up in these discussions is that as it pertains to academics and institutions, ie the art world.

For better or for worse, the institutions of the art world – the galleries, the museums – have a huge impact on what we perceive to be art. In many ways, they are the standard by which works of art are validated. Take Marcel Duchamp’s Fountain for example, a work which consists of a porcelain urinal that the artist had purchased and then wrote “R. Mutt 1917″ on. If the work hadn’t been eventually adopted by the contemporary art world, and taken up in the collections of museums like the Tate Modern and the National Gallery of Canada, would we still attribute the same significance to it? Would it still be considered “an icon of twentieth-century art“?

Fountain by Duchamp

The art world, despite whatever grandiose notions we may attribute to it, is an industry. And like any other industry, it has commodities (art), manufacturers (artists), distributors (galleries), and consumers (collectors). There is an economy of supply and demand that drives the art world, and at the core of the economy is the following business model: selling limited number of goods at a high premium price to a small number of consumers. Most painters who are part of the mainstream art world do not try to sell ten thousand paintings as $100 each. Instead, they will sell twenty, at $10,000 each.

Video games, on the other hand, do not subscribe to this business model. Nobody spends 3 years making a game only to sell it to 5 people for $100,000 a copy. Not only does it not make sense financially, as most games tend to have a very high upfront investment cost in development, but also having multiple copies of a game does not devalue the work.

In art, having multiple copies of the same work lowers the value of each individual work. Scarcity is a huge factor in the pricing of art. It’s no secret that the value of a famous artist’s work will rise after the artist has passed away. From an economic standpoint, it is easy to see why. Production has ended, and the number of goods are now limited. A game, on the other hand, being a digital medium, does not derive its value from its rarity, but the experience it provides to the player. And your experience while you’re playing the game is independent of the number of copies that exist.

Art exhibition
An art exhibitition

As such, if we’re using the definition of art as a commodity in the art world, then video games will not be considered art, because they simply do not fit into that industry’s economics model. However, this is and should not be a problem. There are incredible works that wouldn’t fit, for example the majority of films and music, as well as a lot of performance and social activist art. As a brief aside, I should explain here that yes, I am aware of “art games” such as Feng Mengbo’s Long March, which is very much within the art world, but I consider these works to be in a very different category than most video games. It’s a fairly long topic that I hope to address in another post, but I’ll raise a few points here quickly. For one, it is not a work that can be accessed outside of a gallery or museum context, and in addition, the work is intended to be judged and viewed not at all as a game, but more as a statement. In fact, if one were to judge it as a game, I think it would fail tremendously.

long march
Long March by Feng Mengbo

This brings me now to the other definition of art, which is frankly, in my opinion, the much more important and meaningful definition: art as something that moves us, something that is the “evocation of the inexpressible”, as Moriarty defines. In this case, then yes, of course video games can be art. Certainly, not every game would qualify, just as not every single painting should be considered to be art, but there is absolutely no reason why the medium alone would exclude works from reaching this higher standard. The ability of video games to elicit emotions and move players is evident and cannot be denied.

While I would definitely agree that the canon of great works in video games is minute compared to more traditional mediums such as paintings or sculpture, it is a medium that is very much at its nascence. Not only has there not been enough time for it to grow and mature, the technical barriers of game development have also prohibited many otherwise brilliant artists from contributing. I am not saying that painting or sculptures are easy skills to master, but game development is a process that brings together a wide range of disciplines and which goes through massive technological changes at an extremely rapid rate. There is a good reason why most large games are made by teams consisting of tens or sometimes hundreds of people.

Luckily however, the barrier of entry is being lowered every day, as software and technology become more accessible, and as the general population becomes more sophisticated in its usage. The potential of video game as a medium for creation is staggering, and I truly believe that if more artists were aware of its power, and less intimidated by the technology, they would all be making the switch to this medium.

The creative ambitions of the mainstream game industry may be misplaced in trying to make better-looking shooters with bigger explosions. However, the technological advances that they push for trickle down and benefit the medium greatly as a whole. With this potential, and the entrance of more talented and creative individuals willing to challenge existing conventions and strive for higher goals, I have no doubt that works within the medium will one day reach the level of sublime. And isn’t that what art is about at the end of the day?

Relativity: The Journey Thus Far

I am going to take a break from development of my game, titled Relativity, for the next few days to 1) reflect on the project and get an overview of the game so far, 2) plan out a course of action for the next few months, and 3) catch up on all the life things I’ve neglected for the past several weeks.

I should warn you now that this blog post will be quite long and convoluted, and will likely reference many things that probably don’t make any sense. This is because this post is intended mainly for myself to help me make sense of the project. However, if you’re interested in game development, you may find a few bits here and there that are somewhat useful, or at least interesting.

State of the Game

I have been working on the game full-time for a little over 7 months now. My initial intention was to create a small practice project to get myself familiar with the Unity engine, but alas, I am now knee-deep in development of a game I’m hoping to release publicly sometime in 2014.

By now, I’ve rewritten the entire game about 6 or 7 times, although the exact number depends on what would be considered a “rewrite”, as some versions contained major modifications from previous versions, but were not changed from the ground up. Both the game mechanic, as well as the visual aesthetics of the game, have gone through significant changes in the course of development, and will likely continue to do so. In fact, I would say that even the latest visuals are nowhere close to what the final game will look like.

Currently, these are the features I have implemented in the game:

  •  28 puzzles
  • 1 environmental hazard
  • 2 different kinds of objects to interact with
  • Various visual cues to assist with interaction (allowing the player to better sense distance)
  • Some sound effects
  • Various environmental cues to assist the player with determining the objective of each puzzle
  • Some placeholder background music
  • Title screen and in-game pause menu
  • Xbox 360 controller support.

While it is very difficult for me to estimate how far along I am in development, as this is the first game I’ve ever made, I would venture to guess that I’m about 30% of the way through. I have ideas for 5 more kinds of objects that the player can interact with, each of which will lead to 10 puzzles. By the time I finish implementing all the different ideas I have for player capabilities and object types, I will probably end up with around 80 to 90 puzzles. I will then select around 40 of the best levels from this group, and refine them over the course of a few months.

Evolution of the Project

The core idea of the game centers around changing the orientation of gravity, and in this way, the player gains new perspectives on how to solve different types of puzzles. Without going into too much detail about the game play at the moment, I want to show you some screenshots of how the game has evolved. I no longer have the project files for the very first prototype of the game, but version 2 is pretty close, so I will start with that one.

Version 2Relativity_02_Screenshot_01Relativity_02_Screenshot_02

Version 3Relativity_03_Screenshot_01 Relativity_03_Screenshot_02

Version 4Relativity_04_Screenshot_01 Relativity_04_Screenshot_02

Version 5Relativity_05_Screenshot_01Relativity_05_Screenshot_02

Version 5.5
(This version didn’t contain enough significant changes to warrant a full number upgrade)Relativity_05B_Screenshot_01 Relativity_05B_Screenshot_02

Version 6Relativity_06_Screenshot_01 Relativity_06_Screenshot_02 Relativity_06_Screenshot_03

As you can see, in versions 2 and 3, I put a lot of focus on the visuals, spending a tremendous amount of time looking at different wood panel and concrete textures to try to pick the right one. This was a bit of my mistake, as I should have spent that time prototyping different game play mechanis and puzzle designs.

Another mistake I made while working on these early versions was that I caught too caught up in creating a narrative for the game when the game play itself hadn’t been fully finalized. When working on version 3, I had written an entire elaborate backstory, including what the style of architecture should be, and even a new language system. Much of it was irrelevant to the game at this point, and used up valuable time. Also, by having a story set in place, it forced me to design puzzles around the narrative, instead of trying to create puzzles that explored the game play mechanic.

After having some people playtest the game, I realized I needed to rework the core mechanic and the puzzle design. It was hard to let go of the old ideas at this point, as I had already invested 4 months into the project. However, I knew that if I didn’t do it now, it would only get more difficult down the line. Also, around this time, I watched this talk by Jonathan Blow, in which he talked about the importance of constantly prototyping, and the willingness to ax an idea as soon as you realize it’s not working out.

With version 4, I decided to start from the ground up, and to focus on the game mechanic without worrying about the visuals at all. As you can see, pretty much everything in the game is white, with only a few colors here and there, and almost all the objects are basic primitive shapes. This allowed me to focus on the game play itself, and it was here that I began to find another mechanic that led to much more interesting and diverse puzzles.

From then on, I began to explore the potential of this mechanic, and would only introduce visual elements to the game when they played a function role. As such, there are no unnecessary visual elements. Everything, from the shape of objects to the color of the wall, exist to convey certain information to the player. The game may not look as “exciting” as the early versions, but the visuals are more carefully designed, and in this way, much cleaner.

Through various small changes here and there, I arrived at version 6, the latest version and what the game looks like right now. It is still nowhere close to finish, and I have a lot of ideas to add. Consequently, I don’t think I will get to the final polishing stage until early 2014.

Problems I Am Having

During the first few months, I was able to keep track of the number of bugs in my head. But now, it seems like every feature has at least one or two minor bugs, and every time I fix one thing, something else seems to break. I thought this would be a good place to list some of the problems (in both design and development) that I am currently facing:

  1. The game looks too much like Portal. While it does seem like you can’t make a first-person puzzle game without people inevitably comparing it to Portal, I think the visuals at the moment do draw a little too heavily from that game. Most of these are placeholder art I’m using to prototype levels, so eventually they well be redesigned. But when I show the game for playtesting, the first thing that springs to the player’s mind is Portal, which ends up influencing their expectations. Right now, this isn’t necessarily a negative thing, but I do want the game to have a unique visual aesthetic and style, so I will have to spend some time on this aspect of the game later.
  2. Collider objects intersecting with one another. I think this problem is mostly due to the native physics engine in Unity, which requires objects to intersect one another in order to calculate collision. For most circumstances, the intersection is minor and doesn’t affect game play. However, because stacking boxes is a pretty major component of my game, intersection of the boxes is a bit of an issue. I’ve found a way to minimize the intersection by playing with the min penetration value in the project settings menu, and making objects kinematic when not being used, but collisions are still not working as well as I would like.
  3. Odd physics glitches here and there. The physics in Relativity is heavily restricted. For example, there is no rotation and no bounce. While this is unrealistic, I found that it was a huge improvement with regards to the playability of the game. This is because the game requires very precise placement of objects, and if the physics is too realistic, it actually becomes very difficult to position objects in the desired positions. By restricting the motion within a certain range, I can minimize player frustration. As such, I am overriding a lot of the native physics functionality in Unity and writing my own. For example, sometimes, for collisions I am using triggers placed on the surface of objects, and using the trigger to detect whether something has come into contact with an object, instead of the default collision detection functions. This leads to unexpected bugs here and there, like objects going through walls, especially when the objects are used in a new situation. I haven’t quite figured out a good way to tackle this issue yet except to try everything I can think of when playtesting, and see if any odd behavior arises.
  4. No narrative. This is not really a problem at the moment, as I’m still trying to refine the game feel, and to work out all the puzzles and player capabilities. However, at some point, I will need a narrative structure for the game in order to provide incentive for the player to keep going. It gets a little boring to keep solving puzzle after puzzle without knowing why, and with no end in sight.
  5. OnTriggerExit function on some of my triggers are called when it is not desired. Specifically, when I have a kinematic collider sitting on the trigger, and another objects hits the kinematic collider, OnTriggerExit will be called, and the trigger will think that the kinematic collider has left even though it hasn’t. If I make the collider non-kinematic, then I get major problems with colliders intersecting one another, as stated in problem 1 above.
  6. Player occasionally rotating out of the room. I think this can be solved by using a ryacast from the back of the player’s head and determining the distance from the player to the wall to make sure player rotation doesn’t cause the player to flip out to the other side of the room. However, in my experience so far, these small problems are usually deceptively difficult and end up taking a ton of time to fix.

What’s Next?

I spent the past few days adding decals to all the levels in order to better communicate puzzle objectives to the player. In the next few weeks, I will begin to create various new capabilities and design new levels accordingly.

While the interaction design and the feel of the game are not completely finalized, I’m pretty happy with how it is at the moment, so I will leave it as such for the time being. I do need to implement a way for players to save the game, and also to adjust the sensitivity of the mouse and the controller while they’re playing. I also need to implement a background timer so that once I begin playtesting, I can get an estimate of the game’s play length.

I will also start to brainstorm ideas for a story, and ways to communicate the story to the player, whether via in-game text, cut scenes, or voice-overs. However, I don’t want to get too carried away with the narrative at this point. I want to have the game structure pretty much set, and then use this as a foundation to create the narrative, instead of the other way around.

Finally, it has been a while since I pushed to Github, so I need to get around to doing that. Soon.

A Few Lessons I’ve Learned So Far:

  1. Always be prototyping.
  2. In the early stages of development, focus on game mechanic, not narrative and visual aesthetics.
  3. Playtest often, and early.
  4. Don’t be afraid to let go of ideas that are not working.

Hangzhou Trip

I’ve been in Shanghai for a little over two weeks now, as part of my six-month residency at the Swatch Art Peace Hotel. Despite things being a little overwhelming at times, it has been a very eye-opening experience so far.

I have a number of different projects in the works, and lots of things I want to share with you. I will get to all those in due time. However, for now, here are some photographs from a day trip to Hangzhou I took yesterday with a few of the other resident artists.