Item-Based Ship Layouts

Hey Folks! With the NEO Scavenger v1.13 test build live, I'm going to give it a couple days to see if it has any critical issues before promoting it to the default build. So with that, it's back to prototyping!

Today's work continued efforts to build the ship from arbitrary items (prefabs) instead of square tiles. These items still get placed on the tilemap grid, but the tilemap itself is invisible and only used for things like pathfinding, light/collision tests, and socket info for placing items.

I've made some progress on this front. For one thing, I'm now able to place these parts onto separate layers based on their role. So things like structural beams will render below floors, which render below items (e.g. fridge), which render below walls...I can get a nice layered ship on screen. Plus, since the layers are well-organized, I can show/hide them incrementally (think Z-level in The Sims or Gnomoria).

I was also able to get lighting info to transmit to these items, based on the tilemap info below. It seemed to behave as designed, with shadows cast by placed wall items. The problem is that I still get some really harsh transitions from lit to black, and it looks pretty jarring.

One small hack I tried actually made a big difference: I simply made the minimum lighting dim instead of black. So areas in complete shadow still had some color and definition, and it looked pretty good.

On the other hand, a more complicated hack I introduced had a less-desirable effect. Adding blur/feathering to the lightmap to smooth the light/shadow boundaries takes us back to lightmaps that spill through walls. That's not really going to work.

Before going any further with this, however, I needed to solve a problem. Every time I tested one of these lighting models, I needed to rebuild a ship from items by hand. My old save/load layout system only cared about tiles. So I quickly added items to the data, and...

They're missing on load. Or more specifically, they're loaded, but not visible. And here we have most of my afternoon: trying to figure out why they weren't appearing. It was only late in the day that I realized it worked normally on the crew sim state, but not the build state. And this came down to reloading the graphics for each item after setting the ship's layout. (Switching states seems to kill the graphics for sprites.)

And then, I realized a big, deep problem: all my ship loading/saving/state-transition code does a lot of tilemap operations by manipulating the tilemap array directly. This was fine back when the ship only had tiles in an array. But now, it has tile tinting info, socket info, and visibility info, each in their own arrays. And these arrays get out-of-sync with the tilemap array when I muck with it.

There are quite a few places that are going to need fixing, or replacing, to get these lined-up again. Though, at least I have a clear problem to tackle tomorrow!

Until then, have a good one!


Rovlad's picture
I'm not seeing the test version.

dcfedor's picture

Ah, crap. Sorry about that. Looks like I forgot to add the Test links.

Should be working now, thanks Rovlad!

Dan Fedor - Founder, Blue Bottle Games

ra1's picture

Blur and feathering are two separate approaches. I would think a form of feathering is what you want. For each "real" light, place 3 (or more) dimmer "ghost" lights in a close circle around the real light (but only where that real light is shining). The ghost lights should generate the dithered lighting effect you want around corners.

This of course would be a performance hit of 3X (or more) on your lighting code. I don't know if that is a significant hit or not, but I wouldn't think so in 2D space.

dcfedor's picture

Yeah, feathering is probably the result I want, as it would preserve wall occlusion while softening floor lines. Blur was a quick and dirty attempt to approximate which failed to deliver.

Unfortunately, the 3x performance is a significant cost in this particular "engine." The lighting code uses a tilemap grid octant calculation which is going to hit the CPU exclusively (the same code to calculate creature line of sight). Dedicated 3D engines would have much more reliable and optimized code than this hacky, hand-made mess.

There may still be ways to handle this (e.g. OpenFL recently added GPU shader support), but I may also have to bite the bullet and keep things simple so as not to get bogged-down. Nice art is a requirement, and so is fun. Realism is a goal. But lighting isn't required.

I'm willing to keep the option open, though!

Dan Fedor - Founder, Blue Bottle Games