Tree Band Problem

David fixed the issue with the floating branches when you merge the tree. Mostly it had to do with getting quaternions right to handle the correct rotation.

We had another problem though, with the bands on the tree:


These are only supposed to appear at the base of the tree to indicate how many fruit cubes grow from it. I think Chris wrote the script so that it should only go on the trunk part, which should be separate from the rest of the tree.

Anyway, right now it is getting applied to the entire tree.

First Day of Unity Tools Programming

Long day of diving into Unity editor scripting. Not as productive as I would have liked, but finally getting somewhere by the end.

It’s been so long since I’ve had a whole day where I just focused on coding.

While I don’t particularly enjoy programming, it felt great to get back into that mindset again.

The mix of constant frustration and the joy/relief when you finally get something working.


So basically, I’m trying to write a tool that will let me make these lines easily:


At the moment, each line is made up a bunch of segments that I place individually, and it is a massive pain in the butt.

I’m going to be making a lot of these lines, so it’s best I main the process as painless as possible.

Lots of weird things about editor scripts in Unity, like the scene view not updating until I click on the inspector (uggghhh!)

I managed to get the blue lines to follow my cursor around in the scene view:


Eventually, I got a asset from the asset store that does mesh painting. It’s not exactly what I need, but it has a feature that would be really useful.

I’m starting to go through the code to extract to relevant stuff I need, and then will build the tool from there.


Been really busy the past several weeks, getting ready for name change announcement, and a ton of stuff in the works.

To be honest, I’m feeling pretty stressed out and overwhelmed. I think once the name change announcement is made, I’ll be able to rest for a bit.

Writing here just to let you all know development is still going, and I will get back into regular posts here soon.

I’m still streaming regularly over on Twitch:

Here are some screenshots of a glitch effect I’ve been playing with:

1 2 3 4

This happened due to some weird bug in the shader that renders the depth buffer inverted from everything else.

Here’s one of my favorite screenshots that I’ve taken in a very long time:


Also been working on water – that’s almost done. The hardest part is getting it to work with world wrapping. There’s a lot of edge cases.

David has also been working on a level editor. More stuff to show about that soon.

Pagoda Pillar Level

Last night’s stream started off as an attempt to put in the finishing touches of a level, and then ended up as a debug session in which we uncovered some changes with Unity’s instantiation code in their latest update. All in all, another typical night of gamedev.

Part 1:

Part 2:

Anyway, we did manage to solve the weird bug, but then Unity crashed pretty hard, so I ended the stream then.

Afterwards, I was able to set up the level to run again. It took some tweaking, but I think I finally got the level of scale I wanted in order to convey some sense of mystery:Relativity_01 Relativity_02 Relativity_03 Relativity_04

Game Critique and World 1 Rebuilding

On late Friday night/early Saturday morning, as I usually do, I shared some updates on the weekly Screenshot Saturday thread over at /r/gamdev.

Someone there read the devlog and the issue I had with the door scaling, and responded with this link to a per-object clipping plane shader in Unity. I haven’t had a chance to look at the post too closely yet or to play around with the shader script, but I think it might do the trick!

Game Design Critique Session

On Saturday, I went to another game design critique session. It was pretty much the same as the first one I participated in back in January, but this time, we had a few more games/people joining us:

We Are Chicago by Culture Shock Games
CodeMancer by Rob Lockhart (Little Important Games)

Just like last time, it was a really productive day and we had a lot of interesting discussions. There’s definitely a very diverse range of games being made here in Chicago.

I’ll be talking more about the specific design challenges I presented here in the coming days.

World 1 Rebuilding

The rest of the weekend has been spent dealing with administrative and bureaucratic (ie very boring) stuff.

However, I did get to take some time to work on rebuilding (and redesigning) world no. 1.

Here are a few shots of the level in progress:

1 2 3 4 5 6 7

Windows are pretty much my favorite things to design.

