Roadmap for the next few weeks

Planning and Development

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.

Boar movement

Planning and Development

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.

More boar control

Planning and Development

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.

Boar control

Planning and Development

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.

Planning for v00004

Planning and Development

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.

v00003 (2018.06.10)

Release Announcement

Chronicles of Tright: Lyridia v00003 is now live.  Here are the things that are new in this version:

  • Collisions
    • Collisions are buggy at the moment and completely un-optimized.  Be careful because I’ve had my browser crash several times during testing, especially around the random blue tombstone.  This is something that will need some more attention going forward, but does mostly work for now.
  • Enemies that follow the terrain
    • The 10 boars still don’t really look very realistic in any way, but at least they don’t sink into the ground or float in the air.  The boars also move somewhat smoothly from location to location between update messages from the server.  Position updates are still only emitted once per second, but each boar tweens between the position of the previous position and the position of the most recent update.
  • Improved, but still terrible animations
    • You can press space to make the player jump (if you aren’t moving) or press ‘1’ to see a really awful punching motion.  This is an area that obviously needs much work.
  • Better terrain
    • Penrith Forest is basically a bowl valley.  Right now you can walk right up the steep slopes around it, but eventually that will change.
  • Very, very basic NPC interaction
    • If you move relatively close to the guy next to the house and put your mouse cursor over him, he will be highlighted.  If you click while he’s highlighted you get a goofy message.
  • More stuff in the world
    • I added quite a few trees and some other scene filler

It really feels like I should have more to list here because I seem to be implementing new things all the time, but I guess that just really shows the enormity of what this project really is.  I’ll take a little time tonight to start preparing a list of things to implement next, but if you have any suggestions feel free to leave a comment.

Preparing for a release

Planning and Development

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.

More collisions

Planning and Development

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.

Collisions and more collisions

Planning and Development

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.

Collision system refactoring

Planning and Development

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();


var newPosition =, 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.