Juice up your Game

I read and watched a lot about game feeling beyond many I liked these best
- Jan Willem Nijman - Vlambeer - "The art of screenshake"
- The art of screenshake
- Juice it or lose it - a talk by Martin Jonasson & Petri Purho

Game feeling is how you experience your interaction with in a game. Does jumping feel good? Does the gun have a powerful feeling when using it? Is it satisfying when you destroy or kill something? Does it have a snappy control? Was it exiting to solve that puzzle?

Read on →

Lost & Found: Gaffer On Games

I found this gem of game development articles Gaffer On Games, I guess wort reading it.

Lost & Found: The Level Design of Hob

I found this amazing talk with Rick Lesley about level desing about that awsome looking game Hob.
I write this article solely to not lose the link.

Shake it

I wrote an effect to shake the camera on explosion or any other high impact. I found a nice article about that here, this article does nicely explain the road you will have to go.

Nevertheless my own implementation is much simpler and straight forward and it gives quite a badass feeling on explosions.

Read on →

Lost & Found: The Nature of Code


If you ever want to write your own simple physics or any other natural looking movements like swarms or oscilating stuff or scratch the surface of evolutionary code and neuronal networks for game development purpose then this book is a perfect starter. You can buy the book or simply read it online.

ECS Pattern: Decay

There are so many things in game which have some kind of a life time. A bullet, an effect, vanishing tiles in a can't stop running game, dying enemies and many more things which have a life time.

In the past I would have done it seperately depending in which situation something hast to vanish. With the ECS you can solve all of them with one component and one system.

Read on →

ECS Pattern: Model Visualization

To understand and try out entity component system approach the visual system was the first hurdle I had to take. Without that system you see nothing on the screen. Further more this system makes you understand how you should separate game logic from the visual stuff.

Anti Pattern

Don't store your spatial, the visual thing, in a component. Never ever. It is as if you would save Java classes in databases. It is backward. When ever you face your self to store a real thing in component it is a sign of wrong design.
Also think a bit bigger, if you start with a simple drawn character and you want later improve it all your saved game states are garbage then, because they still held the old crappy character. So a good decoupling helps you also to exchange your model at any time.

Read on →

Lost & Found: Shadertoy

I found a very useful page about shaders called shadertoy. It looks very interessting and I definetly will take a closer look. I will try to find out how this shaders can be used in jMonkeyEngine :)

ECS Pattern: Virtual Link

The idea of links is that one entity points to another entity by storing the others entity id in the link component. When I now want to store the entity with the link and later reload that entity but the linked entity did change its entity id (remove/add) for some reason the loaded entity do point now to a wrong entity. This can lead to odd behaviours.

I'm not just a Number

The solution is very simple, I add two new components a virtual link and virtual id component. As well I implemented a system which checks if a virtual link and virtual id do match and then renewed the link components entity id. The benefit is that in the level designer I now really can give things a readable name not just a number. Another benefit is that I can easily say that item foo is linked with item bar even if item bar is in a completely different level. If I now place that item foo to the level where item bar resides the link automatically take place.

Read on →

ECS Pattern: Entity Follow Entity

When I write games I have always something following something else. Camera follows hero. Light follows ghost. Goody follows space ship. Weapon follows player. And so on and so on. This is a very common pattern in my opinion. I do like to show you how to do it with an entity component system. Show you the beauty and reusability of this pattern.

In object oriented way you would give the items to the corresponding object somehow by reference or something. In an entity component system you go the other way around the items does have a link to the object they shall follow. Once you have your system which makes it happen, that every item entity with a link to an other entity will follow that other entity you will be able to let nearly every thing follow anything else.

Read on →