next »

[Torchkas]

I like the stair physics in theory, but I think you really should add a camera bounce to make it feel better.

This is a great devlog. You haven't really been showing the level design which is probably intended. I think this is a really good method of keeping people up with progress.

Also the trees are cool. You should give them backstory or something.

[William Chyr]

Devlog Update #183 - 03/28/2015

I like the stair physics in theory, but I think you really should add a camera bounce to make it feel better.

This is a great devlog. You haven't really been showing the level design which is probably intended. I think this is a really good method of keeping people up with progress.

Also the trees are cool. You should give them backstory or something.

There is already a bit of head bobbing when you're walking, and it does happen when going up and down the stairs. In the gifs I posted, I think the stairs are too short for the effect to be noticeable.

I haven't been doing much level design of late, mostly because I'm focusing on getting all the code for the systems to be perfect, or at least to not have any game-breaking bugs. I will hopefully be getting back into level design around middle of next month. However, you're right in that I won't be showing much of that even then. With a game like this, it's hard to talk about level design without spoiling much of the game.

Fortunately, there's still plenty to talk about besides level design, such as...

Traveling Light on Switch and Doors!

Got the light on the line to work together with the switch:



I think it works better for the entire line to go off when the box is removed, instead of having the light slowly retreat, as that would look pretty weird just to have the light on but not the box there. Also feels more snappy that way.

Also worked on door animation:



I think I'd like to draw up some more designs of doors. I like the way this opens (feels very equal on all sides, which is necessary for the mechanic), but I wonder if the actual design can be improved.

Calling the door animation from script was a bit more tricky as Unity 5 has changed the API for animation, and it's quite confusing coming from Unity 4.

Basically, it seems like one has to use animator now instead of animation component, and it's animation states instead of animation clips.

Here's how the script looked to get the call the animation from within a script:

Code:

using UnityEngine;
using System.Collections;

public class DoorController : MonoBehaviour {

	void Start () {
      
	}
	
	// Update is called once per frame
	void Update () {

        if (Input.GetKeyDown(KeyCode.T)) {
            
            GetComponent<Animator>().Play("DoorOpen");
        }

        if (Input.GetKeyDown(KeyCode.Y)) {
         
            GetComponent<Animator>().Play("DoorClose");
        }
	
	}
}

Once that was done, it was just a matter of connecting the door to the switch:



It feels quite satisfying, but I'm going to make it so that the door doesn't open until the light travels across the path and hits it. Right now the door opens right when the box gets placed on the square, and I think it feels a little bit off.

[dmcondolora]

Love this dev log! Really fascinating stuff, and the game is looking more and more beautiful.

Regarding the old Animation system, I've been able to use it without issue in Unity 5 so far. Is there an advantage to switching to Animator? I know that Animation is sort of deprecated, but its functionality makes more sense for a lot of what I'm doing.

[William Chyr]

Love this dev log! Really fascinating stuff, and the game is looking more and more beautiful.

Regarding the old Animation system, I've been able to use it without issue in Unity 5 so far. Is there an advantage to switching to Animator? I know that Animation is sort of deprecated, but its functionality makes more sense for a lot of what I'm doing.

Thanks so much!

Regarding the animation system - I'm actually not too sure about the exact differences between the new system and the legacy system. I actually find the new one to be way more complicated than what I need it for.

I would have stuck with the legacy system, except I couldn't exactly figure out why it wasn't working for me, so I switched to the new one instead. For me, it was just a matter of changing a few API calls.

It sounds the legacy system has been working fine for you. If I were in your shoes, I would just stick with that, until you find that for some reason, you really need to upgrade to the new system.

[William Chyr]

Devlog Update #184 - 03/29/2015

Found out today I didn't get into A MAZE Festival

Will try again next year!

Anyway, some good news is that I got the switch working so that the door opens *after* the light travels through the path and reaches it:



It feels really satisfying!

[William Chyr]

Devlog Update #185 - 03/30/2015

Got the basics of fruit growing on tree working.



In the above gif, the animation looks pretty dead. It's just a linear growth rate.

I then switched to using an animation curve to control the growth rate, and made it so the box actually is larger than normal at a certain point to add some juiciness to the animation.

Found this really funny glitch while playing around:



Anyway, you can pick the box off of the tree and then use that box to open a door:



It was a really cool moment when I finally saw this. I've had this idea in my head for so long.... Since Tokyo Game Show in October I believe. To finally see it in action felt very weird, but incredibly satisfying.

Like I knew exactly what to expect since I wrote it, but to actually see something with my eyes that I had been picturing in my head for so long... I couldn't stop laughing.  

[William Chyr]

Devlog Update #186 - 03/30/2015

Worked on both growing and shrinking of the cubes today.



Most of the day was spent trying to get the coroutine order right, and to have the cube that's not on the tree be destroyed as soon as you pick the new cube off the tree (so that's there's only ever one cube at a time).

Eventually got it so that when you pick a cube off the tree, a new one grows in its place:



Lots of bugs still, and it's going to be a while before I get everything right.

[dmcondolora]

It sounds the legacy system has been working fine for you. If I were in your shoes, I would just stick with that, until you find that for some reason, you really need to upgrade to the new system.

Thanks for the info! I'll do that. Hopefully it won't give me any trouble.

- David

[mokesmoe]

I don't like the way the doors squish open, it looks really weird. I think it would look better if the doors slid open but it would probably be difficult to do that without the door segments clipping out of the frame.

[William Chyr]

I don't like the way the doors squish open, it looks really weird. I think it would look better if the doors slid open but it would probably be difficult to do that without the door segments clipping out of the frame.

Is it really that noticeable? Ideally I would like the door to not look squished, but to instead look like they go into the frame. The problem is indeed that then the segments would move out of the frame, like in the situation shown in the gif.

I guess one way would be to have the door segments move without scaling, and then do something where the ends get clipped, or they become invisible.

I will look into this and see if there's a solution. It does bother me too, but was hoping I could get away with it not being super noticeable.

FWIW, I've had people ask me whether it was scaling or clipping. They couldn't tell until they slowed down the gif.

[Jeddychan]

Is it really that noticeable? Ideally I would like the door that look squished, but to instead look like they go into the frame. The problem is indeed that then the segments would move out of the frame, like in the situation shown in the gif.

I was able to notice it, but I hadn't put much thought into a better solution so I never mentioned it. I have thought about it lately though.

So, if the door is going to be used as a door, isn't it going to have to have walls and whatnot attached to it? if so, wouldn't the walls give you some space for the doors to slide into? It might not be a perfect solution, but it's the best I've got currently.

EDIT: Read your tweet about walls being orthogonal to the door. Never-mind my suggestion! I know you'll be able to figure something out.

[Zorg]

I did not notice it until someone mentioned it. If you have walls around, slide would be cooler, but i don't think that many players would even notice the squish or think it's a flaw, if they to.

[William Chyr]

Devlog Update #187 - 03/31/2015

Decided to take a look at the door segment scaling issue. The way I hide away the door segments into the frame of the door is by scaling it in the direction of movement.

Here's what it looks like slowed down:



Here it is without scaling:



I could just leave it this way without scaling and simply hide the door segments in the surround walls, but the problem is sometimes the surrounding walls are orthogonal to the door, like this:



Not to mention the floor...

Anyway, I looked into seeing if I could resolve this by using a shader that makes the parts of the door that protrude transparent.

However, this ended up being much more complicated because of the edge detection shader.

If the object is rendered in the transparent queue, it's rendered after post-processing, but this means you can see the edges of other objects through parts of the object that are opaque:



In the above image, it's supposed to be stripes of transparency - the white parts should be opaque and you shouldn't be able to see black edges through it.

But if I render the object not as part of the transparent queue, but before post-processing, the outline of the object itself gets drawn. Notice that an edge is drawn along the part that is supposed to be transparent:



Obviously, I don't want to see the outline of the door segment that's protruding.

Another approach that I thought would work would be the replace the door segment with a single box with a texture applied on top, and then offset the texture based on how much scaling was done.

However, that had the same issue with the edges. The door segment with the texture (float in front) looks very different than the actual door:



