Leaf Lerp Color, Dense Towers

Past few days have been insanely busy, especially with the stream schedule, and just a ton of new developments.

Streaming has been going really well. Super stoked about the community that’s growing over at the Twitch channel.

Below are some major updates.

Tree leaf material now lerps between colors when you change gravity

leaf lerp gif

Still have a bug where the lines start off with emission on at start, and then fade away quickly:

line start problem

Cube is growing back on tree with inactive colors. Not sure why it goes back and forth between correct and incorrect color:

cube grow back problem

Looks cool though!

Accidentally forgot to change distance between instances of the world due to a new editor tool that was implemented, and during the stream last night, we “discovered” this level. I love that it actually feels like a city!

tower dense 01 tower dense 02 tower dense 03 tower dense 04 tower dense 05

 

 

Perfectly Looping Structures

Back to working on the game after spending the holidays with the family. Really needed the break!

I’m going to start creating a series of perfectly looping structures as a kind of “visual study” and side-research project. These may work their way into game, maybe not. Mostly it’s a way to get my creative juices going. Sort like exercise reps to complement the main activity.

The very first one:

loop01

Playing with some colors:

loop02

Now we’re getting somewhere!

loop03

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:

Relativity_Portal_In_Game_01

Relativity_Portal_In_Game_02

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

DevLog Update – Saving System, Keys, and Bridge

The checkpoint/progress saving system is almost done. Made several improvements over the weekend, and also cleaned up the code quite a bit. For the script controlling the lights on the teleportation doorways, I managed to reduce the number of lines of code by about half after figuring out how to use arrays of arrays in Unity.

Stage-Map

Respawn System
I still need to spend some time working on the respawn system, which is used when players fall of ledge into nothingness. There’s basically several large invisible collider boxes around the level, and when the player makes contact with one of them, the scene restarts. Right now there are some problems with the player position, since the starting location when a scene begins is based on which entrance the player came in. I think one solution would be to not use a scene restart when a player hits a respawn trigger, but instead destroy the player object, and create another one, all within the scene.

Key Switch
In an earlier design of the game, whenever a puzzle is finished, the player would need to walk into a rotating rubiks cube in order to be teleported to the next area.

rubiks_cube

It acted as a sort of a key. There wasn’t a reason why it was a rubiks cube – I used it primarily as a placeholder, so I knew the look of it would have to change. There was also another problem with this mechanism – it didn’t allow of backtracking. After you touched the rubiks cube, it disappeared and you were brought to the next area. This worked fine when the stucture of the game was a linear one, but as I began to make it more open-world, it became problematic. Additionally, the “make contact and have it disappear” aspect of the key felt like a very cliched video game trope, and that was something I wanted to stay away from. It didn’t make sense within the context of the world.

I therefore switched instead to these key switches:

key_switch

Instead of walking into the key and having it disappear, here you’re actually turning a switch on. You’re not teleported to the next area, but the switches act as keys, unlocking doors to certain areas. For example, after you turn on the first blue key, you’re able to walk through any doors that only require one blue key switch to be on:

teleportation_doorway_opening

Notice the blue square in the top left corner of the door. That’s the signal that tells you it requires one blue key, and the fact that it’s lit up informs you that you’ve already switched it on.

To avoid confusion in the game, I’ve made these keys so that you can turn them up, but you can’t turn them off.

Appearing Bridge
I also went back and rewrote the code controlling the bridges that magically appear in front of you. Made the whole thing much more efficient and clean. While I was doing this, I decided to add a bit of offset to the animation of the bridge, so that the segments do not all appear at the same time.

Here’s what it looked like before:

bride_forming

And here’s what it looks like now:

bridge_forming_2

You can notice that in the newer version, the bridge segments that are further away take slightly longer to form than the bridge segments closer to you. In the old version, all the segments would form at the same time.

DevLog Update – More GIFs!

Continuing to work on the redesign of the first stage. Happy to say that it is almost done, probably around to 90% mark now. Still plenty of finishing touches to add, but the end is in sight (well, just for this level at least).

Anyway, more GIFs!

Here’s another platform rising from beneath the water:
Platform_Rising2

And here’s a special-purpose door opening and closing:
doors_wip

This is my to do list for the rest of the day:

  • Add sound effects to the various elements in the first stage of the level
  • Add a slight delay before platform emerges from the water after the button is pressed
  • Fix the respawn triggers in the scene
  • Add teleportation chambers

Bonus: I’ve been listing to ‘Magic Arrow’ by Timber Timbre on repeat these last few days while working. It’s a great track! You guys should all check it out: https://www.youtube.com/watch?v=icJOkfS7ImA

DevLog Update – Animation Problem, GIFs

The last two days have been pretty slow with regards to productivity. Lots of “one step forward, two steps back” moments.

The one problem that plagued me for hours was that my animations would only move the colliders of the objects, and nothing else. Like this:

Unity_Animation_Collider_only

As you can see, for everything except the stairs, only the collider (the green outline) is moving, but the rest of the object remains behind.

For hours, I struggled over this, and couldn’t seem to figure out what was wrong. Eventually, I put the question to twitter, and David Laskey pointed out that it might be due to having the geometry set as static. It turns out he was right! Thanks to him, I did not destroy my keyboard out of frustration.

I was aware of the static setting for game objects, but up until this issue came up, I thought it applied only in the context of lightmapping. I didn’t realized it affected animation as well.

I think what threw me off also is that previously when I animated, I was using Unity’s primitive shapes, which are by default not set to static. However, this time I was using objects created with ProBuilder, and those are by default set to static, so that threw me off a bit.

Anyway, got the animation working eventually, here it is in action:

Platform_Rising

I’m continuing to work on redesigning the first stage of the game, refining the architecture, and polishing bits here and there.

Here’s one of the red doors:

Red_Door_Opening

And this is a clip of a bridge that forms itself in front of you (Bastion inspired), plus a gravity rotation:

bride_forming