next »

[Mark Mayers]

I've just been using the default console within Unity's editor; and the 'Development Build' checkbox for actual builds (and output errors).
It does the job, but seems much more useful.

I'll probably implement something similar in the future. Thanks!

The default console in Unity's editor is really more like a log though, in that you can't actually input anything, you can only print out to that.

I haven't use development build feature in a while, but that's the same thing, no? Correct me if I'm wrong.

I believe that's correct, I don't think there's an input mode.
 
I actually did something similar to you, in regards to binding developer actions to keys. Ex. 'developer sprint' where I run 20 times faster than normal. Sometimes I'll accidentally leave them in the build! It's been amusing to find this out during playtesting sessions.

The console is probably a much better way to avoid errors such as that!

[William Chyr]

Devlog Update #167 - 02/23/2015

Tweaking Rotation Movement In-Game

One issue I've been dealing with on and off is trying to get the feel of rotating to a wall right.

Problem is that I've been working on the game for so long and looking at it so closely that I honestly don't know what feels good and what doesn't anymore. I've gotten pretty used to the placeholder rotation movement that I implemented a long time ago, but that doesn't mean that that's the right feel.

I'm going to start testing it at soon, and at GDC next week, I'd like to be able to show it to people and get feedback.

To this end, I've set up the console to allow for in-game tweaks of the rotation.

Curve

I switched to using an animation curve for the rotation, instead of using slerp (which as it turns out, I was actually using incorrectly). I could have written a smoothing function, but I decided to go with a curve since that allows me more control, and I don't have to worry about the math.

For testing purposes, I have made fives curves:



Concave, convex, linear, and S are all standard animation curve shapes that come with Unity. I include them primarily as reference points. Custom is one I made that is a starts of concave, and then ends linear. It's the one I feel works best, but it's always important to have comparisons.

Concave:



Convex:



Linear:



S:



Custom:



S curve feels pretty good as well. The problem I find is that because the curve plateaus out in the end, when the player comes out of the rotation, their speed goes to 0, where has this stop and go effect. With custom, concave, and linear, it just goes straight into forward movement from rotation.

I also take into account initial speed (the fast you're moving when you rotate, the faster the rotation is), as well as a time divisor (just a way to slow down or speed up the rotation time overall). Both how much the initial speed is accounted for, as well as time change can be changed as well.

[William Chyr]

Devlog Update #168 - 02/25/2015

Rotation Curve Comparison Test

I made a video comparing the different curves I'm testing for the rotation movement:



I think S curve and Custom curve feel the best.

The problem with S curve is that because the curve plateaus in the end, you get a drop in speed. So if you're holding down the forward button and pushing the joystick forward while rotating, you get this stop and go effect. Custom curve doesn't have this problem, and instead goes straight into movement. However, S curve feels much better when stationary.

As such, my solution is to use a combination of S and Custom curve. When you're stationary and you rotate, we use the S curve. If you're moving and you rotate, then we use the custom curve.

Perhaps a more precise solution would be to see if the forward button is held down to decide which curve, but I think this works pretty well for now.

Console Design Improvement



Improved the design of the console. Darked the window and change the typography to a more typical "Computer Font", and also increase the font size.

Also added a hack to make it scroll (basically set the y value of the rect to 30000). This does cause a problem later if you type in enough commands (it'll stop scrolling), but it's fine for now.

[Torchkas]

The custom one certainly seems to give the best kinaesthetics, but what's with the pause after the animation is over?

[karlozalb]

I prefer the concave one

[Juan Raigada]

Question: are you using the curve both for rotation and movement, or are you just stopping the movement while rotating? (I'm trying to make sense of the stop and go effect you mention).

Watching the video, I actually like the convex curve most (although reversed custom might be preferable). That is, I prefer the rotation to ease off at the end, but to start fast (to give inmediate feedback to the player that the rotation is on).

Have you thought about coupling rotation and movement to avoid the stop and go problem? (that is, allowing the character to move as if the rotation is finished even while rotating, so when the rotation ends the character already has speed forward if moving...). What I mean is that depending on the return of the curve Evaluate() function, you can allow the movement input to start taking effect (so when the rotation is almost finished you are already moving if desired).

Basically multiply the movement input vector you would have if you were not rotating by the return of that Evaluate() function. Or even put that through a different curve so the movement doesn't start until you are at least 50% rotated...

[ProgramGamer]

I'm with Juan on this one. Convex, if not reverse custom. 

[Paul]

What about adding a bit of a dip when the player lands on the new surface? As if the character is bending their knees a small bit before returning to a normal standing position. Just to add a bit of weight to the character

[ProgramGamer]

You should take a look at how Portal handled rotation. As a wise man once said, the key to becoming wiser is to copy the wise.

[marcgfx]

its quite hard to really notice the difference i think. I liked the S-curve best. the one i did not like was linear, but I believe it was only because it seemed very slow. if its not harmful for you, put it in a settings menu and let the player decide.

[William Chyr]

The custom one certainly seems to give the best kinaesthetics, but what's with the pause after the animation is over?

Hmm.... I played around with it some more just now, and it seems like it happens most noticeably when you're rotating towards the wall at an angle. However, I don't really think it's a pause in the sense of speed going down to 0. I think what's happening is that there's a change in speed that's quite sudden, and is giving that slight jitter. Will look into it today.

I prefer the concave one

Noted! That one is pretty-fast paced. I think I will make it an option in the game for you to choose from a set of different curves.

Question: are you using the curve both for rotation and movement, or are you just stopping the movement while rotating? (I'm trying to make sense of the stop and go effect you mention).

Watching the video, I actually like the convex curve most (although reversed custom might be preferable). That is, I prefer the rotation to ease off at the end, but to start fast (to give inmediate feedback to the player that the rotation is on).

Have you thought about coupling rotation and movement to avoid the stop and go problem? (that is, allowing the character to move as if the rotation is finished even while rotating, so when the rotation ends the character already has speed forward if moving...). What I mean is that depending on the return of the curve Evaluate() function, you can allow the movement input to start taking effect (so when the rotation is almost finished you are already moving if desired).

Basically multiply the movement input vector you would have if you were not rotating by the return of that Evaluate() function. Or even put that through a different curve so the movement doesn't start until you are at least 50% rotated...

I'm using it for both rotation and movement. Here's the code:

Code:

float y = rotationCurve.Evaluate(t);

transform.position = Vector3.Lerp(orgPos, dstPos, y);
transform.rotation = Quaternion.Lerp(orgRot, dstRot, y);

orgPost and orgRot are the original position and rotation, respectively. And dstPos and dstRot and the destination position and rotation.

I think what you're saying is to decouple rotation and movement, right? Having two different curves instead of just one, and having the movement curve finish before the rotation curve? I think this could work actually. Will try it today.

I'm with Juan on this one. Convex, if not reverse custom. 

I will add reverse custom to the set as well.

What about adding a bit of a dip when the player lands on the new surface? As if the character is bending their knees a small bit before returning to a normal standing position. Just to add a bit of weight to the character

I've been playing Dishonored quite a bit recently, and this reminds me of how they do things with that game. Very immersive FPS, with hands reaching down to the ground when you fall. The problem for RELATIVITY I think is that pretty much for most of the movement, it's pretty disembodied. There's head bobbing and stuff, but it's like you don't really have a physical body here... Maybe it'll improve game feel. I do have a similar effect when you land after a very long fall. But I think for rotation, which happens quite often, this might be too disruptive.

You should take a look at how Portal handled rotation. As a wise man once said, the key to becoming wiser is to copy the wise.

Portal had rotations? If you're talking about when you have a portal on the ceiling and one on the wall, and when you fall through one, the player gets rotated, I think that's way too fast for me as a reference.

its quite hard to really notice the difference i think. I liked the S-curve best. the one i did not like was linear, but I believe it was only because it seemed very slow. if its not harmful for you, put it in a settings menu and let the player decide.

The linear rotation actually takes the same amount of time as the others, but without the variation in speed, it does feel very slow.
I think I will put these different curves in a setting menu and let the player decide. Even the comments that have been posted here in the devlog in response to the video shows that there's a very wide variety of preference.

[William Chyr]

Devlog Update #169 - 02/26/2015

Separating Position and Rotation Curves

Question: are you using the curve both for rotation and movement, or are you just stopping the movement while rotating? (I'm trying to make sense of the stop and go effect you mention).

Juan's comment in response to my last update made me realize that rotation and position are indeed separate. I have been working on this for so long that the action of switching to a wall just seemed like one action.

This is what the code looks like:

Code:

float y = rotationCurve.Evaluate(t);

transform.position = Vector3.Lerp(orgPos, dstPos, y);
transform.rotation = Quaternion.Lerp(orgRot, dstRot, y);

As you see, both the position and rotation changes are reading from the same animation curve.

I decided to try decoupling that and having separate animation curves for each.

Here's the comparison test video: 



Again, it's very difficult for me to tell, because of how close I am to the project, but I think separate animation curves do help a little.

I made the position curve end slightly earlier than than the rotation curve. The thinking here is that the player is already moving by the time the rotation finishes.

Anyway, I'll need to start playtesting to really figure it out.

[William Chyr]

Devlog Update #170 - 02/28/2015

Best Curve Combination

After playing around with the animation curves controlling position and rotation during the gravity switching, I've decided that this is the combination that works best:

Rotation - Custom when moving, S when stationary
Position - Convex

I'm going to put this as the default settings in the game.

Of course, I will have the option in the settings for players to choose different animation curves to use. I think there will even be an option where it skips the transition completely and just places the player in the new orientation (it will still take the same amount of time, so as not to mess up the mechanic). This is mostly done for people who are have motion sickness with the game. I'd like the game to be as accessible as possible, so would hate for people to not be able to play it because of that.

Also, I would love to make a VR version of the game. And I think for that format, it would require a lot of tweaking as well, so it's good to have the options in place.

Light Bleedthrough

Was noticing an issue with light bleeding through the wall:



It turns out it's because the light isn't set to cast shadows. I could set the light to cast shadows, but I think that's more performance heavy than is needed for this. I ended up just reducing the range of the light.

Illuminated State of Boxes

Working on the designs for the illuminated state of the boxes (when they're placed on the correct switches)

This was the original design. I thought by turning the outline around the shapes to white, it would make for a stronger effect:





I posted these images on twitter, and several people complained that the white arrows on the yellow box was pretty hard to see (yes, it is pointing in the wrong direction). It did seem pretty inconsistent, especially given that the arrows on the other color boxes were quite clear.

I decided to add the outlines back. Here's what the illuminated boxes look like now:







Head Bobbing

Finally got around to tweaking the head bobbing settings.

When you land, there's a stronger head bob effect. I've made it so that how much head bobbing occurs is dependent on the speed of the fall right before you land. So the faster you were falling when you landed, the greater the head bobbing. The relationship is quadratic, so that the really big head bob effect doesn't happen unless you're falling near terminal speed.

Here's a video showing the effect:



Water Redirection

Got water redirection working in the new build! Excited to show it off at GDC and have people try it and get feedback on it. It's pretty broken, but works well enough to convey the idea.





GDC

Finally, I'm going to be heading out to San Francisco later today for GDC. Very excited to catch up with friends and also meet new people.

Last year was my first GDC, and my experience then had a tremendous impact on the development of the game. A lot of the feedback I got at the time was that the art style needed to improve. I was actually a bit frustrated by this, because I thought I had really great mechanics and that was all that mattered. I have come to realize since that I was wrong, and that art and mechanics are closely linked, and both matter a lot for the final game.

Anyway, last GDC inspired me to dive into shaders and constantly improve the art style, and I think all the work has paid off.

Here's a comparison of what the game looks like back then and what it looks like now:



Of course, there's still plenty of room for development, so I'm excited to see how the art style evolves moving forward!

[deab]

Head bobbing effect looks really nice, subtle but very effective.

[William Chyr]

Devlog Update #171 - 03/10/2015

GDC 2015



I just got back to Chicago from GDC. Just like last year, GDC was an exhausting, overwhelming, but also incredibly fun and inspiring week.

In a lot of ways, even though I was familiar with the format, and had some idea of what to expect, it was even more intense than last year. This was mostly because this time around, I knew more people, and there was more stuff that I wanted to do.

Anyway, since I wasn't really showing RELATIVITY at GDC, at least not officially, I thought I'd try something a little different with this write-up. Instead of a standard post-mortem talking what I did and why, I'm just going to make a list of some of my favorite moments and events from last week.

1. Talks!

Last year at GDC, I got an expo pass, which got me into the expo floor, and also into all the upstair levels of the convention centers, but not into most of the talks. This was sufficient as I mostly was just interested in meeting new people. This year, I got the Independent Game Summit Pass, which allowed me to attend talks on Monday and Tuesday, many of which were focused on independent game development.

There were a lot of great talks, but the two I enjoyed the most and found to be very useful were the Talos Principle post-mortem and the Race The Sun post-mortem.



For the Talos Principle post-mortem, Alen and Davor from CroTeam talked about the various development and debug tools they used. One of debug tools allowed testers to hit a hot key, and then a raycast would shoot from the reticle to a point, and place a pin there. Then the tester could type in a description of the problem, hit enter, and their position coordinates, and camera orientation would be saved. Then the developer could view all the pins, and by clicking on each one, you could go straight to the position with the exact camera angle and see what the issue is.

They said once they implemented this system, the number of bugs reported went from hundreds to thousands (of course, this does not mean more bugs, just that previously, all of those weren't being reported).

They also had a bot that was able to run through the game very quickly, making sure that there weren't any areas where the player would get stuck (from a technical, not design point, ie doors not opening). For a human playtester, it would take about 40 hours to run through the entire game. For the bot, it took around 20 minutes.



The Race The Sun post-mortem from Flippfly was very inspiring. What was most interesting was that despite the game not being a megahit, or even a hit rightaway, it was still a success in that it has allowed the team to fund their next game, and it has gotten really positive review from players. A lot of it can be attributed to the team being open to feedback, and actually willing to make changes based on those feedback.

I won't go too much into detail (hopefully it gets posted for free on the vault). However, they gave one analogy for game development that I thought was really great. They compared making an indie game to throwing darts. At first, you're going to miss a lot. Over time though, not only do you get better at the act of throwing darts, but you've also thrown a lot more darts, so your chances of hitting the bullseye increases. With making an indie game, you just have to keep trying things, and constantly evaluate what you're doing and how you can improve, and then keep trying more things.

2. EDGE Magazine





The latest issue of EDGE Magazine (#277) features a beautiful 2-page art spread of RELATIVITY!

EDGE had reached out to me back in January regarding this feature, so I had known about it for a while (it was very hard to keep it a secret), but I didn't see it in person until I was at GDC and saw the issue in the "Industry Press" section.

It's the first time RELATIVITY has been in a printed magazine, and it looked great! I was so excited when I saw it that I grabbed 3 copies and ran around the expo floor showing everyone.

This is actually a really significant moment for me, because at GDC last year, a lot of the feedback was that I needed to work on the visuals of the game. I also remember picking up a copy of EDGE and looking at the games in there.

This time around, to have the visuals improved so much that it's in EDGE is pretty special. Also, this time at GDC, the reaction of people when I showed them screenshots of RELATIVITY was no longer "The art style needs work", but "I've seen this game before! It looks beautiful!"

Of course, there's still a lot of work to do and lots of room for improvement, but I think it's safe to say that all the work spent on the shaders this past year has paid off.

3. ProBuilder

On Thursday, I met Karl from ProBuilder, who had a kiosk at the Unity booth on the show floor.



As you know, ProBuilder has been indispensable for me in making RELATIVITY. I talked to Karl about some of the issues I was having with my edge-detection shader picking up artificats due to T-Junction issues, and I think now I could fix them by using the weld vertices function.

Also, Karl showed me some of the stuff that's currently in the works with ProBuilder. Not sure if I can talk about it, but it's very exciting.

Anyway, it was just really cool for me to finally meet someone behind one of my favorite Unity plugins. It really has made development of the game so much easier, that I honestly can't imagine ever making a 3D game in Unity without ProBuilder.

4. Steam VR Demo

I got to try the Steam VR Demo during GDC! When I told people at GDC that I got to try this, a lot of them were pretty surprised and asked how I got to do it. All I did was sign up for an appointment on the Valve website a week or two before GDC, but I guess a lot of people didn't know about this? Anyway, in the future, do keep an eye out for the sign up notice. It was a scheduled half-hour demo that took place in a room, so it was by appointment only.

I don't want to talk too much about it because 1) spoilers! and 2) I could dedicate 3 blog posts to this topic alone.

All I will say is, it was very cool, definitely the best VR demo I've tried so far. That being said, it is a demo, so the entire experience is tailored to showcase what it does best and to  minimize any of the problems.

It did make me realize that I don't want to port RELATIVITY to VR. What I learned is that for a good VR experience, it must be designed from the ground up to be VR-specific. A port of something designed for another platform just doesn't work.

5. Catching Up with Old Friends and Making New Ones

This was really the best part of GDC for me. It was great to see a bunch of friends I had met at various conferences and conventions throughout the past year all in one place. I wasn't showing my game in an official capacity, so was able to take things at a fairly leisurely pace and not feel rushed all the time. The weather was fantastic for the whole week in San Francisco, so lots of time was spent in the park.

[Connor]

looking good! i really like the third and fourth rotations
also, grats on getting into edge magazine! super cool to see! ^^

[William Chyr]

looking good! i really like the third and fourth rotations
also, grats on getting into edge magazine! super cool to see! ^^

Thanks Connor! As always, really appreciate the support.

By 3rd and 4th, you mean Linear and S curves?

[dmcondolora]

I loved the GDC write-up! The Independent Games Summit pass was sold out by time I went to get it, so your notes from the post-mortems were really helpful.

I'm glad that Brooke and I ran into you at the end of GDC! Now I'm kicking myself for not picking up a free copy of EDGE magazine, haha. Congrats again on your feature!

- David

[William Chyr]

I loved the GDC write-up! The Independent Games Summit pass was sold out by time I went to get it, so your notes from the post-mortems were really helpful.

I'm glad that Brooke and I ran into you at the end of GDC! Now I'm kicking myself for not picking up a free copy of EDGE magazine, haha. Congrats again on your feature!

- David

Great running into you and Brooke as well! Was very happy to catch you two near the end. Hope GDC went well for you!

[William Chyr]

Devlog Update #172 - 03/11/2015

Edge-Detection Shader Artifacts Fixed!

Back in May of last year, I wrote this devlog post about a particular issue I was having with my edge-detection shader. Specifically, it was generating these tiny black dots that appeared along the seam where two objects touched.



From what I could tell, it was due to the normals of the faces. It seemed like there was a floating point error and even though you can have two boxes lined up against one another, there was still a tiny gap that was invisible to the naked eye, but which the shader could pick up. At least this is what I determined.

My friend Devon, who was the graphics programmer on Octodad helped me tweak the shader a bit, and he did make improvements, but the artifact wasn't completely removed.



Finally, during GDC last week, I stopped by the Unity booth on the expo floor, where ProBuilder had a kiosk, and spoke with Karl from the ProBuilder team about this issue.

Karl had two suggestions:

1) Merge the boxes together and then weld the overlapping vertices. Welding puts both vertices at the same point, so should in theory close up the seam in between the faces.

2) Delete the faces that are facing each other in between the boxes.

I decided to try these methods when I got back. Here's a video comparing the different methods and their results:



Separate Boxes



This is the default set up of the situation. In this case, I have a wall that's made up of a separate individual ProBuilder boxes. The boxes are vertex-colored to show that they are different. At runtime, a material is applied to all of the boxes, so that together they look like one wall.

Below you can see that there are artifacts (note that this doesn't show the problem as well as the video) since it's just a still. However, it shows that these artifacts exist. You can click on the images to see the larger version.





Merged

In this method, I merged all the boxes into one mesh. As you can see, the problem persists.





Merged with Welded Vertices



I actually forgot to include footage from this method in the video, which sort of defeats the point a bit...

But anyway, it looks just liked the previous two methods, without any improvements.





No Draw

In this method, I set the top and bottom face of each box to a 'NoDraw' material. If using ProBuilder, then during run-time, these faces get deleted.





It reduced the number of artifacts significantly when viewing the wall at a distance, but when you're up close and looking at the wall at an angle, there are still artifacts.





Also, one thing that is very interesting is that the artifacts actually look different than the others. The others are a black X, but these artifacts seem to be a white square.



No Draw and Merged

Taking all the boxes with no draw faces on them and merging them into one mesh.



For some reason, the mesh texture just gets completely meshed up. I think ProBuilder doesn't intend for you to apply NoDraw faces and then merge?



Clearly, this method isn't an option.

Deleted Faces



Delete the top and bottom face of each box. As to be expected, this looks just like the case when I'm using separate boxes with NoDraw faces (since NoDraw faces get deleted at runtime).

There are much fewer artifacts when viewed at a distance, but close up, there are still a lot.





Deleted Faces and Merged

Take all the boxes with top and bottom faces deleted, and merge them into one mesh.

This actually fixes the problem! There are no artifacts! NO ARTIFACTS!!!!

Check out how clean that wall looks both up close and from a distance:





It's so beautiful!