Development update video #6

Development update video #6 is now up! It summarizes the last 10 months or so of development down to 5 minutes.

These are some of the topics covered:

- Save system
- Menu
- New water art style
- Tree growing animation
- New portal system
- World shrinking mechanic

The last one of these videos I did was back in June 2016, then development got really busy and I stopped. Now that the architecture of the game is more or less set, I’d like to produce these on a biweekly basis.

DevLog Update – Decals

The last 2 days have confirmed my theory that it’s the most trivial parts of a game that end up being the most time-consuming and tedious to implement.

I cleaned up the code for the Teleportation Doorways, and started to replace the old teleportation areas with this new element. However, I started to notice this very weird bug: the decals around the archway of the door, which show how many keys the player has obtained, and how many are needed to open the door, would fade in and out of visibility.

The way the decals for the door works is that I have 12 of them responsible for the key lights. 6 of them show how many keys are required, and 6 of them show the number of keys the player has.

The decals showing the required number of keys are off-set from the mesh by 0.01. This is because if there is not offset, there ends up being a strange flickering effect because there are 2 meshes overlapping and the engine doesn’t know which one to render.

Then, because the decals showing how many keys the player has need to be shown on top of the decals showing required number of keys, they are off-set by 0.02, show that they are rendered over the other decals.

However, I was noticing a problem where, if I stood at certain angles, some of the decals showing how many keys the player has would become invisible. I double checked the code, and the logic was all correct. As far as the element was concerned, it was detecting the right number of keys, and had the right requirement number. From this, I determined it was just a problem with the decals.

I started to play around with the different settings of the decal projectors: size, culling angle, position, affected layers. Eventually, what I found was that the decal for the required keys and the decal for the number of keys the player has, cannot overlap. Despite having the mesh off-set values be different, if the decal projectors overlap, there ends up being some kind of a problem.

This is what the set up for the decals look like now:

decals_setup

You can see that the decal projectors (represented by the capital D with three lines next to it), are off set from each other.

Not the most satisfactory solution, as I still don’t know what was going on. However, it has solved my problem for the moment, and I’m just glad I can move on and work on other aspects of the game.

DevLog Update – Prototypes & Project Management

The last few days have been pretty slow. I have a lot of deadlines for different applications due at the beginning of February, so have mostly been busy with writing and other bureaucratic activities.

I’ve also be refining and tweaking old levels. Between the last stable build (from around October) to now, I’ve gotten much better at making assets for the game, so a lot of the stuff from the levels I built six months ago no longer match the stuff I’ve been making. As such, I’ve had to go back and redo a lot of stuff. Some of these early levels are a real mess, so it’s taking me quite some time to fix them.

I’m also trying to improve the hierarchy of the project to manage assets a little better. Was speaking with a developer friend of mine yesterday evening, and he mentioned something along the lines of “naming things is 90% of development”. It’s a bit of an exaggeration, but there’s a lot of truth to that.

For me, the problem is that I do a lot of prototypes of different mechanics, which then get incorporated into the game without a restructure or rewrite. So basically, what happens is that the messy structures, which are good for prototypes since they’re not that big anyway, end up being carried over into my main project. For a while, I had like 20 scenes all named something like “TEST_001A”. After a few months, I couldn’t remember which ones were good or even what they were.

I’ve done a lot of cleanup already, but there’s still plenty to do. There are also still far too many “Misc” folders in the project…

Anyway, yesterday I did a bit of an overview of the project, basically going over all the content I’ve made and levels I’ve designed. The good news is that there’s a ton of stuff, and a lot of it really good. There are at least 4 very interesting mechanics that I’ve prototyped which have a lot of potential to become very interesting puzzles. The bad news is that much of the code base is a mess and is going to require a lot of work to get it solid.

Hopefully once I get these deadlines out of the way, I’ll be able to dive back in to more hardcore development.

Anyway, here are some images to give you a taste:

Relativity_Game_Screenshot-2014-01-14_16-52-57

Relativity_Game_Screenshot-2014-01-14_17-22-10

Relativity_Game_Screenshot-2014-01-15_00-35-01

Also, starting to get somewhere with the portals:

Portal_prototype

DevLog Update – Teamwork, Design Docs, Expanding the City

I met with Kiku, the sound designer and composer, on Sunday to discuss the music of Relativity. I’m learning that working in a team is very different from working solo.

For one thing, I’ve come to appreciate the power of design documents. Up until now, I hadn’t created a design document for Relativity, nor did I feel the need to. However, I think when you’re working in a team, it becomes a really powerful way to make sure everyone is on the same page.

I am continuing to expand the world within the game. Not doing so much programming these days. Mostly modeling and high-level design work on paper. Really looking forward to taking several days off next week to relax.

The level codenamed “The City” is the one I’m still working on. It’s about 70% complete now.

Relativity_Willy_Chyr_The_City_70_percent

DevLog Update – Replacing Color Change Beams, finetuning puzzles

Spent today and yesterday fine-tuning various puzzles that use color-change beams and dispenser cubes. Mostly this involved replacing the old version of the beams with the new ones, and adjusting solutions that were either too obvious or too tedious to execute.

Tomorrow I will start designing different architectural elements and space to populate the game’s world.

Anyway, got some new screenshots to share:

Relativity_Game_Screenshot-2013-11-25_21-07-26

Relativity_Game_Screenshot-2013-11-25_21-08-37

Relativity_Game_Screenshot-2013-11-26_00-28-33

Relativity_Game_Screenshot-2013-11-26_12-51-31