https://www.redblobgames.com/ is very cool colction about pathfinding and other topics.
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 →
I found this gem of game development articles Gaffer On Games, I guess wort reading 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 →
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.
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 →
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.
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.
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 :)
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 →