A basic, working system for gravity is now in place. Eventually I would like for gravity to work a little more realistically because right now you fall at a rate of 9.81 m/s, not 9.81 m/s². This isn’t a huge deal, but eventually I want to make it so that falling off a cliff means the character’s falling speed increases until he hits the ground, then use that impact speed to determine how much, if any, damage the character should take in the fall. Still, I’m really excited a player can now stand on top of a box, or a fence, or whatever. There is still plenty of adjusting to do. For instance, I’m not sure what would happen if a player stood on a sloped roof. My desire is that a character would slide down a steep slope but not on a shallow slope, but that will likely come later. Now that the major pieces of my collision system are in place, I absolutely have to spend the time to refactor that part of the code to be more usable. That will take at least a few days, but I’m happy to be moving forward again.
I have incorporated the collision detection system in its current state into the game engine. This took some time because I was fighting with the Blender-to-THREE workflow again. Here’s a little sidebar on that.
The recommended file format for working with 3D assets in THREE is glTF. This format is maintained by Khronos Group and includes important features like materials and animations. Unfortunately, it’s also been a huge pain to work with so far. Creating assets in Blender then exporting them to glTF seems to work fine, but working with the imported assets in THREE is just quirky sometimes. When you import a file it is added as a Scene that you then have to add to an existing Scene. The geometries are all BufferGeometry objects (which is actually a good thing for performance, but difficult to work with) and you just have to really work at getting things to line up just right.
After quite a bit of tinkering my system is now working. I have a weirdly shaped concave object with a separately modeled (also concave) collision cage that I put into a map file. My engine loads the asset, recognizes the collision cage, and the collision system responds correctly when you walk around it.
This is a big step in the right direction. Next I still need to do pretty much everything from my last post, but I have a working system already integrated into the rest of the engine. Hopefully this will keep me motivated to finish the code rewrite, implement gravity, blah blah blah.
This is very, very exciting as is but there are several things I need to implement or improve:
- Code refactoring
- The Fauerby paper actually includes some information on how to implement this, so hopefully it will be easy.
- Broad phase collision detection
- The current implementation runs the rather expensive collision detection algorithm on every object in the scene on every frame. This is fine for a very limited number of objects but I need to implement a broad phase that can quickly eliminate objects that are far away and thus cannot collide with the player. THREE automatically generates an axis aligned bounding box (AABB) for every object in a scene, so checking against those is likely the way to go.
- Spatial partitioning
- In addition to a broad phase, I would like to use something like an octree to further optimize the collision detection system. There are lots of good articles on this concept, but I probably won’t implement this immediately.
There are other things to do but these are the big ones. I’ll probably spend the next several days rewriting the code, then stick in a broad phase check, then put the code into the game. After that I’ll work on gravity, and save octrees for another day.
Overall I’m very excited because a reliable collision detection and response system will allow me to make a basic world that feels interactive. I can then build off that by adding more “game” type features.
Undoubtedly the biggest frustration I’ve had working with THREE.js is loading and animating objects modeled in Blender. The tools just aren’t very polished yet and it drives me crazy that so many things work so well but that process is basically broken. I’ve noticed on my older development machine that the created SkinnedMesh objects work differently than on my (somewhat) more powerful machine. Specifically, I get this weird jittering action on loaded gLTF objects whenever the object is any distance at all from the origin. This is a known issue in THREE.js and has to do with matrix transformations being performed in world space instead of local space, but I’ve looked at the code and I get lost immediately. I just don’t understand the animation system as a whole well enough to contribute anything of value. It doesn’t happen on every machine, which makes it all the more frustrating to troubleshoot and makes me wonder what else behaves differently on different platforms. One of the primary advantages of using a browser and WebGL is (I thought) consistency across platforms. It’s still open as a bug in THREE.js, so I’m hopeful that it will get fixed one day, but for now I will just see weird jittery animations sometimes because it isn’t worth the time to try and find a workaround right now.
My next step is to do a little painting of the Penrith terrain, just so it looks a little nicer. Then I’m going to tackle collision detection again. That’s always been a big hangup for me but if this project is ever going to get off the ground I absolutely must have a reliable way for players to collide with and react to objects in the world.
My new machine isn’t here yet. I’m expecting it Saturday. Still, I’ve been diving back into the codebase the last few days and continuing the reorganization project. I’m now back to basic “walk around the map” functionality. No collision detection, other than not falling through the terrain, but you can zoom the camera in and out. I’ve also been working on some of the substance of the game since I really need to know what I’m building at this point, so that’s been helpful. Penrith will still be the game’s starting area, but I have the first region semi-mapped out and a general scale for the whole game. Lyridia is going to be a big place. Or, at least it can be a big place. The island is about 10,000 km². That’s roughly the size of Jamaica. Of course none of it will actually exist until I make it, but that’s the plan for now.
I’ve ordered the components for a new computer to use for game development. I have been working on an old machine that was generally good enough, but I was just getting tired of it. I ordered everything around a week ago and I’m still waiting on a few things to show up. Once everything is here and the new machine is built I’ll dive back into development on the game. I’ve been a little lazy/distracted the last few weeks but I’m definitely planning to pick back up soon.