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.

As the last day of May comes to a close I thought I’d post the state of Penrith Forest right now:

It’s a little hard to tell from the screenshot but the character is standing on a hill, not just floating ominously.  Anyway, you can see here that I’ve been taking advantage of the new terrain editing tools.  I made a ring of mountains all the way around Penrith Forest.  Right now you can just walk up and over them, but eventually they will be a barrier to players going where they aren’t allowed.  I also added some more trees, although many more are needed.  I’m a little torn because the trees in a little game you may or may not be familiar with are HUGE!

The trees in Penrith Forest are big, but not that big.  The great thing about huge trees is that they take up so much screen space and very easily keep the world from feeling empty.  This is a technique I may have to use because in the screenshot above I increased the fog distance by about 200 meters so you can see pretty much everything at once but eventually I’d like to keep that distance fairly low and have assets load dynamically for efficiency’s sake.  But if the world feels empty because you can only see things less than 100 meters away that’s not going to work.  Maybe huge trees (and huge buildings, for that matter) will help take up a lot of screen space so that it feels like you are “somewhere” all the time.  We’ll see.

I’ve implemented two very helpful features in the world editor, specifically for terrain editing.  First, you can now change the strength of the raise/lower function.  The selection sphere’s opacity gets lower (so more opaque) when the strength is higher, so you can see approximately how much the terrain will be affected by the tool.  This is really helpful because when you want to make a mountain it’s almost impossible to use the tool at the same strength as when you are fine tuning the terrain around a building or other asset.  Second, I added a smoothing tool.  This is super, super helpful.  The tool just takes the same selection sphere for raising/lowering and averages the height of all the vertices within the sphere, then moves each vertex part of the way toward that average with each onmousemove.  It works almost unbelievably well and has already helped me make the terrain in Penrith Forest like 1,000% better.

Ok, technically the boars were already moving around but now it’s not all jittery and jumpy.  I found a fun little library called Tween.js that does, you guessed it, tweening.  I have used the excellent CreateJS suite before and it includes tweening functionality, but Tween.js has examples specific to THREE.js so I went with it for now.  In any case my boars are still walking around in a completely random pattern and their location only changes once per second, but in between those 1-second updates the boar model moves smoothly.  This tweening thing will probably be a really big part of the whole project because rarely am I going to want anything in the world to just move instantly to a new location.  Anyway, I’m excited about how Lyridia looks now and I need to decide what to do next.