next »

[William Chyr]

Devlog Update #261 - 11/21/2015

Manifold Garden - State of Development

The last few weeks have been crazy busy. I really need to get better at posting in the devlog more frequently.

I'm taking this weekend to write an update on everything: tools, game design, related projects, etc. It's going to be quite extensive, so I will break it up into parts.

Let's get started.

Tools Programming

David Laskey came on board to the project earlier this year, initially with the goal of working on optimization and PlayStation 4 port. Pretty soon after, David started working on a bunch of custom tools to help streamline the design process.

I didn't quite realize it at the time, but the project was basically going from pre-production to production. As in, the prototyping stage was more or less over, and it was time to refine the development process and trim inefficiencies.

I also started learning to write Unity3D editor extensions as a result of working with David, and it really has been such a huge help to production. There were so many processes that used to be super tedious and time consuming to do, which now have been refined.

The thing with tedious processes is also not just the time it takes up (although that is definitely a big factor). It also makes you mentally dread working on it, because it's just not fun. I'd be really in the zone making a level, iterating on areas, moving stuff around, and then all of a sudden, I have to make a window, which would just be tedium for an hour, and it would really kill the mood for me.

Also, it meant I was reluctant to iterate. If a window was good enough, but not great, I would just leave it at good enough, because the time it would take to get up to great just didn't feel worth it.

The window making process is just one example. There were a lot of similar task that were incredibly tedious for me to perform, and the last several months, we've put a lot of time into trimming these inefficiencies.

I'm going to start talking about all these tools in detail in these next few updates.

We'll start with the window generator.

Window Generator

Here's a quick video showing a timelapse comparing the old and the new ways of making windows in Unity for Manifold Garden:



The old way:



Here's how I built windows the old way (everything is done with ProBuilder here, just FYI):

1. Make a "backboard" that is the dimension of the window I want. This gives me a reference for the size

2. Start putting in frame pieces. Almost every straight segment is a separate piece.

3. Horizontal and vertical pieces are colored differently so I can tell them apart.

4. Place the window pieces. These are also colored differently than the frame pieces.

5. Color the outside faces of the window to be the glass material

6. Merge the frame pieces and the glass pieces (but first need to save the version with the separate pieces in case I want to come back and make changes).

For a complicated design, this can easily take an hour or more. In the gif, I was just randomly putting pieces in place without actually thinking of the design, and that still took 10 minutes.

Also, if I wanted to make changes to a design, it was a lot like having to rebuild the entire window again. Even a small change involved moving a bunch of pieces out of the way and readjusting their sizes. It was not fun.

The new way:



One of the first tools that David worked on when he joined was the window generator. I showed him the old process and we both agreed that it needed to go.

It felt like the most natural way of designing the windows, since they were basically 2D designs, was to design in photoshop, and then extrude that into a 2D shape.

For the process now, I basically have a grid in photoshop, each pixel is 0.25 units, make the design there, and then open up the window generator tool from Unity, which automatically makes a 3D version of the window and has it automatically prefabbed and aligned to the grid.

For the image, grey means frame, white means glass, and black means cutout.

Using photoshop means that I can take advantage of all the photoshop features (layers, invert, etc) when doing the actual design.

An entire window, even complicated one, instead of taking hours, can now take just minutes.

It's easily my favorite tool in the engine.

If you're interested in how the window tool works, David actually came on the stream a few weeks ago to talk about the tech behind it. It was storming in Chicago that day, so there were some internet issues, and the stream got cut up into 2 parts.

Here's part 1:



Here's part 2:

[Connor]

valkyria chronicles! woooooo

[William Chyr]

valkyria chronicles! woooooo

Haha, ya, David is a big fan of the game. I've never actually played it.

[William Chyr]

Devlog Update #262 - 11/22/2015

Tools Programming - Staircase Generator



There are A LOT of staircases in Manifold Garden.

In fact, some levels consist entirely of staircases:



It took way too long for me to finally get around to writing a staircase generator, but I'm really glad I did.

Now, ProBuilder does have a staircase generator, but the stairs in Manifold Garden have to be built in a very specific way.

Thin Stairs

0.5 is the smallest unit for the geometry in Manifold Garden. All the floors, walls, etc, are at least 0.5 units thick.

Since you can change gravity and walk on any surface in the game, every staircase needs to work on both sides. The player can walk on the top surface of the stairs, as well as the bottom surface of the stairs.

If the floor is 0.5 units thick, the stairs must be built like this:



Here's how I would build it:



The individual steps are ProBuilder cubes, which I have to manually put in place. Once there are few, you can speed up the process by duplicating multiple steps at a time. It's still quite slow though.

Then I have to make the "ghost steps". These are the small invisible steps that the player actually walks on. The visible steps are actually too tall for the player to climb, since the player doesn't actually have legs and is a just a capsule.

The ghost steps are made with ProBuilder staircase tool. However, it still takes time to figure out the size of the ghost steps, the number of steps, and also to put it in the correct position.

Anyway, for a long time, due to the 0.5 thickness requirement, I actually thought that all floors had to be 0.5 units thick and no more.

Thick Stairs

Eventually, I realized that there was actually a way to build stairs to allow for thicker floors. Thicker floors are actually quite nice because this means that the player can walk on the sides of the staircase as well, instead of just the top and the bottom.

The key was to stack the steps horizontally instead of vertically, like so:



As you can see in the image above, this allows for the floor to be 2 units thick while still making the staircase work from both top and bottom surfaces.

The build process is pretty much the same as that for thin steps (here I copied the ghost steps from another staircase):



Staircase Generator

Anyway, finally decided to write a tool to automate this process:



The tool automatically decides whether to stack horizontally or vertically depending on the step height assigned, and places the ghost steps accordingly. It also puts everything inside a parent object and names it with the width, height, and number of steps. It also assigns the correct tags and layers to the objects.

Here it is in action:



The tool took about a weekend to make, and now a step that was rather tedious for me, and took minutes to do, is now done 3, 4 button clicks in the span of a few seconds.

[William Chyr]

Devlog Update #263 - 11/22/2015

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.



Here are some of the tree designs:




 




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:



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.



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:



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 . That will be in the next update.

[William Chyr]

Devlog Update #264 - 11/22/2015

Tools Programming - Tree Finalizer

After a tree is made by the tree generator, all the parts are actually separate individual components, parented to the object it spawned from.

As you can see here by the object hierarchy on the right:



This is necessary, because often I still need to do a bit of editing to the tree - removing overlapping branches, rotating trunk pieces, etc.

Once that is done, all the trunk and branch pieces need to get merged together, as well as the leaves, and then everything needs to have the appropriate materials and scripts applied.

There are also some additional considerations, such as adding the "tree base cube" - this is the cube at the base of the tree that the tree grew from, the soil patch, and also any cubes that are growing from the tree.

Instead of manually dragging the scripts and prefabs and placing them in the hierarchy, it's just much easier to automate this with a tool.

Here's what the tree finalizer window looks like:



A bunch of the processing is optional. In the case in the above image, everything is selected, and we're generated 2 cubes to grow from the tree.

When you click to finalize the tree, a warning message comes up. This is important as the trunk and leaves are merged into separate individual meshes and there is no undo.



Here's what it looks like when the tree has been finalized.



Note the hierarchy of objects on the right. There's the "branch" object, the "leaf" object, leafShadow is an object specifically for the shadow of the leaf due to some weirdness with shaders. Note that there are two CubeSpawnPoints. They are both placed at the base of the tree so they're overlapping. You have to manually move them to the position you want, but this is something that I wouldn't want to be automated anyway, as the placement needs to be carefully designed.

[William Chyr]

Devlog Update #265 - 11/22/2015

Tools Programming - Line Mesh Generator



Lines are pretty important in Manifold Garden. They connect switches to doors or other objects, and a light travels through them to know when it has been switched on.

Originally, lines were made with separate individual prefabs.

Each segment had to be scaled and placed manually, and every corner needed a separate piece. Not only that, I also had to manually toggle the corner to invert the material if the bend was going the other way. The default corner material is for bending right, so if it was left bend, the material needed to get flipped.

The segments also needed to be placed in the right order, as that was how the line manager figured out in which sequences the lines should turn on. It was a bit of a mess from the code standpoint as well, with each line having to check the previous line to get the timing of when it should turn on.

Anyway, here's how it was built:



As you can see, very tedious.

Decided to finally write a tool for this. Here's the line mesh generator in action:



How this works is I bring up the tool, and I can select what kind of line (cube, button activator, or independent). The difference is that it will attach the finished line mesh to the appropriate object with the appropriate script.

