Very few of the tutorials you find on Unity start from scratch.  Almost everything starts with “Download these great assets and import them into your scene” then you just tweak it.  This is fine, I guess, but it’s frustrating when I don’t want to go just buy a bunch of pre-made assets from the Unity store or use the generic stuff that come standard with Unity.  I guess I just have to spend the same amount of time learning it as I did learning (what little I know about) THREE.js.  Since it’s a slick graphical tool it just continually feels like it shouldn’t be so complicated, but then again making games is an inherently complicated prospect, so I guess I should just adjust my attitude a bit.  Sigh.

It really looks like Unity is the way to go.  The whole system is just awesome and there are extensive resources show how to do basically anything you could want to do.  I don’t know why I feel like I’m choosing the “cheap” path on this because Unity is a professional toolset used by game studios all over the world, but I still sort of do.  Of course I don’t ultimately care.  I’ve always said I don’t really care about the way the game gets made, just that it gets made and runs in a browser.

This is a pretty monumental shift.  I’ve spent very, very much time developing a browser-based world editor and generally doing stuff with THREE.js, but the Unity tools are just too good to pass up.  In 5 minutes I made a terrain that’s more expressive that what took me weeks to make with my own tools.  Plus I don’t have to worry about exporting and importing assets.  Unity natively imports Blender files and the whole thing Just Works™.

It will take me a while to get a Unity-based version of the game up to the point that the THREE.js-base version is now, but it should be time well spent since creating the world will be much, much faster and easier with Unity.  I’ll keep posting little updates but things here will be sparse for a few weeks while I basically start over and make some big decisions about how the game will work now.

I really like THREE.js.  It’s fast, light, and easy.  Well, it’s easy to do easy things with.  Unfortunately, the further I get with this project the more concerned I am that I need a more complete set of tools.  The thing that has really set me off the last several days is the pipeline, specifically for animated assets, from Blender to THREE.js.  One of my primary goals is to have the game run without the need for plugins or other installed software, which is what led me to THREE.js and WebGL in the first place.  After doing  a small amount of testing it appears that the WebGL exporter in Unity3d is finally fully supported.  Running a couple of WebGL demos created with Unity3d on my secondary test computer shows me that the WebGL exporter seems to be pretty efficient because the visual effects in the demos are miles ahead of what I’m going right now with THREE.js and it still has a decent frame rate.  Plus some physics and other things are also running in the demos, so it appears to be a viable option.  I’m not 100% convinced yet because there are some real concerns with switching toolsets, not the least of which is the learning curve involved, but I’m going to spend some time getting familiar with Unity3d and I’ll make a determination soon about whether it’s time to switch, or double down and try to create some better tools myself based on THREE.js.

The alternate Blender glTF exporter seems to be working great.  I exported my player character and the actions defined in Blender showed up just fine.  After some fiddling I was able to get those animations to play in Lyridia.  So I now have an idle animation, a run animation, and an attack animation.  The idle animation plays when you’re, um, idle.  And the other two are self explanatory as well.  Right now the attack is just a sort of punching motion and it’s not very expressive.  I think I might give the character a sword and modify the attack action just so that it’s more obvious what’s happening.  Once that’s done, I’ll definitely release a new version, so look for that this weekend.

There are definitely big parts of the animation system in THREE.js that I don’t understand at all right now.  I tried using the crossFadeTo function but had absolutely no luck getting it to work.  Presumably it can be used because there are examples that use it, but I may punt on that issue for now just to keep moving forward with more substantive game features.

The animation pipeline from Blender to THREE.js is just horrible.  I want to use the glTF file format because that seems like it will be supported the best in the future but the official Blender exporter from Khronos Group doesn’t support multiple animations.  I’m not sure how that’s not a core feature, but apparently it isn’t.  I found another exporter plugin that seems to play more nicely.  I was able to create a very simple scene with a cube that just moves around, but it’s movement is defined by two different actions in Blender and the export to glTF is actually working.  I’m really disappointed in how kludgy this whole process is, but these standards are all rapidly changing so hopefully the official exporter will be updated soon and maybe things will be a little clearer to me as well when I’ve spend more time creating animations in Blender.  In any case, I’ve seriously wanted to just rage quit the whole project several times over this, but maybe I can just barely, barely see the light at the end of the tunnel for this process.

I’m at the point where I need a reliable method to import animated assets into Lyridia.  I’ve been back and forth with several different options from the THREE.js native JSON format, to .fbx files, to glTF files.  I currently don’t like any of them, but it seems like glTF will have the best standardization and support going forward, so that’s what I’d really like to use.  I’ve been using .fbx files but I’ve noticed that the animations I’m creating just don’t look right.  It’s like what is shown in the game is a watered down version of what I see in Blender.  I realize that makes no sense, but that’s what I’m consistently seeing.  As a test I made an animation where the player’s leg raises up to the side at a 90 degree angle.  In Blender it comes right up to 90 degrees then drops back down.  When I export the animation to a .fbx file and play that same animation using THREE.js, the characters leg only goes up about 60-70 degrees.  That makes absolutely no sense to me, but I can see it with my eyes.  Fortunately the glTF exports seem to be better, but importing .glb files into THREE.js is a process on its own and has the whole game broken at the moment.

As much as I was looking forward to putting out a release in the next day or so, I feel like I just have to spend the time to figure this out now.  So I’m going to take at least a few days and set up a .glb importing test environment so that I can figure out exactly how to export the animations from Blender and import them into THREE.js.  The joys of using rapidly evolving open source tools.

I looked at the development server world today and could only see maybe 3 boars wandering around where they were supposed to be.  I obviously had a problem with the control code so I went and looked and the check to keep the boars inside the spawn area was just wrong.  I fixed it, but it was funny to walk around and see the boars so spread out after just randomly moving around for many hours.

I also made the boars not move on every single update.  Now a random selection of about 10% of the boars move on each update.  It still isn’t totally natural looking, but it’s much better than having every one move at regular 1 second intervals.

According to my schedule from a few posts ago, I just need to get a somewhat decent attack animation in the game and I’m ready for a release.  I’ll work on that tonight.

I’ve been pretty busy the last several days so I’m just getting around to implementing this but it looks like my exclusion zones are working.  After watching for several minutes it does not appear that the boars will walk into the cylinders surrounding the trees that were created in the map editor.  This took some wrangling as the collision zones are actually children of the enemy spawn point itself, so getting the correct coordinates to check against took a little fiddling, but it seems to be working.  One thing the code does not do at this point is check for paths through an exclusion zone.  That is, if a boar tries to walk from a point outside an exclusion zone that goes through an exclusion zone but stops again outside the exclusion zone, it won’t be stopped.  This isn’t an issue right now because the maximum distance traveled at each update is only 2 meters and the exclusion zones all have radii of about 5 meters, but eventually this will need to be improved.  Now I need to make a small improvement to make the boars move around just a little more naturally.

I’ve been working on some new animations for the player character so hopefully I can get those put in by this weekend and release a new version at that point.

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.