next »

[William Chyr]

Currently working on a never-ending staircase. Here's a view of it from the Unity editor during play mode:

[William Chyr]

DevLog Update #51 - 05/13/2014

Experimenting with a day/night cycle in the game:

[William Chyr]

DevLog Update #52 - 05/18/2014

I'm currently working on a new hub level, and I'd like to take a moment to talk about my approach to its design.

This level is intended to be a very central location in the game, an area that players would return to often as a way to transition between different areas. As such, I needed it to be very visually distinct, so that every time players return to this area, they know exactly where they are, and can feel grounded.

My initial idea was that it would look like the interior of a box. This way, it would be very easy for the player to see where all the different parts of the his level is, and because it would be so sparse compared to the other levels, it would be immediately recognizable.

Just a plain old box would have been too boring, so I decided to spice things up by removing different surfaces of the box to create these winding pathways:



Here are a few shots from the player's point of view:





The problem is that it looks quite convoluted, and actually not as easily recognizable as I would have liked. In fact, it looked a lot like areas from other hub levels.

I spent about 4 hours building this level, and after getting nowhere with it, I decided to go to bed. Just as I was falling asleep, I remember this level I made back in July 2013:



It was one of these levels I drew up thinking it looked really cool, but turned out to not work very well at all.  I had it set up where there was an entrance and an exit in this level. I hadn't implemented world wrapping at the time, so none of the geometry you see here are repetitions of the same stuff, it's all different.

This meant that if the player wandered away from where I had intended for them to go, they would get lost very easily. And by having the geometry repeat itself in all directions, there was no way for players to orient themselves, and get a sense of where they were in relation to where they were supposed to be. It was a disaster, so I ended up removing this level.

However, last night, I realized that now with world wrapping, I can actually bring this level back, and it would work really well. In fact, it solves the problem of the level looking too much like others.

In all the other hubs, the world wrapping means that the repetitions of the world appear as floating platforms in the distance. In none of them do the repeated worlds connect. This means that here, when they do connect, it is visually very striking. It also means that I can have the appearance of an endlessly repeating infinite space, but when players wander off, they will always return to the heart of the level, so they can't actually get lost.

Here's a shot of what the hub looks like in the editor:



Here's what it looks like from the player's perspective:



And some gifs to show what it's like to move through this space:

[oleomingus]

Wow ! I hadn't seen the game since the world wrapping, and it's great to see it used in the construction of your new level. Wonderful work as usual.

[William Chyr]

Wow ! I hadn't seen the game since the world wrapping, and it's great to see it used in the construction of your new level. Wonderful work as usual.

Thanks oleomingus! Always appreciate the support. So often these small ideas end up having a pretty large impact on the game design.

[William Chyr]

DevLog Update #53 - 05/20/2014

Yesterday, through a teacher friend of mine, I was invited to demo Relativity to a group of middle school students at an after school gaming club.

It was an interesting experience. Prior to this, most of the people who've playtested the game have been much older. To date, I'd estimate I've had around 200 playtesters. Out of this group, I think only 3 of them were under 18.

I didn't really know what to expect. Going in to this particular playtest session, I wanted to test out some of the new changes I had made to the game since PAX East, to see if I've fixed some of the pacing issues I had observed. But I didn't know how younger playtesters were going to react.

For the most part, the kids seemed pretty excited about the game. It was a little difficult to see how each of them were reacting to the puzzles, because as soon as one of them solved a puzzle, he would talk about how he solved it to the others. A few got frustrated early on and switched to playing Minecraft instead, but several were really into it and got pretty far into the game.

One thing that I did notice was that kids seem to use a much more intuitive approach to solving the puzzles, as opposed to older playtesters, who tend to be much more rational in their approach. This meant that the kids had a much easier time "getting" the mechanics, and found the early puzzles pretty easy.

However, for some of the later puzzles, which required a deeper understanding of the mechanics, and involved larger logical leaps, the younger playtesters struggled quite a bit. This could have been a combination of them being distracted and impatient, as by this point they had been playing for about an hour.

In older playtesters, I noticed that it often took a little longer for them to figure out exactly what's going on with the mechanics, so the early puzzles were a little more tricky, especially the first one where they have to use cubes from two different gravity fields to accomplish one goal. However, once they understood this, they were able to apply their knowledge and logic their way through the more advanced areas.

