Print

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

[Ciehoo]

Then you know how a 16x16 pixel texture would look when zoomed in?

They look awesome.  I'm serious.  Don't have time for anything more than this hit-and-run post now, but I'll be back.

The only game i can think about, which used flat, low res sprites at 1024x768 is Darwinia. And they used colour to distinguish the units from dark, uniform backgrounds.

Even if we'd use them without any blending (nearest point sampling), which would give the game a stylised look, but make the objects recognizable, at longer distances they would fail to convey the information they are meant to convey.

Additionally, assuming the terrain would be made of real-color blocks, the objects might start blending in with their backgrounds. Of course, white dwarf icon, on an obsidian floor would be crisp and sharp, but the same white dwarf icon on sand, would disappear.

Now, it could be solved by making the color of the icon complementary to it's backgrounds, or even use some more advanced algorithms, to allow the sprites to stay visible regardless of their background, but this would produce a huge overhead, as the screen would need to be analysed pixel by pixel, each frame.

As I said, everything you imagine can be done, but I'm not that keen on it. Additionally it provides a nice segue to this:

But really, throwing it onto sourceforge or anywhere else will do the project much more good than just choosing a successor.

As seen in this discussion, a successor is necessary, even if the code is to be open sourced. Someone has to have control, and the final say of the things that go into the code. Otherwise the various ideas will dilute the resources, and lead nowhere, as each participant will pull the project in his/hers personal direction.

And if I'm going to manage the open-sourced project (which I would hate to be forced to do), I'm propably not going to mainline using sprites, barring a demo, which would dispel my objections.

[Footkerchief]

Even if we'd use them without any blending (nearest point sampling), which would give the game a stylised look, but make the objects recognizable, at longer distances they would fail to convey the information they are meant to convey.

That's kind of how distances work.  Would models fare any better?

Additionally, assuming the terrain would be made of real-color blocks, the objects might start blending in with their backgrounds. Of course, white dwarf icon, on an obsidian floor would be crisp and sharp, but the same white dwarf icon on sand, would disappear.

That totally depends on the sand tile.  Plus, if you're using a creature graphics pack, dwarves won't be any single color anyway.  Plus, it makes sense for some items to blend in with their background.

[Sean Mirrsen]

Well, for a 3D game with sprites (of course, they are larger sprites) there's Rangarok Online.

Something closer to what we'd have here (and in a first-person perspective) is Ivan3D, a recompilation of Ivan into a Duke Nukem-esque first person slasher, using only existing game resources. Sure, it doesn't look as good as you'd want this one to look (it doesn't have a Z axis, for one), probably about a 4 by your scale, but it's surely not mindwarpingly ugly.

So, to recap:

3D models:
 Pros: look good, allow universal animations
 Cons: more resource intensive, models and textures would be required for each individual creature which isn't all that easy, little room for modding.

Sprites:
 Pros: Easy to utilize and readily available, WCS can be replaced with ASCII graphics for a unique look. Do not create a mess if piled into a cramped space.
 Cons: Less scalable, less detail up close, generally more effort required to create a good sprite compared to a model.

(note: WCS=Worst Case Scenario)

[Ciehoo]

Even if we'd use them without any blending (nearest point sampling), which would give the game a stylised look, but make the objects recognizable, at longer distances they would fail to convey the information they are meant to convey.

That's kind of how distances work.  Would models fare any better?

yes, if they would have unique colour patterns, and not be easily mistakable with other objects/animals/characters. That's the way the eye works. It looks for distinguishing patterns. It might "combine" different sprites into one tracked object, leading to confusion (you might start to follow a cat with your eye, when before you were tracking an enemy)

Additionally, assuming the terrain would be made of real-color blocks, the objects might start blending in with their backgrounds. Of course, white dwarf icon, on an obsidian floor would be crisp and sharp, but the same white dwarf icon on sand, would disappear.

That totally depends on the sand tile.  Plus, if you're using a creature graphics pack, dwarves won't be any single color anyway.  Plus, it makes sense for some items to blend in with their background.

For the player, no items should blend with the background, except when the game designer (in this case Toady) has defined them as invisible/stealthed etc. The graphics packs have been designed to fit mostly a black bacground, which means they won't be as clear to spot as 3d models.

[Ciehoo]

So, to recap:

3D models:
 Pros: look good, allow universal animations
 Cons: more resource intensive, models and textures would be required for each individual creature which isn't all that easy, little room for modding.

To add to the pros: more room for expansion, when hardware and resources allow, easier to fit into a "nicer looking" 3d environment.
You provided all significant cons, but I have a few points about them:
Resource intensive: yes, definetly more than 16x16 tiles.
models+textures: again yes, but not as bad as it might seem. I could create+animate+texture a low polygon humanoid in a single weekend. Granted it won't be pretty, but I'm not an artist.

Sprites:
 Pros: Easy to utilize and readily available, WCS can be replaced with ASCII graphics for a unique look. Do not create a mess if piled into a cramped space.
 Cons: Less scalable, less detail up close, generally more effort required to create a good sprite compared to a model.

I wouldn't agree with not creating a mess, when cramped in a tight space. all the cases I can imagine look confusing.
as for more effort... well that puts them at the same level as models doesn't it?

