DevLog Update – Lightmapping Problems Continue

Despite everything, it seems that I still don’t fully understand lightmapping in Unity3D. For some reason, I keep getting pieces of geometry that end up looking charred. It’s as if they’re being ignored by the lightmapping process. This is what it looks like from the game view:


As you can see, the platforms on the upper left and bottom right corners look really dark, as if they weren’t lightmapped.

Here’s what it looks like from the scene view, first without lightmapping applied, and then with lightmapping:



You can see that the same thing happened to the stairs on the left.

I honestly have no idea what’s going on here. This has happened to me several times already. Sometimes, I’ll select the problem geometry, and choose “Bake Selected”, and this will fix the problem. Sometimes, renaming objects can do the trick. However, there hasn’t been a consistent fix that has allowed me to pinpoint the problem.

In any case, here are a few tutorials on Unity lightmapping that I watched this morning while trying to find a solution. None of them helped me solve my problem, but they’re still good for getting a basic overview of lightmapping In Unity:

Lightmapping in Unity

Beast Lightmapping [UnityQuickTips]

ProBuilder: Super-Optimize Your Scene! (This one is specific to ProBuilder users)

DevLog Update – Redesigning Starting Level

Mostly been working on the redesign of the starting level of Relativity. This time around, I was able to approach the scene with the experience of having designed several other levels, and also having settled on various architectural elements that fit well with the game’s overall art direction.

I paid more attention to how the space is divided, as well as the the flow of player movement in going from one area to another. Basically, I wanted to maximize the function of each area in providing player with knowledge whilst minimizing any possible confusion. Of course, at this point, all of my theories are speculative, and only playtesting will tell whether the level is effective or not.

I’ve also made two additional improvements to the visuals:

  1. I’m quite happy with the new look of the windows. I made the grid a little bigger, and also changed the color of the lines from white to black. This has a little more contrast with the opaque walls.
  2. I’ve added an additional ring band around the interior of the door frame. It looks weird and unfinished when the decal line just ends right before the door, and this new look feels more complete. Compare the two images below:



They are two different kinds of doors, and that’s why the patterns of the decals are different. But you can see that when the line ends right before the door, it looks a bit awkward. Note that in both images the doors themselves are open and hidden inside the door frame.

And here are a few other screenshots:


DevLog Update – Doors

Took a break this past week from development to spend some holiday time with family and friends. Back to work on Relativity now, feeling refreshed and re-energized.

In reading some of my old posts on this devlog, I noticed that I’ve tended to focus mostly on technical aspects of the development process – optimization problems, etc. I think this has mostly been because these were the types of challenges I was dealing with these last few months.

I’m going to start talking about some of the design aspects of the game from now on, as I think you guys might find it interesting, and also I think it would help me organize my thoughts to write them down.


I’ve mentioned before that my design process is very iterative-driven. Instead of starting with any concept art, I’ll usually just go with a vague idea of something in my head, program up something with placeholder art, see how that goes, then rewrite everything with slight improvements. I’ll then repeat this process until I have something I’m happy with, or there’s something more important I need to work on.

This has been the case with doors in Relativity, which is now on the third version.

This was version 1:

I basically just placed some sci-fi looking texture on the doors, and had then move linearly when opening and closing.

During a playtest sessions, one of the feedbacks I recevied was that the aesthetic of the door didn’t really match that of the environment. Everything was so bare and minimalist, and contrasted very strongly with the texture on the door.

This led me to do version 2:

Here, you can see that because I’ve introduced the grid pattern to the environment, I decided to incorporate that pattern into the door as well. I also added a bit of ease-in and ease-out to the animation curve of the doors, so that they’re not just moving linearly. You can see the doors slowing down a bit towards the end while opening, which I really liked.

The problem with this design, however, is that it is biased towards certain planes. What I mean is that, because the doors open along one axis, it has an obvious up/down direction vs side direction. Since in Relativity, the player can walk on any surface, the environment should be designed so as to accomodate different perspectives.

So here’s the latest, version 3:

While it’s not the final version yet, you can see that by having the door break into 4 parts like this, it solves the bias problem in version 2. The door appears the same from 4 planes and thus accomodates all of those perspectives. To me, this design makes more sense given the physics of this world.

One other thing you will notice is that the wall around the door is flat against the surface of the door, instead of protruding forward a bit. This wasn’t so much of a design consideration, but more simply that I found a solution to a problem I couldn’t solve earlier.

Basically, in versions 1 and 2, the thickness of the door is 0.5 units, and the wall around it was 1 unit thick. The reason why this was done was because if the wall was 0.5 units thick, then when the door opened, the mesh of the door would overlap with the mesh of wall and cause a flickering effect.

By making the wall thicker than the door, I was able to hide the door mesh inside the wall mesh. However, this led to a number of other problems as most other walls were generally 0.5 units thick, and it would throw of the gemoetry.

When doing version 3, I realized I could make the mesh of the doors decrease in scale from 100% to 99%. This prevented the meshes from overlapping and flickering, and from the player’s point of view, the decrease in scale is not noticeable at all.

So anyway, this is where doors are at at the moment. I do think there are still improvements to be made. For one thing, I’m not too happy with the texture pattern at the momnet. Additionally, I think the animation can be a bit more snappy. I also need to get a good sound effect to go with the door opening and closing.

DevLog Update – Optimization & New Screenshots

After experimenting with a number of different settings and techniques, I was finally able to optimize the scene and get the frame rate back up to around 100.

Here are a few things I did:

  • Merged Geometry – Because I was ProBuilder to construct everything in the level, everything is built with pretty much a combination of boxes. This would often result in a building being made up of over 100 gameObjects (walls, steps, window frames, etc). I went through all the geometry and merged all the ones that were close together. I wanted to wait until I was almost finished with the level, because once the geometry is merged, you can’t unmerge it.
  • Changed Water Reflection Setting – I had a few pools of water in the scene. As it turns out, their reflection and refraction settings were set to respond to all the object layers in the scene. I’m not really going for a super realistic look with the game, so this was totally unnecessary. I reduced the layers that the water material responded to from 10 to 1, and this resulted in a huge improvement in performance
  • Lightmapped the scene – Since the scene is so large now, it takes quite a while to generate the light maps. However, once this is complete, the scene does run a little bit faster (and also looks way better).

Anyway, here are some new screenshots:





And here’s an isomorphic view of the entire level:

DevLog Update – Teamwork, Design Docs, Expanding the City

I met with Kiku, the sound designer and composer, on Sunday to discuss the music of Relativity. I’m learning that working in a team is very different from working solo.

For one thing, I’ve come to appreciate the power of design documents. Up until now, I hadn’t created a design document for Relativity, nor did I feel the need to. However, I think when you’re working in a team, it becomes a really powerful way to make sure everyone is on the same page.

I am continuing to expand the world within the game. Not doing so much programming these days. Mostly modeling and high-level design work on paper. Really looking forward to taking several days off next week to relax.

The level codenamed “The City” is the one I’m still working on. It’s about 70% complete now.


The Library – Weekend Progress

I spent the weekend working on a building I’m calling the Library for now. I’m not 100% sure yet what it’s purpose will be in the game, but I’m thinking of a place where players can go to find hints for other puzzles, or maybe find out more about the mysteries of the world.

I took some screenshots throughout the build process: