Development Update – Water Design Process

The main design challenge I’m working on is the water mechanics in Relativity. Specifically, what are the rules of its behavior. Because this is a puzzle game that’s heavy on logic, the behavior of the water needs to be really predictable. Think of it as the light bridges from Portal 2, except they respond to gravity. I need the player to be able to plan out everything in their head, knowing that if the water falls off here and hits that, exactly which direction it will go.

I’m planning on introducing the L-Shaped blocks later in the game that lets the player bend streams of water. Below is my thought process for deciding how water should behave in Relativity. Please excuse the crudeness of the drawings. These are all from a top-down perspective.

When you place the L-shaped block this way, you bend the water stream to the left (the water’s left). The arrows indicate the direction of the water.


And when you place the L-shaped block the other way, you bend the water stream to the right (the water’s right).


These are the basic starting rules.

So then, what happens when water approaches a block like this (perhaps 2 normal blocks placed side by side)?



There are three options.

1) water splits and continue in their new directions:


This seems logical enough, if not a tad bit unrealistic. However, the problem here is that it renders the L-shaped blocks useless. Why choose one direction, when you can basically get 2? It also makes the puzzles way to easy, since you don’t really need to think of how to redirect the stream, you can just keep splitting it bidrectionally until you’ve got the stream you need.

2) water splits, but then continues in original direction:



Ok, so then water happens after the block? Do the streams re-merge into one?


or continue as two separate and independent streams?


The problem with keeping the 2 separate streams is that one of the streams is pretty much useless. It doesn’t add anything to the puzzle, since the other stream is going in the same direction and is right beside it.

The problem with water re-merging is, what if I have a much wider obstacle, which can be formed by players putting multiple regular blocks in a row.

If it’s really wide, it would look weird for water to continue in the original direction:


This seems more natural, but I’m back to my original problem of creating bidirectional streams and making the puzzle solving to easy:


This leads me to the final option:

3) stopping the stream: 


It’s not the most realistic option. However, it solves a lot of the problems with the earlier options. For one, it’s really predictable. You know if you don’t have an L-Shaped block lined up correctly, the water will just stop. Also, it doesn’t allow the player to create bidirectional streams. So, I think this is the option I’m going to go with.

What do you guys think? Of course, this doesn’t handle all the cases. For example, what if the block is shifted and only touches half the stream? I haven’t worked this out now, but these are just the basics of the water behavior rules.

Development System – Water Branching

Ok, I’m finally getting somewhere with the water branching system:


Writing this system was pretty painful due to the debugging process. The water system uses a recursive function, so that the water segment just keeps replicating itself. This is necessary as the water will need to respond dynamically to environmental changes, so each subsequent segment of the water is just a brand new water source, embedded within the previous water segment.

As anyone who was written a recursive function knows, if you mess up the code, you can get yourself caught up in an infinite loop. Every time this happened, Unity would freeze, and I’d have to ctrl + alt + delete out of it. This made the entire process extremely tedious.

I did eventually figure out what the main bug was. In Unity, it looks like if you have a prefab, and your instantiate itself and add a child to that object, then instantiate it again, the second instance will actually include a child as well. This was causing an additional water starter to get created, which then increased the number of gameobjects exponentially with each subsequent update.

Experimental Gameplay Workshop
Heard back from the organizers of the Experimental Gameplay Workshop at GDC. Sadly, Relativity didn’t make the cut this year. However, I’ll look at it as motivation to work harder, and will definitely try again next year.

Development Update – Water Drafts

Hey guys, been a while since the last devlog update. Got a new set of approaching deadlines for different applications, so have been a bit stressed out and busy with those. Also, the weekend right after IndieCade East, there was another small indie game dev meetup here in Chicago. I spent the few days right up to the meetup implementing a lot of the suggestions and feedback from IndieCade East. From the latest playtesting session, it’s definitely an improvement.

One of the biggest design challenges for Relativity has been trying to find a balance between freedom and linearity of the puzzles, and I think I’m finally starting to find the right way to do it.

