First attempt at a hopefully continuing series where we take a closer look at games and their systems. Worked in collaboration with Michael List:
Author: Lorenz Jäger
[Talk] – Master Thesis Defense: Real Time HDR-Video on the GPU
[Talk] – Shades of Play post mortem
We took a look at the hectic months of creating a game with unique challenges:
[Talk] – Procedural Generation
Introduction to various procedural generation approaches in different fields. Created and presented with Marco Frühwirt:
[Talk] – Computer Graphics 101 – Post Processing
Part of an introductory series to computergraphics I gave at the GDG-Meetups. This time dealing with postprocessing effects.
[Talk] – Streamable Free Viewpoint Video
Brief overview of a paper by Microsoft:
<iframe src=’https://onedrive.live.com/embed?cid=088549EA3ACB8CA5&resid=88549EA3ACB8CA5%21218&authkey=AItvHWprJrJzWgA&em=2&wdAr=1.7777777777777777′ width=’610px’ height=’367px’ frameborder=’0′>This is an embedded <a target=’_blank’ href=’https://office.com’>Microsoft Office</a> presentation, powered by <a target=’_blank’ href=’https://office.com/webapps’>Office Online</a>.</iframe>
[Talk] – Computer Graphics 101
Part of an introductory series to computergraphics I gave at the GDG-Meetups
[Talk] – Introduction to Google Cardboard
Brief introduction to setting up a Carboard Project in Unity:
[Talk] – Introduction to Omnidirectional Cameras & Omni-SLAM
Introduction to Omnidirectional Cameras & Omni-SLAM
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…