next »

[William Chyr]

Great song. Forgot where I first heard it though. Think it was a movie or show trailer

Breaking Bad - Season 3 Episode 2 

[Christian]

Great song. Forgot where I first heard it though. Think it was a movie or show trailer

Breaking Bad - Season 3 Episode 2 

Yes, now I remember. Awesome scene

A response that specific, you catching up on the series?

[William Chyr]

Yes, now I remember. Awesome scene

A response that specific, you catching up on the series?

I actually finished it back in September, but just re-watched a few episodes recently.

When I was watching that particular scene, knowing what was going to happen took some of the suspense away, so I was paying attention to other details. It was then that I noticed the music, and how awesome it was.

[William Chyr]

DevLog Update #20 - 01/12/2014

Screenshot Saturday

It's been a really exciting weekend for me. As some of you may know, I've been participating in Screenshot Saturday pretty regularly for about 2 months now, both on Reddit and on Twitter. Both places have been good venues to showcase some work-in-progress stuff and get feedback.

This Saturday, I shared this image below, which I made earlier in the week, and had posted in a previous devlog update:



It got some good response on Twitter, people were retweeting it and also commenting on the image.

I decided to share it on /r/indiegaming, the section on Reddit dedicated o indiegames. I had been lurking there for quite some time, but had never posted anything about Relativity, so had no idea what to expect. And to be honest, I wasn't expecting much, just thought it would get lost amongst other posts, or worst, get downvoted to oblivion.

Instead, the feedback from the commutniy was really enthusiastic! It quickly became the most popular post on the subreddit, and I got a lot of response. Even RockLeeSmile, the Let's Play youtuber, and Mike Blackney, who worked on Antichamber, commented.

Here's the post: http://www.reddit.com/r/IndieGaming/comments/1uz7ig/escheresque_staircases_from_a/

Anyway, I know this stuff isn't that important, and there's still plenty of work to do, and a long road ahead of me. However, because I've been working on this game for so long by myself now, it can be really hard to gauge whether something I think is good actually is good, or if I'm just deluding myself. So for me, getting such positive feedback at this stage was just encouraging, and I felt like it validated my efforts in some way. At least now I know that I'm on the right track.

Portal

Ok, I'm starting to prototype some portal mechanics for my game. It's turning out to be a little more difficult than I had expected. However, I've seen some pretty good working examples in Unity, so at least I know it's possible. It just requires time.

My approach is to use render textures. Basically having cameras that point out from a portal entrance, and then rendering whatever the camera sees onto a texture, which is then placed on another portal door.

I'll need to do some matrix transformations so that the cameras on the portal doors move according to how the player camera moves, so that it appears as if you're actually looking through a portal, and not just a flat image.

This is just the visual side of it. In terms of actually teleporting player and objects across, I'm thinking I'll need to use additive asynchronous level loading so that I can have two scenes open at once, and create the illusion of a seamless world.

Anyway, here's what I've got so far:



Gotta start somewhere.  

[OniWorld]

Awesome progress! I think one thing that could work really well in Relativity is non-euclidean level design. That, combined with everything you have currently, will really throw some people off. It's essentially just using the portals like you've shown above, but in a clever way. It works really well in source engine because Portal already has those mechanics.

Here's an awesome video that showcases what I mean really well:

[Christian]

Awesome progress! I think one thing that could work really well in Relativity is non-euclidean level design. That, combined with everything you have currently, will really throw some people off. It's essentially just using the portals like you've shown above, but in a clever way. It works really well in source engine because Portal already has those mechanics.

Here's an awesome video that showcases what I mean really well:

This. I love games that use Escher style level design.
Now it's not really similar to Relativity, but would love to see some kind of elements like Monument Valley's levels. Check out the

to see what I mean. Playing with perspective, impossible structures, stuff like that

[William Chyr]

Awesome progress! I think one thing that could work really well in Relativity is non-euclidean level design. That, combined with everything you have currently, will really throw some people off. It's essentially just using the portals like you've shown above, but in a clever way. It works really well in source engine because Portal already has those mechanics.

