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:


Opening Menu UI

Been super busy with development and travel these last few months.

Soon I will write an update catching up on the past few months, but for now, here’s a quick update.

Been working on the UI for the opening menu. This is what it looks like so far:


I spent this weekend trying to get button remapping working. Using the control mapper that comes with Rewired.

It’s been like pulling teeth this entire time, but I’ve got the basics integrated into the Manifold Garden menu layout now:


Had to adapt it to use TextMeshPro and also to not auto-generate the layout that I don’t want.



Indiecade East Feedback, Programmer Search, and Next Steps


Indiecade East Feedback

I just got back from New York City. Manifold Garden was showing at Indiecade East, as part of the Sony PlayStation 4 section.


I received some really great feedback from this last showing, both in terms of how to refine world 001 and how to set up the pacing for the entire game.

There were two playtest sessions that really stood out to me.


In the first, the playtester had found her way outside in world 001 after solving the initial indoor puzzles. She had lit up one the first laser beam, and had more or less figured out that she needed to get to the other islands and light up the laser beams there.

However, even though she knew where they were, once she got to them, she wasn’t able to orient herself correctly to access the entrance. This was because she wasn’t approaching the island from the center tower, so she would land on the “side” of the island. Because she kept landing on the exit door, which didn’t have a surrounding ledge, there wasn’t a surface for her to orient herself correctly. As such, she kept falling off and getting frustrated.



This was unnecessary frustration. She had already solved the basics of the outside puzzle, in that she knew what she needed to do. The problem she was facing was an execution one, which is not in line with the goals of the game.

The solution is to simply add a ledge around the exit room. This provides a surface for the player to rotate onto to correctly orient themselves with the entrance room.


In the second playtest session, I had gone out to lunch, and had come back to see the playtester had made it to about the 4th world (which means he had been playing for about 1 hour). I asked if he had started from the beginning, and he said, yes, and then I asked him what he thought of the game. At this point, he didn’t know I was the developer. The gist of his feedback was: the puzzles were good (he was obviously engaged having played the game for about 1 hour), thought the architecture was cool, but was starting to wonder why he was solving the puzzles. What was the purpose?

He explained that he wasn’t a puzzle game player normally (he had played Portal only), so for a puzzle game to really grab his attention, it needs something more than puzzles.

This was very helpful information for me. While Manifold Garden doesn’t have an explicit narrative with characters or voiceover or text, there is an implied one. There is mystery to be discovered. What this playtest session informed me, is that I need to introduce this mystery within the first hour.

The puzzles and architecture are clearly engaging enough that even a non-puzzle game player will play for an hour. However, at that point, they are starting to wonder why they are spending their time doing this when they could be playing something else. The prospect of more puzzles as a reward is not enough. There needs to be a sense of purpose.

I had the beat where the mystery is introduced, but not until 1.5 or 2 hours in. Now I know I need to move it up and introduce it earlier.

Personnel Change

An update on the situation, since some people have been asking questions.

David Laskey is no longer working on Manifold Garden.

In the end, things just didn’t work out, and I decided to look for a new programmer.

New Programmer Search

The search for the new programmer is going well. It’s been very busy. So far, I’ve gotten about 60 applicants. This was quite surprising to me, as I only posted about the job on twitter for a few times, and didn’t put it on any job boards.

It has been incredibly time consuming going through all the emails and resumes, scheduling interviews, checking references, etc. Last week I got very little done in the way of actual work.

I hope to finalize everything within either this week or next week.

I’ve also learned a tremendous amount about the hiring and job application process. One day I will write a more detailed blog post about.

Moving Forward

This week I’ll be adding in the feedback I received from Indiecade East. I’m now at a point in the development of the game where I need to start thinking about launch. I need to start looking into logistics of releasing the game – setting up infrastructure for beta testing, setting up a steam page, etc.

To be honest, things have been quite difficult without a programmer. My estimate is that I’ve lost about 6 months of work-time (taking time away to do interviews, working with inefficient tools, legal overhead, the new programmer having to catch up on codebase, etc). It’s very possible this will push back my original planned release date, but I just have to make the best out of my situation.

I am still able to work with existing tools to create new levels and test out pacing in the game, so that is what I will be doing in the next few weeks. I’ll be meeting up with the design club here in Chicago soon to go over what I have planned.

