Recently I was at GodotCon 2019 where I was giving a talk about the GPU particles that collide with the terrain, you can find this talk video stream here http://www.youtube.com/watch?v=8Q77OlffvfQ
Lots of people liked the presentation and asked for demo. So here it is.
I created very simple scene just to show the basics. Just a simple sprite where the transparency defines the collision areas and the particle2d node. Also simplified the particle shader – all custom magic happens there.
You you can download Godot project here (should work on version 3.0 and up) http://www.mogilagames.com/wp-content/uploads/2019/02/ColParticles.zip
If you make something nice based on that shader, please share it with me.
Working on the new game! Not sure what it will become but for sure it will have destructible environment. Here is the video of gpu colliding particles with dynamically modified terrain. Grimind was 2D and the view was from the side. Clinically Dead was 3D first person perspective. So the new game will have 2D top down view. I’m also changing the game engine to Godot engine which I like so far (Urho3D was cool but Godot seems like the best option for 2D)
I managed to get the Oculus Rift virtual reality goggles work with Clinically Dead. The results are great. Immodestly, I have to say that Clinically Dead is one of the best VR experiences I ever had. I also shared my implementation code on Urho3D forums. For now as plain code and instructions, but maybe in the future I will make some pull request to the official Urho3D repository. Stay tuned and in the meantime, I will work some more on the game.
I decided to create my brand – “Mogila Games” under which I am going to develop the games. I hope you like the new website. The old blog www.szamq.wordpress.com is not active anymore.
Also, if you hadn’t noticed, I’m developing a new game called “Clinically Dead” which is 3D FPP Adventure Puzzle Game with a creepy feel and 4 – dimensional maps(sounds crazy) the fourth dimension is time and you can travel freely through it. The game cast you as guy called Mr. Samson who is dying and all gameplay happens in few seconds before actual death timepoint. All that short time is stretched into hours because time no longer matters after death. Read more about the game here.
I also changed a bit the way I create the games. In Grimind all of the engine code was written by me, and I can say that it was fun and very educational, but it was taking too much time. When creating Grimind I spended more time on creating game engine than the actual game. So I had to choose if I want to create games or game engines. The choice was easy 😀
But, I’m not going too far from my home made engine as I decided to use Urho3D engine which is MIT licensed so I can modify source code for my needs. From my experience Urho3D is awesome engine and has small but very helpful community. If you are game developer and you are looking for great multi platform(Windows, Mac, Linux and more), free(MIT) game engine then definitely check out Urho3D
1. Player dynamics changed – I think that is the most important change. now it’s easier to move the character because it has reduced inertia.
2. Xbox 360 controller support – the game can be played with Xbox gamepad. Unfortunately I managed to implement this feature only on Windows.
3. Rebindable keyboard keys – this potentially was an issue for non qwerty keyboard users. Of course they could always play with arrow keys, but I can imagine that could be uncomfortable. Now it’s fixed.
4. Puzzles are now slightly changed to be more intuitive.
5. Steam achievements added.
I also added possibility to purchase Grimind with Bitcoin. I will see if this is worthwhile, now I’m processing all Bitcoin payments manually. If you know better ways to accept bitcoins or automate it somehow, let me know. Check it out on www.grimind.com
Currently I’m trying to create Grimind builds for Linux and Mac and it’s nightmare.
Basically, I moved my code form Visual C++ to Eclipse under Linux and most of my code worked correctly right away. It’s because I used cross platform libraries like: GLFW, SDL, SDL_mixer, OpenGL – that’s cool. But when I run Grimind for first time it looked ridiculous. Particles were spawning only at one place and there was many graphical glitches. This is why it happened:
On windows I used to use abs(…) function for float numbers and it worked correctly so abs(-1.2f) was changed into 1.2f so it worked for floats. On Linux there is no abs function for floats, so the same code on Linux produced bad return value. In this case -1.2f was converted first into integer value -1 and then the return value was 1 not 1.2f. The solution to that problem was to replace all abs functions to fabs
I was mixing two values RAND_MAX and 32767 which on windows these was the same. On Linux RAND_MAX is 2147483647 so it is much larger number than 32767. In addition I was dividing random number from range 0..32767 by RAND_MAX. On windows this was correct and division result was from 0 to 1 that’s OK but on Linux this range was from 0 to 0.00001525832 not 1 and that’s why particles was spawning just in small area
I was able to create 32 bit build and it’s working but I still can’t make 64 bit to work correctly everywhere (it’s working for me)
I used xcode 4.6 to create build and it’s working fine but I cant set deployment target to 10.6 (Snow Leopard) because I use c++11 features in my code. That could mean that I will be able to create Grimind Mac build only for 10.7 and later (Lion and Mountain Lion) but I will look at this once again.