Here's an awesome video that showcases what I mean really well:

Thanks! I am planning on having non-euclidean level design in Relativity. That's precisely the reason why I'm making portals, so that I can have rooms inside boxes, looping hallways, etc.

I actually was just playing that non-Euclidean level you linked to. It's one of the community maps in Portal 2, and it's given me a few ideas. I've been having trouble getting the projected camera view in the portal to line up with the players view. You can see what I mean below:



It seems that for some reason a default camera you create is actually different from the camera that's attached to the character controller...

Anyway, kind of wish I was using Source for this. Valve has obviously spent a ton of time making that mechanic really smooth. With Unity, on the other hand...

There actually is a plugin in the Unity Asset Store that does portals, but it's a bit pricey at $35 (it also doesn't have very good reviews as the dev is not very responsive and doesn't provide support). However, there really doesn't seem to be a lot of information about making portals in Unity, and the package seems to be a pretty good clone of Valve's, so I might have to suck it up and get it, if I can't figure out how to do it on my own.

Now it's not really similar to Relativity, but would love to see some kind of elements like Monument Valley's levels. Check out the trailer to see what I mean. Playing with perspective, impossible structures, stuff like that

I actually don't think I can do what Monument Valley does. A lot of those tricks are only possible because their world is actually a 2D world, in the sense that you only see it from one perspective. you're not looking at the world from the point of view of the character. In Relativity, you're actually experiencing the world in 3D, and can look at the world from any angle, so you can't really fool the player with those kinds of perception tricks.

Take the penrose triangle, for example. You can pull that off if you lock the player's position and perspective. But if they're allowed to walk around, the illusion gets broken.

I will have impossible structures in my game, but they're going to be 'impossible' in a different sense than the structures in Monument Valley.

[William Chyr]

DevLog Update #21 - 01/15/2014

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:







Also, starting to get somewhere with the portals:

[William Chyr]

DevLog Update #22 - 01/18/2014

Been a little while since the last update. As mentioned last time, still dealing with lots of boring bureaucratic related stuff, so haven't had as much time to work on the game.

Today I'm starting to work on a position saving system so that players can respawn after falling off platforms. It's a little bit tricky though as I need to save the player's rotation as well, but Unity's playerprefs doesn't allow you to store quaternions.

It's turning out to much more difficult than I had originally imagined.

Here's a picture of a scene with the respawn triggers turned on:

[chris wade]

Maybe try saving the euler angles of your rotation?

[William Chyr]

I did, but it was getting messed up for some reason.

My new solution is basically to set up 6 empty game objects, each rotated so that its bottom is facing a different gravity fields (basically along the positive and negative direction of each axis). Then, basically, I just need to remember which gravity field the player was on before the respawn, and apply the quarternion from the correct gravity game object to the player.

[oleomingus]

bizarre geometry, magically appearing bridges, and portals ! The game updates in complexity at a staggering pace. Brilliant work. this Devblog is an absolute delight to follow.

[William Chyr]

bizarre geometry, magically appearing bridges, and portals ! The game updates in complexity at a staggering pace. Brilliant work. this Devblog is an absolute delight to follow.

Thanks, oleomingus! I do feel an little bit in over my head (at least more so than usual) with the new additions. I knew a lot of the more interesting thing wouldn't be easy to implement, but hadn't expected there to be so many little things to consider with each new element. Portals alone bring up a whole range of questions, beyond just the technical ones. Like, should there be a door in front of a portal? What if areas need to be locked off? Should players be able to carry items through portals, etc? If not, then how do I stop them? If I destroy the item, wouldn't it need to be recreated somewhere?

Anyway, I'm taking a divide-and-conquer approach, and just implementing things a little bit at a time. It's the most efficient way, as it means I often end up going back and replacing things, but I think it makes the whole task seem less daunting and more manageable.

[William Chyr]

DevLog Update #23 - 01/19/2014

Player Rotation Saving

In the last update I talked about how I was having trouble saving player rotation using Unity's PlayerPrefs. I was using euler angles at first, but was getting some weird bug, so decided to use another system involving grabbing quarternions from various objects already in the scene.