At this point, I'm not too sure how this would affect the design of the game. I'm not really making this game with any specific demographic in mind, except maybe people like me who are interested in mind-bending stuff.

I did always picture someone a little older, at least college-aged, to be my intended audience. And for the most part, these are the people I've been getting feedback from. However, it certainly wouldn't be a bad thing to make the game as accessible to as many people as possible.

[Connor]

the infinite looping in that level looks awesome. wholy crap. i like how it looks like you feel onto another platform below you, when you havent actually done so, that kind of stuff is cool as heck

[William Chyr]

the infinite looping in that level looks awesome. wholy crap. i like how it looks like you feel onto another platform below you, when you havent actually done so, that kind of stuff is cool as heck

Thanks, Connor! The world wrapping is definitely one of the best features in the game. Everytime I playtest the game now, when players fall off a platform and realize what has happened, you can almost see their minds get blown from their facial expressions. It's pretty awesome.



I plan to keep exploring this property. I feel like I've only just scratched the surface.

[William Chyr]

DevLog Update #54 - 05/21/2014

Trying out a new design for the door. Glass panels allow the player to see what's on the other side. This actually solves a ton of game design problems.



Previously, if the switch was located on the other side of the door, players had no way of knowing this. From where they were standing, it just looked like a door with no way to open. Now, players can see that there is a switch to open the door, it's just located somewhere they can't get to at the moment. And later, when they do get there, they make the connection that this was the previously locked door.

Also, the other day, I played an early build of Relativity in preparation for a talk I was giving at an art center. I was surprised to see how primitive the game looked back then, and decided to do a quick screenshot comparison. Amazing the difference a year can make!

[Zaphos]

Is the talk online?  Sounds like an interesting one!

Also --

I keep getting mesmerized by this gif -- it's so good

[William Chyr]

Is the talk online?  Sounds like an interesting one!

Unfortunately, the talk wasn't recorded.

It was mostly about how I transitioned from working on installations such as this one:



to my current work on Relativity.

I also touched on different design decisions I had made and why I implemented them. A lot of that stuff is actually here on the devlog in more detail, so you're not missing too much

[William Chyr]

I was having trouble finding a specific scene file I had worked on about a week ago, and so I started talking to some people on twitter about different naming conventions and systems.

I mentioned how many scenes I thought had in the project, and some people seemed pretty shocked at how many there were. I hadn't expanded the scene folder in quite some time, and was a bit curious myself, so I decided to take a snapshot of the entire folder.

As you can see, it's a bit of a mess... 

[William Chyr]

DevLog Update #55 - 05/22/2014

I finally got my edge-detection shader to work on render textures! This took a really long time to figure out, so I'm really happy to have solved this issue.

Basically, for a long time, I didn't know how to get shaders applied to render textures. Since the portals in the game use render textures to create the illusion of a world on the other side, this meant an inconsistency in visual style when looking through a portal, like this:



You can see that everything that appears inside the portal doesn't have edge-detection applied. This didn't affect gameplay or anything, but I knew that this would definitely need to be fixed for the final release of the game, and I had no idea how to address this problem.

A few weeks ago, I finally decided to roll up my sleeves and really figure out how render textures work. Up until then, the portal system was just hacked together, and I only knew enough to get things barely working.

I knew I would need the shader to get applied to a camera, but for a long time, I just couldn't find where that camera was!

Eventually, I discovered this line of code:

go.hideFlags = HideFlags.HideAndDontSave;

