Cube Switch Activator Bug

Solved another bug tonight, but in the “not really” kind of way that makes me very uncomfortable.

Here’s the issue:

manifold_garden_cubeSwitchingBug

When you pick the cube from the tree, the one that is out on the switch (which is connected to the one on the tree) is reset and you can see it shrink away and disappear. However, the switch stays active and the door remains is open.

This needs to be addressed because this is not how the switch activators work, and the player ends up with an extra block.

After a bit of digging around, it turns out that OnTriggerEnter() is getting called twice:

OnTriggerEnter

I couldn’t figure out why this is. I think it has something to do with the cube changing layers when it goes from being held by the player to being on its own? I will have to look into this tomorrow.

The switch keeps track of the number of cubes in it in a list: _currentTriggeringCubes

Because OnTriggerEnter() is being called twice, the gravity cube is getting added twice to _currentTriggeringCubes.

When you go to remove the cube, it only deducts a count of 1, and so the switch thinks there’s still one cube left in it when in fact there are non.

I added this code to check to see if the cube is already inside the list before adding it:

manifold_garden_code

This check is good to have anyway, but it really bothers me that I can’t figure out why the OnTriggerEnter() method is getting called twice. Inevitably this bug will come up somewhere else later and end up causing other problems. I will ask David about it in the morning.

Anyway, here’s the switch working correctly: manifold_garden_cubeSwitchCorrect

Cube Growing Back in Wrong Color – Fixed

Streamed for a bit tonight, and actually did figure out the issue with the cube growing back the wrong color.

manifold_garden_cubeGrowingBackInWrongOrder

Basically, the tree cube spawner instantiates 2 cubes at start. One is enabled, and one is not.

All cubes are actually instantiated as blue cubes, and then the colors are set accordingly (since they all need their own material instances anyway).

When you grab a cube, it basically swaps the two, putting one on the tree, making the other active off-tree.

It turned out there was a block of code where the color of the cube was being set that was for some reason commented out

Uncommenting it did the trick. Simple enough, but it did they me a while to get there. Most of it was figuring out the logic of the code.

manifold_garden_cubeGrowingBackInCorrectOrder

 

Fruit Cube Spawning

Fixed a bunch of minor bugs last night, mostly getting audio stuff to work correctly again.

Now starting to go through and understand the system for tree fruit cube spawning. It’s a bit complicated as it relies on delegates from the cube itself to call the spawner to decide when to reset the cube and so on.

Will probably just need to read through the code several times to fully understand it.

manifold_garden_fruitCubeSpawning

 

Manifold Garden 3 Year Development Anniversary

ManifoldGarden_2012vs2015

3 years sure makes a big difference.

Life

Took Thursday off for thanksgiving. Did not working on Manifold Garden at all. Helped cook, ate, and then played NBA 2K. It was awesome.

Latest Build Update

Anyway, getting ready for PSX next week. Thought I’d post about different issues with the game here. I’m working to address them all this weekend.

Regrown Cube Color Messed Up 

manifold_garden_regrownCube_001 manifold_garden_regrownCube_002

When you pick a cube off of a tree and it grows back, it should grow back the color of the cube, but translucent. That way, you know there’s a cube out there that you’ll be destroying as you pick this. Right now, the cubes are all growing back blue regardless of what their correct gravities are.

Tree Mesh Normal Screwed Up

manifold_garden_treeMeshScrewedUp

When trees are made with the tree generator tool, every segment is a separate piece. There’s a tool, “The Tree Finalizer”, which merges everything together into a single mesh (for optimization and management purposes). For some reason, when the mesh is merged, the normals get screwed up. If you look in the picture, you can see the side of part of the tree is blue. Only the top surface should be blue.

Cube Material Is See Through

manifold_garden_cubeMaterialSeeThrough

Shouldn’t look like this. Should be opaque. Pretty sure this has something to do with the shader.

Beam Mesh Z-Fighting

manifold_garden_zmeshFighting

When not extended, the beam mesh is this black plane which results in really ugly z-fighting.

Cube goes through wall when player standing on stairs

manifold_garden_cubeGoesThroughWall

I think this is because when you’re on stairs, I actually make the player weightless, which I think tricks the player object into thinking there’s nothing beneath the player, which changes the state of the cube that the player is carrying (removes actual physics). Will need to look into this obviously.

Sound messed up

The sound for a bunch of objects is screwed up, but I can’t really show that visually.

Plans for rest of weekend

Fix bugs and test the full game on PS4 devkit.

Tools Programming – Tree Generator

Trees are a pretty important part of the core gameplay system of Manifold Garden. After all, trees are the source of the cubes, which are used to solve puzzles, bend water, and grow more trees.

Tree Generator

Here are some of the tree designs:

ManifoldGarden_Tree01 ManifoldGarden_Tree02 ManifoldGarden_Tree03 ManifoldGarden_Tree04

All of the trees above were made by hand. You can see that the same tree repeats many times. I was originally planning to make 100 trees by hand. I made about 4, before I realized that process was not fun and also super tedious.

Here is how I used to build trees:

tree building old method

Like the old ways of building stairs and windows, it involved using ProBuilder and building each separate component, manually sizing and placing every segment.

Some people have asked “why not just create a set of 10 trees or so and randomize their placement?”.

The reason is because the volume of the tree matters a lot in a level. If there are only a set number of trees, I would actually have to design the level based around their volume, and the specific needs of trees vary widely from location to location.

A much more typical process for me is I’ll design a level, and then go: “this area needs a tree, but it needs to be 20x40x20 in volume, because of the setup of the level”. If I just have a fixed set of trees to choose from, it’s highly unlikely I’ll find a tree that’s exactly of that size.

Also, using a fixed set of trees can get pretty obvious to the player.

Anyway, the trees do follow a very specific ruleset in their look, so there’s really no reason that the process can’t be automated.

David and I decided to make a tree generator for this.

tree generator

As you can see, it takes a lot of input. You can choose the probability for growing upwards, the probability of a trunk or branch splitting into two, the range for each segment (vertical or horizontal), etc.

The red outline box is the tree boundary, and the green outline box is the trunk boundary. The idea is that the trunk would never grow outside of the green box, and the tree would never grow outside of the red box. They’re kind of soft boundaries (especially the red box as the leaves can go past the boundary). However, it’s pretty easy to tweak, which is part of the tool design.

You hit “Generate Tree” to create a tree, and then if you actually want to make it a tree in the game, you hit “Actually Create Tree”. This allows me to go through a bunch of variations to pick out the one I need, which is really great.

Once the tree is generated, it’s actually all in separate parts, with each branch parented to the one it grew out from, so it’s quite easy to edit (or should I say… prune?) the tree and tweak it till I get exactly what I want.

It also saves the seed value, so you can always go back to the base design.

Here’s the tool in action:

tree building new method

The key with the tree generation algorithm is that each segment uses world coordinates to determine the direction. So the y positive is always up. This was thanks to David.

I’ve done some procedural generation with fractals before, and always used local coordinate systems, with each object passing on its rotation and position with relation to its parent to the next object. In this case, none of the objects had a sense of the objective up, only in relation to its previous object. This would actually have been pretty complicated, involving passing on rotation with matrices and all that.

Using the world coordinate system worked out quite well in this case and made the algorithm a lot easier to manage and piece together. It works in this case because the trees do have a sense of “up” when growing.

Anyway, what I love about the tool is that in the time it used to take me to make one tree, I can go through hundreds of design in the same time.

Once the tree is built, there still needs to be some processing done to make it work in the game. Of course, I made a tool for this as well Smiley. That will be in the next update.