Here are the things I want to get into the game next, hopefully in this order:

1. Add exclusion zones to enemy wander zones.  This is needed so that enemies won’t walk through trees and so forth.
2. Improve enemy wandering algorithm so that movement is more natural.
3. Improve player character animations.  Specifically, I’ll need better idle, run, and attack animations.  [Release new version here.]
4. Let players attack boars.  Initially the boars won’t attack back, or even react to being attacked but attacking boars should eventually kill them and a new one should respawn.  [Release new version here.]
5. Create the beginnings of a HUD to display very basic character information and stats.
6. Create an NPC dialogue box system.
7. Create a very basic quest system.  [Release new version here.]
8. Fix collision detection and add in gravity.  [Release new version here.]

That’s a pretty good list for now.  I’m guessing this is a month ore more, so I’ll keep referring back to this list as I add features.  Nothing new tonight, though, because I’m beat.

I finally got the boars to face the correct way as they are moving around.  Sometimes I get a little turned around when I have to do straight up trigonometry, and that’s what this was.  Here’s what worked (in pseudocode):

var o = boarObject;

var currentPosition = ...

var newPosition = ...

var direction = newPosition - currentPosition;

o.rotation.y = Math.atan(direction.x / direction.z);

It took me an embarrassing number of tries to get this right, but it’s working now.

***

Edit: After I was sure this was working, I fired up Lyridia on my second test machine and it was still completely broken.  I fumbled around with it for some time before I found a Stack Overflow post that recommended using lookAt.  Instead of trying to calculate the rotation myself based on the direction vector, now I just tell each boar object to lookAt(newPosition); and it works great.  Internally THREE.js must be doing what I was attempting to do, but the THREE.js code actually works, so I’m going to let it handle it. 🙂

***

I had a few hours in the car today to sort of plan out the next steps for Lyridia.  I don’t want to get into all of it now because it’s late, but I’m at the point where some more “game” type functionality is going to be added soon, and once there is something for a player to actually do I might start hunting around for alpha testers just to get somebody on the site.  Exciting stuff.

It turns out last night my boars were spawning in the right place but my world editor wasn’t saving the spawn point correctly.  Once I saw that getting the editor to place the spawn point properly made the boars spawn in the correct place.  I feel like I need to write the word “spawn” a few more times.  Now the boars wander around under the trees where I wanted them.  The server side code is an absolute mess right now, but it is technically working.  Next I need to make the boars point in the direction they are walking.  I may not get that done tomorrow, but hopefully by Thursday we will have pigs facing where they are moving.

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.