Basic Version of Intro

Lots of progress done on saving / loading system.

Super busy of late.

Anyway, finally got a basic version of the intro, loading screen, quit + fade to start screen going:

Basic Version of Intro

This stuff takes way longer than you’d expect. So much effort for these tiny details, but they really do contribute to the overall impression.

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.

world_map_001

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.

world_map_002

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.

world_map_003

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.

world_map_004

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:

ManifoldGarden_UI

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_optionA_Opaque

screen_optionD_gradient

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-BackAndResetReversed

Menu_Settings-Gameplay Menu_Settings-Controls-Keyboard

Menu_Settings-Controls-Controller

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.

Mouse:

mg_mouse

Keyboard:

mg_keyboardonly

Dualshock 4 controller:

mg_ps4

Xbox 360 controller:

mg_xbox360

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:

ManifoldGarden_UI_001

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:

UI_ManifoldGarden

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

 

 

Development Update – Controller Support for UI

controller support UI

Finally starting to implement controller support for the UI. Should have done this a long time ago.

It’s a real pain doing this with Unity 4.5, as there is no controller support for the GUI.

This problem is actually resolved in Unity 4.6. However, in Unity 4.6, I wasn’t able to open my main scene files. Not sure what the issue there is, but not being able to open scenes is kind of a deal breaker for me.

Anyway, ended up switching back to 4.5, and was able to hack together something with GUI.FocusControl.

The code is a total mess and I hate it, but I just need it to be sufficient for demo purposes. Eventually I will have to redo the entire UI for the game anyway.

Development Update – New Changes, Bit Bash, & IndieCade Feedback

Relativity_Game_Screenshot-2014-09-11_17-26-44

I am getting ready to go to Japan for the Tokyo Game Show. These last few days are getting pretty hectic with packing and making sure the build is ready, and of course, all the tiny little details that crop up last minute.

Anyway, I thought I’d take a moment to write about my experience showing Relativity at Bit Bash last weekend. I also heard back from IndieCade – unfortunately, I didn’t get in. I’d be lying if I said I wasn’t disappointed in the result, but the judges also gave me some really detailed and useful feedback. This is still a great opportunity to improve the game, and I’ll post their feedback  below, and share what I’ve  learned from this experience.

New Changes

Last month, I had the opportunity to show Relativity at SIGGRAPH as part of the MIX Showcase. I wrote about my experience and what I learned there in this devlog post.

Basically, after showing there, I realized that there were some serious design problems in the introductory part of the game.
When I got back to Chicago, I immediately scheduled a number of playtest sessions. I knew I had to redesign the introductory sequence in a very fundamental way before the Tokyo Game Show, and wanted to test out any changes, so I don’t run into unforeseen problems while exhibiting.

playtestingAbove – A friend invited me to his office to demo the game. Here is one of his co-workers playing the game.

I ended up doing about 4 playtest sessions a week for about 2 weeks, and slowly molded the intro into something new.

Here are some of the new changes I’ve made:

1. Interactive Instructions - Instead of having the instructions all in separate slides before the start of the game, the instructions now pop up during gameplay when players see the relevant element. Relativity_Game_Screenshot-2014-09-11_17-26-29 Relativity_Game_Screenshot-2014-09-11_17-26-37

2. Shortened the tutorial sequence - I want the player to get outside as soon as possible, as that is the real meat of the game, and the most impressive part visually. I realized that there were a few puzzles I had placed in the beginning indoor tutorial sequence that didn’t need to be there, and as such, could be moved elsewhere. For me, a good demo at a convention setting is when players make it through the interior tutorial section, and get outside. Too often though, I’d see people give up and leave right before the last puzzle. This was really anticlimactic, both because the player didn’t get to see the payoff for solving all these early puzzles, and also because they didn’t see the depth of the game. Relativity_Game_Screenshot-2014-09-11_19-21-43

3. First Hub World Overhaul - Completely redesigned the first hub world, effectively replacing it with the second hub world. From playtesting, everyone would talk about how much they liked the second hub world, while with the first hub world, people only talked about how often they got lost and how confusing it was.

