Crew Sprite Testing, Fixes, and More Pathfinding

Hey Folks! Hope everyone had a good weekend. Our last four days were unfortunately largely spent driving, in hotels, or in waiting rooms. One of the benefits of immigration! It's good to be back at home, though, and decompressing.

Despite the tedious roadtrip, I did manage to break out the laptop in the evenings after checking-into each hotel. But first:

Rock Paper Shotgun Scooped My Prototype!

I guess the cat's really out of the bag now, huh? This is simultaneously really exciting and scary. Exciting because more people suddenly were made aware of my next project, and better yet, seem excited by it! Scary because, well, I haven't built it yet :) Hopefully, expectations won't outstrip what I can build!

As for progress, I've tried tackling a few things. I looked into alternatives for making crew sprites, fixed a few bugs in crew sprites, worked on pathfinding code, and fixed some hardware-related bugs.

After chatting with some friends, it was starting to look like hand-painting normal maps on animated sprites was, as my friend put it, "maybe insane." Even just drawing them would be a ton of work, as the number of animations increased.

In my last devlog post, matsy pointed out that Project Zomboid switched from hand-painted sprites to using 3D mesh to render sprites for their animations, all while trying to maintain the pixel-art style they originally had.

Now, having worked on 3D characters in my last job, I was loathe to try and tackle this. 3D is no joke, and it can take an army of people to produce and maintain the content for anything but the simplest of games. However, since my view was top-down orthographic, and low-res, maybe it was worth a look.

I set about grabbing the first low-res human mesh I could find, and found this helpful example by Clint Bellanger. And this useful Blender tutorial helped me setup a normal-mapped material for rendering the scene as a normal map. A few camera and rendering setting tweaks, a quick-n-dirty UV unwrap and texture splash, and here's what we get:

IMAGE(http://bluebottlegames.com/img/screenshots/screenshot-2016-01-13.jpg) Warning: this is programmer art.

What we see above is an in-game shot of a rendered sprite (top) vs. a hand-painted sprite (bottom). For reference, I included a few insets along the right to show what the rendered normal map, Blender model, and UV unwraps look like. It is low, low res, and low-effort at this point. I'm not thinking this is ready for prime time or anything, but for the amount of effort I spent painting blue, brown, and black on that unwrap, the results aren't terrible.

The main problems I see are a lack of crispness in the rendered mesh, and some garbled areas where there are tiny details in the render. But I spent way more time painting details on that hand-painted crew than I did on the solid-color clothes of the rendered one. So there may be hope yet.

Also, all this fiddling with sprites revealed a bug in my shadow code. I was generating shadow mesh incorrectly, resulting in weird holes, and self-shadowing due to the height of the crew, its shadow, and lights in the scene. So this experiment helped solve some rendering issues, even if I don't go with it.

This is going to need more investigation, and probably some art with more care put into it, in order for me to compare more fairly.

Moving on, I also spent a bunch of time working on pathfinding. The heatmap algorithm finally started generating good data, and I began working on walls. And this is where I noticed a problem.

The way I was dealing with walls, I just gave them a +10 pathfinding cost per tile, where normal floor would be +1 per tile. I was thinking this would make AI prefer floor over walls.

Instead, what I discovered was that the heatmap algorithm would break in situations where the walls blocked the majority (but not all) of shortest paths to the goal. It looks like my simple, brute-force heatmap approach is actually not so simple. I may have to explore more traditional approaches, such as A* or Dijkstra's methods. Or maybe my queue just prioritizes wrong. We'll have to see.

Finally, I ran into an alarming bug while on the road. Using my laptop to dev for the first time, the Unity graphics were garbled all to hell. In a panic, I started Googling "Unity textures messed up" before I realized it could be a driver issue. Sure enough, my Bootcamp driver for the MacBook was out of date, and manually installing an update helped. Some minor mesh importing and other setting changes in Unity did the rest, and I was back in business.

Not as productive as I would've normally liked in a 5-day period, but not bad considering the road trip. Hopefully, we'll be back to more or less normal tomorrow. Have a good night, all!

Comments

matsy's picture
matsy

Funny you mentioned being unproductive, as I was impressed with the amount you had done since your last post. Without you even mentioning the heat map and path finding code.

Did you try going super crazy and setting the path finding cost per tile for walls like +100?

Rovlad's picture
Rovlad

The rendered sprite doesn't look half bad, considering how simplistic the texture is, and more importantly, how easy it would be to swap it as character's wearable equipment change, or even doing animations for that matter.
It's definitely worth at least considering going this route, I think this step is very logical since it's a 3D environment as it is already; so why not utilize its potential.

linibot's picture
linibot

Re: the RPS post - I saw what you did there. ;) Also, congrats! Must be terrifying. XD


NEO Scavenger: FAQ
10 Ways (not) to Die - A beginner's guide

dcfedor's picture
dcfedor

@matsy, that's good to hear. I think being on the road for so many work days always makes me edgy, like time is slipping away. But I guess there was some progress after all!

And I think increasing wall values won't affect this particular bug. It seems to be more a case of the order of processing. It's doing the wall earlier than a more viable path, causing bad values in the floor tile on the other side. I should probably just make a "passable" property for each tile, to mark those that are definitely impassable differently than those which have a costlier path.

@Rovlad, I'm glad to hear someone say that. I've been feeling a bit critical of the art lately due to feedback I'm getting. But I need to keep in mind that it's early prototype art, and like you say, this opens up quite a few options for customizing assets.

@linibot, thanks! And yup, pretty terrifying :) When I read Graham's summary of what I was building, my first thought was, "oh my god, did I really commit to all that?"

Dan Fedor - Founder, Blue Bottle Games

Malacodor's picture
Malacodor

You really have ants in your pants. If I were a cartoonist I'd make a series "Daniel could sneak in a bit of work" depicting you using your laptop in various situations like in a strip club, on the ISS or sitting on a chair carried by furniture movers.

The rendered guy looks like I imagined it, not state of the art, but good enough. The resolution could be a bit higher, though.

Don't give up on heatmaps, they seem valid to me. I'd use heatmaps for static goals and goals in different rooms (using heatmaps of bottlenecks) and A* for mobile goals in the same room. A* is extremely fast in situations with little to no obstacles.

Ran around with a clown mask before it was cool