As it turns out, euler angles is the correct solution (you were right, cjacobwade). The reason why the weird bug was happening was because in saving the player position, there was a typo in the code, and I was saving the Y coordinate as the Z coordinate, so the player was being respawned at a completely different location, without any ground beneath him, which resulted in the weird rotation (I have some code that uses ray tracing to detect the surface normal of the ground in order to determine which gravity field is on, and it requires the player to start the game with ground beneath him).

Game Progress Checkpoint System

I'm also working on a system to keep track of player progress throughout the game. Right now, the structure of the game is like this: There are a number of large open areas, called hubs. Each hub contains entrances leading to independent puzzles. So, for each hub, I assign a number that's basically n x 1000, for example, hub 1 is 1000, hub 2 is 2000, etc.

Then for each level that the branches off of a hub, it gets a number that n x 100 plus the hub number. So independent levels branching off of hub 1 are 1100, 1200, 1300. Of course, this limits each hub to only 9 levels, but the way I'm structuring the game, each hub only has between 3 - 7 levels branching off.

Then items inside each level, are labelled 1101, 1102, etc. This way, it allows me to keep track of which doors the players have opened, which triggers have been pressed, and which area they've already visited.

I'm not totally set on this system yet, as it has its obvious limits. But we'll see. I think it's enough for now.

Puzzle 1 Redesign

Continuing the mission of redesigning earlier parts of the game, I've been working on redesigning the first puzzle. One of the major changes is that I actually combined two puzzles into this one. It used to be split into puzzle 2 and puzzle 3, but after watching playtesters go through these levels, I realized the two, while different, were sort of testing around the theme, with the latter being an application of something learned in the former. It made more sense for them to be together.

Here are some images:








Teleportation Doorways

Starting to add these entrance areas I'm calling Teleportation Doorways to the levels. Basically, they teleport you from one level to another. They're really placeholders until I get portals working. Ideally, I'd like the whole world to appear seamless.

[William Chyr]

DevLog Update #24 - 01/21/2014

I should say in advance that there's a lot of rambling in this devlog post. Mostly just trying to work through some design problems. Read at your own discretion.

I spent the last two days working on a design problem that I initially thought would be simple and trivial, but turned out to be quite complicated as it was very closely related to the central structure of the entire game.

Doors, Keys, and a larger design problem

I mentioned at the end of the previous update that I was starting to work on these Teleportation Doorways, which are basically triggers that teleport the player from one scene to another. For now, they are primarily placeholders until I get seamless looking portals working.

It seemed like a pretty simple element to design and implement. However, as I started to get into it, I realized I was actually tackling a much bigger problem.

You see, the game is structured as an open world game, within which are a series of linear puzzles. I've  described the game as a mix of Portal and Myst, here I will go into detail why.

Portal

Portal is clearly a very linear game. You progress through the set of puzzles in a very specific order, and aside from the little bit towards the end before the boss fight, it's always pretty clear where you should be headed. In Portal, where there is a strong focus on a core mechanic, this structure makes a lot of sense and works really well. In order to solves the more advanced puzzles, you need techniques developed in earlier levels. In Portal, first you learn to use portals, then you learn to put boxes on buttons to open doors, then you learn to combine the two, and so on and so forth. Towards the end, you're using all the techniques you've learned to solve the puzzles.

For me, personally, I really liked this structure, as far as puzzle solving is concerned. Every time I was stuck, I knew there was a solution, and I just needed to think of approaching the puzzle in a new way to find it. I wasn't stuck because I didn't have the right tools, or because the game hasn't opened up the area yet. I was exactly where I needed to be, and just needed to think through the problem, given the elements on hand. For me, this was really fun and enjoyable. And even though there were parts that were challenging, they were always fair and not frustrating.

Relativity started out like this, with a linear sequence of puzzles that grew progressively more difficult, involving techniques and skills that built up on each other. However, in the course of development, I came to realize that the world in the game is much more important and interesting than the puzzles themselves, and that exploration would actually become the main component of the game. This is where I started to draw influence from Myst.