Relativity_Game_Screenshot-2014-09-08_02-07-54

I think this is because the second hub world had logic to it. There was a meta-puzzle to the hub world itself, and this presented a sense of purpose, and a way to track progress. There were patterns that allowed the player to figure out where they had come from, and where they were going.

The original first hub was more or less random in design, and how you progressed through it depended largely on luck. Some playtesters told me that there was no sense of progression, and even when they did complete the level, it didn’t feel like they had completed it. They felt like they may have missed a thing or two.

After SIGGRAPH, I realized there was really no reason not to have the second hub as the first one. It’s better designed, easier to navigate, and everyone liked it. It was much larger than the first hub, but since it had a pattern and logic to its design, players found it much easier to deal with. It was only the second hub because that’s how I originally designed it, and my mind had come to accept that as reality.

4. Revamped the UI - I know it doesn’t make a difference in terms of the core gameplay, but having nice-looking UI really goes a long way!

Relativity_Game_Screenshot-2014-09-11_17-26-55

Bit Bash

bitbash

Bit Bash is a video game festival that a bunch of Chicago developers organized, which took place this past Saturday, September 6th. It was inspired by the Wild Rumpus party at GDC, and began as a series of conversations.

I won’t go too much into the festival itself, as there is plenty of information on the interwebz, except to say that it was a huge success with a turnout of around 1,400 people, and demonstrates that there is clearly a demand for such an event here in the Midwest. Also, the Chicago indie community is made up of a group of seriously awesome people, and I’m incredibly blessed to be based here.

IMG_6053Above – There was a huge crowd only an hour into the festival.

Anyway, showing the game at Bit Bash proved that all the design changes I had made were right. This time, instead of actively trying to recruit players, I would stand back and observe. And I noticed that people were making through the tutorial section and getting outside. It also helped a lot that I improved the start menu screen, so that it actually looked attractive and got players interested in it.

I had spent a lot of time on UI, and the game at Bit Bash was more or less able to run itself. There was a constant stream of players, and I didn’t have to stand around to reset it. Because of the improved UI and faster load time, people could very easily restart the game themselves.

I would stand in the distance and keep an eye on the screen, and after people finished playing, I would go up, introduce myself, and ask them some questions about what they thought. Almost everyone was able to make it the exterior parts of the level, so that was a very good sign.

Here are some shots of people playing the game at Bit Bash:

IMG_6060 IMG_6061 IMG_6067

IndieCade Feedback

Yesterday, I received an email from IndieCade informing me that Relativity wasn’t selected for this year’s festival. Needless to say, I was pretty disappointed. IndieCade was one of my top festivals I wanted to get into.

However, having seen the issues that arose when I was at SIGGRAPH, I can totally understand what happened. One of the really nice things about the IndieCade submission process is that the judges are required to give feedback on the games they juried.

The feedback I got from the judges were very informative and detailed, and I totally agree with the points they made, especially regarding the box puzzles. In fact, during a playtest session about 2 weeks ago, a playtester told me that he found the box puzzles to detract from the main theme of the game, and were very tedious to play through. This got me thinking about their role in the game, and I’ve since decided to scale them back a lot. So it was great to read the comments from the judges about the box puzzles. It means that the decision to lessen the role of the block puzzles in the game is the right one.

As always, each feedback is an opportunity to improve the game. It definitely hurts when criticisms are made about your game, but it’s important not to get emotional about it. This isn’t about feeling good, it’s about making a great game!

It can be easy to dismiss the feedback from the judges, saying “they didn’t get it” or that “this is just not the kind of game they like”, and I’ve seen some people posting on twitter to this effect upon finding out they’ve been rejected.

However, from the feedback I received, it’s very clear that the judges took the time to play through the entirety of my demo (which takes on average about 3 hours for a first time player), so the judges clearly made an effort to play and understand my game. I really appreciate this, and since the judging process is anonymous, and there’s no incentive for the judge to lie, it’s really important to think about why the judges felt that way. It can be easy to blame the system, to become angry and say that your game was biased against, but I think it’s much more effective to use this opportunity to really analyze your game – ask yourself if the design is really that good, and what’s holding it back? It’s not fun, but it’ll make your game better.