This summer is going to be a super busy one, but I’m looking forward to getting into a cycle of iterating and playtesting.



Programmer Search, PS4 bug, Indiecade East, Twitch

A major part of the last several days has been the search for a programmer to help me finish Manifold Garden. It’s been very exhausting, but also really eye-opening. It has definitely been a learning experience.

Earlier last week, I met up with the Young Horses, the creators of Octodad. They’ve been looking for an environment artist to joined the team, so I talked to them about how they’re going about searching for someone and what their interview process is. It was very informative.

I tweeted about the job post daily for about a week and also sent it to a few mailing lists that I’m on. I got quite a lot of applicants, and it’s actually taking me quite a while to go through all the emails and respond to everyone. (If you sent it in and haven’t heard from me, I will be responding soon.)

Anyway, it’s my first time interviewing people for a position, and I’ve learned a tremendous amount. One day I would like to write a full blog post about this.

PS4 bug where everything is rendered on top of each other

Due to a null reference bug, on the PS4 build, all the renderers for the different levels were getting loaded in simultaneously. It actually made for a really cool looking level. It was unplayable, mostly because you couldn’t tell which things had colliders, but it definitely gave me a lot of ideas for some new levels.

Indiecade East

I’ll be at Indiecade East this weekend. Manifold Garden will be playable at the Sony booth. Need to submit a build to Sony by Wednesday. It’s looking pretty good so far so I’m not too worried.

Twitch Front page of creative


Starting last week, Twitch has been featuring my channel on the front page of the creative channel! It’s been really amazing. The concurrent number of viewers went from 20 to over 100! The most I had at once was 150, which was pretty awesome. Also really positive feedback. Lots of people learning about the game and getting excited about the art style.

My stream schedule now is basically every weekday at 3pm CT / 20:00 UTC.

Pacing Across Levels

Starting to spend time thinking about pacing across levels. It’s a very different challenge than pacing within level, especially because everything in the game is seamlessly connected via portals.

I’m still figuring out the proper workflow and what works and what doesn’t. Will aim to keep updates about that process here.

Development Update – Midwest Game Developers Summit

This past weekend, I attended the Midwest Game Developers Summit in Wisconsin. Drove up from Chicago with a couple of other local developers.

I was exhibiting Relativity there, so didn’t get to go to too many of the talks. On a side note, Lemma, another game with a devlog here on TIGForums was there as well, and I got to try it out. Very fun.

The response overall for Relativity was quite positive and I got some very useful feedback. The most important is that I finally figured out how to deal with a problem that had been bothering me for quite some time, specifically, how to guide the player once they’re in the “exterior” area. While this part looked extremely cool, with all the architecture twisting and turning, and staircases in every direction, it was extremely easy to get lost. Some players, usually the ones more experienced with puzzles games and first-person perspective, would be fine, but far too many would get stuck here. This was very evident especially when playtesting during conventions and festivals, because it’s at this point that players would stop and leave.





Notice that in the first picture, it is much more cluttered: the green box on the right side pushes into the frame, and the tree (w/ the translucent grey leaves) is blocking a good portion of the view. Also notice that there are more things in the center in the upper area. Having things directly above the player in this area was problematic, because some players would fall off, and proceed to land in the area directly above where they fell. Instead of realizing that the world repeats itself, players would think they had landed in a different ‘world’ altogether. By moving the above area off to the side, now when players fall, they’re much more likely to land near where they fell off, thus realizing that the world they’ve landed on is a replica or the same world as the one they fell from.

Here’s a comparison of another area:




DevLog Update – Big Picture, Audio, and Trees

For the last few days, I’ve been working mostly on high-level design stuff such as back story and game progression structure. The game is definitely coming together, and it’s really helpful to see the big picture, but it’s also overwhelming at the same time to see how much there is still to do.

Also met with my friend Kiku Hibino, who will be doing the audio and music for the game. We’ll do a proper intro for Kiku in a few weeks, when I can get him to write something up about himself. Looking forward to using original sounds and music in the game instead of placeholders.

I spent today listening to the Tron: Legacy soundtrack and designing trees. I have 5 different types now, which should be enough for the moment:

Here’s an attempt at a tree-lined street: