Starting with enemies

Planning and Development

Look at these lovely little piggies:

I realize, again, that it’s hard to get a real sense of what’s happening here since it’s a still frame but the boar models are moving around in a random pattern.  Every 1 second the server sends an update to every client with the new location of each boar.  Each boar moves a random amount in the x and z directions and stays within a certain range.  This is super basic functionality but it’s neat because it’s controlled by the server so every player sees the randomly placed boars in the same places.  Eventually I’ll need some actual “intelligence” in the ways the boars move around, but for now this is ok.

You may have noticed there’s no player character in the screenshot above.  I’m still struggling with getting that working on my secondary machine that I’m using today.  Also, the boars don’t react to the terrain.  That opens a can of worms I’ll have to handle eventually, specifically how much of the game is running on the server and how much is in the client.  For instance, should the server somehow load the entire world and make decisions about collision detection, terrain height, etc., or should I leave much of that to the client to just tell the server what the world is like?  I’m guessing it will end up as some sort of hybrid between the two, but that’s definitely a design topic I haven’t tackled mentally or in the code, so it will be fun to figure out eventually.

Lastly, I installed Forever on my server so that I can leave the Node server running all the time.  Since the next release will include multiplayer  (and now some random boars) it becomes dependent on the server running all the time, and Forever allows me to do that.

Animation frustration (revisited)

Planning and Development

It turns out that my animations actually were not working correctly on my secondary test machine.  I’ve fought with this for days at this point and I’m ready to just give up on that other machine as a testing platform, but I’ve found something interesting in the process.  It appears that my other machine doesn’t like big numbers.  That makes no sense to me but here’s what was happening.  When I created a test scene with the animated character at (0, 0, 0) the character displayed and behaved fine.  However, when I moved the character and the camera to a far flung location, like (130560, 2, 130560) he suddenly disappeared.  No errors or any other indication anything was wrong, the character was just not there.  Again, this only happened on my lower-powered test machine.  On my main development machine the character shows up just fine at that location.  It’s really weird.  I’m going to create a test suite to see if I can isolate this issue further, but not right now.

The other slightly problematic thing I’m seeing at this point is a little bit of jitter in the character while an animation is playing.  It’s not huge but it seems to get worse the more loops through the animation plays, and was much more pronounced on the secondary machine.  I’ll need to do some digging on this but I may skip it for now just to keep moving forward with the project as a whole.

Next up is creating a simple attack animation then getting some enemies to walk around in the world.

Animation frustration (continued)

Planning and Development

I still don’t understand exactly what I changed but I was able to get my player character’s running animation to play on my secondary test machine.  The process isn’t exactly simple but if I have a .blend file that exports correctly that I can use as a template, and a scene that imports the .json file correctly and actually plays the animation clips correctly, I can handle it.  This is one of the major downsides of not using an integrated environment like Unity.  Since THREE.js has tons of moving parts and Blender has extra-tons of moving parts, it can be a bit tricky to get an asset to move out of one and into the other and maintain the desired behavior.  I’ll still create a tutorial on this process because simple, straightforward documentation on this specific task either doesn’t exist online, or is very difficult to find.  I’m just happy to make some headway here because I was starting to get worried that if I couldn’t figure this out the whole project would end up derailed.  Crisis averted, for now.

Animation frustration

Planning and Development

My simple animations are working in one place, but not the other.  This is very frustrating.  Maybe if I describe it here I’ll magically see what I’m doing wrong.  I develop and test Lyridia on two different machines.  One is a Windows 10 box with an old but ok graphics card and an old but decent processor.  The other is my Ubuntu machine that I wrote about earlier.  For reasons that I absolutely do not understand, when I run Lyridia on my Windows 10 machine I see my goofy animations.  When I run the exact same code in the same browser on the Ubuntu computer, the player character doesn’t render at all.  No error messages in the console, no other apparent problems, just no player character.  I can walk around just like normal, I just can’t see the character.  I know that skinned meshes will work on the Ubuntu machine because the examples on work just fine, but I have no idea why the specific thing I’m doing works in one place but not another.  I’ll keep hacking away at it because this is a pretty big deal to get working correctly, I’m just confused.