"go" is the game object with the camera attached, and what this line did was told the engine to hide it from the editor hierachy (so that it wasn't seen), and to not save it after run time.

I changed it to this:

go.hideFlags = HideFlags.DontSave;

So now, I could see the camera created during runtime inside the editor hierarchy during run time.

From here, I just added the edge-detection shader to the run time generated camera.

This is what it looks like now:



This still isn't perfect. There's still the problem of shadows not being rendered on render textures, and making the lighting look inconsistent.

However, I'm really happy to have been able to cross a big item off of the bug list.

[William Chyr]

DevLog Update #56 - 05/23/2014

Notebook Sketches
I've been meaning for some time to make a post sharing some of my notebook sketches. Finally getting around to doing it now.

World Map


This is an early version of the map of the game. I was trying to lay out how the different hub worlds would connect to one another. The current structure of the game is quite different, but you can get a sense of the complexity I have in mind.

You can also see that previously I had specific themes for different levels: Downtown, The Library, Museum, Industrial, etc. This isn't really that relevant to the game, at least in its current state. Mostly, this was a way to help me think about how levels would evolve. Coming up with reasons for why specific structures existed gave me a starting point from which to design the levels. 

Opening Level Design


An early draft of the layout of the first level in the game. You can see that on the right I was playing around with different arrangements for how the space would fit together in 3D.

Advanced Hub World Design


This was a sketch intended for a Hub level that would appear in the later stage of the game. I'm not sure if I will still put it in the game. Different elements from this design have found their way into early levels. Anyway, it gives you a sense of the design process.

Water Logic


This is a flow chart I drew up to help me work out the logic of water in the game. I still haven't finished implementing that mechanic yet. I got it working on a basic level several months ago, and then decided I needed to focus my efforts on more immediate problems, such as the early levels.

[William Chyr]

DevLog Update #57 - 05/24/2014

For the past few days, I have been struggling a lot with optimization problems in the game.

I'd be running the game from the Unity editor, and for the most part, the game would be running at around 100 FPS. However, every once in a while, there the framerate would drop down to 30 or 40, and this would cause a very noticeable lag in a gameplay.

I opened up Unity profiler, and noticed these massive spikes in CPU usage:



When I clicked on the spikes to see what exactly was causing this, most of it was caused by GC.Collect (garbage collection) under GUI.repaint.

This was really confusing to me, as I have very minimal UI in the game.

However, I started doing research, and it turns out that just by having void OnGUI in your script, even if it's not drawing anything, will cause allocation. At some point, all of these garbage will need to get collected.

I then remembered that earlier in development, when trying to debug different triggers and switches, I would use OnGUI to let me know when different states have changed. After I got everything working, I commented out what was inside OnGUI, but left the actual call there.

So in a bunch of scripts, I had something like this:

void OnGUI(){
    //draw something
}


And of course, each of these was generating garbage, which then had to be collected.
 
After deleting this in all the scripts I could find, performance increased significantly!

So all I did, was delete a bunch of code that already wasn't doing anything, and it fixed my performance problem. 

[marvinhawkins]

Hey Wily,

Met you q few months back at the Unity User's group. This project is looking cool! Really interested in your techniques on project management. Are you working n this by yourself? How do you prioritize what you work on?

In an earlier post, I saw you were trying to figure out a good system for managing your scenes. Did you figure it out yet?

Loving the in progress sketchbook stuff! Good luck!

[William Chyr]

Hey Wily,

Met you q few months back at the Unity User's group. This project is looking cool! Really interested in your techniques on project management. Are you working n this by yourself? How do you prioritize what you work on?

In an earlier post, I saw you were trying to figure out a good system for managing your scenes. Did you figure it out yet?

Loving the in progress sketchbook stuff! Good luck!

Hey Marvin:

Yes, I am working on this game by myself. With regards to how I prioritize what I work on, I don't really have a formal system in place. A lot of times, I'll be jumping back and forth between different parts of the game, sometimes working on design, sometimes working on graphics, and sometimes working on optimization.

I suppose my main priority right now is getting the pacing of the puzzles correct. However, this isn't always a design issue. Sometimes, to make sure a certain level progression is working, I need to work on optimization, so that the level is actually playable and not having lots of lags.

I'm still working on a system for managing the scenes in the game. It's not finished yet, but I'm getting close.

[William Chyr]

DevLog Update #58 - 05/27/2014

Edge-Detection, revisted

Yesterday, I decided to revisit the topic of edge-detection again. I was reading through the devlog of Lucas Pope's newest game, Return of the Obra Dinn, when I saw this post about the visual style of the game.

Even though the look for Obra Dinn is very different from the look I'm going for, his shader does require edge-detection. When I saw the image he shared of just the edge-detection effect, I was blown away. It was so clean, had pixel-perfect thin lines, and no artifacts.

In Pope's technique, he uses object position and face normals to give each poly face a random color, and then draws lines separating the different color areas. Funny enough, this is very similar to the technique used by Thomas Eichhorn in his sketch shader, which was actually the initial inspiration for my shader effect.

At the time, I didn't have a lot of experience with shader programming (I still don't, but I had less back then), and I couldn't figure out how to use color areas for edge detection. Eventually, I just went with comparing normal and depth values of pixels directly to draw the edges. You can read about the details of what I did here.

