Despite the technical difficulties I had a great time demoing and presenting the movement of my game.
Slides:
Webbuild of the movement sandbox:
Despite the technical difficulties I had a great time demoing and presenting the movement of my game.
Slides:
Webbuild of the movement sandbox:
So, it’s been a while I know. I shall spare you the usual excuses for why…
I spent a lot of time tinkering with the movement after showing it to a couple of people and getting lots of valuable feedback. The tinkering unfortunately lead to quite a mess in my movement code by adding yet another special case to the handling. It became such a mess, that I started putting off working on the movement code and instead messing with other, less important stuff.
So today I decided to scrap everything and start from scratch. This time around we have a bunch of new features:
I would like to treat you, dear reader, to some fancy gifs as a reward. Unfortunately most of that stuff is actually not visible and only felt while playing. Especially the jumping tolerance adds a lot to a smooth feeling without being explicitly noticeable. Players can only tell when it is not there. I wonder how much more invisible stuff is out there that I take for granted in other games without realizing. Any Ideas?
Bonus: There are physics now! | Brief example for the queuing. |
So, turns out that Sunday is „Improve-Movement-Model“-Day. I decided to nail down how the character moves to finally move on an actually start creating levels.
In platformers I’m usually a big fan of super crisp, digital movement. There is no inertia and no run-up. But this kind of movement would be too hectic for the co-op experience. Therefore I decided to use a physics based movement model in which I “enhance” real physics. Just using the standard Unity Rigidbody and applying the correct forces felt too floaty and slippery for me. So I took some inspiration from the Doom movement model. Here the player is always slowed down by a vector that is opposite of the current movement direction as long as there are no inputs. In physics this should be handled by friction, but when I increased the friction of the player the starting of the movement became too sluggish. So now I slow the player only when he is not trying to go somewhere.
Furthermore I pondered for a long time if I should keep the double jump in the game. I decided to leave it in to give a player that got screwed by a throw a slim chance to recover. Else the screwed one is completely helpless and I think that will leave some players frustrated. Now I just have to figure out a good balance for how long a double jump is possible (it is based on the y-speed) of the player.
Finally just a quick venting: Uninstalling Visual Studio 2013 took almost an hour on my aging notebook. That was already bad enough. Installing VS2015 that comes with the newer versions of unity actually takes two fricking hours. Back when Unity shipped with Mono-Develop the entire installing process was done in 15mins. For both pieces of software… At least the setup gave me time to type up this piece of text…