I make games

Gotland Game Conference

It’s been a week since we showed the game at GGC and it still feels quite good. We went through the feedback yesterday and even though there’s a lot to fix there wasn’t really any large issues that we hadn’t thought of/knew about already, which is always comforting.

Most of the feedback was about simply making the experience smoother. There’s quite a few things that’s not clear to the player, mostly because we couldn’t fit enough tutorial puzzles into our GGC build. And also, as you would expect with a project of this scope within this timeframe, there’s some bugs here and there – but only one rare gamebreaking bug that I can think of right now!

Needing to cut on the levels was the exact reason for us to include the sandbox level. We’ve got more mechanics implemented than we had space to show and the sandbox level does just that.

We certainly went for a big game during this project and succeeded in just that. We could have easily made something smaller and more polished but I’m glad that we aimed so high with this project. I (and I’m sure, the rest of the team) learned things we didn’t really think we ever would. What we’ve been doing the last months has been insane and there’s so much to be proud of.


Guiding the player

After some testing, we discovered that players would lose their way in one of the areas in the factory level, and become unsure of where to go next. It simply left most people confused. Before going into what I/we did to fix it, lets break down the problem(s).


  1. This is what you see when you first enter the room. It’s not very interesting. Most people just simply walk forward without paying attention to what’s below or to the right, which is not what we had in mind.
  2. This is what you see if you look to the right when standing on the walkway visible in first shot. When designing the space I wanted to convey a sense of grandeur to the player, It feels like that somewhat succeeded but it’s at the cost guiding the player. Even though that’s the direction the player should go, it’s not clear exactly where you should be heading, which it reasonably should be.
  3. This is an overview of the entire area. The large open spaces gave the player room to play around with the robots, but at the same time it contributed to the confusion. Players felt like there had to be a more meaningful purpose to the area.
  4. This is where the player is suppose to go, the opening next to the rotating paddle wheel. The player needs to advance to the second half of the room to even be able to properly see this, and even then it’s somewhat obscure and difficult to see.


The screenshot above shows the view you now get when entering the area. What we did was cut the entire first part and re-positioned the entry point so that the player is directly infront of where they should be going. Even though there’s still some improvements to be made, it’s almost infinitely better than what it used to be.

Also, by cutting the first area we were able to put another puzzle in, which is something this level desperately needed. It was also possible to preserve the vista seen in 2nd of the smaller screenshots above, but with some changes to make sure the player doesn’t feel they should be able to get there directly.



Float precision

Float precision issues is something you always know is out there, but something you rarely need to pay any thought to. As you can guess, it’s an issue we ran into. When making a build, one of our puzzles involving a rotating platform would seemingly work, but not fire the event it was suppose to at the end of it’s movement. Not firing this event essentially locked the entire puzzle as the player was not able to rotate the platform into any of the states required to proceed.

After a lot of debugging and generally tearing our hair out, me and Kenth finally found the cause of the issue. To keep track of what rotation (and if it had reached its destination) the delta rotation was calculated and then added to a variable each frame, simply:

actualRotationDelta = Mathf.SmoothDampAngle(...) - m_rotatedDegrees;
... do rotation ...
m_rotatedDegrees += actualRotationDelta;

It turns out, in this particular case, the value calculated by Unitys SmoothDampAngle got below the Epsilon value at high framerates. What this means in practice is that the value got so small enough for it to more or less equal zero, making it completely useless.

The way we resolved this issue is to simply check if whether value of actualRotationDelta is less than the Epsilon and if we’re close to the rotation we’re rotating to. This is not a optimal solution but considering the time constraints we had it was the simplest to implement.

actualRotationDelta = Mathf.SmoothDampAngle(...) - m_rotatedDegrees;

if (actualRotationDelta < Mathf.Epsilon && Mathf.Abs(m_rotatedDegrees – targetRotation) < 0.001f)
… snap to target rotation …
… do rotation…

Lesson learned here is to prefer lerp, slerp and smoothstep functionality in the future. Sure, it’s slightly more hassle but you’ll completely steer clear of these sort of issues.