Print

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

[Starver]

I've been playing around a bit with the brook. Not for the brook, itself, but for trying general water-depth effects.



There are errors in there. I don't do anything about the amount of rock that breaks the surface (because it'd be virtually impossible for me to establish the positional-dither/wavelet pattern properly atop of that) and part of one of the frames seems to be partially untreated (you may notice the flicker, a slightly brighter 'flash', which is not intended) but it'd take too long to go back and fix that properly and it'd be quicker to start from scratch. I think I only 'depthed' the water, but if you notice any bordering vegetation pixels that are wrong then I didn't spot that while working zoomed in and the other problems were then more obvious to me.

Probably not practical as an in-game filtering effect (it works solely on hue, leaves everything else the same - on top of all the other effects that went into creating the source graphic that I obviously don't have access to the components for) and even if it is it perhaps ought to be tuned differently, or even applied in a different position in the graphics-queue, in advance of the waveletting probably (and underneath the overhanging vegetation layer, which I manually excluded for each of the 16 frames for each of the 7 or 8 hue-shifts I applied...)

Other than that, thought I might share it. Then move on.

[Rekov]

I want to throw out a few thoughts for the artists and others to think about concerning how diagonal movement might best be handled. The idea is that new players should be able to intuit where movement is and isn't possible, correctly and accurately, just from the graphics. Currently, players just have to know that you can move diagonally, even if visually it doesn't necessarily make sense.

Here are the three scenarios I've come up with:

• Stick with what we have. Players will just have to know that diagonal movement is possible.
• Shave off all 'convex' corners of solid tiles where diagonal movement is possible.
• Shave off 'convex' tile corners, but only in the narrow case, where movement isn't otherwise visually possible.

EDIT: I've modified my examples to include a few more likely scenarios where this makes a difference.

[[HYBRID BEING]]

I'd prefer option 2, but maybe shave off a bit less? Columns look really small like this.
How would ramps behave near walls with shaved off corners, though?
Btw, were 90° vs diagonal minecart track pieces discussed already?

[Superdorf]

Option 3 is nice.

[Starver]

Option 3 looks complex. And I can see situations where "only if otherwise not visually possible" leads to strange transitions as the immediate surroundings change and the "visual possibility" changes, forcing morphing solid walls into the alternate mode with some strangeness to the effect. I can see why you're doing that, though.

I always thought that with round pillars depicting walls without orthagonal neighbours, a diagonal (single 'thickness') row of these has obvious gaps between. Hemispherical wall-ends (opposite the one orthagonal neighbour it has) and semihemispherical corners (opposite the two adjacently orthagonal connecting walls) would give similar gaps as this octagonal-based shaving. Combine with a 'phantom' inner-corner deshaving into the empty tile would improve a "solid diagonal edge" (two or more connected diagonal rows), or just realign the wall to the "antialias mean" diagonal. But would need more 'special case' code sending feelers out further than the single tile being currently being considered, to send out suggested changes to its near-neighboours too.


(TL;DR; I think it's a complex question, no ideal solution. I could live with any, but would personally consider the no-fuss Option 1 to be the absolute least bother so long as the player can imagine diagonality as taken for granted. And so many other gridded games already prime people to expect this, so that any that forbids it is considered peculiar)

[Rekov]

I'd prefer option 2, but maybe shave off a bit less? Columns look really small like this.

Here I've reduced the amount I've shaved off of the corners so that a single-tile column will look like an octagon. Obviously this makes that narrow passage quite tight, but that actually makes some sense considering how fluid mechanics work along diagonals.


There are of course increasingly more potential variants which I'm not going to mock up:
5) Smaller cut-off corners for narrow parts, but regular square corners elsewhere.
6) Large cut-off corners for narrow parts, but small cut-off corners elsewhere.
etc, etc,

[Cruxador]

I don't like option 3 because it would lead to cases where mining something away adds stone on the other side of the corridor, which can create the reasonable but incorrect impression that the stone dug out from the ground has to be put somewhere.

I think 2 would be good if the amount cut from the corners was smaller. Maybe half that amount, per tile.

Ninja: I think option 4 looks pretty good even though I sort of hate the round-looking bits, aesthetically. But presumably they'd look better once actually sprited, rather than cobbled together for demonstrative purposes.

[JesterHell696]

I like option 2.

[Ziusudra]

I think I'd like #5 most, with #4 a close 2nd.

[Rekov]

I think #3 looks the best, but #5 still looks good while more accurately reflecting the geometry.

[PatrikLundell]

#1. All the other versions mess with the layout morphing the rock, and makes it harder to distinguish the tiles properly (and results in a lot of additional work for both Toady and the artists).

