Development Update – Game Feel, Rotation System

Game Feel Improvement

A few weeks ago, I wrote a post here about game feel issues in the game, specifically the movement of rotating onto different surfaces.

At the time I was trying to use a system of procedurally placing invisible quarter pipes in front of the player and letting the player walk up that in order to change surfaces.

I got it so that the quarter pipe would line up right against the wall, and move along side to side with the player.


Despite this, the system didn’t end up working very well. It was too unpredictable as to where the player walked to, and involved to many sub-cases. The quarter pipe worked best when it was 4 units high and 4 units deep. This meant that any wall shorter than 4 units would need a smaller quarter pipe. However, smaller quarter pipes just didn’t feel as good.

There was also the issue of the tail end of the quarter pipe catching the player as the player walked off of it, and messing up movement. Corners also didn’t work very well, as there were 3 different surface normals all within really close range of one another, and the quarterpipe placement would occasionally overlap with the player.

I decided to go with the previous system of rotating the player rigidbody object through code, and just improving that.

However, making with the quarterpipe system was not at all a waste of time, as it allowed me to get a feel for what a more “natural” rotation movement would feel like, and served as a good reference point when improving the other rotation system.

Issues with Old Rotation System

After studying the old rotation system a bit, I realized that there were three reasons why it felt clunky:

Problem #1: When the player rotated onto a wall, they snapped to be facing straight regardless of original angle of approach - this is probably best explained with a visual. Look at the gif below – the red line shows which way the character is facing. Notice how it doesn’t matter the angle with which the player is facing the wall before rotation. After rotation, the red line is always aligned with the axis. It’s especially noticeable in the gif when the player rotates from the orange surface to the blue surface.


I actually hadn’t noticed all throughout development until I started to pay attention. What happens during gameplay though, is that you end up having to keep readjusting the angle you’re facing, which contributes to the clunkiness.

2) The player’s speed drops to 0 after rotation, even if they were holding the forward button – Again, a very slight effect, but contributes greatly to clunkiness. It’s like coming to a red light at every intersection. The player is constantly stopping and going, instead of being in a flow state. The problem here was that I was making the player rigidbody kinematic during rotation, and then disabling it again after, so that the physics force pushing the player forward had to be reapplied.

I’m not sure why I implemented the temporary kinematic thing.

3) The rotation speed doesn’t take into account the player’s speed when enter rotation. - It didn’t matter if you were running at a wall, or standing still next to it, if you hit the rotate button, the speed ends up being the same.

Improvements to Rotation System

1) Player can now rotate onto wall, and the angle with which they were facing the wall is maintained - This was pretty tricky to implement. Mostly it involved using a lot of quarternions and raycasts. A basic run down: first figure out the difference in angle between the player’s actual rotation and what the rotation of the player would be if they were directly facing the wall. This is done using the surface normal of the wall (gotten from a raycast). Then, create a quaternion based on the angle difference, and apply that to the quaternion of what the player would be after they switch walls.

Anyway, here you can see it working:



2) Player doesn’t stop after rotation, if they continued pressing forward the whole time – pretty straightforward technical fix. I just didn’t set player to be kinematic during rotation.

3) Rotation now takes into account the speed with which player approaches the wall – if you rotate from standing, the rotation will be much slower than if you rotated when approaching the wall at full speed.


As you can see, it takes into account the initial speed, and also makes it slightly faster during the middle of the rotation.

Head Bobbing

I’ve added a slight head bobbing effect when you’re walking. Don’t worry, you can disable it if you want to. :)

The more important effect is a more noticeable bob that happens when you land after a long fall. The landing always bothered me before, because the player would just stop immediately.

I’ve added an effect so that the head will bob up and down once after you land, and it makes landing feel like it has actual impact.


Sorry for the potato quality – it’s a gif made from a vine recorded of my monitor (too busy to actually screenrecord it properly).

2 Year Anniversary of Development, 1 Year Anniversary of DevLog


Today is Thanksgiving in the US. This is a really special time for me, as the very first prototype of RELATIVITY was written during Thanksgiving weekend in 2012.

Initially, RELATIVITY was intended to be a project to learn Unity with, and I had expected to be finished in three months.

And now, two years later, here I am. These past two years have been an incredible journey for me – I’ve learned a lot about myself, learned a lot about games and game development, and best of all, have met some very passionate and talented people who continue to inspire me everyday. Working on RELATIVITY has been the most difficult task I’ve ever undertaken, but also the most rewarding.

RELATIVITY is not yet finished, and there’s still a lot of work to be done, but even coming this far, I could not have done it alone. My family and friends have been incredibly supportive throughout this process. Likewise, I owe a tremendous amount to the Chicago game development community, as well as the indie game scene at large.

To me, RELATIVITY is a community project. I’ve received so much support, feedback, and advice from others throughout development, and the game has improved exponentially as a result. I’m not just talking about fellow indie developers either. People who read this devlog, who playtested this game, who’ve written about it, who’ve organized events to show it, and who’ve told others about it. All of these people have had an impact on the game.