Myst
While I really like the world that's created in Myst, how encompassing, and detailed it is, I can't say that I was a big fan of the puzzles. There were many that just felt outright arbitrary, and also, the skills you used to solve one did not necessarily transfer to the others. In some ways, one could say that the puzzles in Myst were more riddles than puzzles. There was no core mechanic that one became better at using to solve progressively more challenging puzzles.

Combining the Two
In Relativity, what I would like to do, is bring together the best elements of Portal and Myst and combine them together. There would be an open world that players are free to walk around and explore, with lots of details and hidden treasures, but at the same time, all the puzzles would focus around variations of a core mechanic. But how do you ensure that players go through the puzzles in the sequence you intended? This is where the doorways come in.

The doorways would be locked at first, and would require keys to open them. By restricting access to the keys, I can ensure the player solve puzzles in a specific sequence. For example, a player may come across the door for puzzle 3 before he comes across the door for puzzle 2. However, in order to open the door for puzzle 3, he needs get the key by first solving puzzle 2.

As such the doorway needs to communicate this information:

1. Whether it is locked or unlocked.
2. Whether the puzzle it leads to has been solved or not.

Regarding the key system, I decided to use a quantity system, similar to Fez. Basically, there aren't specific keys for specific doors, just certain number of keys. So for example, Puzzle 3 requires you to have two keys to open the door. This is similar to the system in Fez.

The thing with the key system though, is that I don't want to have an inventory system in the game. I don't want to player to hit 'q' and bring up a screen showing them how many keys they've collected. That might make sense in other games, but I think here it would just take away from immersion.

Anyway, here's the system I came up with:



Basically, here's how it works: There are 36 keys that can be obtained in the game: 6 blue, 6 red, 6 yellow, 6 green, 6 orange, and 6 purple. Each Teleportation Door requires a certain number of each colored keys. In the above screenshot, to open the door, you'll need 3 green keys, 4 yellow keys, 1 blue key, 2 red keys, 6 orange keys, and 5 purple keys.

How would you know how many keys you have if the game doesn't have an inventory screen? Well, the door tells you. If you look at the sqaures, you can see that some of them are slightly larger and brighter. The orange ones are most evident, you can see that there are 5 slightly larger and brighter squares, and 1 dark one. This tells you that you have 5 orange keys already. In other worlds, the doors themselves serve as an inventory screen. In the above screenshot, you can see that the player has already met the requirements for blue, red, and green keys. However, this doesn't mean that the player only has one blue key, the player could have more, but this door only requires one blue key, and that requirement has been met.

I think this system thus provides just the amount of information that the player needs to know to progress.

Additionally, it doesn't mean that there will only be 36 teleportation doorways. There are many different combinations of requirement keys, but it ensures that the player always goes into each puzzle having already learned the necessary techniques previously. For example, there could be a door that requires 6 blue keys and 6 red keys, and another that requires only one yellow key. The player could have the requirement for both doors, and could do either one. The door with the yellow key is simply on a different track, and doesn't require the same techniques needed for the puzzle with the 6 blue and 6 red keys.

[William Chyr]

Finally got around to properly setting up the IndieDB page for Relativity: http://www.indiedb.com/games/relativity

If any of you are IndieDB users, I'm going to try to be active there as well and start posting new content on a regular basis.

[William Chyr]

DevLog Update #25 - 01/23/2014

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:


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.

[Connor]

when you get this thing playable i wana be the first one on XD,
this has progressed so rapidly, its so cool to watch.
good luck!

[William Chyr]

when you get this thing playable i wana be the first one on XD,
this has progressed so rapidly, its so cool to watch.
good luck!

Thanks for the encouragement, Connor! I'm glad to hear that at least progress appears fast to some people. For me, it's felt extremely slow these last few days. I just want to work on puzzles and architecture, but have instead been caught up with this progress saving system.

It's coming along though, and once this part is done, it'll be easy to implement it in other areas of the game, so development later should go a little more smoothly.

[William Chyr]

DevLog Update #26 - 01/26/2014

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.



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.



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:



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:



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:



And here's what it looks like now:


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.