This is a pitch for a learning group in which we can learn Unreal Engine 4 together.
Also I’m suggesting a game that we could try to implement during the course of the group.
Category: gamedev
[Talk] – AR and Games: what works, what are lies
I give a basic and brief introduction to AR. Equipped with that knowledge we then take a look at a pokemon go trailer and debunk some of the claims of that video. As usual it was a pleasure talking at the meetup!
Here are the slides:
[Talk] 2D Platformer Movement Tips&Tricks
Despite the technical difficulties I had a great time demoing and presenting the movement of my game.
Slides:
Webbuild of the movement sandbox:
[Talk] – Abridged Locomotion in VR
Gave a shorter version of my last years GDDG Talk.
DevDir – Gettin’ Juicy
Carrying on with our theme of “small things you don’t notice until they are not there”:
1. Inspired by a great talk about player movement at GDC I now modify gravity based on whether the player is in the upward or downward part of the jumping ark. Finally it doesn’t feel that floaty anymore! I tried generally modifying the gravity, but I would have never considered that much “cheating”.
2. 
I wrote a general purpose bouncyfier. Now things don’t simply appear on screen. This is one of those simple things nobody notices, but at least make me happy knowing they are there. Also, simple to add, unless you draw your GUI in the most stupid way possible, thus requiring a complete rewrite…
3.
After the famous talk by Vlambeer everyone and their mother added screen shake to their game. Personally it got to a point for me where I was pretty fed up with it. After chromatic aberration it felt like a completely overdone effect for me. Nevertheless I wanted to add some weight to the player deaths. So I added it and I have to admit, I like it. I now understand how one might end up using it everywhere. I will have to show some restraint…
Next time we will be talking about writing your behaviours properly so you don’t have to rewrite them once you have more than one level and have a state machine up and running.
DevDir – Movement Pt. 2
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:
- Jumping input queue: When pressing jump in mid air it gets buffered for a short while. This way the player can hit jump just before landing and will jump again right away.
- More jumping tolerance: it is also possible to jump just after having left the ground (by e.g. running of a ledge)
- Player Slowdown: in the previous post I mentioned that I use the doom style of always slowing down. Well, I reworked that bet and now I only slow the player down if there is no active input. This got rid of some wobbly mid-air behaviour.
- Got rid of the infamous triple jump bug. For a while I actually considered keeping that one for the experienced players, since it was a reproducible behaviour. But it made some of the levels just too easy…
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. |
DevDir – Movement
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.
Sample of the current movement in the game
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…