Anyway, since the feedback given was anonymous, I’ve decided to post it here in its entirety (this is for the version of the game in July 2014):

—–

Once my head got used to it and didn’t hurt anymore from switching, the game was interesting. However at one point I did feel like I was doing stacking boxes against a ledge. Navigating the balls through the tunnels bugged a bit in the big puzzle; the ball fell through the doors I was meant to open. ‘
In the seemingly endless staircase, I guess this was sort of the end of the game for now? I could revisit previous puzzles, and a place with cubicle-likes connected to each other. I fell through a connecting beam that was glitching with green. I also fell out of the endless staircase that didn’t turn out to be endless (red gravity). Here was another of those cubicle-like below it, but I missed it and fell into the void.

I think I was able to skip some puzzles in the first open world, I didn’t need to use a blue box there. I just fell myself toward the green pop and could make it from there.

I hope that if you’ll make more puzzles, you’ll be able to make some that feel more different from each other. The box-against-the-wall puzzles are different from each other, but they don’t feel that much different, since the concept of solving them is often the same, just a little more difficult. I’m sure you can think of some that are more clever, rather than more difficult; it feels like you can get a little more out of this.. Surprise your player!

Hope you won’t think of me as too harsh. I love puzzle games (such as Antichamber and Portal, which seem like a big influence), but that’s why it feels familiar and the patterns are easy to recognize.

Good luck with the rest of the development!

—–

The core mechanic of Relativity has immense potential. The first time you flip the world and start walking on the ceiling to access a hidden corner of a room is a real thrill. That novelty and discovery propelled me through the much of the game. And while walking through the different rooms there’s a real sense of how the entire structure connects in greater way. Walking outside the buildings into the open spaces where you can see the worlds repeat infinitely is a unique and wonderful moment.

The individual puzzles though bog down the experience by making the focus of the game on block placement than the joy of shifting the axis of gravity and bending spaces. While there’s some clever puzzles based on following block-line connections across floors and walls too many times I felt like I was staring at the floor placing blocks over and over. The worst offenders here are the puzzles in which you are required to use blocks as temporary platforms to get across spaces. The effective landing area of the player is a lot smaller than you would think and each time you fall off and have to restart the process is an exercise in frustration.

Still though the newness of the mechanic really helped push me the more mundane moments. I look forward to seeing the experience as it develops and I feel this game with further refinement and polish can be something incredibly special.

—–

Art is great, shows a nice refrain given the subject matter. For more variety, maybe different superstructures could have different color schemes, bright, dark or colorful, etc. Something as simple as alternating the color scheme could really give different superstructures different moods.

I really enjoyed the mistake of slipping off the edge of the structure, it was a pretty clever way to handle ‘falling of the edge.’

While engaging at first, the box-stacking component of the gameplay became a bit tiresome, especially because you know the solution, but now you have to apply the repetitive movement to complete it. I wonder if experimenting with the box scaling could help with this?

I did enjoy falling off edges to get to strategic locations, which there was more of later in the game, like when you’re turning on the color-coded beams, you’re falling down into various nooks and cranies of the superstructure. There was one interior puzzle where, after an extensive box-stacking, I lept off with a box in hand to the desired platform.

I would’ve like to see more variety in the puzzles, maybe this could be a good angle? Since its a WASD first-person with a central gravity mechanic, I think considering more non-discrete acrobatic movement in the puzzles could help add diversity.

—–

IGF Feedback

The IndieCade feedback strongly parallels the feedback I received when I submitted Relativity to IGF last year. When I submitted Relativity in fall of 2013, I thought I had such a kick-ass demo, and the judges would be crazy not to choose this a finalist. Of course, this didn’t happen, and I was disappointed.

However, I continued to work on the game, to improve it, and by the time I got the feedback from the judges, in April 2014, I not only agreed with the problems they pointed out, but I had also started to address those.
In the spirit of open development, I meant to share the feedback I received for IGF when I received them, but had forgotten to, so I’m going to do it here. This is for the October 2013 version of the game:

