Print

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

[Mike Mayday]

Pillbo: let's not be harsh in our words here please. I appreciate that people are passionate about the project, even when we have trouble communicating.

We're certainly going to have various sprinkles over the grass.
Schmaven: good idea, I'll bring it up.

[Rekov]

I'm back to talk about ramps some more.

So Toady posted an admittedly work in progress picture of ramps. I gather that they aren't unique tiles, but shaded overlays applied above normal ground tiles.

In any case, I believe the current regime requires more types of ramps in order to be complete. I am referring specifically to the scenarios highlighted here, where you have ramps "behind" ramps on the same z-level. 



I will use 3D models to represent the current set-up, and then my proposed solution.

This is the exact set-up highlighted above. The current solution is on the right, with my proposal on the left. That new tile represents a unique geometry which transitions one of those inset hills into a corner. You would obviously need versions of this to represent the mirror image layout, as well as rotations thereupon.



This scenario can also occur along a straight ramp. The presumed current solution is on the right, and my solution with another unique geometry is on the left.


I present these solutions as a means of creating shadows that represent actually possible geometry.

[Mike Mayday]

As always, my response is - it's a WIP screenshot.
I've already made all the tiles you're talking about, they're just not implemented yet.

[Meph]

Yeah, we ended up with 56 possible ramp sprites. I think Mike dreams about them at night now. Lovecraftian, non-euclidian ramps at all angles haunting him at the darkest hours at 2:20am...

Anyway, moving on. Working on walls at the moment.

[ZayZe]

lmfaoooooo

[Rekov]

Well as I say, I knew ya'll were WIP. Just checking .

Do you guys have a set policy in terms of what is top down vs. isometric angle, or are you just playing it by ear? So far it seems like terrain is portrayed top down, while sprite and so on are at an angle.

Terrain makes perfect sense to be top down because that allows you to extend it across multiple z-levels. But does that work for staircases? How about trees?

[Mike Mayday]

I think the rule we've intuitively set up is this - if something occupies one tile, it's at an angle. If something forms multi-tile relationships - it's top-down. Hence, the stairs will be at an angle, but trees need to be top-down.

[Meph]

Yeah, pretty much.

Creatures are side-view.
Items are at an angle.
Terrain is top-down.

That's the basic idea. We kinda wanted to do terrain at an angle at first, but the multilevel made that a bit difficult, as you noticed. So it had to be top-down. Unfortunately top-down doesn't allow much details on items or creatures, so we switched it up.

Edit: He, I was just using an old mock-up as a test for gem-highlights, and it still has isometric trunks. XD

[Bumber]

There should probably be a bunch of frames where the gems aren't sparkling. Mock-up is a bit of an eyesore. Maybe you knew this already.

[LordBalkan]

Well I wouldn't bother if the sparkle was thing on real game.
Maybe was a feature specific for more valuable ones? 
No problem if it was just a mock up thou.
And yet its being really nice to see the progress even when it is just WIP.

[Meph]

The issue are gems with colors white, grey, black or brown. They aren't super visible with merged with the background rock. The red and cyan ones in the mock-up are very visible, but imagine a grey gem in grey rock.

[Cruxador]

I know usually I'm more inclined to speak up when I think something isn't good than when I think it is, so I just wanted to make sure I say: This looks great. Aside from the tree trunk which is already changed, everything in this screenshot is well designed and aesthetically pleasing. The only thing that's potentially overpowering is the glimmer effect but it fundamentally looks good and I agree with Bumber's implicit statement that it's fine as long as they're just not constant. But if they can be made to do it relatively infrequently, then they're perfect.

There should probably be a bunch of frames where the gems aren't sparkling. Mock-up is a bit of an eyesore. Maybe you knew this already.

From a technical perspective, lots of frames would require needlessly large filesize, it's better to just slap a delay on. That's one variable which ticks, rather than a variable which ticks AND something like 8 kilobytes before compression if the animation is the whole 32x32 tile. Plus, if you have delays you can make them dynamic and do things like making the animation happen a few times in unusually quick succession for all cases, when you jump to a new screen by choosing to go to event from the dialogue box saying your miners have struck a new mineral or cavern. That would allow the game to represent dazzling beauty without it detracting from the actual play/action of the game, as we discussed with the spring flower case. And this is something that isn't very beautiful in the base game, so it would be most definitely an enhancement in the graphical version, if Toady finds it viable.

The issue are gems with colors white, grey, black or brown. They aren't super visible with merged with the background rock. The red and cyan ones in the mock-up are very visible, but imagine a grey gem in grey rock.

Cyan gems in microcline could also be a problem, if the microcline maintains its characteristic garishness going forward. One possible solution that could partially address this would be more dramatic highlights, even going as far as actual #FFFFFF white. But I like your glimmer solution better.

[bloop_bleep]

If the files are compressed, most decent interframe compression algorithms out there would make repeated frames much smaller when stored.

[mko]

I know usually I'm more inclined to speak up when I think something isn't good than when I think it is, so I just wanted to make sure I say: This looks great. Aside from the tree trunk which is already changed, everything in this screenshot is well designed and aesthetically pleasing. The only thing that's potentially overpowering is the glimmer effect but it fundamentally looks good and I agree with Bumber's implicit statement that it's fine as long as they're just not constant. But if they can be made to do it relatively infrequently, then they're perfect.

And I really dislike this kind of animations, but I hope that it will be easy to remove it with mod.

[Schmaven]

And I really dislike this kind of animations, but I hope that it will be easy to remove it with mod.

Just out of curiosity, what is it about the animation in particular?  The color, the size of the sparkle, frame rate?