Something closer to what we'd have here (and in a first-person perspective) is Ivan3D, a recompilation of Ivan into a Duke Nukem-esque first person slasher, using only existing game resources. Sure, it doesn't look as good as you'd want this one to look (it doesn't have a Z axis, for one), probably about a 4 by your scale, but it's surely not mindwarpingly ugly.

Well, to be honest, if that's a 4, then I'm aiming for 8-9. Well it seems I'm too spoiled for good graphics.

Ciehoo

[Sean Mirrsen]

About the difference in the effort required to create sprites - we have sprites for just about everything already available - and we'd have to create all the separate models if we wanted to go that route. Don't forget we still need to discern all possible professions, which means 100+ models for every major race, plus the ridiculous number of creatures (and gibbons) to model.

You know, I would understand the 3D models if you used procedurals - but we'd need something to arrange the bodyparts properly, like some generic build charts.

About "not creating a mess" - a bunch of 3D models stuck into a small space will clip each other and form an indiscernible mass. A bunch of sprites huddled together always have a definite order to them, and overlap cleanly instead of intersecting.

I don't have a definite scale to judge graphics by, but I usually prefer good-styled graphics over technologically advanced ones. The tiles and sprites made for DF give it a proper 'feel', while 3D models would very likely fail with that.

[Sergius]

I just wanted to point out that I think some of the graphic pack artists have made really big samples of their work (like 64x64 dwarves or so, maybe bigger). If there are enough of them we could have big sprites.

Remember that old 2.5D games had flat sprites. Some even allowed you to look up or down somewhat and corrected the sprite perspectives accordingly.

If anyone has played the full 3D opengl versions of DooM, you'll notice that someone has made full 3D model packs for them. The flat sprites look 100 times better. Of course it's 'cause the 3D models themselves are FUgly, they don't have to be.

[Ciehoo]

I've updated the main post with a patch.

[Zaloran]

Dwarf Fortress Canīt be played in 3D. The surroundings of the fortress can be represented in 3D, but the game canīt be actually played in a full 3D engine. So please, letīs keep that wonderfull ASCII, wich gives more information than any 3D tile.

It would not be dwarf fortress any more.

[Overkill]

If you go down the path of 3d models, i could pitch in to help from time to time (im working on alot of other projects)

[monolar]

Dwarf Fortress Canīt be played in 3D. The surroundings of the fortress can be represented in 3D, but the game canīt be actually played in a full 3D engine. So please, letīs keep that wonderfull ASCII, wich gives more information than any 3D tile.

It would not be dwarf fortress any more.

Hogwash. Dwarf fortress is not about being ASCII (it isn't pure ASCII anyway ) but about the depth of gameplay. To date and the foreseeable future this meant not concentrating on graphics or interface. But Dwarf Fortress could be entirely playable in a full 3d engine. Granted certain things could not be displayed currently incl. things like e.g. in which direction a furniture faces.

A 3d engine would implicitely allow a top-down view and if done corrently it could be used for iso projections or cavalier projections (or somesuch). And since it's already there i don't see the "ascii" interface going anywhere so this would still be an option.

I think what is useful, and some people are doing this, is producing mockups and discussing about which approach has which advantages. So i see this little gem in the thread here a wonderful exploratory spike for alternative interfaces.

[Sean Mirrsen]

Well, it still uses the original DF window for control (though if it'll be possible to bring the entire game through, it'll work great). Bringing the interface into 3D will mean that there will have to be features not present in the game - like complete mouse control. I can already imagine some of the workarounds for that, but really that's a lot of work for something that'll likely be lost with the next version. We'll eventually have to create the whole shell for the game, from menus to individual controls and such, but some things will never be possible - like orienting furniture, because the game itself doesn't keep track of it.

[Sergius]

Here's a 3D model question (poll?):

If you had to model a big beast, say a giant or a dragon, would you rather:

- Make it regular tile-sized (same size as a dwarf)
- Make all "small" creatures take only a small fraction of a tile.
- Make the big beast bigger than a tile (even if it causes clipping into walls).

I'm leaning a bit toward the third one, but it can get ugly in narrow tunnels.

[monolar]

Well obviously option 3 would be really unwise.

For creature sizes we would need some norm size that offers space downwards and upwards. Since additional to creature a lot of other things can be on one tile i think an approach like currently in df (the rotating cursor thingy) would probably be great. Since we do not have enough information on creature placement in one tile we should not try to guess it i think.

Later on some smart other approach could help there and also with aspects like furniture orientation. Basically we would need to expand the information already present in the df data with display relevant information that can be a) automatically generated or b) user defined or c) both.
E.g. the orientation of a cabinet could be calculated once to be reasonable (align with wall whichever direction applies first: N->E->S->W, if no wall present it would align N). If the user would be unhappy with this he could override it in a menu that annotates the cabinet for display only purpose. The only remaining aspect is removing/cleaning/dirtying those data structures (though not trivial i dont see any troubles there).

[Sean Mirrsen]

The trouble is with keeping the data. As in, saving and loading the fort. I can see a chair being rotated towards the table that is used by the dwarf on the chair, but there's no way to preserve that data in a DF save unless the game has a way to store this information.

As for sizes - make it so only size 20 and up creatures fill the entirety of the cell, with any possible clipping/overlapping issues with multiple such creatures handwaved into oblivion. Smaller creatures would be respectively smaller, though not on a completely realistic scale - only enough to get a sense of a "big goddamn creature" in relation to a dwarf. A dwarf will likely be occupying a quarter of a cell at most, more likely a sixth.