next »

[William Chyr]

Devlog Update #117 - 11/19/2014

PRACTICE Post-Mortem - Part 1



This past weekend, I attended the PRACTICE Conference in New York City. If you're not familiar with it, PRACTICE is a conference organized by the NYU Game Center that focuses specifically on game design.

This year was the 4th year the conference was organized. Despite this, I hadn't heard of it up until two months before the event, when Zach Gage announced on Twitter that he was going to be one of the speakers.

If you've been following this devlog, you'll know that I've been writing about all the conferences and festivals I've attended. I'm going to write up about my experience at PRACTICE as well, sharing about how the conference is set up, why I went, what I learned, etc.

I'm not going to dive into the specific details of the talks themselves, as all the talks were recorded and will be posted online for free, so you can judge the quality and content for yourselves. I'm going to focus more on my point of view of the event, as an independent game developer/designer, who went with a very specific intention.

Why I Went
Between February and October of this year, I went to 11 game conferences and festivals. The first one I went to was IndieCade East in NYC. It had a tremendous impact on the development of the game, and made me realize the importance of getting regular feedback from players and other game developers. This is why for much of 2014, I went to every single show that I could.

However, while it is beneficial to show at these events, there is a decreasing rate of return. For example, the first few events gave me very high-level ideas that resulted in massive changes to the course of the game. I was rewriting entire levels and changing the progression system. Towards the end of the year though, most of the changes were more about finetuning and tweaking details - making a hallway shorter here, adding a window there, putting stairs here, etc.

By October, the game had been playtested by about 1,000 people, and I was starting to feel like I had a very, very solid first hour of the game. It had allowed me to sort out major design issues, and the game had improved tremendously. However, I was also noticing the limitations of this development process:

1) It's hard to make large changes to infrastructure - After each festival, I would try to implement fixes for all the issues I observed, so that I could have a new build in time for the next festival. Technically, I could just show the same build I showed last time, but then I'd see the same problems, and wouldn't get any new data. Each festival was an opportunity to try something new and see if it works.

The problem is that if there was a big infrastructure issue in the project, I couldn't risk rewriting it from scratch, because what if I took it out, and couldn't get it working again in time for the next showing. As such, even though I was able to make design changes on the surface level, it was all being held up by really bad code underneath.

2) Showing at Festivals really only allows you test the beginning of the game -  I would always have a few people at festivals who would play the game for over an hour, but most people played for between 5 and 15 minutes. This meant you got a lot of feedback about the early parts of the game, but not the late parts. It's not even about whether your game is good or not, it's just the nature of the setting.

After 10 conferences, the intro wasn't perfect, but it was good enough, and it was time for me to move on to the mid-late parts of the game, which festivals/conference weren't going to help.

So I had decided Gamercamp in October would be my last event.

Of course, the next day I saw Zach's tweet and learned about PRACTICE. When I saw that it was a conference specifically about game design, and that the list of speakers included Jonathan Blow, I knew I just had to go.

I was struggling with creating progression between levels (I will go into the specific problem a bit later), and this conference seemed like the perfect place where I could ask about this problem and get feedback on it.

Conference Structure

PRACTICE happens over the course of 3 days. I've gone ahead and posted the schedule for this year here:



Everything happens in the same building on the NYU campus, and it's a single-track conference, so you don't have to choose between talks. I really liked this aspect of it, as it felt like all of us who attended got the same experience, and were able to discuss everything that went on together.

Friday - Opening Talk / Reception


On Friday, the first day of Practice, there was an opening talk by Holly Gramazio, and a reception afterwards. The reception happened just outside the lecture hall, and there were several stations set up with games for people to play.

Here are some people playing a social game designed by Holly Gramazio, which involved learning to insult each other in Old English.


Here are some other pics from the reception, taken from the Game Center's tumblr.




After the reception, a bunch of us went out and got ramen!

[William Chyr]

Devlog Update #118 - 11/19/2014

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.

Party
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 :

[William Chyr]

Devlog Update #119 - 11/19/2014

PRACTICE Post-Mortem - Part 3

Sunday

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.

Conclusion

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.

[acatalept]