So, anyway, I just wanted to take a moment to thank everyone who has been a part of this journey so far. Thank you for reading, and thank you for your support!

PRACTICE Post-Mortem – Part 3


Sunday was the third and final day of PRACTICE. The format of the day was more or less the same as that of Saturday. The talks were much more detail-oriented compared to those of the first day. For example, many of the talks on Saturday were about game design in the broad sense, the Sunday talks focused more on design choices within specific games.

Things I Liked at PRACTICE

1) The Size of the Conference - PRACTICE was one of the smallest conferences I attended this year. I think there were about 150 – 200 attendees. It felt incredibly intimate, and was very easy to meet new people.

2) Single-Track Activities - A single track meant that everyone got the same experience, and didn’t have to choose between talks thinking they were missing out. Another thing is that you got to attend talks you may not have had you had a choice. If there was a talk about outdoor social games, and a talk about puzzle design going on at the same time, I would have gone to the one about puzzle design just because of my current project. However, the outdoor social game talk may have had some really good insights for me. At PRACTICE, there wasn’t this issue, and I got to see a whole spectrum of talks and was exposed to some new points of view.

3) Open-Problems and Discussions - I can’t stress how awesome these are for getting feedback on specific design challenges you may be facing. If you go, definitely take advantage of the fact that there are some amazing designers in the audience.

4) Organizers are really open to feedback - You can tell the organizers are really interested in improving the conference, and are constantly seeking feedback from attendees. On Sunday, right before the closing talk, there was a session where the organizers took suggestions from audience for things they’d like to see and improve upon in the future. There were also plenty of other opportunities to offer opinions.

Things I’d Like To See In the Future at PRACTICE

There wasn’t anything negative that I didn’t like at PRACTICE, and as stated previously, the organizers are very open to suggestions and feedback. As such, there isn’t a list of “things I didn’t like”. Instead, I’ll list just a few things I’d love to see in the future at PRACTICE. Some of these were actually suggestions made by other attendees during the feedback session, and I really liked them, so I’m listing them here.

1) Talks from Experts in non-game fields - I would love to see a talk by a psychologist on how children learn, or a neuroscientist on how the brain perceives new information, or an architect on how to design physical space to guide people, or an urban planner on how to design cities. They don’t even need to talk about it in the context of games. I think a lot of their insights would be directly applicable to game design, and I’m sure a lot of the designers in the audience would be able to pick up on how it applies to their practice.

2) A live level design session - It would be awesome to see a level designer create a level with feedback and suggestions from the audience, and discuss why some things work well and some don’t.

3) Panel Sessions on specific topics - I think a panel session like this one from IndieCade, featuring Jonathan Blow, Marc Ten Bosch, and Droqen talking about puzzle design would be a awesome at PRACTICE. It would be great to hear what different designers have to say on the same topic.


Was it worth it?

For me, yes. I went to PRACTICE with a very, very specific design problem that was holding me up in the development of the game. I was able to present it in front of a group of people who were all passionate and interested in game design, and was able to get their feedback on it. There could not have been a better group of people to ask.

I haven’t had a chance to actually implement any of the solutions, so cannot know for sure whether the design challenge in the game has been resolved. However, I got a lot of ideas, and was able to discuss the issue quite thoroughly with a lot of other game designers.

Outside of this specific design problem, as someone who is very interested in game design, I found the talks and discussions of the conference really informative and insightful. If funds and timing allow for it, I would definitely return next year. Compared to all the other conferences I’ve been to this, it’s definitely the one where I’ve learned the most about game design in general.

Should you go?

If you’re a beginner, and are just standing to learn about game development/design, I actually would not recommend that you go to PRACTICE. I’m not saying I would recommend against it, but that I wouldn’t say “You should definitely go!”. This is not to say you won’t stand to gain anything if you do go, but I think a conference like IndieCade or GDC would be much better and more suitable. For one thing, at those conferences, there are a range of activities going on simultaneously, so you can customize your experience to suit what you’re looking for. At PRACTICE, if you’re finding the talks on design to be too in-depth, there isn’t really much else to do. Additionally, at other conferences, there’ll be talks in which they introduce the basics of a game engine, or talk about starting out with a project, etc, and those aren’t at PRACTICE.

However, if you’re a game designer, and are really interested in taking your practice and craft forward, I can’t think of a better conference to attend.

PRACTICE Post-Mortem – Part 2

Saturday – Talks / Discussion Groups / Open Problems

The day started at 9 AM with breakfast, which was provided at the conference. It was in the same place as the reception. It was a nice way to get to talk to some of the other attendees just as the day was getting started.

The first talk of the day was from Joanthan Blow:


The format of the talks was pretty straightforward, either 30 minutes or an hour, with some time for questions and answers in the end. Like I said in part 1, since the videos will go up online, I won’t talk about the content of the talks.

Here were some of the other events on that day:

Lunch/Discussion Groups


Lunch wasn’t provided, but there were plenty of spots around NYU where you could grab food. Just outside the lecture hall, there were several tables set up, each with a discussion topic, and people who were interested in that topic could just sit down at the table to eat and talk. If you had a specific topic you wanted to discuss, you could write it on a card, and give it to one of the conference volunteers in the morning.

