I’ve had my confidence in the Unity WebGL exporter somewhat restored by a little experiment tonight.  I changed the terrain in the game to a built-in terrain type object, instead of just putting a mesh collider on a big terrain mesh.  This seemed to work much better once the game was exported to WebGL without the weird hang ups I was getting before.  The stock third person controller kind of blows, but I guess I can deal with that.  The only real reason I was using a separately modeled object with a mesh collider was to get the low poly look I like on the terrain because the stock tools won’t allow you to do that with a Unity terrain object.  So this means I’ll either have to just deal with the terrain looking different from the rest of the game, ditch the low poly look entirely, or figure out how to make a Unity terrain object look the way I want.  I believe there are assets in the Unity Store that do exactly what I want, so if I ever fully settle on Unity as the game engine I want to use, maybe I’ll pony up the cash to purchase an asset that gives me the look I want.  For now, however, the terrain is just going to be smooth and textured while virtually everything else is faceted with no textures.

On a lighter note, happy birthday Lydia!  You’re lots of fun.

I’ve been away for a bit trying to get familiar with Unity.  It’s a great toolset but I’m just not sure if it’s right for this project.  I’ve been trying to get a very basic scene to export to WebGL and while it works, it’s not exactly right.  I have a terrain object with a collider on it and my player character model moving around with the standard third person controller.  In the game editor you can move around and everything is gravy, but the WebGL export hangs up in weird places.  It’s frustrating because there are WebGL demos that were created in Unity that look fantastic, so I don’t understand why my simple scene is having issues.  I’ll keep playing with it for a while longer and if I feel like I can do what I want to do with Unity I’ll stick with it, otherwise I’ll look at all my options again.

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.