Then, I just hit 'P' to place down the marker. There is also undo, which is great, as occasionally you can place the marker just a little off. David wrote the undo feature, but I believe it's just using a stack and putting things on and taking them off accordingly.

A preview of the mesh is generated as the markers are placed down, and when you're ready, just hit "Form Mesh" and the final mesh is formed. All as one piece, instead of multiple different segments, so much easier to manage.

The trickiest part was getting the correct offsets and UI for it. The actual mesh generating stuff is actually almost exactly the same as the mesh generation for water, which Chris Wade had written several weeks back.

The new water system actually generates a new mesh every frame, and simply updates the points of the mesh based on what happens. Because the water also handles bends in various directions (left, right, up, and down), the code for setting the vertices of the mesh was just what I needed for the line mesh generator.

The key for the tool was setting up markers as line is placed. They are restricted to be along the axis of the previous marker, so that you can't make diagonal lines (which I don't want anyway). Also, a marker doesn't know which way it is bending until the next marker is placed, so there is some back communication.

[William Chyr]

Devlog Update #266 - 11/22/2015

I spent almost the entire weekend updating this devlog. The tools stuff is now up to date.

[William Chyr]

Devlog Update #267 - 11/23/2015

Tree Merging Tool Problem

If you rotate any part of the tree and then apply mesh merge, you end up with floating branches. Needs to get fixed.

[William Chyr]

Devlog Update #268 - 11/23/2015

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.

[William Chyr]

Devlog Update #269 - 11/24/2015

David and I are really working hard to get photography mode in place for the PlayStation Experience build. More info on that soon.

In the meantime, here's the design for the banner of my booth at PSX. Just submitted it to the printer.

[insideoutgames]

Very cool concept, even the early gameplay seems really cool. It's nice that you did leave the old Relativity stuff up, it really shows how far your games come. I really did the portal/antichamber vibe it has going for it too, yet it's different enough from both to stand out on its own. I look forward to seeing more.

[William Chyr]

Very cool concept, even the early gameplay seems really cool. It's nice that you did leave the old Relativity stuff up, it really shows how far your games come. I really did the portal/antichamber vibe it has going for it too, yet it's different enough from both to stand out on its own. I look forward to seeing more.

Thank you! Really happy to hear this.

Ya, I'm keeping everything up here, mistakes and all. It's great as a reference to see where to game came from, both for myself and readers.

[William Chyr]

Devlog Update #270 - 11/28/2015

Manifold Garden 3 Year Development Anniversary

The very first prototype of what became Manifold Garden was written during the 4-day Thanksgiving weekend 3 years ago, in 2012.

It was initially intended to be a small project to learn Unity with. I thought I would be finished in about 3 months. Never would I have guessed 3 years later I'd still be working on it, and yet here we are.

Here's a comparison of the very first level of the game, in the very first version vs the latest build of the game.



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





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



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



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

Beam Mesh Z-Fighting



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



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.

[William Chyr]

Devlog Update #271 - 11/29/2015

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.

[William Chyr]

Devlog Update #272 - 11/30/2015

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



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.

[William Chyr]

Devlog Update #273 - 11/30/2015

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:



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:



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:



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:

[deab]

Very unsatisfying when a 'fix' doesn't fix the underlying issue, no doubt you'll get to the bottom of it.

Had similar issues with coroutines recently - hard to debug, especially when they are called every frame. Avoid this now by running a single coroutine per object that can run multiple tasks, rather than starting/ending multiple coroutines for 1 object.

[YaW]

Those kind of problems are a pain in the ass, but I'm sure you'll end up finding why that happens.

The game is looking so great I'm feeling a little envious, haha. So beautiful in its own complexity...

[William Chyr]

Very unsatisfying when a 'fix' doesn't fix the underlying issue, no doubt you'll get to the bottom of it.

Had similar issues with coroutines recently - hard to debug, especially when they are called every frame. Avoid this now by running a single coroutine per object that can run multiple tasks, rather than starting/ending multiple coroutines for 1 object.

Yeah, David and I will be looking into the OnTriggerEnter issue. Hopefully an update soon on the problem.

I have to admit, coroutines still trip me up, even after having used them a bunch.

The game is looking so great I'm feeling a little envious, haha. So beautiful in its own complexity...

Thank you so much! It's really just a matter of lots of little changes piling up together over time.