——–

I just wanted to say that I had a great time playing Relativity, and I think the general premise has a lot of potential for some interesting puzzles. But I wanted to convey my thoughts that it felt like this was the BEGINNING of a much bigger and better experience. And by that I primarily mean how you progress. The colored box system works, but I don’t think that should be the primary form of interaction/progression. I don’t want to sound disrespectful when I say this (as I probably would be annoyed by this feedback if I worked on the game), but I would recommend trying to experiment with what it means to orient the gravity to each wall in a room. I think there’s a lot more that you can find if you mess around more. What if there was a linear progression through a room, with the room filled with stairs and hallways, and you had to go through the right order? What if this? What if that? As I played the game, I sorta got bored by the colored block requirement and I just started walking around the room, flipping the gravity. It was like a breath of fresh air, and it makes me think there should be something more inherent to that in terms of going through the game. It’s way more fun to think of where you are, instead of where the blocks are. I guess that’s it, base it on the player’s perspective primarily, not the block’s perspective. But again, this is your expression, so take what I say with a grain of salt. I think, with more time, it could be a great game. I definitely like the block idea, but I don’t think it’s the “true” form of the game.

Oh, and not sure how far along the game is, but try to differentiate yourself visually and narratively from Portal, otherwise players will think it’s a retread of what Valve already did. To me it definitely like I was playing Portal again, and that loses some of the wow factor. But overall, great job on it! I’ll be looking forward to what you do with it in the future :)

—–

Hi there – was very interesting playing through Relativity. As a game I think it’s definitely accomplishing some of what it sets out to do, but it also feels very very early in terms of things like setting and puzzle design, which I think is holding it back a bit for me in terms of voting for any of the categories.

Let me say, first, that I think that you really have got a lovely mechanic here, and one that’s much more interesting that just “look ma! I can walk on the wall!”. I think the way it changes your relationship to the space of the world is fantastic, more interesting than the Portal gun I think, in the way that it’s localized and perspective-changing. I had several occasions when I felt genuinely disoriented and the way that the game forces you to spend a lot of your time *not* taking an orientation to the world is really interesting (and slightly nauseating at times). I had a moment of running up some stairs while very much simultaneously thinking of myself as running *up* them toward a wall. These sorts of moments are just the kind of Escher-esque things that can be great about this game.

So, that said, I didn’t vote for any of the awards because it just feels too early. You have this really interesting mechanic and relationship to the world, but the world isn’t there yet, the puzzles aren’t really there yet, there’s no contextualization, no texture (literally and figuratively) and so on.

Very, very much looking forward to seeing where you take this.

Also a “bug” (perhaps it isn’t, it hard to tell in these sorts of environments) in the elevator cube thing – if I changed orientation while inside it I got spat out into the surrounding world. Which I initially thought was a kind of homage to Portal’s furnace scene, but didn’t actually seem to be. Nice potential easter egg to hide there somewhere maybe.

One minor technical comment is that I think it would make a *huge* different if the orientation change was just animated quite a lot faster (and perhaps more smoothly)… the jolt of stopping at a wall definitely removed some of the kinaesthetic enjoyment of the space…

—–

The puzzles were fun/interesting, but — in the end — was looking for more of a ‘hook’ to the game, other than the whole walking-on-walls thing. Would like to see some kind of story or ‘voice’ to set this game apart and make it feel like more than a Portal homage. Also, agree that the overall mechanics need to be tightened up/smoothed out to be an optimal experience. 

—–

Conclusion

Making a game is hard! For me, I’ve been working on this game alone for almost two years now. It’s like my baby now, and it can be really difficult to get an objective view of the game. My feelings toward the game can go from thinking it’s the coolest thing ever one day, to thinking that it’s absolute crap the next day. Rejection is never easy, and taking criticism is still difficult. I get butterflies in my stomach whenever I’m about to open an email with feedback on the game. However, honest, straightforward feedback that point out the problems in your game is hands down the best way for you to improve!

When I look at the IGF feedback and see how far the game has come, I know I can do the same for the IndieCade feedback!