There have been few indie gaming success stories as big as Dwarf Fortress, an ASCII freeware simulation game in which the player helps to establish and govern a colony of dwarves, as they construct a Moria of their own.
The scope of the game defies belief: it contains an extensive world generator, a three-dimensional cellular automata system for simulating fluids, naming languages for all major races, an economics simulation, and even a complete Adventure Mode in which the player can explore abandoned fortresses.
It's so detailed that large web communities have sprung up around the game, both on the developer's forums and Something Awful, where players trade stories about what happened in their games. Some of these stories have even become popular outside the game's community.
Amazingly for a game as rich as Dwarf Fortress, it remains the work of just te wo people, programmer Tarn "Toady One" Adams and his brother Zach. Tarn supports himself primarily with donations from Dwarf Fortress enthusiasts. In this interview, Tarn talks about the inspiration and origins of the game, and some of the finer points of its construction.
This interview was originally held over a private IRC conversation, and edited into a more traditional interview format.
Games Leading Up To Dwarf Fortress
Why don't we start with what gave
you the inspiration to create Dwarf Fortress?
Tarn Adams: It's really the joining of
two different tracks of development. The first has to do with our (my
brother Zach Adams and I) "fantasy game." Way back when,
like, when I was in elementary school, fifth grade or so, I wrote a
BASIC game called dragslay. That was just a D&D game,
more or less, with text that scrolled up from the bottom of the
screen.
You mean Infocom-style?
TA: Pretty much, yeah. But it
didn't even have a map. Just a line through 8 or 10 encounters, then
a dragon fight, then repeat. It was very basic, but it was our first
project. Our first fantasy project, rather. We had a ton of other
space/samurai/etc. things going on, all BASIC, all very small, so we
didn't do so much with it. Then in the summer of my freshman year in
high school, I picked up C and dragslay was revisited.
So I was able to make a larger project. Dragslay was sort of horrifying. You could kill an enemy and then be attacked by maggots from the corpse at random. Wounds could fester as well then you'd catch diseases.
In any case, yeah, this
time it got a basic world map, and you could depopulate goblin tribes
in the wilderness as you searched for dragons. Along with several
other projects, we worked on that until, say, my sophomore year of
college.
So the game kept track of goblin
populations?
TA: Yeah, it was one of my first
save/load experiences outside of score lists. It kept track of their
names and kills and they could yell at you like the enemies do in
Dwarf Fortress. It was really quite far along, farther along
than DF adventure mode in some respects. By yell at you, I
mean it would track which players they had killed then they'd proceed
to make fun of you. They also stacked their skulls outside the
caves.
Ah, that's a significant departure,
I'd say, from the basic fantasy game template, and quite an
interesting idea. Between-game continuity.
TA: By this time we were operating in
spite of the games we were playing, rather than because of them, I
think. It was 1998, 3D FPSs had already been out and popular for five
years or so, I guess, and I was hardly playing anything anymore. A
lot of the games we played, like the Ultimas, also kind of got
us into thinking about the worlds themselves, rather than just
playing a game in one.
So I hit a Borland compiler limit, 65K something or other, and moved on to other projects. I didn't see a monetary future in my games, and I wasn't into CS as an academic pursuit, so I got serious about math for a few years, and went to grad school.
The summer before I went to grad school, though, we restarted the fantasy project. This time, it was called Slaves to Armok: God of Blood, named after Armok, the god from dragslay. Armok himself was named after "arm_ok", a variable that counts the number of arms you have left, for inventory purposes. This was a 2D project in a somewhat-isometric view, where you walked around a cave with a bunch of goblins in loincloths. It was entertaining, but short-lived.
I got started on the actual Slaves to Armok that I released on Bay 12 around 2000-2004 or so. This was our fantasy game. Lots of complex things going on, and of course, a boatload of plans. It was unwieldy, and got even more so when I went 3D. This is the first piece of Dwarf Fortress.
Now, you might have seen the various, questionable games littered throughout my site. I would occasionally take time off from Armok and grad school to write really short projects on weekends or whenever I found time or had an idea. A few of them got released, and many others just died before they saw the light of day.
A game called Mutant Miner is one of these. It was roughly inspired by Miner VGA and Teenage Mutant Ninja Turtles mutagen, or something. As in Miner VGA, you'd dig out tunnels in the ground under a few buildings, looking for minerals and deal with threats. It's turn-based.
In Miner VGA you can find many things in the ground. In Mutant Miner, we added green radioactive goop. You could take it back to one of the buildings at the top, and apply it to yourself to grow extra arms and other mutations that would help you combat threats down below. Which were just, like, these holes that would spit out enemies or blocks of slime that you'd encounter in the mountain.
I eventually wanted to put in extra
miners though, and since it was turn-based, it started to drag like a
battle in an SSI Gold Box game. And instead of rewriting the game, I
thought, well maybe it should be dwarves instead. And it should be
real-time, to combat the SSI problem. Now, you'd be digging out
minerals in a mountain, combating threats inside, and making little
workshops.
Then I thought, well, how should the high score list work? We really like to keep records of plays. Not just high score lists, but expansive logs. So we'll often try to think of ways to play with the idea. This time, the idea was to let your adventurer come into the fortress after you lose and find the goblets you've made, and journals it generates.
If your adventurer
successfully brought these back to town (after facing threats in the
now-abandoned fortress), the player would get to see the fortress'
stats. For instance, if they found a journal that said "This
month, we produced 3 silver goblets...," they get the entire set
of stats on silver goblet production in the score list.
That was the idea. It was supposed
to take two months. I started in October 2002.
Creating the game?
TA: Yeah, longer games took a few weeks, most of the other ones up there took 2 days (ww1medic, corin, Kobold Quest, etc.) so I didn't think it was a bad estimate. And it might not have been, but I called up my brother and we just kept planning it out. It became obvious that it was really stealing thunder from Armok which was right in the middle of its life cycle at this time, so DF development was actually stopped that November and I went back to Armok, which was still going all right, and various other projects.
"Strike the earth!"
TA: By around 2004 though, it was
obvious that Armok was floundering under its own weight. So I
announced on the forums that I'd be switching gears to dwarves. I
kept adventure mode a secret though.
(Ed note: Adventure mode is a special feature of Dwarf Fortress, where the player can take an adventurer through various areas of the game's random world in a traditional roguelike adventure. The player can visit old places he's worked in Fortress mode.)
So, you kept going with a variety of
different games at the time?
TA: Oh yeah, it's important to break
things up. DF isn't the only game I want to write.
Did you already have a good forum
community at the time?
TA: It was nowhere near as large as it
is now, but there were a few dozen hardcore people and many more
occasional lurkers/posters. Most of them came on board with me
working on the dwarves. They knew only that it was a dwarf-sim. I
kept the RPG part quiet, for fun.
It took longer than I thought, but I finally got it out in August 2006. It was our only fantasy project by that time, and all Armok dev had moved over there, so it was Armok 2 as well. Hence the long-winded name, which is for kicks, mostly.
Ah, hence Slaves to Armok,
God of Blood II: Dwarf Fortress. A quick question: The
game already contains a great many ideas working in concert. It's
really quite amazing. Do you think Dwarf Fortress
will get to the point where it too will flounder under its weight?
TA: Nope. After many project
deaths, I think I've finally got a handle on simultaneous programming
and design. It's tricky to keep it up though. There's certainly
a lot to learn. And I think the latest z-axis release shows I'm not
afraid to gut the entire project if I have to [laughs]. Having it
collapse is not really an option at this point. My livelihood is tied
up in it.
The z-axis thing, that really was a surprise, yes. But a good one. Before, the world generator seemed to determine climate and wildlife and not much else. Now it's an absolutely essential part of the game, and determines the entire nature of the fortress to come.
TA: I was going to be starting armies without messing with the z-axis, but there came a point where I felt like I'd be hemming myself in. I'm only going to have time for one shot at this fantasy project now, so I want to stuff as much into it as I can.
We appreciate that attitude, believe
me.
TA: It would be almost like facing mortality to refuse a solid idea. I hate having to say something good doesn't fit my specs.
What's left to answer is why'd we be so
into doing a fantasy game. That's probably the same as everybody
else: Tolkien, D&D, myths, and of course, the movie Beastmaster.
(We like the part where the evil priest is like, "You'll be
sacrificed to 'The God of AAaa,'" like they didn't even bother
thinking of a name, just powering through on the power of their
badassedness.) But there were all kinds of things like that. In
the movies, books, the arcade, PC, consoles, we were surrounded by
that sort of thing.
So along with generic sci-fi, generic fantasy is part of our heritage. This kind of brings us to the stories.
Storytelling as an Idea Source
TA: That started with Armok, although there might have been traces of it with C dragslay. We had a spiral notebook, and we decided to write stories about events that happened in the game universe, things that we'd like to have happen. My brother Zach would write a chapter, then I'd write the next chapter, we'd go back and forth several times. Then we'd look over it and decide on some low-hanging fruit to implement.
It was partially inspired by our repeated experiences with plots in video games. We never really wanted to write a plot, and a lot of them seemed like they could be generated by a computer. So we thought about breaking stories down into core elements, and working with those instead. You'd be very hard-pressed to capture really beautiful symbolism or an advanced writing device like that with a random generator, but there are very few game stories where that would be an issue.
It's really the same
principle as world generation or anything else in the game: finding
the key, basic elements, finding the rules that govern them, and then
activating those things in the world.
So, kind of a random drama
generator?
TA: That's right. Create actors
with motivations, and let them go. It's about the same process you'd
go through in a writing class, or with Dramatica or something. Not to
say I've implemented much of this but that's the idea, and it applies
to all aspects of DF design.
Now my brother, who isn't programming,
has taken the bulk of the story writing role. He has a lot of fun
churning things out, and then we look at them. I assume there are
more impressive story generators, world generators, body part models,
etc. I'm just trying to put moderate versions all in the same place.
It should give rise to some really awesome stories from the players
themselves.
Actually, I can't point to a better
world generator than DF's.
TA: I can't either, but I'm the
last person to ask. I've only played a handful of new games in ten
years.
The nice thing about DF will be
that the actors in the story have the whole, random DF
universe to work with. So even if they aren't cutting-edge
complicated, it should be awesome.
It must be heartening to see the
Something Awful guys writing stories about the trials of their
fortresses.
TA: Yeah, Boatmurdered had me laughing my ass off [laughs].
(Ed note: Boatmurdered
is the story of a single long Dwarf Fortress game played in
turns by a large number of Something Awful forum goers. It became a
minor internet sensation some time back, getting as far as the front
page of Metafilter.)
It's like Zach's stories are
being retold, in a way.
TA: Yeah, even for the mechanics we haven't added yet, people just fill in the blanks. It's like that with a lot of games -- people think they are more complicated than they actually are. I remember having that experience with the ground war in Falcon.
Stories aren't the only way we plan. I think a few people had that idea. But it's certainly a fun way to plan that can really crystallize exactly what we want to accomplish.
The Wounds System & ASCII Graphics
TA: Yeah, we were role playing quite a
bit, at least through '93. Cyberpunk was influential, as far
as the damage system goes.
The body-part system.
TA: Yeah, Cyberpunk did not
have hit points. You'd get shot, brain damaged, in the hospital
permanently, roll up another character, back into it.
In most RPGs, hit points are something wholly replenishable. In DF, if a character loses a limb, he's not getting that back!
TA: Hit points are depressing to me.
It's sort of a reflex to just have HP/MP, like a game designer
stopped doing their job.
While I think a lot of people who stick with that kind of system do it in order to simplify the game, it does seem to be unexamined by many who use it.
TA: You should really question all of the mechanics in the game from the bottom up. I dunno. It really doesn't seem like a conscious decision sometimes.
Of course, somebody with a game with dwarves and elves and goblins should be careful, but I think about that too. I don't think it's a bad decision many times, but that's assuming it was a decision. I just don't see it as the case. And there are so many equally simple things you could do that are more inventive.
DF's way of doing it
seems to work quite well for its purpose. Let's move on to graphics
for the moment.
TA: If [Dwarf Fortress] had
a fantastic interface and graphics tomorrow, it would really be
something. I'd lose a few core people, but it would really be
something.
Yeah, it'd be nice if they were
there... on the other hand, I think ASCII has worked surprisingly
well so far.
TA: I've squeezed almost as much as I
can out of the letter E though. It's really getting iffy at this
point.
I can go over to something more Moria-esque. Sort of a class-based system, like "feline=f," instead of first letter + color being inline with reality with size = caps. That would get me a little more mileage perhaps, but the problem would remain. Not that small graphical tiles are any better.
But I don't entertain such thoughts for the time being, since Armok died this way. I just tell myself that DF graphics are like a storyboard. Once the storyboard is done, you can make the movie if you want, but not before. And with my creeping specifications, we just keep going with ASCII.
"Losing is Fun!"
How about the "Losing is fun!" motto in the instructions and on the site? Where did that originate?
TA: Ha ha, that was originally just a
throw-away line in the manual. But some people like it.
I think it's really an important
thing to say, when I think about it.
TA: I put it there to try to create
some comfort with the concept of permadeath. Reloading every time
you fail will really hamstring you in DF, especially later on.
I've also tried to put out a concept of "playing the world, not
the fortress." Though in a sense it's a bit premature, since the
best parts of the persistent universe are still in the works.
Right. Permadeath is generally a
roguelike concept, of course.
TA: Yeah, I've seen some of those 7DRL
contests. It's too bad it takes so much time to undertake a large
project. Time is really the only barrier for a lot of people.
Yeah, true. Still some of the
7DRL games are surprisingly good. ChessRogue impressed
me to no end.
TA: I like short projects. I used
to have a thing I called a three hour knockoff. I think Squiggles
might be the only one I've posted.
That reminds me a bit of the
Experimental
Gameplay Project. To return to "Losing is
fun!" for a moment, the suggestion helps the player to get over
losing, so he'll leave behind exploration sites for Adventure mode.
I'd say one of the game's breakthrough ideas is how the fortress
gameplay naturally encourages the player to create areas that are
challenging to overcome in an Adventure Mode game. An excellent
strategy in one game becomes a dire challenge in the other.
TA: Yeah, that was the original
premise of the smaller game, and it was one of the things I thought
would be very interesting from a metagaming perspective. On the Bay
12 Games forums, they've gotten together and are now making an
"Adventure Park," where they each take a small portion of
one world map square and make a for-adventure-mode fortress. Then
they'll upload it, and anybody can play, wandering through the varied
creations. It kind of reminds me of a MUSH. This kind of sharing and
moving between game modes is definitely fertile ground.
Do you think DF
might become internet-capable in the future, and facilitate this kind
of sharing itself?
TA: I'd need help with that, since I've never made a multiplayer game. A lot of people are interested in this kind of thing, and it's kind of counteracted by my own complete lack of interest in multiplayer games, but something could happen. The community certainly finds a lot of ways to go multiplayer without my involvement though.
The World Generator
Let's talk about the world generator
for a bit. If you wouldn't mind giving us a general overview of the
process the game goes through? No need to go into great detail.
TA: Sure. The first overall goal of
the world generator is to create enough information to produce a
basic biome display. A lot of initial attempts at a world generator
will start with things like "I need to lay down some forests,
and some mountains, and some rivers, and some deserts..." and
then when you end up with a jungle next to a desert, or a desert next
to a swamp in an unlikely way, it's difficult to fix.
So the idea is to go down to basic elements. The biomes are not the basics, they arise, at least in DF, from several factors: temperature, rainfall, elevation, drainage. First, it uses midpoint displacement to make an elevation map.
It also makes a temperature map (biased by elevation and latitude) and a rainfall map (which it later biases with orographic precipitation, rain shadows, that sort of thing). The drainage map is just another fractal, with values from 0 to 100. So we can now query a square and get rainfall, temp, elevation and drainage data.
This is where the biome comes from. There's an
additional vegetation field so it can alter the amount (from logging
for example), and there's also a "savagery" and a
"good/evil" field. So for instance, if rainfall is >=66/100
and drainage is less than 50, then you have a swamp.
I guess oceans get high salt as a special step?
TA: Yep, for now, it just sets the salinity to 100 at the oceans (oceans are just all the low elevation spots), and tapers it off quickly over the land squares.
You still get some artifacts from the midpoint displacement. It tends to like vertical and horizontal lines, so the next step is the erosion phase.
It picks out the bases of the mountains (mountains are all squares above a given elevation), then it runs temporary river paths out from there, preferring the lowest elevation and digging away at a square if it can't find a lower one, until it get to the ocean or gets stuck. This is the phase where you see the mountain being worn away during world creation. I have it intentionally center on a mountain at that point so you can watch.
This will generally leave some good channels to the ocean, so it runs the real rivers after this. However, some of them don't make it, so it forces paths to the ocean after that, and bulges out some lakes. Then it loop-erases the rivers, and sends out (invisible on the world map) brooks out from them. During the loop-erase it also calculates flow amounts and decides which rivers are tributaries, and names the rivers.
This gives us a world with biome data
and rivers, but no actual life. So now it actually looks at the
general biome groups of each square (what I call a region type) and
forms regions, giving them names. So you can have the "Silvery
Forest" which is taiga in the cold regions and a jungle in the
warm region, as long as it is connected.
At this point, it looks at the biomes
available in each region and sets up plant and animal populations.
This gives you a canvas for world history.
And from there I imagine it's just
looking up the combinations of circumstances and looking them up in a
table of random possibilities.
TA: Yeah, I'd like to do more with
ranges for animals, so that it's not so scattered. So that many of
the northern forests have certain critters, and many of the western
forests have others to kind of set up more of a geographical image.
Right now, it goes strictly by biome type. It also sets up all the
seed information around this time. There are some additional
structures it sets up, for features like cave rivers and so on. So
it could set up a non-local feature like a world-wide cave tunnel
like this.
It wouldn't be so complicated to have
the computer generate the races itself, though the lack of
familiarity could be jarring. Armok 1 did this.
Very cool idea, I'd say. But
does this mean we won't have dwarves to play in the future?
TA: Nah, I like having a stock universe
around. It helps people get into the game, and they can stick with
that if they like.
I do like the idea of there
being unknown species to discover though.
TA: The intermediate part of this might be the most interesting. Like when an evil wizard creates a randomized race, and over several games it actually forms towns, starts wars, etc. Then you play one in adventure mode. Lots of possibilities here.
I've kind of put some of that to the
back burner while I work on the basics, like the current Army Arc.
But it's really cool that I could start working on that even now if I
wanted to. I've always wanted to be able to do some of this stuff!
Deeper Details
Anyway, let's move on to what I
expect was one of the biggest challenges in developing the game: the
amazing pathfinding.
TA: Is it amazing? It's creaky and
slow.
Well it looks amazing from my end,
since there's a metric ton of characters all doing it at once.
TA: The dwarves themselves mostly move around with A*, with the regular old street-distance heuristic. The tricky part is that it can't really call A* if they don't know they can get there in advance, or it'll end up flooding the map and killing the processor.
(Ed. note: see here)
Sometimes in commercial
projects the developers do a bit of cheating, and predefine travel
paths.
TA: Yeah, that's the hard part. We
can't really predefine areas beyond very basic notions because fluids
can zip by and block them off, or they can mine a floor out. All it
does now, and this isn't ideal, is keep connected component numbers.
So if a dwarf is standing in "2", they know they can't get
to "3" and don't bother trying. However, they assume they
can get to any other "2", and will A* those paths. There
are still a few failures, but it's fixable.
There's a price to pay for that though, on a few levels. First, it's a pain to maintain. If a fluid occupies a square, it has to update. If a fluid flows through a passageway and cuts it in half, it has to reindex one or both sides. There are other ways to think about handling it, like keeping track of some sort of rectangles or something, and pathing on those, but the memory cost is too great.
The memory cost here is large, and it's
also a speed burden. There are probably a ton of better ways to do
it, it's just a very hard problem.
And all of this taking
place over potentially many Z-levels too.
TA: In a 480x480xZ map. Or even a
768x768xZ at max settings.
And there's another huge downside to it that I have to cope with, and that's the mode of travel. A dwarf walks; a dwarf does not fly. For a flying creature, the path components are meaningless. So flying creatures are much dumber than dwarves, and dwarves are already kinda dumb.
I still stand by the adjective "amazing" though, based on how watching a dwarf make his away around the world, then suddenly disappear because he took an unforeseen shortcut over a hillside, is a cool experience.
TA: Yeah, it's nice that they can solve
an arbitrary labyrinth of your own design, and they'll pick the best
possible path, generally. There are some exceptions, like mining
where they can mine from multiple sides, and don't try them all.
At its most complex, running Dwarf
Fortress is like having an ant farm. You look in, and
these little bearded guys are roaming all around, each with his own
agenda. It's fascinating to watch for its own sake.
TA: Somebody modded their dwarves into
antmen [laughs]. I even have a few people that went as far as
donating, and they don't even play. They just like to check out the
stories.
Fluid dynamics is one of those
features that, to look at it, one can't help but wonder, how on earth
did he do that? I think the answer to that question would be of great
interest to the authors of falling sand game
clones.
(Ed's note: We're talking about the most recent versions of Dwarf Fortress, that use a three-dimensioned cellular automation system to manipulate water, much like a multi-plane version of falling sand. In it, each space is a cube that can contain from 0 to 7 levels of water. A "1" is the smallest amount of water possible in the game, and a "7" space is full of water.)
TA: I think the falling sand games are
more impressive than my stuff. I've got kind of a bare-bones
system. The only thing impressive about it is probably that it
runs at all while everything else is going on.
It's really not that
complicated, just a specialized cellular automata.
TA: Neither is mine, he he. Mine isn't
much more than that. Water falls down if it can, over if it can. The
pressure is a bit interesting, I guess, since that isn't a local
operation. There's probably a local model for pressure, but the ones
I've seen wouldn't work for me, I think.
Pressure is the thing I'm personally
interested in seeing explained.
TA: The main problem was at
waterfalls. The water would fall on to the river below, and just
start clumping, forming a pyramid. This is because of the local
behavior. It can't go down, so it goes over.
Ah, I see. So the water is
flowing out, but too slowly.
TA: You get a slope that naturally forms. And the hard part is that you really can't have any artifacts at all, it really has to just look like a river. Anything unusual is bad, it can't do any pre-calcs based on the map, because the fluid system has to work with water the player throws at it.
The water in the falling sand games I've played with does something similar when a great amount of water lands in an area, it tends to sort of pile up and takes quite a while to settle down to an even level.
TA: This example was in a canyon or a
cave river. If you are out in the open, it'll overflow the banks,
which is also terrible. The cave river is the case where I started,
the water is completely contained, but it still has to look normal. I
did solve the problem, it doesn't do this anymore, but there are
probably a ton of solutions. The way I did it, I can also model
pressure, but it's a bit expensive.
What'd you end up doing?
TA: Let's say you have a U shaped
tube, and the left half and bottom are full. This should not be a
static situation.
Yes, in the falling sand model,
water won't rise up the right-hand side.
TA: The nice thing about this is
that I'm not dealing with a ton of small particles, but large tiles,
so I can afford some pretty cludgy operations. From the local
perspective, let's say it is the turn of the water at the top left to
move. It can't flow anywhere, and it can't flow down, so it checks
the square below. If it is marked "static," it stops. If it
isn't marked "static", it'll start doing a flood-fill check
downward, through full water spaces, never rising higher than its own
level until it finds an open slot.
If it finds one, it teleports there.
Otherwise it marks the square below as "static" to avoid a
recalc. If the situation ever changes (like water is removed) it can
just remove the static flags. It seems like it would be pricey but
it's really pretty fast, and doesn't account for very much of the lag
on computers having problems. This also happens at waterfalls.
The recalc elimination aspect helps
keep it fast.
TA: Yeah, without the recalc
elimination it would be impossible at the waterfall. Incidentally, I
turned this off for magma on purpose, so it's all clumpy.
So what happens to, say, a tower
of 7 water? I don't know if a tower of water can happen in game.
TA: Yeah, you could do it. Pour water
into a tube walled off by floodgates in a stack. Then pull a lever
and open them all at once. There would be intervening floors I guess,
on the sides, but it's close.
For the tower stack, if it started
updating at the bottom, then it would do what happened in the first
case, and the water above would just be able to fall down, then
repeat. So you get a nice blob spreading out. If you start at the
top, it sees the square below isn't static so it goes down, then it
goes whatever direction, down, to the side, whatever, and puts a 7
there once it gets to an open spot. So your 7s would teleport and the
end result is a blob, but it has moved a bit faster.
Some people will purposely open a
water reservoir that is more than one deep. The water shoots out fast
because the entire second layer suddenly searches for an opening. You
can get super fast flooding that way. Somebody had a goblin trap
where they'd drop water on the gobs, and it happened to be outside in
the arctic so it would immediately freeze and the gobs would die.
It also tracks which direction the
water flows in a few ways so it can push objects and show flow
animations.
So then, how does this cause water
to flow up the right-hand side of that U pipe?
TA: When a water is doing a search for
an outlet, it is allowed to go anywhere up to one below its original
Z level, including up the pipe.
I don't let it go the last step, or
you'd end up with a three-quarter split that doesn't know how to
stop. I have a dev item to improve that, but that involves expanding
the static flag to a byte size counter.
And it respects physics, because
it can't rise above its original height!
TA: Yeah, I was happy with it. It's
crude, but it works, like the rest of the game. It would be nice to
have a local model, but those are hard to come by.