Anyway, I decided I would switch over to using color areas for edge-detection. It seemed to be much more accurate and also had less artifacts (further down I will explain some of the problems with my previous edge-detection shader).


In my shader, I follow Eichhorn's method, and for each pixel, I set it's color according to this formula:

color.r = normal.x;
color.g = normal.y;
color.b = depth;

Here are two images from my first go at using normals and depth to color poly faces, and then drawing edges between the color areas:





As you can see, while the shader is able to draw lines between different color areas, it is missing a ton of edges! The problem here is that there is not enough depth sensitivity, so that areas with the same normal, regardless of distance, all appear to be the same to the shader.

So, how to increase depth sensitivity? Well, one way is to lower the far clipping plane of the camera. Since depth values are spread out from 0 to 1 across the camera view distance, by lowering the far clipping plane, and therefore shortening the camera view distance, you can increase the variation in depth values.

This is what it looks like with the camera far clipping plane set to 70:



You can see there is strong variation in color, and the shader is picking up a lot more edges. Unfortunately, this is also causing a lot of clipping. Because of the size of my levels, I need the clipping plane to be at least 800.

Basically, what I needed was to have more sensitivity at the depth values closer to the camera, and less sensitivity at depth values farther away. I'm a bit embarrassed to say I couldn't think of an equation right away (my math has been a little rusty having been out of school for some time), but Nick Udell suggested using a logarithm function (of course!  )

I changed the color assignment to this:

color.r = normal.x;
color.g = normal.y;
color.b = log(depth);

and noticed improvements right away (just look at all those edges!):



What's interesting is that you still can't see the color variation just with you eye, but for the shader, there's enough difference to distinguish between pixels having the same normals but different depth values.

The new version of the shader is better than the one I had before, but still not perfect. It's also still not quite the same technique that Pope is using, as he is using the world space coordinates of the objects as well (I asked him about the approach, and he goes into some detail here)

I'm still learning shaders, so haven't quite figured out how to actually do this yet, but it appears it should happen in the vertex shader, and not the fragment shader, which is where I had been focusing on.

Below is a comparison of the shader vs the old one.

Here's the old shader:


Here's the new one:


Here's a gif comparing them:


You can see that the older shader had many more thicker lines. This may not look that bad from the gif, but in the game, it looks quite cluttered and distracting.

You can also see in this close up there were a ton of artifacts in the old version:


I know that this is a problem due to using normals, and not depth values. Not exactly sure what the problem is, but I think it has something to do with floating point precision. They tend to occur at places where primitives are supposed to align. I'm guessing  there's just some tiny difference, and the shader is detecting a gap. During gameplay, these would flicker in and out all the time, which really bothered me.

In the new version, I've managed to improve on this:


Some of the artifacts are still there, but they're much smaller and less noticeable.

There are also some problems with the new shader. For example, it is missing the edges on the stairs, as shown below:



I'm not too sure what's happening. I know it has something to do with depth sensitivity, but haven't nailed it down yet.

Here's a gif comparing a close up of the two versions:


Anyway, I'm going to leave the shader alone for now to work on other more pressing aspects of development. I'm going to try incorporating object position into the shader next time, like what Pope is doing, as this seems to be much more precise and effective.

[Juan Raigada]

Much cleaner now! I really like  how it looks not zoomed out.

I need to learn to code shaders someday... Life's too short.

[William Chyr]

Much cleaner now! I really like  how it looks not zoomed out.

I need to learn to code shaders someday... Life's too short.

Thanks Juan! I've definitely learned a lot about writing shaders in trying to get this edge-detection right. For a while, I thought I had gotten pretty good at shader programming (typical novice mistake), but then seeing Lucas Pope's post on his shader made me realize there's still so much for me to learn.

The hardest part about shader programming is probably the debugging process. Not sure if it's due to Unity/Monodevelop, or if it's just the nature of the beast, but it's really hard to tell where you've messed up. You just see a pink screen, and know that something is not right.