On the technical side of things, I’ve started really looking into how the water mechanics in the game would work. To make water fit within the context of the world, it will need to be very constrained and follow a very specific set of rules, so that its behavior will be very predictable to the player. This is because water will be an important role in solving several puzzles, and I can’t just have water splashing all over the place.

I’m still not finished with it yet, but just wanted to give you guys a preview of what I’ve been working on so far.

Here’s the first draft of the water system I wrote:

What’s happening here is that I start with a game object called the Water Starter. The Water Starter does raycasting in a number of directions (forward, down, left, and right) to determine if anything is there. If there’s nothing below it, it will fall down one step, and then re-perform the check. If something is below the water starter, it will check to see if something is in front of it. If there isn’t, it will move forward one step, and re-perform the check. At each step of the way, it creates a collider.

It looks pretty good, but it’s not what I want from a technical standpoint. There are simply way too many colliders that are created, and also, it isn’t responsive to environmental changes. So, for example, if the ground were to be removed at certain point for whatever reason, the water would remain in place, which is not what I want.

Here’s the second draft:

What I’m doing here is looking for changes in the blocking situation, for example if the water starter detects that there’s now no ground beneath it, it signals a state change. What I do then, is that I use the starting and ending positions to get a midpoint, and a distance between the points, and create one single collider. It doesn’t look as good as the previous version, since the colliders just pop into place, but from a technical standpoint, it’s closer to what I have in mind.

Here’s the third draft:

As you can see, I’ve started the check if there’s something in front, to the right or left of the water starter, and react accordingly, thus creating bends in the water. Also, in this version, each subsequent segment of the waterfall is actually a child of the previous segment. This way, if the source of the waterfall gets cut off, or if something changes higher up in the waterfall, all the subsequent segments will be affected.

Still quite a lot of work to do, but I’m celebrating the small victories for now.

Development Update – Kotaku

I was in NYC this past weekend for IndieCade East. The event was really great. I didn’t get to attend too many of the talks, but simply meeting other developers and checking out games at the Show & Tell sessions alone was worth the trip. I will do a more detailed write-up of my experience there later this month.

However, I have some very exciting news to share with you all – Relativity has been featured on Kotaku!


I met some of the Kotaku people while in NYC, and they invited me to swing by the office on Monday and play through some of the early levels of the game. It was my first time showing the game to the press, but I think it went super well.

You can check out the article here.

Or, if you’d like to skip right to the playthrough video, here it is:

Development Update – IndieCade East

I want to share some super exciting news. As mentioned in my last update, I’m currently in NYC at the moment for IndieCade East. Yesterday was the first day of the conference. I didn’t get to attend too many of the talks, as I had a lot of fun just meeting other developers in person and talking to them about my game and what they were working on.

The best part was I got to meet Alexander Bruce, who created Antichamber! Any of you who’ve been following this devlog will know that that game is a huge influence on Relativity, and is one of the games I’ve studied very closely this past year in making mine. The influence is probably quite evident in the aesthetic choices I’ve made, but also in the design of the overall structure and the progressions system of the game.

Anyway, it was super awesome to finally meet Bruce in person. He playtested the game and gave me some really good and invaluable feedback. We ended up talking for an hour or so, and it was an incredible experience for me to be a able to pick his brain on different design challenges I had been struggling with, and to get insight into how he approached the same kinds of problems for Antichamber. We even discussed the logistics for some of the new mechanics I’m thinking of introducing later in the game.

Talking to Bruce, I realized there were a lot of issues with the first stage of the game, with some of the mechanics for keeping track of progression, and some of the backtracking that the player had to do. Bruce gave me a lot of good suggestions on how I can approach these problems and possible solutions to implement.

Most importantly for me, he believed that my game was interesting and had potential. Of course, there’s still a ton of work that needs to be done, and a lot of problems to be addressed, but it was really great to hear that from him. He’s really direct and honest in his feedback too, so I can definitely take take his word at face value.

For me, as someone making a game for the first time, and also doing it completely on my own, it was very reaffirming to get positive feedback from someone whose work I hold in high regard. It took some weight of my shoulder, just knowing that I’m not deluding myself on the quality of my work.

Development Update – Portals & New Screenshots!

The last few days have been pretty intense as I’ve been working to get a playable demo ready to show off at IndieCade East. I wanted to include as much new content as possible, so that I could gauge different players’ reactions to the new direction that the game is headed in.

The portal system took a while to get right. There were still a ton of problems after integrating them into the game, and I actually ended up overhauling the entire system. In the previous version, I had all these triggers to detect when players were in different zones. Each trigger had a script and certain functions, so they were all cross referencing one another. For example, the detector to determine whether player was in range for the door to be open or not, would first check the detector to load the scene to see if the other scene actually exists.

It was way too confusing to manage, and when it came to debugging, it was a nightmare because I couldn’t tell which trigger or which script was causing the problem. Eventually I rewrote everything so that the only thing the detectors do would be to turn one boolean value on or off, depending on whether the player was inside or not, and a central script, the portal manager, would handle all the different states and controls.

In hindsight, this seems like the obvious approach, but it was really only clear to me after the portals and their basic functions had been put in place.

Anyway, here are some gifs of the portals in action:



And also, screenshots from the latest build!

Relativity_2014-02-12_v2 2014-02-12 21-18-43-28

Relativity_2014-02-12_v2 2014-02-12 21-17-50-11

Relativity_2014-02-12_v2 2014-02-12 21-28-27-18

Relativity_2014-02-12_v2 2014-02-12 21-24-55-21

Relativity_2014-02-12_v2 2014-02-12 21-36-44-37

Relativity_2014-02-12_v2 2014-02-12 21-38-22-67

Development Update – IndieCade East

IndieCade East

So, I have some pretty exciting news. I learned a few days ago that I’ll be demoing Relativity at one of the Show & Tell sessions at IndieCade East next week. The session I’m scheduled for is Sunday, February 16th 1:30 PM – 3:30 PM. I’ll have a playable version for people try out. So if any of you will be in NYC for IndieCade East, come say hi! (Itay Keren‘s Mushroom 11 will also be at the same timespot, so be sure to check out that game as well. It looks super sweet) It’ll be the first time I’m having the game playtested publicly in over 3 months, so I’m really looking forward to getting some feedback.

Also, if you stop by, you’ll get one of these sweet business cards, which I just got in the mail:


Integrating Portals

I’ve placed myself in a self-imposed crunch to try to get a mac build ready these few days before heading off to New York. My goal is to integrate portals into the main gameplay, and have the first several levels be able to smoothly transition between one another. This is probably the biggest change to the game since the last stable build, and I’d really like to see if it works well.

Here’s a shot of a portal integrated into the actual game:


You can see that the lighting between the two scenes is not consistent – there are no shadows in the scene inside the portal. However, this is something that’s going to have to wait for now. More important problems to tackle at the moment.

Mesh Collider vs Primitive Collider

Everything in Relativity is constructed out of boxes. This is mainly so that you any surface would fall explicity under one of six gravitational fields (if I had a slope at 45 degrees, it would have to be in 2 gravitational fields), and also because I have limited resources, it’s a minimalist style that I can do well. To try to optimize my scenes, I started to merge all the primitives into meshes, in order to reduce draw calls.

However, I soon started to have all these weird problems with collision. It turns out, while having a single mesh over many primitives may be preferable for rendering, it is not for so for collision. Thanksfully, I still had my original primitives saved. The current set up is I created a giant mesh with the primitives, but the mesh only has a renderer and no collider. I keep all the primitives, but turn off their renderers, so that only colliders remain.

It took a while to figure this out, but I’m glad things are working now.

Mac Build

Also, I finally went ahead and put together a build for Mac. And everything works great, except the camera is inverted along the Y-Axis…

mac build