Terrain work

Planning and Development

I’ve been messing with the terrain in Lyridia recently because it needs work.  After some general indecision I decided it would be best if I could set the color of each face individually, that way I can add some painting tools to the world editor and just paint in paths or grassy patches or snow or beaches or whatever.  As a step toward that I needed to just figure out how to set the color of each face, and what better way than with a different random color assigned to each face!

This obviously looks a little crazy but I kind of like it.  I could see a part of the world where the terrain looks something like this all the time.  Maybe in a truly chaotic place, or maybe this is how you see the world if your character eats a hallucinogenic berry.  Lots of options.  The main point, however, is that setting each face’s color programmatically is totally possible.  That’s good because this way I can keep the low-poly style, but still add in some details to keep the terrain from just being a green blob.


I have also tried shading the terrain with vertex colors instead of face colors.  The neat thing about this approach is that WebGL blends the colors between the vertices so that if I want to draw some snow on a mountain, I can take the length of a triangle to transition from gray to white.  Or if I want to draw a path then the sides of the path can fade from brown to green.  This might take away from the low-poly look, or it might enhance it.  I won’t really know until I get some actual painting capabilities built, so my next task is to rebuild the world editor.

Starting again

Planning and Development

I’ve been away from the game for a few weeks due to my personal life being really busy lately but I’ve been thinking about the game and now it’s time to pick back up on development.  Here’s some things I’ve been pondering, in no particular order.

  1. I need to rebuild my world editor.  The world editor mostly works right now but it’s gotten big enough that it’s difficult to maintain because I didn’t really plan it out from the start.  THREE.js actually has a somewhat nifty editor already built so I will probably take that editor and start adding in feature I specifically need to create zones for Lyridia.
  2. The game engine needs its own project.  I’ve been making the game engine alongside the game and so far that’s worked but over the last few months it’s gotten unwieldy.  It’s just hard to organize well when you don’t have a clear separation of “engine” from “game created with engine.”  I have also created a very basic workflow that might make professional software engineers cringe, but the gist of it is that I have a file that lists every file in the engine project.  A Node script copies all of those files into a single file, then another node script minifies the whole thing.  This gives me a single Javascript file to load and also reduces the file size pretty drastically.  I realize there are more robust ways of accomplishing this but this way works for me and doesn’t require me to rewrite the whole code base to work properly with Node.  For now I’m calling the game engine “OK.”  Because, let’s face it, it’s not great but it’s OK.
  3. I’ve been thinking about character classes for the game.  For a long time I’ve had this idea that character classes should progress as a character gains more experience.  For instance, a fighter type may start off as a general tough guy at level 1, but by the time a character is at end game he should be something more specific and impressive like a gladiator or a commando.  It has never made sense to me for a level 1 character to be the same class as a level 100 character.  A level 100 character shouldn’t be just a “fighter” and a level 1 character shouldn’t be a “death knight.”  So my thought is that set points in a character’s development the player should choose how to progress.  For instance, for Warrior types every character starts at level 1 as a “Tough.”  This is just a basic low-level fighter.  But at level 10 the player would choose whether to focus more on attack or defense and become either a “Fighter” or a “Defender.”  Then at level 20 you can become a “Warrior,” a “Brawler,” or a “Guardian.”  This carries on until level cap.  The only refinement I might make to this is to give every archetype it’s own progression chart.  So instead of a Warrior type choosing between DPS and tanking, I might make Warriors choose between targeted DPS and AoE DPS, then have a progression chart for Tanks where characters can be more agile or withstand more damage.  In any case, I like the idea of being able to play multiple different classes during the life of a character, and even getting to plan out skills and playstyle based on the path a character takes through the progression chart.

That’s enough planning and thinking for now.  I need to go actually do some work on the game.

Animations are hard

Planning and Development

I’ve been fighting with getting a player character animated and, as always, there are complications.  I get that Blender often does things in its own special way but it’s quite frustrating that the process to export an animated character from Blender to glTF and import it into THREE.js is still flaky.  Specifically, here’s what’s happening.

I made a character, based heavily on a model I found on opengameart.org.  The model was not rigged so I rigged it in Blender and created a basic idle and run animation.  As far as I can tell, the export to glTF and import into THREE.js in this simple case is perfect.  The guy runs, I can see the animation names in the console, all is grand.  I thought, though, “It would be nice if I could model equipment separately then just parent the equipment to different bones on the model and eventually I could change the parented equipment programmatically.”  This is going to be necessary eventually, but for now I have punted and simply modeled a sword as part of the character’s base mesh.  This is because parenting separate objects to a bone works perfectly inside Blender.  The sword, in this case, moves right along with the hand to which it is parented with no issue but when I export the animation to glTF, things go funky.  The sword’s orientation goes crazy and it becomes difficult to predict where the sword will actually appear in THREE.js.

I honestly believe this is just something I’m not grasping about Blender but it’s frustrating nonetheless for the animations to work great until I add in the twist of parented objects, then it goes wild.  In order to move forward what I have now is good enough.  You can tell the guy has a sword and once I create the attack animation you’ll be able to tell he’s swinging it with the intention of doing great violence.  Eventually I’ll need to spend some real time with this, and possibly bring in some outside expertise to get everything working correctly, but for now I’m just going to move forward with what works and not worry about it.

Next step

Feature Development

I’m honestly not sure what the next step is for development of the game.  I’ve been thinking about battle mechanics and I have an idea for a system that is pretty different from a typical open-world MMO, but I’m hesitant to go all in with the idea because I didn’t start this project to do things differently, and doing things differently involves risk.  That being said, doing things exactly the same as they’ve always been done also involves some risk, so I’m torn.  Because the battle system is pretty core to the game experience as a whole, I need to make this choice correctly the first time.  I’d rather not have to implement a new battle system after the game is up and running.  Of course, one of the nicest things about the web as a platform for games and not working for a big company is that I can try things that are probably completely crazy.  For instance, I could have the battle system work completely differently in different parts of the world, or maybe have open world battle done like a typical MMO then use something different for party play.  I’m only constrained by what I can think up and implement.

I’m glad I started this post because it’s help me decide to go back to the typical MMO open-world battle system for now.  That’s what players will be used to and if I want to add in another system later I can always do so.

So, I think my next step is to recreate an attack animation for the main character and implement a very basic battle system.  It will be nothing more advanced than “attack an enemy and it dies” but that will do for now.

Better animations

Planning and Development

I’ve spent the last several days thinking about the overall art style of the game.  I very much like the low-poly look I’ve been using thus far but my concern is that I’ll be too limited if I ever want to add assets that need more details.  The primary thing that comes to mind is faces.  It’s way, way cheaper to just draw a cartoon face onto a few triangles than to model and render geometry for eyes and mouths.  Also clothing and equipment may be difficult to keep interesting and varied if every distinction between one piece and another has to be in the geometry.  I’m not ready to go full-blown Blizzard-style art assets yet, but I’ve starting creating assets that have a single, small diffuse texture attached.  I can then create a color palette on the texture and just assign faces of the mesh to the desired color.  It keeps the low-poly look but also gives me the flexibility to use gradients or even just hand drawn textures where needed.  I’m still feeling all this out, but the versatility of using textures is undeniable.

I’ve also been working on getting a better player character in the game.  I found a nice little human character on opengameart.org and modified it some to suit my needs, then rigged it and created an idle and a run animation in Blender.  I then loaded it up into Lyridia, and lo and behold I have a decent looking character that runs and kind of looks around when he’s not running.  Super cool.  Not sure what I’ll work on next, but I’m excited to be making progress again.