I’ve started working on the system to keep enemies in a specific area.  This obviously requires some work on the server and it’s not terrible simple.  I started by updating my editor so that I can add an enemy spawn point to a scene.  This adds a model of the desired enemy along with a cylinder around the model that is supposed to set the range of enemies spawned at this point.  I also need a way to exclude specific areas within the range so that, for instance, a boar doesn’t walk through a tree.  But that comes later.  Just getting the cylinder and enemy model to show up and save properly in the world editor was a chore and I’ve been trying to get the boars to spawn at the correct place.  It’s giving me fits and I’m tired so I’ve really quit making progress at this point and would be best off to just let it go for tonight and pick it up again tomorrow, so that’s what I’ll do.

Since the game is at a point where there is at least something to do, even if it’s just walk around a small little section of the world, I’m going to start focusing the features implemented in each release with the intention of releasing at least one new version of the game each week.  The primary focus of the next release will be interaction with enemies.  Here are the goals for that release, in order of importance:

1. Create one or more zones where enemies will remain and respawn
2. Make enemies turn so that they are facing the way they are moving
3. Update the wandering algorithm
   1. Enemies shouldn’t move at every single update
   2. Each enemy needs to decide whether to move and, if so, where it wants to move, then this movement should be carried out over a number of updates so that the movement speed is normal for the enemy

I think this is a good list for a release next Sunday.  If I get it done faster I will release v00004 whenever that happens.

I have added collision meshes to almost all the assets in the world right now and re-exported them as .fbx files.  I just have a few trees and the weird, random tombstone left.  The collision system definitely needs more work.  It does generally function the way I want it to, but unfortunately it hangs in a few spots and doesn’t like complicated geometry at the moment.  I’m not going to let that keep me from releasing a version, though.  I’ll get the last assets fixed tonight then do a release.  After that I’ll need to make a list of improvements for the next release, so stay tuned.

I have updated the object loading code so that if an FBX contains a mesh called “Collider” that that mesh gets added to the collider list.  This way I can add collider meshes in Blender, export the new object, and when it gets added into the world the collider mesh is included, so that’s neat.  I created a collider mesh for the fence sections and one of the tree types.

This is mostly working but, again, I noticed that it’s not perfect.  On the fence collider sliding down some of the faces isn’t perfect.  It just sort of hangs up here and there.  Also, the tree collider gives me some of the same issues that my test sphere was having, specifically the browser crashed at one point.  This shouldn’t be surprising since I can’t really say I understand the collision system all that well, but hopefully now that it’s organized I can go through and optimize it and really gain a full understanding of what’s happening.  Even with these nagging issues, I’m still really excited that creating collider meshes for objects in the world looks like it should be pretty easy.

I have added the CollisionSystem code to Lyridia and things are looking mostly ok.  I can create a BoxGeometry, translate it, rotate it, and add it to the collisionTargets array and the collision detection system works great.  There’s still no gravity and the collision sphere is too big, but it works.  I’m a little disappointed because I tried switching out the BoxGeometry with a SphereGeometry and the results were a little mixed.  The system seemed to mostly work but I was able to walk into the sphere in one place at least one time, and another time it actually crashed the browser.  So there is still some work to do on the collision system, but overall I’m still very pleased with it.  The next step is to add an invisible collision mesh to another object in the world, like the fence or the Penrith farmhouse, and make sure I can use the system there.

I have rearranged the code from Fauerby’s paper into a single Javascript function (class) in a separate file.  I called it CollisionSystem and a single instance of that function keeps up with everything related to collisions.  Fauerby used a “CollisionPackage” (or “CollisionPacket”, depending on where you look in the code) to pass variables to the collision functions.  I moved that into a single class with the appropriate members and methods.  So now my code looks like this:

var _cs = new CollisionSystem();

_cs.collisionTargets.push(collidableObject);

var newPosition = _cs.run(position, velocity);

position = newPosition;

Once the CollisionSystem is created and at least one collisionTarget is added to it, I just call run with the collider’s current position and velocity.  run returns the new position and I can then update the scene with that position.  Easy peasy chicken squeezy.

A current limitation of the system is that I’m not implementing gravity right now.  That will need to be done eventually, but I thought I could add that later after the core system is running.  I’m also not taking a collidableObject‘s rotation into account at the moment.  This will obviously need to be implemented but it shouldn’t be difficult at all.  I’ll need to look through the code to confirm this but I believe that the collider has a hard-coded radius of 1.  Since the base unit in Lyridia is 1 meter, a collider sphere with a diameter of 2 meters is really just too big for a humanoid player character, so that will need to be adjusted.

My next step is to take my CollisionSystem class and bring it into the rest of Lyridia’s code base.  The only real challenge with that is that the player doesn’t move based on velocity directly right now, but that should be easy to change.

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.