More animations

Planning and Development

I still say the process as a whole is one of the weaker points of THREE.js at this point, but the animation system is becoming a little bit clearer to me.  I managed to get my guy running around (still with the horrible running animation) and he jumps when you press the space bar.  The running animation only triggers if the player is actually moving, so pressing ‘w’, ‘a’, ‘s’, or ‘d’.  The jumping animation will play whether the player is moving or not and you can’t jump again if a jump animation is currently in progress.  The jumping action is animation only, so there’s no way to jump “on top” of anything right now, you know, without any sort of collision detection.  All in all it’s pretty bad right now, but it’s a reasonable placeholder for better animations in the future.  Now I’ll make a sword attack animation and trigger it with left mouse clicks, then start working on getting some nasty little piggies running around Penrith Forest.

Animation update

Planning and Development

Even though the documentation is a little thin, I managed to get some animations in Lyridia.  Now when you press any key the game plays an absolutely horrible run cycle animation.  When you release all keys, it stops.  Again, the animation is absolutely horrific at the moment.  This is on purpose just to force myself to spend zero time on polishing at this point.  It’s just not needed.  The functionality, and the ability to polish later, are the important bits.  Still want to do that tutorial on animation because I’m getting just a bit of jitter in the animation itself.  I know this can be resolved, and I’m hoping that the digging required to write a decent tutorial on this stuff will reveal the underlying issue.

Animation is a nightmare

Planning and Development

It turns out the THREE.js animation system is a total nightmare.  Hopefully I’ll look back on this fondly in a few months and think, “What a fool I was.  The animation system is actually very powerful and really simple!”  For now, though, it’s rough.  The primary issue is that this very, very brief overview of the system is the only real up to date information I can find online about the it.  The animation system in THREE.js changed radically somewhere around r69 or r70 so there is some information about the old system, but that really does me no good.  I think that the best thing here is to just write my own tutorial covering everything from exporting a mesh from Blender to running specific clips in a scene.  Writing a tutorial will force me to understand the system a little better, and also hopefully create a resource for others who might be struggling with this, so keep your eyes open for that over the next several days.


Planning and Development

Next up is animations.  Once I have the player using a basic walk cycle and, hopefully, a simple sword attack animation, I’ll release a new version.  This will take me some time because I’ll need to familiarize myself with the animation system in THREE.js and create the actual animations in Blender.  Since I’m very much an amateur modeler and animator, the process may be slow.  But, once that is done I can focus on enemies.  Specifically, having enemies that walk around in a semi-random pattern within defined regions and react when a player attacks them.

Dancing piggies

Planning and Development

Screen capture software and I apparently don’t mix so you’ll have to take my word for it from a still image, but this is fun:

What you can’t see is that those pigs are in a staggered line and they are moving in a preset pattern across a small part of the world.  The only reason this is cool is that their movement is control by … wait for it … THE SERVER!  So everyone connected sees the piggies move in exactly the same way at exactly the same time, which is awesome.  This is, hopefully, the very beginning of having enemies controlled by the server that players can actually interact with.  Fun stuff.


Planning and Development

It’s back!

Fancy meeting you here

Fortunately I saved all the code from when I had basic multiplayer support using BabylonJS.  It took a bit of minor tweaking but nothing really very serious.  Fortunately all of the Node stuff didn’t change at all.  I’m not leaving the Node server running when I’m not actively working on the development, so you can’t technically do this right now, but when the server is running an unlimited number of players can connect and watch each other walk around on the terrain.  Pretty exciting stuff.  I did this because I want to get a few boars running around and that requires the Node server.  It will be really cool to have multiple browsers running simultaneously, each just watching some boars wander about aimlessly.  So cool.