Great insights into this con (that I wasn't even aware of), thanks for sharing a first-person view for those of us who didn't attend.

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

Can't tell you how much I love that

[William Chyr]

Devlog Update #120 - 11/20/2014

RELATIVITY Featured in Chicago's South Side Weekly


"First rule: look up. Second rule: there is no up, objectively speaking."



This is definitely one of the best write-ups about the game so far. If you're in Chicago, you can actually pick up a physical copy for free in these locations.

[sam_suite]

Wow, cool!
Congratulations.

[William Chyr]

Devlog Update #121 - 11/23/2014


Starting a rewrite of the project. I will go into more detail later about why this is necessary.

This time, I'm focusing on game feel first. I want to nail down the feel of the movement of switching between walls first before adding anything else in the game.



This new approach I'm trying involves placing a quarter pipe in front of the player when the player wants to walk up a wall. The nice part of this is that there is no momentum loss.

There is also another suggestion from Doomlaser, which is to detach the camera from the player collider, then snap collider to new orientation while tweening the camera.

I'm pretty much open to all ideas at this point, and very much back in an experimental and prototyping phase, so I will give it a try.

Another thing I'm working on is trying to maintain a more regular schedule. I think I've been overworking this whole time, and am starting to feel the effects of exhaustion. Going to limit the number of hours I spend on the game each day.

It's a marathon, not a sprint.

[bsp]

As in rewriting the whole game?

[joseph ¯\_(ツ)_/¯]

i saw you talking to magdev and stuff about this on twitter! excited/scared for you.

gl w/ refactor, make the best game!!!

[Caravaggi0]

Devlog Update #121 - 11/23/2014


This new approach I'm trying involves placing a quarter pipe in front of the player when the player wants to walk up a wall. The nice part of this is that there is no momentum loss.

Interesting.  Sorry I haven't read most of the thread so I'll just throw out random thoughts.  Does this still work if you walk into a corner?  What if you approach the corner from a 45 degree angle, which wall do you end up on?  What about smaller steps?  Are you sure you'll only ever have 90 angles?

Are you sure you need the ramp?  The ray can get the angle of the surface can't it?  Maybe you can just say "if ray hit distance is less than x then lerp between angle of character and wall normal angle" or something so it gradually changes to whatever angle the ray is hitting.

[William Chyr]

As in rewriting the whole game?

Yes. Sort of. It's not as bad as it sounds.

So technically, I am starting a brand new project in Unity, and developing the game from there.

However, it's really more about refactoring all the code. There really aren't that many assets in RELATIVITY as it is. Most of the work that has been has been trying to nail down the design of the game, and I'm finally at a point where that's clear.

The current project folder is a massive 6 GBs, with hundred of scene files and scripts and 3D models that aren't even used. All of these were various prototypes I wrote in the past two years, and they're all there.

I knew at some point I needed to rewrite much of the code guiding player movement and the different physics systems, as they were all written when I was first learning Unity. It was necessary in order to optimize, fix bugs, as well as to generally improve them.

However, in the current state, so much is tied up together, that it's actually really difficult for me to make such large structural changes. For example, it's hard to try to improve the code controlling the player rigidbody because all these other systems depend on it.

Hence, starting a new project allows me to focus much more on game feel before adding the other layers. It'll definitely take some time, but it's not as bad as it looks.

At least that's what I think for now...

i saw you talking to magdev and stuff about this on twitter! excited/scared for you.

gl w/ refactor, make the best game!!!

Thank you!

Interesting.  Sorry I haven't read most of the thread so I'll just throw out random thoughts.  Does this still work if you walk into a corner?  What if you approach the corner from a 45 degree angle, which wall do you end up on?  What about smaller steps?  Are you sure you'll only ever have 90 angles?

Are you sure you need the ramp?  The ray can get the angle of the surface can't it?  Maybe you can just say "if ray hit distance is less than x then lerp between angle of character and wall normal angle" or something so it gradually changes to whatever angle the ray is hitting.

When you approach a corner from 45 degree angle, you still end up choosing one wall or the other to walk up on. The player doesn't get the raycast exactly in the middle.

And yes, there are only ever 90 degree angles as the core mechanic depends on it.

The method you suggested of lerping is the one I've used in the past. The problem with that is that it doesn't feel as natural, since the code is taking control of the player, instead of letting the player's own momentum guide.

See this:



This is using the lerping method. Notice how the player "pauses" after each rotation? That feels incredibly clunky during gameplay.

Here's a post where I dive into this issue in more detail.

[Zaphos]

In the old lerp method, it looks like you freeze the forward motion of the player while lerping the orientation, which is what cause the unnatural lack of smoothness.  Couldn't you lerp while still allowing the player to keep moving forward?  The combination of the forward motion + lerp might automatically give you a motion similar to the half-pipe's, if the player keeps moving forward during the transition.  It would also give a more precise transition with the player remaining right on the edge of the wall, if they stop moving forward during the transition.  Unless I'm missing something?

[bsp]

That makes a lot of sense. Always happy to see you make the good but hard decisions

[Rat Casket]

this hurts my brain but in a good way

[William Chyr]

In the old lerp method, it looks like you freeze the forward motion of the player while lerping the orientation, which is what cause the unnatural lack of smoothness.  Couldn't you lerp while still allowing the player to keep moving forward?  The combination of the forward motion + lerp might automatically give you a motion similar to the half-pipe's, if the player keeps moving forward during the transition.  It would also give a more precise transition with the player remaining right on the edge of the wall, if they stop moving forward during the transition.  Unless I'm missing something?

Yes, I definitely need to revisit the old lerp method. Having played with the quarter pipe method for the past few days, I'm thinking the old lerp method is still better, primarily because it's much more accurate.

I wrote the original rotation code way back when I was still learning Unity, so I didn't really figure out a good way to lerp while maintaining momentum. 

However, I think what the quarter pipe method has shown me is how a smoother transition might feel like. I'm going to continue playing with it for another day or two to really explore this method, and will then go back to the lerping method.

That makes a lot of sense. Always happy to see you make the good but hard decisions

I talked to a lot of people about it first before deciding to go ahead with it. When I first mentioned, a lot of people said it was not a good decision and would say to ship the game first and save the rewrite for version 2. Ultimately, any advice only works on a case by case basis.

this hurts my brain but in a good way

That's exactly what I like to hear

[William Chyr]

Devlog Update #122 - 11/25/2014

Worked on banner designs for the booth at PlayStation Express:





I'm going to go with the blue one. It feels more mysterious. Red is a little too chaotic.

[William Chyr]

Devlog Update #123 - 11/27/2014

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!

[William Chyr]

RELATIVITY on Destructoid!



Destructoid actually wrote about RELATIVITY two weeks ago, but for some reason I didn't see this article until yesterday. Way cool!

Here's the piece.

[EdFarage]

man this game is trippy, i love it.

[William Chyr]

Devlog Update #124 - 11/29/2014

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).