Editor improvements

Planning and Development

I’ve been working on exclusion zones in the world editor and this is what I have so far:

Right, what is this?  This is Penrith Forest a little away from the farmhouse in among some big trees.  Near the middle of the screen you can see a tiny little boar.  It only looks small because the camera is pretty high up.  That boar is the center of the yellow cylinder and that represents a wandering zone for the enemy at the center, in this case a boar.  Eventually I’ll need to configure how many enemies to keep in the zone, but not now.  The blue cylinders are intended to be “exclusion zones” where the boars will not walk.  This is computationally less expensive than having the boars move around with standard collision detection turned on.  You can imagine that it’s really easy to determine whether a point or path is within one large circle and not within a few smaller circles.  Since I need to control movement only in a very general way it make sense to do it the cheap way.  Of course, this is more work on the front end.  I have to actually define each of these zones but as long as the tools in the world editor work ok it’s not too bad.

Next I’ll need to update the server code so that boars won’t walk into or through an exclusion zone.  That should be fairly simple, I hope.

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.

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

_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.