Yukari Hafner
patreon
The state of things so far
🕑 Added 2023-08-25 09:21:33 +0000 UTCHello! If you're reading this you just backed me. Thank you so very much! But, without further ado, let's talk a bit about what I've been cooking on since the Kandria release.
Here's a brief overview of most of the work that's gone into the engine:
- Added a micro-collisions physics system for rigidbody simulations
- Added a verlet particles physics system
- Added an entirely new rendering subsystem, including:
- A Physically-Based-Rendering implementation
- A Blinn-Phong implementation
- Various different light types, including Image-Based-Lighting environment maps
- Automated shadow mapping for all applicable light types
- Support for inverse kinematics in the animation pipeline
- Support for composition of texture inputs from multiple sources
- A GPU-based particle system that can simulate millions of particles at once
- Implementation of the GJK+EPA and V-Clip algorithms for collision detection of general convex polyhedra
- Various algorithms for ray casting collision detection
- A complete rewrite of the vector, matrix, and quaternion math libraries
All of this is preliminary work to support a full 3D game with animated characters, IK for realistic movement, collision detection with the terrain, advanced rendering, and so on. However, I'm not yet done. One piece is still missing, and it's what has eaten up months of my time now. It requires some explanation:
Collision Detection
In order to check whether two things are colliding, most notably for instance the player and the terrain, a collision detection algorithm is used. Most of these algorithms are limited to convex shapes however, meaning shapes that don't have "dents" or "holes". More general algorithms do exist, but are prohibitively slow. So what do you do instead?
For the player and other characters, the usual practise is to manually define one or a couple of primitive shapes that make up the character's collision. Stuff like cylinders, spheres, boxes, and "pills". This is fine and even preferred to an accurate collision detection, as the detail on the models is usually far too high, and would lead to undesirable gameplay behaviour.
However, you can't do the same for the terrain, or at least I consider it far too much of a pain in the ass. As far as I understand "typical development workflow," it appears that first a level designer builds the raw collision geometry, using the same primitive shapes as for characters. This is called a "gray boxing". The gameplay is then iterated on this. Once the gameplay is fine, the graybox is "frozen" and the environment designers come along to turn the graybox into a visual level that is actually pleasing to look at. The engine will still internally use the graybox for collisions, but will only render the nice environment that was designed around it.
This effectively means creating the environment twice. It also means that if you notice gameplay problems too late, fixing them is suddenly extremely expensive. Operating on such a minimal budget as I am, I consider this kind of "manpower based approach" prohibitively expensive. Instead what I would like is to design the level in an advanced tool like Blender, and then be able to directly import that into the engine, let the engine figure out how to create the collision geometry for it.
This would reduce the overhead of fixing mistakes late, remove the need to design the level twice, and entirely eliminate the need for me to create an entire editing system in my engine from scratch, and instead let me rely on established tools that are made for that kind of editing.
That sounds really neat, right? Well, it is. The problem is in the "let the engine figure out the collision geometry" step, and that's what I've been bashing my head in over for the past two months.
Essentially what we need is some algorithm to automatically extract a set of convex shapes that fit the level. The shapes should be as few in number as possible and as simple as possible, while still giving the same collision behaviour as the full level would.
A lot of my time working on this was wasted chasing rabbit holes that not only didn't end up working, but also turned out to be useless for what I wanted. Most of the research in this "convex decomposition" area seems to be focused around approximate convex hulls, meaning the hulls can deviate from the original geometry by some amount, creating potential gaps or bumps where there didn't used to be any. This is not suitable for level geometry.
I did find a paper that is specifically focused on convex decomposition for level geometry and does seem to be perfect for that, but as is so often the case, it is extremely terse on details and does not include any source code for me to compare to. And I'm already burnt out on the topic.
So I've decided to hire someone else for the job. They should be done by the end of September, so if everything goes well I'll be able to show off full level collisions in the next update. But hey, here's something your money will be going to that isn't me already! Wow!
Other Stuff
I'm also hiring someone else in September to create a rig for the protagonist of the next game as well as a base set of animations. With that I should be able to fully launch into the prototyping of all the movement mechanics and even get started on the combat feel. It'll let me try out all sorts of systems, and I'm genuinely excited to get my hands on the finished model, see how it looks in the game.
Here's a peek at the model as it is right now without a rig:
The sword and initial design was made by me, but the actual model was also commissioned, as I don't trust my 3D modelling skills well enough for something as vital as the player character model.
I've also been working on some other effects that I'll need like this cutaway to ensure the player isn't hidden behind walls without being able to see where they're going:
I want to get started with experimenting with visual effects next. Creating stuff like splashes and sparks and other things like that that'll be needed for the full game. I've never done that before, so it'll be quite interesting.
However, before I get to that I also want to create a minimal particle system, as the GPU particle system is optimised for hundreds, thousands, or millions of particles, while most of these visual effects will only require a handful at most.
I'll also be off on holidays in Japan for the second half of September, so who knows how much I'll get done.
Closing Thoughts
Alright, I think I'll close this update here for now. There's other things I could have talked about as well, and probably tons of things I forgot to mention, but I'll keep those for another time, whenever I remember to.
Thank you once again very much for your support, and I'm excited to see what I can get done with the funds.
— Love, Shinmera ❤️
Comments
Yukari Hafner
Aw, thank you so much for your support and kind words! I'll continue to try my best!
Max Zettlmeißl
I just created an account to support you. I chose the 5€ tier because it is sustainable for me. All the best to you and your development efforts. I hope if enough people chip in, it eases your worries and will let you focus on creating beautiful new programs. The Lisp community needs new technology and to see what can be done with this absolutely beautiful language and the game development community needs smaller engines that stand against the Unreal and Unity Engine which seems to slowly subsume everything.
