Print

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

[Novocain]

The main issue I have with most of these comments is that they're trying to bring excessive complexity to the current interface, without really giving it any meaning besides a touch of aesthetics(in an ASCII game, no less!). I hope you've read my bit of satire on the first page, though I'll admit that it doesn't get straight to the point.

I do agree that there are issues with scaling in DF, and that divisions within the 'tiles', as they exist now, would be beneficial. However, adding in an overly-complicated system to the basic game mechanics, while only going in and doing only part of the job you could be doing, is a waste of time. Don't you agree that it would be far more efficient to just increase the raw number of tiles while simultaneously allowing for more realistic sizing, as opposed to going in and only adding in the ability for seven z-segments per cube, which itself would likely require substantial rewrites to function?

I'd much rather see a well-requested feature(better creature scaling/tracking), in addition to better scaling for small transitions, than a system that would only allow for parts of the latter while still taking a significant amount of work itself. And I'd rather see it later than sooner, when systems will be able to handle such a load. I just don't like the idea of sticking in a jury-rigged system that will ultimately serve little purpose.

[PTTG??]

...Also, you could no longer assume that the game has a cubic grid for any purposes, making a lot of things (especially volumetrics) potentially more difficult...

I agree with your post, but F.Y.I.; the grid is actually not cubic- my calculations show that it is 6.125 feet tall, with a 2.5x2.5 footprint. But that's annother flame war.

[Mechanoid]

Spoiler (click to show/hide)

[image]

I had a dream that looked something like that once.
It was kick ass.

[Duke 2.0]

 The problem with DF in an isometric perspective: Things high in the sky, and things low in the ground.

 For example, place a bird squarely in the middle of the isometric example. Is it in the center of the pa? Or at the bottom, ten or twenty z-levels high?

 Isometric graphics are for generally flat simulations. If you have ever messed around in Roller Coaster Tycoon with some really loopy coasters, you know how furiating it can be to make things match up. And I don't want to take ten seconds of frantic rotating to understand what the heck I'm looking at.

 A full 3D interface might address these problems, because generally isometric graphics are rotated at 90 degree angles where 3D can be rotated to any angle. Parallax is indeed helpful.

 I do agree that having sub-sections of tiles would be helpful, but only if it does not hurt preformance.

[G-Flex]

By the way, I've created a topic a while ago about the Presentation Arc:
http://www.bay12games.com/forum/index.php?topic=21099.0

It's a quite long topic, but lot of good infos/chit-chat about the topic can be found in it.

Also take a look at this screenshot, and tell me that the isometric system wouldn't work in DF. [Keep in mind, I prefer the 2d top-down gfx system, this image is just an example.]

Just because you created a single example of a map where an isometric display works fine doesn't mean it always will.

That's an extraordinarily simple map. Of course it works.

For instance, take those mountainous-looking tiles. Make a 3x3 ring of them, with a hole in the middle. Congratulations, the mountains are now occluding that middle tile and rotation won't help you.

The more complicated the map is, the worse the issue becomes.

[MuonDecay]

The flying-units issue, and the occlusion issue, are both some pretty good examples of things that I know would piss me off (and I can totally relate to that Rollercoaster Tycoon reference. I've done that too, fscking mismatched tracks forcing me to throw in s-bends).

And I didn't think about the memory usage issue, though the solution of only using it for allocated surface or cave floor areas is simple and ingenuitive and would probably help a LOT.

I'd kill for that kind of terrain gradation. It'd make the world much more real, AND it would solve several current shortcomings in today's DF which break the 4th wall.

[Tormy]

For instance, take those mountainous-looking tiles. Make a 3x3 ring of them, with a hole in the middle. Congratulations, the mountains are now occluding that middle tile and rotation won't help you.

Isometric view is working like that. It's pointless to argue about that part. This view worked very well in all games what I know about. Basically it's a matter of subjective opinion that what do you prefer. Like I've said, I prefer the top-down [2d] system personally.

[MagicJuggler]

By the way, I've created a topic a while ago about the Presentation Arc:
http://www.bay12games.com/forum/index.php?topic=21099.0

It's a quite long topic, but lot of good infos/chit-chat about the topic can be found in it.

Also take a look at this screenshot, and tell me that the isometric system wouldn't work in DF. [Keep in mind, I prefer the 2d top-down gfx system, this image is just an example.]

Just because you created a single example of a map where an isometric display works fine doesn't mean it always will.

That's an extraordinarily simple map. Of course it works.

For instance, take those mountainous-looking tiles. Make a 3x3 ring of them, with a hole in the middle. Congratulations, the mountains are now occluding that middle tile and rotation won't help you.

The more complicated the map is, the worse the issue becomes.

Um...Gflex, for awhile I've been mentioning how we would still be capable of stripping away levels to view stuff (e.g. Xcom); another option could be to do like Age of Empires 2 did and have outlines of stuff occluded by walls/trees/etc.

[Jifodus]

A second question of mine would be whether or not this should be expanded to give each square's x- and y-based layering as well, to be completely fair to those of us that are huge fans of these under-represented dimensions. This would result in 7^3 = 343 Intuitively Derived and Described Material Cubes(TM) per tile, giving us quite a handy tool for quickly reading a tile's most important characteristics, and allowing for more accurately represented rounded corners. Of course, one could ask if this would be too much to store in memory, but really, if you do out the math, it would only give us around 6,303,744 more bits per mapsquare per z-level. On my current map of 9s x 9s x 89-z, this would be only 45443690496 extra bits!  That's only ~5.3 GB, and anyone that doesn't have at least 12GB of RAM on their Dwarf Fortress computer is an undedicated coward and should be made into mittens post haste.

7^3 is incorrect. It'll just require 3 bits (8 possible values), however you'll want to align it to 32-bits, and you'll only loose 2 bits in the process. You'll gain ten x/7 levels, which is definitely more than necessary. 4 extra bytes in a 9x9x89 (144x144x89 tiles) map would be another 1.76MB.

My only question to all of this is: Do you want DF to spend more time figuring out how to draw the map or running the game?

[Mike Mayday]

Sarcasm detector OFF

[Tormy]

Sarcasm detector OFF

Come on Mike, tell us what you had in mind! [Btw it's nice to see you around again.] 

[Mike Mayday]

Well, seeing Jif's last question made me think that he didn't detect the sarcasm in Novocaine's "suggestion".

And... uh... thanks

[Tormy]

Well, seeing Jif's last question made me think that he didn't detect the sarcasm in Novocaine's "suggestion".

And... uh... thanks

Ah heh. 

[Pi]

I... I firmly believe that MRI slices are the best way to view internal 3d detail on a 2d screen.

[Jifodus]

Well, seeing Jif's last question made me think that he didn't detect the sarcasm in Novocaine's "suggestion".

And... uh... thanks

That question actually wasn't directed at Novocaine, only the math part was.

My question was actually directed at everyone who's wanting an isometric/3D view of their fortresses. I'll say that an isometric view looks better, but it'll take much more processing time to determine the cleanest way to draw it.

I guess I didn't make the transition clear enough. Oh well.