Pathfinding Works, Beginning On Crew
Hey Folks! I think I've got the heatmap pathfinding working, for now.
Introducing a "passable" property to each tile avoids the bug I described yesterday when I tried to make walls cost more to traverse. Instead, if the tile is impassable, the heatmap code just ignores it, so they don't pollute nearby tiles with incorrect path values. As a result, I can get a whole map processed with numbers increasing each grid square away from the destination!
The next step was to see if I can get crew to follow it. And before that can happen, I need to introduce the concept of crew to the code.
I started out by ripping the mesh-creation code from items, since both items and crew are going to use similar code to create display mesh in the engine. This is where Unity's component-based architecture pays off, since I can just create a "SpriteMesh" class that both Items and Crew can share. I just create either an Item or a Crew object, and tack-on a SpriteMesh component, and voila! Each can now have procedurally-generated mesh in the game.
After I extracted that code, I created a simple Crew class that could track current position, destination, and heatmap info. For now, I'm storing the heatmap on the crew for simplicity. I could easily move this over to the ship, though, and just store heatmaps for each goal on the ship as-needed. (Assuming those heatmaps remain valid, that is. If any obstacles can appear and/or move, heatmaps become out of date.)
A little bit of tinkering later, and my Crew object was able to pick a destination at random and move to it! Except it was so fast that it looked like The Flash blipping in and out of every tile on the ship in rapid succession. To fix this, I turned down the movement speed of the Crew, and I could follow more closely. It kind of cuts corners now, but that may not be a bad thing.
The next thing I started was changing the Crew's orientation to match the direction of movement. And I almost have this working now. Except, the rotation is mirrored when traveling in the X+ direction. I'll have to dig into it to see why, but I suspect there's a sign error somewhere, or else an arctan correction that's missing.
In other news, I stumbled across an interesting crew sprite solution today. @Ellian, a talented pixel artist, was tweeting about a set of top-down sprites he did for a cancelled project. They had a clean pixel art style, movable parts/joints, and swappable parts/clothes. And best of all, it required no 3D modeling/rigging/keyframing/rendering!
This is a video of the early prototype in action:
His channel has a few other videos, including one for character creation with swappable parts, and a character select screen where the characters are much larger and easier to see.
It's not perfect, of course. For one thing, the animations look a little like the heroes are wading through water. And there may be a limit to the types of animations those parts can produce (e.g. prone). And rotating sprites in 3D will look a bit weird, since "real" pixel art would have different animation frames per rotation.
Still, though, this offers a ton of customizability in terms of clothing, equipment, and even character builds (male, female, burly, thin). And it's way simpler than trying to model, rig, and animate each of these combos in 3D.
That said, I'm taking a break from experimenting with art styles for now. I feel like I've been noodling on that for so long that I'm ignoring more important things, like gameplay. I can always come back to the character art and change it later. But this warrants a bookmark for further review.
Tomorrow, I may dip into some NEO Scavenger stuff (bugs/modding). And if time permits, I'll probably continue fleshing-out the Crew class to do more of the stuff the old HaxeFlixel prototype did. (AI seeking needs, interacting with each other and items.)
Have a good night, all!