I also played around with adding depth of field to the camera. It’s a little too much, at least for gameplay, but I’m considering maybe adding a photography mode of some sort to the game? I’d definitely have to have some preset values for the focus and blur amount. As it is, it’s really easy to make awful looking images.

8 9

Object Carry System Overhaul (Yes, Again) – Spring-Raycast Raycast System

I continued to think about the object carry system, and decided to overhaul it one more time. I’ve actually lost count of how many times I’ve done this, but I think this time I’ve actually done it.

The last system I was using was the Spring Raycast System, which uses the spring method when the player was on the ground, and used the raycast system when the player was in free fall. More about that in this post.

However, there was still the problem when using the spring system, of the box you’re carrying penetrating other objects. In the last post, I posted on collision is very different depending on whether the rigidbody is kinematic or not, and so I had to have a system which made all non-moving boxes kinematic so that the box you’re carrying doesn’t get pushed into it.

But even with having the rigidbody set to kinematic, it wasn’t always 100%. It’s incredibly difficult when relying on this, because even if it happens 1 out 1000 times, that’s still a problem. And because it’s a bug that does happen occasionally, but is difficult to replicate, it’s pretty hard to debug.

I decided to be safe and just create a fool proof system.

Spring-Raycast Raycast System

I’m going it the Spring-Raycast Raycast System, because now, the spring system actually incorporates raycasts as well. Like the Spring Raycast system, we use Spring-Raycast while the player is grounded, and Raycast when the player is in free fall.

How does the Spring-Raycast system work?

We still use the spring to control the movement of the box, and when the box isn’t in contact anything, it’s just at the end of the spring.

However, on the box, we’re also sending out a series of raycasts from each face. On each face, we shoot out a raycast from the center, and if that doesn’t hit anything, we shoot out raycasts from the corner.

The raycasts are very short. They are 0.6 in length. Given that the box is 1x1x1, this means each ray protrudes out of the box by 0.1 only.

As soon as the box comes close enough to an object such that the raycasts detect it, then we position the box based on the distance to hit. This allows the box to be straight up aligned with the object. There is a slight magnetic effect at close enough range, which I think is actually bonus.

Anyway, this basically takes the best part of the raycast system, and doesn’t have the problems I mentioned in this post, such as the carried box being positioned in small spaces and getting drawn on top of meshes.

We’ve taken the overall movement of using actual collision, and added the precision accuracy of raycasts. Best of both worlds!

This is what it looked like before with just the Spring Raycast system. The yellow box is kinematic, while the green box is not:

With the new Spring-Raycast Raycast system, it doesn’t matter whether the box is kinematic or not:

Box Raycast System

There was also the problem of boxes occasionally falling through things. A very mild case is something like this:

I thought by implementing grid snapping this would fix the problem.

In the above case, this would probably work, and the grid snapping would cause the box to align to wall. However, grid snapping doesn’t fix the problem if the box penetrate deeply enough, which is really the root of the problem.

If the box penetrates pretty far into what’s below it, grid snapping doesn’t fix it, like here:

Sometimes, even when grid snapping did correct the position of the box, there was one frame in which the box penetrated before being snapped back, and even though it wasn’t noticeable, if you knew it was there, you’d see it all the time, and it was visually quite jarring.

There was also the issue where occasionally the box wouldn’t detect that what’s below has moved, and would end up floating in mid-air.

Since raycasts worked really well for carrying the box, I decided to implement it in the boxes as well.

Whenever the box is in free fall, I send raycasts downward. Like the system for object carrying, it sends one ray downward from the center, if that doesn’t hit anything, then we send rays downward from the corners.

If any of those rays hit something, we align the box based on distance to the hit point.

And if the box is stationary, meaning that there is something beneath the box, it’ll also conduct a series of tests with the rays. But as soon as any of the rays detect something, it’ll break out of the test. We only need one true positive to confirm that it’s working correctly.

If none of the rays detect anything, that means nothing is below the box, and so it needs to fall.

Here’s a gif showing the new boxes in action: