I haven’t done a ton of testing with it yet but it looks like I have successfully implemented collision response a la Fauerby’s paper.  I’ve only tried against a simple box but it is absolutely beautiful to watch a sphere collide with the box near the edge and just slide over until it’s past the edge then continue on its merry way.  The code listings from the paper are, in my opinion, an absolute mess.  I just don’t like code that follows this structure:

var object;

function doSomething(object) {

object.prop = “value”;

object.otherProp = “otherValue”;

}

doSomething(object);

if (object.prop == “value”) {

// whatever

}

I don’t like it when a function changes the properties of an object passed into it as a parameter, and Fauerby’s code does a bunch of that.  Maybe that’s a very common practice for some programmers but it drives me crazy because it becomes very difficult to follow the values of an object’s properties.  So I’ll be rewriting all that code but regardless of all that it seems to be working!  So exciting.  Once I’ve refactored this code I’ll integrate it into the rest of Lyridia’s code, then test some in the world and as long as everything looks good I’ll definitely release a new version at that point.  So stay tuned.

The collision detection system is still moving along.  I can now test a sphere against an arbitrary triangle and if there is a collision the sphere simply stops.  This works whether the sphere hits the face, vertices, or edges of the triangle.  I also made a simple test case with the sphere moving against a SphereGeometry mesh in THREE.js.  This just basically involved looping through all of the faces of the sphere to test for collisions.  That simple test seems to be working but I’m reserving judgment until I have done much more testing.  Specifically it would be really nice if I could load an object modeled in Blender with a custom, hidden collision cage and see if that works.  That’s the ultimate goal since I don’t want the collision system to test against the relatively complicated geometry of the objects visible in the world, but rather against a set of hidden, simpler geometries custom made for each object.  I think this should be fairly straightforward to pull off.

The next step, after I’ve tested with some other objects, is to implement collision response.  Right now if the sphere hits an object it just stops.  For a game, when the sphere hits an object it needs to slide along the surface of that object.  The paper I’m following includes a collision response code listing, so hopefully converting it over to Javascript will be pretty easy as well.

I’ve been working on collision detection and I think my previous optimism from having worked on this stuff a pretty good bit before was well founded.  So far I have implemented the simplest case of collision detection from this paper.  So with a single triangle and a sphere moving around in space the sphere stops at the surface of the triangle no matter how it is oriented.  The sphere doesn’t react to the collision, it just stops.  It also doesn’t work if the sphere hits an edge or vertex of the triangle.  I just haven’t implemented that part yet.  Still, it’s exciting to have this much done.  The paper describes using ellipsoid space so that a single ellipsoid can represent a humanoid character.  This is fine but I think I would rather use two equally sized spheres, one at the top of the capsule representing the player, and one at the bottom.  This may require twice the checks, but I also don’t have to worry about world space versus ellipsoid space.  In any case, I’m going to get sphere-mesh collisions working correctly, then I’ll decide whether to use ellipsoids or two spheres.  I’ll have a demo of basic collision detection up soon.

Yep, the next step is definitely collision detection.  I’ve tried this before so I have some context to start from so hopefully I can get something in place pretty soon.  I was thinking about collision detection on a long drive yesterday and I think I’ll need to split collision detection into at least three different types.  First, normal collisions between the player and the environment.  This will be the most complicated type of system because I need to detect and respond to collisions between a capsule representing the player and arbitrary meshes in the world.  Second, collisions between enemies and the world.  I think I can simplify this to sphere-sphere collision detection by simply defining the collision zones of all objects as oversized spheres.  Some things don’t lend themselves well to being defined by spheres, for instance a fence.  But it doesn’t matter if an enemy will never walk right up next to any particular object in the world.  It won’t look weird if a boar is never standing right next to a fence object, just as long as no boar ever walks through the fence.  I think the sphere-sphere collision system will be needed because these collisions will have to be handled by the server, and there are potentially a lot of those to calculate multiple times a second.  Third, I’ll need to be able to calculate collisions between players and enemies for battle.  If you swing your sword I need to know if you are close enough to an enemy to hit it.  I think I can use the raycasting capabilities built into THREE.js to do this.

I’ll start with the hardest general case, then maybe the others will be pretty straightforward.  This will take me a while and I may not post many updates while I’m working on it, so stay tuned.

My little world is really coming together.

I think the next beast to tackle may be collision detection.  I’m not looking forward to that because it’s a really complicated subject, but it has to be done.

I’ve been digging around in THREE.js and one of the bits that’s always confused me is shaders.  I’ve been writing software for some time but every time I look at shader code I just get completely confused.  I found a little “shaders for beginners” page today and it’s helped fill in some of the gaps.  The primary reason it’s so confusing (at least when using THREE.js) is that THREE.js does a lot of the grunt work for you and that hidden grunt work makes examples incomprehensible if you don’t know what THREE.js is doing in the background.  Since I understand that a bit better now it affects some design choices going forward.  For instance, I am now convinced that implementing splat maps for the terrains in Lyridia is completely doable.  It will require some custom tools to do it well but I see no reason I can’t use an essentially arbitrary number of textures for each terrain chunk and mix them together with a shader.

This is a really big deal because using textures for the terrain means I’ll need to use textures on every other asset as well.  I’m not 100% ready to pull the trigger on this yet but I definitely want the game to have as wide an appeal as possible and a world with textured assets will be more familiar to more players so the decision might be made for me already.  We’ll see.

Lyridia is getting to the point that it would be helpful to start making some concrete design choices.  For instance, what’s the overall look that I want for the game?  Am I sticking with the super-low-poly thing or a more traditional style with textures?  It would also be helpful if I knew how some of the game mechanics were going to work, like NPC interactions, fighting mobs, etc.  Unfortunately, I don’t know any of those things.  And I guess that’s really the primary advantage of developing the game iteratively.  I can add assets to the world now and then just update them later if they no longer fit the style of the game.  Ultimately it creates more work but I really don’t have the resources to plan out the entire world before implementing it.  Again, I realize this isn’t the “correct” way to do things, but it’s the only way I see making any progress.  So for now, and for the foreseeable future, ugly, simple, awful art assets will be used in the game.  The main thing is to just keep moving forward no matter what.  At some point I will either hire some help or ask for help from the (currently non-existent) community of players to create better quality art assets for the game.