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.
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:
Despite the technical difficulties I had a great time demoing and presenting the movement of my game.
Webbuild of the movement sandbox:
Gave a shorter version of my last years GDDG Talk.
The nitty gritty basics for improving rendering performance in VR
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”.
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…
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.
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.
Had a blast at our first Game Dev Days Graz where I had the honour of giving a short talk about various modes of moving through a virtual world:
First attempt at a hopefully continuing series where we take a closer look at games and their systems. Worked in collaboration with Michael List: