Back In (Prefab) Business

I've got the prefab-based tilemap working again. Looks like my problems were due to some bad calculations in the trimming/padding functions. Things like sign and rounding errors causing null pointers in some cases. As of this morning, I was able to build ships from prefab items and then watch my crew walk around them. And lighting could be toggled on and off.

That's the good news.

The bad news is is that it has lots of problems. Namely, the lighting looks bad on diagonal walls, and performance is pretty poor.

The lighting issue may not be fixable in the current system. Basically, the line-of-sight code spills through some "wall" tiles where one tile's corner meets another. And the stair-stepping pattern still appears. Even if I reduced the tile sizes and/or made diagonals thicker, I'm going to get this staircase pattern in the floor along walls.

And on the performance side, things don't look much better. Rendering all those overlapping prefabs really takes a toll on the draw time. Each "tile" can have a skeletal substructure, floor panel, and possible wall piece all drawn in the same space. And in a 10x10(ish) sized area, this consumes a lot of drawing time.

And to make matters worse, each of these prefabs has an update cycle where it keeps track of changing conditions on itself. It's unused at the moment, but I had envisioned using it to handle things like deterioration, heat transfer, etc. Even now, where each item has a list of zero things to do, and each one only updates once per second, all the time it takes to check each one is slowing the game down.

One thing I considered is whether to give up on real-time simulations, and switch back to something more turn-based. The advantage of such a system is that the calculations only need happen when the user clicks something (probably an end turn button, or other action). This limits the number of times calculations need to be made.

It's also advantageous because it gives players more time to relax and think. This is a very good thing, and one I think was important in NEO Scavenger.

The main down side I can think of is long voyages. Turn-to-turn crew management might be okay during critical moments, but what about the weeks (or months) of interplanetary travel? How will I handle simulation during this time? Do I just run a series of simulation steps one after the other? And how is that any different than running it in real-time? Won't the multi-turn simulation have the same performance issues?

I guess this isn't a problem exclusive to turn-based play. I'd probably need to fast-forward the game in a real-time model, too. I was originally thinking that I'd just fill that long, boring travel time with procedural drama to keep it interesting, so it would invalidate the need to fast-forward. But I suppose even the best-written sci-fi has to fast forward some of the time. A scene ends, a journey finishes without incident. We'll need to move on to the next interesting bit rather than assume every single second of simulation time will be interesting enough to watch.

More food for thought. Good thing the weekend is here! This is the sort of big-picture problem that is best suited to thinking while away from the code editor. Or maybe I need to brush-up on some turn-based games like Dwarf Fortress to see how it's done in those? Hm.

In any case, have a good weekend, all!


Malacodor's picture

Is it possible to handle the wall lighting via bump-mapping?

Instead of update cycles, can't you just calculate how long it takes for a change to happen and put this into a schedule? For example, if something will break in 1 hour due to deterioration, this is noted in the schedule, and when the hour has passed by an update is triggered. This way the game merely had to check the schedule each cycle instead of everything.

Ran around with a clown mask before it was cool

dcfedor's picture

Bump-mapping is indeed something I'm considering (a.k.a. normal maps). HaxeFlixel is due to have shader support "soon," so I've been watching for that.

One thing that doesn't solve, however, is occlusion. If you have a wall between a light and an item, the bump maps on both the wall and item will get lit even though the wall should occlude the item. If one wants the wall to prevent highlights on the item, one needs to do some sort of raycasting (whether in real time or pre-rendered).

And yeah, the update schedule is something that occurred to me over the weekend. No need to constantly check each entity's list of conditions for an update trigger. Just keep track of the next trigger to happen, and wait until that timer is zero.

This probably wouldn't help for things with "tick" conditions, which trigger over and over to simulate something ticking up or down. But on the other hand, there may not be many of these running on more static items like floors and walls.

Dan Fedor - Founder, Blue Bottle Games