@[HYBRID BEING]: There are no diagonal minecart tracks in DF. Introducing such tracks would require a fair bit of changes to the code and memory structures, and I believe a crucial structure is already out of bits. Thus, that's a technical game change, not a display issue.

[Starver]

So, now #4 is closest to my internal ideal ready voiced, with #5 acceptably more complicated (as already discussed re: #3) and #1 stil acceptably more simple (ditto).

Nice artwork, every-which-way, BTW. If there's nothing else to take away from my equivocation...

[Shonai_Dweller]

#1. All the other versions mess with the layout morphing the rock, and makes it harder to distinguish the tiles properly (and results in a lot of additional work for both Toady and the artists).

@[HYBRID BEING]: There are no diagonal minecart tracks in DF. Introducing such tracks would require a fair bit of changes to the code and memory structures, and I believe a crucial structure is already out of bits. Thus, that's a technical game change, not a display issue.

Why should paid artists not due to deliver a product for at least a year worry about the "extra work" of drawing diagonal tracks and corridors? Is there some upcoming deadline only you know about?

Everything else is being modified by Toady and the artists as they put these sets together, why not minecart tracks? Isn't the point to make a fine looking game for the premium release (within the limits of flexible procedurally generated imagery)?

Also, could you post a picture showing how it makes it hard to distinguish the tiles, not sure I understand the logic (apologies if it's obvious, not all us are pixel artists).

[voliol]

#1. All the other versions mess with the layout morphing the rock, and makes it harder to distinguish the tiles properly (and results in a lot of additional work for both Toady and the artists).

@[HYBRID BEING]: There are no diagonal minecart tracks in DF. Introducing such tracks would require a fair bit of changes to the code and memory structures, and I believe a crucial structure is already out of bits. Thus, that's a technical game change, not a display issue.

Why should paid artists not due to deliver a product for at least a year worry about the "extra work" of drawing diagonal tracks and corridors? Is there some upcoming deadline only you know about?

There is the imagined deadline of ”soon”. Also, the estimation of ”hopefully within this year” Toady put forth (with uncertainty) doesn’t put the release ”at least a year” into the future, but as of the start of June, half a year.

[PatrikLundell]

#1. All the other versions mess with the layout morphing the rock, and makes it harder to distinguish the tiles properly (and results in a lot of additional work for both Toady and the artists).

@[HYBRID BEING]: There are no diagonal minecart tracks in DF. Introducing such tracks would require a fair bit of changes to the code and memory structures, and I believe a crucial structure is already out of bits. Thus, that's a technical game change, not a display issue.

Why should paid artists not due to deliver a product for at least a year worry about the "extra work" of drawing diagonal tracks and corridors? Is there some upcoming deadline only you know about?

Everything else is being modified by Toady and the artists as they put these sets together, why not minecart tracks? Isn't the point to make a fine looking game for the premium release (within the limits of flexible procedurally generated imagery)?

Also, could you post a picture showing how it makes it hard to distinguish the tiles, not sure I understand the logic (apologies if it's obvious, not all us are pixel artists).

I'm about as far away from an artist as you can get... Maybe you find the posted examples completely clear, but I do not.

The artists should (and do, as far as I've seen) care about delivering an acceptable level of quality for the full range of assets that are to be included at release, and ought to advice Toady on where to best spend their time from an artistic perspective. Toady obviously has the final say, but it should be part of the artist role to provide advice within their areas of expertise.

The deadlines "only I know about" are, as voliol mentioned, Toady's stated intention, and what (only I, apparently) believe is a contractual obligation to deliver before a two year deadline from the commercial version contract (landing the time somewhere in the vicinity of mid January to end of February). At time of delivery, all contents obviously has to reach a minimal acceptable level of quality (which has been mentioned before in this thread, I believe), although that does not mean work will stop at the first release: there are indications, I believe, that work will continue for an unspecified time after release during which nice additions (as well as pure improvements) could be introduced. But yes, I believe there's a lot of work and less than half a year in which to do it (assuming there will be some closed beta testing to avoid some of the usual crash bugs at release, but testing is the first thing cut when deadlines are not met...).

Any work Toady spends on adding new game play functionality for nicer graphics has to be weighed against time spent on stress balancing, UI overhaul, logic overhaul (an extension of the UI work, such as e.g. the military UI which probably requires functionality changes underneath as well, stockpile refinement [quality/wear/size] and re-partitioning, etc.), the rest of the graphics, and crash bug fixes (and I'd disable Villains by default in the Premium release rather than release that unbalanced mess as a standard feature, or it will hurt the commercial game reception badly). Is diagonal track support more important than some of these things (many of which will probably have to be cut down in scope due to a lack of time)? Not in my opinion.