Some people on twitter suggested simply modeling and animating the door in a 3D software, and have parts that nest into each other as the door goes into the frame. This would work.

However, I thought about it some more, and I don't think it's really an issue I need to worry about. The scaling seemed very obvious in the gifs I posted mostly because time was slowed down quite a bit. In the game, the door opening happens in 0.3 seconds. It's literally a fraction of a second, and given that players are usually standing some distance away when the door opens (because they're pressing a button or putting a box on a switch), the scaling effect would be hardly noticeable.

You can see the door in action in the gif below, in which I demonstrate cubefruit regrow and destruction (that happens behind the camera), working with the traveling light path and the door switch in a perfect loop:



The door opening is so quick I don't think it's anything to worry about at least for now. If it really proves to be a problem later on, I'll just get a 3D artist to animate it with the suggestion above.

[William Chyr]

Devlog Update #188 - 04/01/2015

Ghost Fruitcube

One challenge with having the cubes grow on trees is that the player could pick a cube off a tree, carry the cube to some distance location and use that cube to open the door, then come back to the tree, pick the same cube again, and have the cube that's being used to open the door be destroyed inadvertently.

This problem did exist when I had the cube dispensers, and it also exists in Portal 2 (which is where I got the idea for the cube dispensers from). In the case of Portal 2, the game doesn't let you sneak boxes out of designated areas. Most puzzle areas have that field at the door which desroys any object that the player is going, so it prevents you from carrying boxes out. Also, even in cases where you should be able to sneak a box out, Portal 2 will reset the area with load scenes. Basically, Portal 2 is a pretty linear experience and doesn't let the player break the game.

Here's what a cube dispenser looked like in an earlier build of the game:



By pressing the button, a number of cubes (in this case 2) would be dropped down. If you re-press the button, the cubes would get destroyed, and the same number of cubes would get dropped down again.

With the cube dispenser, I think players are less likely to "reset" the cubes, since it requires pressing down on a button, and the cubes are inside the dispenser. With the tree, it's more immediate, as you see the cube right there, available to pick.


Ryan Cousins and Alan Hazelden gave me some good suggestions with have the cube be a desaturated color if it has already been picked, or to show a "husk". I basically combined their suggestions and had cubes that have already been picked once (meaning that it exists out there somewhere), be translucent and lighter in color. I think it does a good job of showing that the cube is not a "legit" one, or at least warning the player a bit (pick at your own caution).



Fruit Picking from Tall Trees

A really cool unexpected new gameplay that arose with having cubes grow on trees is that picking the cube becomes a bit of a puzzle, if the fruitcube is up high on a tree:



This is what it looks like to climb up the tree and pick a high fruitcube:



What's really cool is that it becomes a bit of a platforming challenge, which I didn't think I could do in my game with the lack of death, and being able to change gravity more or less at will. This is actually pretty fun, and offers a change in the pacing of the game, as well as presents more of a navigational puzzle than a logic puzzle.

Finally, it also just feels really fun. When you finally pick the fruitcube, and drop it down to the ground, so you can go pick another fruitcube, it really feels like you're picking fruit!

Of course, the challenge here would be to make the platforming fun, but not tedious. I really dislike platforming in first-person myself, so definitely would not want to frustrate players on challenges that are purely execution-based.

Anyway, I'm really excited about this new gameplay aspect, and am looking forward to integrating it into the game in different areas. Pretty cool that I'm still discovering new things about the game!

[mokesmoe]

The door thing had been bugging me for a while, but I didn't bring it up because it was hard to tell if it was scaling and I wanted to be sure. What I'm trying to say is that even though players may not be able to tell that the door is scaling, they might still feel like something is off even though they can't put their finger on exactly what it is.

The only thing I can think of would be to make a several frame "animation" where the outside of the door gets cut off bit by bit. You would only need a few frames because the width of the door frame would cover up the choppiness.

(Also the door is still scaling a little in the "without scaling" picture. (sorry))

[William Chyr]

The door thing had been bugging me for a while, but I didn't bring it up because it was hard to tell if it was scaling and I wanted to be sure. What I'm trying to say is that even though players may not be able to tell that the door is scaling, they might still feel like something is off even though they can't put their finger on exactly what it is.

The only thing I can think of would be to make a several frame "animation" where the outside of the door gets cut off bit by bit. You would only need a few frames because the width of the door frame would cover up the choppiness.

(Also the door is still scaling a little in the "without scaling" picture. (sorry))

Really appreciate the feedback regarding the door. I will look into this issue in more detail and resolve it eventually (I do have a few more ideas for how I can make it work), but given that it's pretty minor in the scope of things, I'm going to leave it for now. It's important, but there are a few other design and technical issues that need to be addressed first.

I'm also considering the possibility of changing the door completely, so that it's more like a material which can dissolve into thin air and reappear. If you've played NaissanceE, it has similar door effect to what I have in mind.

Regarding the scaling that's happening in the "without scaling" picture, I think your eyes are playing tricks... I'm doing the scaling via Unity's animation system, where I set the value of what the scale size is.

In the without scaling version, I've removed changes to the localSize, so there's no scaling happening. You can clearly see the bottom right door segment go past the frame.

[William Chyr]

Devlog Update #189 - 04/03/2015

Got trees for different gravities working. It's all in one big sandbox level for me to test that the mechanics are working together, hence why this level looks so ugly.

Also, will need to spend some time tweaking the colors. Will need to find good balance between aesthetics and function.

[Zorg]

The trees look very alive with the bright and saturates leave colors.

I thought about the missing outline of the leaves. In the screenshots in some areas it's hard to tell which cube is in front of other cubes. Which is not necessarily bad! I guess it's very clear in motion. With these very bright leave colors i thought about a white outline for leaves, but in a mockup it did not turn out very well (i'll show it anyway):



I noticed that leaves do not drop shadows, which may result in a shadow image of a "dead" tree on the walls. It would look better with a shadow, imho:

[William Chyr]

Devlog Update #190 - 04/03/2015

I thought about the missing outline of the leaves. In the screenshots in some areas it's hard to tell which cube is in front of other cubes. Which is not necessarily bad! I guess it's very clear in motion. With these very bright leave colors i thought about a white outline for leaves, but in a mockup it did not turn out very well (i'll show it anyway):

First of all, thank you so much for taking the time to do the mockup! Really appreciate.

I actually don't think the white outline looks that bad. I an see it conflicting a bit with the lighter-colored leafs, like yellow, but I think here for red, it looks quite nice.

I noticed that leaves do not drop shadows, which may result in a shadow image of a "dead" tree on the walls. It would look better with a shadow, imho:

Ya, the lack of shadows from the leaves does bother me...


So after seeing Zorg's points about outline and shadows, I decided to do a bit of an experiment on twitter:



The response was overwhelmingly in favor of having outlines. Something like 20 to 2.

One thing that I hadn't considered, and I think what's great about the outlines is that it causes outlines *not* to be drawn through them. This is because of the order in which the transparency is rendered. By rendering the leaves in the order in which outline is drawn on the leaves, it means it's blocking the objects behind it, and hence outlines are now drawn on those.

As a result, the leaves hide the the outlines of the branches inside of it, so when you're looking at a large scene, it makes it much less cluttered.

Compare below:





Without the leaves hiding the branches, the outlines there get all bunched up together, and actually makes the trees look rather ominous. By outlining the leaves, the tree looks much fuller and well-defined.

One thing I also changed was the make the inactive leaves more white instead of grey:



I think it makes the inactive leaves look like they're lamps that are turned off, which is pretty cool. I can see this lending itself to some really nice aesthetic opportunities, like making an area that looks like a empty street at dawn or something.













Here's a close up of the shadows:



While I like that there are now shadows, I'm not a fan of the pattern that's on it. I wish it were just a lighter color of the other shadows, but still solid. Not sure why this is happening. Will look into it some more.

[Zorg]

I guess the outlines are one essential part of your style. Twitter voters are right.

One thing I also changed was the make the inactive leaves more white instead of grey.

This is really great. Looks very light in direct comparision. Huge difference! Lantern trees!