So everyone went out, grabbed some food, and came back for the discussion sessions.

Personally, I thought these sessions were more effective for meeting new people, than they were for actual discussion of game design. I think this is largely due to how broad the topics were. For example, I sat at a table where the topic was “Level Progression”. Most of the conversation centered around examples from games I didn’t play, so I couldn’t really follow along. I think it might have been better if the topics were more specific.

In any case, I think it’s more important that discussion groups facilitate meeting new people, and I think that it accomplished well.

Feedback Loop
This was something that the organizers were trying out for the first time. It was basically like a lightning impromptu panel session. It happened after lunch on Saturday and Sunday, and of the organizers would go up on stage and ask a question, and get some of the people in the audience to talk about it. The first day the question was about puzzle design (I think? I don’t remember), and the second day the question was about the role of puzzles in narrative games.

These were kind of cool, but I don’t think they were super effective. A large part of it was that the conference was always running just a little behind schedule, so the feedback loops got cut short. For example, the feedback loop on the 2nd day got cut short, and didn’t allow for people in the audience to participate.

Open Problems


This was my favorite part of PRACTICE, and pretty much the main reason why I went.

Open Problems is an hour-long session where conference attendees can get up in front of the entire lecture hall (so pretty much everyone at PRACTICE), present a problem, and get feedback. You have one minute to present your problem, and then about 3 minutes for the audience to respond.

A few days before the conference started, an email was sent to all the attendees with information for signing up for Open Problems. About 8 people signed up in advance. I was a little surprised at this, because I thought everyone would be clamoring for a spot. I mean, this is a room full of the best minds in game design! What better group of people to ask for feedback regarding a game design problem?

Several people did sign up on the day of Open Problems, so I think in total there were about 15 presenters.

The Problem I Presented: 

In my game, the core mechanic is the ability to walk up walls and ceilings. Each surface has a different color associated with it, and certain objects that you can use or activate when in that color:


Here’s an early problem, where we use a blue box to “counterbalance” the purple box and prevent it from sliding down:


Because you can walk on any surface in the game, there is no “objective up”. This means that I cannot have an infinite ground, because that would be “objective down”. Therefore the world has to be a floating platform. This introduces the problem of players falling off the world. One solution to this is to fade the screen to black and respawn the player, but this is boring.

Instead, the world wraps around on itself, so if you fell off, there’s just a duplicate of the world right below you:


You can do this along every axis. So let’s say the world in the gif is level 1. How do I get the player to go to level 2 seamlessly? Level 2 cannot exist in the same physical space as level 1. It can’t be above, below, or to the right of level 1, because that’s where the repetitions of level 1 are.

One way to connect levels is through portals. However, players then get really confused about the relation of the worlds with one another. And let’s say you go from level 1 to 2, then 2 to 3, and so on and so forth until you’re at level 10. What if you need to go back to level 1. Would you have to go through 9, 8, 7, 6, and all the other levels? That gets really tedious.

Anyway, I presented this to the group, and got a ton of great responses. In the next few weeks, I’ll be working through this issue, and will go into the topic in more detail, but for now, these are the notes my friend Rob Lockhart took for me of the different responses:


As you can see, there were a ton of ideas and suggestions.

The best part of Open Problems though, is actually not what happens during the session itself. You’re on stage for less than 5 minutes, so there’s really no time to dive into the topic. However, now everyone at the conference is familiar with your game and your design challenge.

For the rest of PRACTICE, a lot of people would come up to me and say “I’ve been thinking of your problem, and here’s a thought…” I was able to get into a lot of deep discussions this way. Additionally, in the past, when explaining my game, the biggest challenge was that it was hard to visualize the mechanic and what was going on. But since I had shown a video of the gameplay, everyone knew what I was talking about. This helped tremendously.

If you do plan on going to PRACTICE in the future, definitely take advantage of Open Problems to get feedback.

Here are two tips to help you maximize your Open Problems experience: 

1) Provide Visual Aid - Definitely provide visuals so that the audience can know what you’re talking about. This also will save you time and allow you to fit in more information, since you won’t have to describe something, you can just show it. If possible, provide video footage.

I had a video showing gameplay and the 3D world wrapping, and this was very useful. It’s important to take time to prepare this so as to maximize the amount of information you’re presenting, and make your situation clear. Think of it as 1-minute presentation. I did spend a few hours putting together the video in the week before the conference.

2) Keep you problem as specific as possible - I think it works best if you keep your question narrow and specific. Some people were asking much larger design questions, and I think these don’t work quite as well, at least in this format. A lot of the responses were much more vague, and also some people in the audience had to ask the presenter questions to clarify what the design issue was. Given that you only have a few minutes, you want to maximize the opportunity for people to throw out ideas.

After Open Problems, there was a break for dinner, and then a party afterwards.

For dinner, I went with a group to Chinatown for Dim Sum:


As for the party, it was a blast! The coolest part was that I got to meet Jonathan Blow!

I had so much fun that the only picture I remembered to take there was of the interior of the fridge :D