Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Kagus]

http://www.bay12games.com/dwarves/dev_v1.html

Second item from the top.

[TiagoTiago]

http://www.bay12games.com/dwarves/dev_v1.html

Second item from the top.

those colored words in that page should be link, smuch less work than having to memorize somthing and then look for it in the bottom

[TiagoTiago]

btw, where can i read about how the current pathing code works?

[NW_Kohaku]

those colored words in that page should be link, smuch less work than having to memorize somthing and then look for it in the bottom

Tell me about it...

Still, I'm surprised that Toady actually wants this with the RGB color spectrum, if only when worked with gems as color filters.

... I also hope he doesn't just force everyone to make fires everywhere, but instead have portable illumination in the form of lamps, because the slightest trace of fire in the current game is certain doom.

[Footkerchief]

Here's a previous Suggestion thread about day/night cycles, including a comment from Toady:

Although you've mentioned it, I just wanted to emphasize that I hear nothing but negative comments about a uniform sleep time for all the dwarves (specifically of the starting 7).  Even if special things happened at night that built potential tension, it's still very important to keep in mind how dull it can be, especially if FPS have dropped a bit.

We've kicked the idea around a bit of course, partially because it makes things more homogenous with adventure mode, which eliminates some annoyances, but there's the sleep problem (which isn't that much of a problem if dwarves aren't made uniformly diurnal) and some other potential difficulties to overcome as well, or at least hurdles, with how it zooms to army battles or relates to adventure mode time.  Even with abstract day/night the accelerated abstract time for dwarf mode is always going to be a problem though, so those potential problems aren't a big deal in the grand scheme of things.  It would be nice to scrap dwarf time altogether, and it's very aggravating on many levels, since two systems have to be kept in place for the same mechanics, but it's not as if I can get rid of it...  unless people want years to pass reaaaaaally slowly.  There are various ways to try to change it, but the flow of dwarf mode is pretty nice now, so anything very radical would need careful consideration.

Also got some tangential discussion in these two lighting threads:
Light...
Lighting arc discussion

btw, where can i read about how the current pathing code works?

Here's a basic overview:

About path finding:
5. Which basic algorithm does it implement, A*?
6. Does it operate on the block-level as well as the tile-level?
7. How is a path that spans Z-levels handled? Does it first look for accessible stairs, then connect the endpoints?<P>About OpenGL:

5.  Yeah, with the street distance/Manhattan heuristic pushed up so that it's just below the minimum traffic weights, with binary heaps for the node lists.  No doubt it's a crappy implementation.

6.  Nope.  The map is dynamic, and I haven't seen a practical way to do this (ie without burning memory or killing the CPU when the map is altered).  There's going to be stuff to do here, but I haven't done anything yet.

7.  It just runs A* between the goal and destination.  Ramps, stairs, water and flight are just ways to move from tile to tile.  It won't try an A* path if the connected components don't match up, which is where some problems arise (as with flight-modded dwarves in fort mode and so on).  Regular flying creatures use something more like short-range flood fills to combat this, if I remember, but they can't use arbitrary A* if they don't have a component check or else the processor will die on pathing failures.

Here's the Wikipedia article on A*.

[TiagoTiago]

is that any better than the algorithm used for Liquid Wars?

[Footkerchief]

is that any better than the algorithm used for Liquid Wars?

From http://www.ufoot.org/liquidwar/v5/techinfo/algorithm

Pros

The Liquid War algorithm for path-finding is very efficient:

    * When you have to move lots of different points toward one single point. Good thing that's the rule of Liquid War!
    * When you have no clue about how your map will look like, ie if the walls are randomly placed. The complexity of the level doesn't influence much the speed of the algorithm. The size does, but the complexity, ie the number of walls, is not so important.

Cons

The Liquid War algorithm is very poor compared to other algorithms when:

    * You have several target destinations, that's to say Liquid War would be really slow if there were 100 teams with 10 players only.
    * You want to move one single point only.
    * You want the exact (100% sure) path. In fact, this algorithm finds solutions which approach the best one but you can never figure out if the solution you found is the best, and the algorithm never ends. In the long term, the algo will always find the best solution or something really close but I don't know any easy way to figure out when you have reached this state.

A* is probably better for DF, yeah.  We have some people brainstorming ways to speed up DF's pathing.

[TiagoTiago]

i see, thanx

[Silverionmox]

Line of sight calculation is a major resource drain, if search for resources for programming roguelikes. So step-by-step shadow updates are probably unattainable until the next generation of mass-marketed supercomputers is available.
I do like the the static or sporadically updated lightning, if only because they make the aboveground and underground feel different. I'd like giant sundials and stone circles that cast let their central altar be illuminated at a single day in the year.