Print

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

That's right

That is right

[strich]

IMO you either do 1 sprite per creature or you go all out and do simple 3D iso. I really think it is a waste of time doing some complex in-between 2D system. It'd be less work in the long run.

If you ask me, it doesn't look right to see a dwarf walking backwards.  And real time does seem to be something people want this in.

You're missing my point - If you want real-time movement in this thing then you'll want to move to 3D. Making 3D models would be less time consuming in the long run and open up the door for future additions such as animation.

And please let me reiterate - I'm all for 2D sprite-based just so we can finally get a decent GUI and framework out there. But if you're looking at adding all this extra stuff such as sprite flipping and direction, etc. You would be better served going straight to 3D.

[LegoLord]

Right, I'm just saying it'd be nice if they could also face the right way.  And somehow, I think flipping a few sprites wouldn't take as much memory as dealing with all the polygons in a 3D program, but eh.  I barely have enough RAM to use most 3D visualizers, while this works fine as long as I don't have the draw distance set insanely high.

[IDreamOfGiniCoefficient]

My take on an uni omnidirectional archery target.

[CobaltKobold]

Well, you'll probably want to draw the backward one too (mirroring takes care of other two cases)- as the building will know, when it's a room, which way it's facing.ignore my foolish reading of unidirectional as unidirectional.

Good omnidirectional target.

[Bricks]

I think the 3D models should be left to Khazad and the like.  This has a distinct sprite style to it.

General praise, general praise, prayers that Toady supports something like this in the future, etc.

[Octopusfluff]

There's a few different points here to consider..
First: It is true that with well defined low-poly low-detail models, you can end up with a huge savings in total ram/storage requirements versus a lot of sprites. Even if you're making heavy use of horizontal flipping, you still need five sprites per character per frame of animation..

Even if you are EXTREMELY sparse with frames of animation, you're still looking at a minimum of two frames per action, with quite a number of actions. Even if you only bother with movement and attacking, that's 20 frames per creature shape. If you're also differentiating creatures by job, as is traditional, that's.. a lot.

You can skimp on a lot of this with clever texturing (making use of palette shifts), but it's still a lot. This adds up both in storage requirements, active memory use, and raw effort.

However, second: The barrier for entry to produce acceptable quality 2d sprites is MUCH lower, as far more people can create or edit a bitmap than can produce decent 3d sprites. Additionally, given the low resolution involved, the practical cost of a donkeyton of sprites is pretty low; you could fit full spritesheets for a civilization in less room than a particularly high quality skin for a 3d model in a current gen shooter.

Third: The technical requirements on the engine side are different. This engine is pretty clearly built assuming 2d, and adding 3d support for movable entities looks like it'd be extremely nontrivial, ultimately making it better to implement such 3d entity sets in other projects that are already 3d.

Fourth: Style, yeah. A 3d creature would look EXCEEDINGLY out of place with the wall/floor tiles in use, and the retro appearance we have here is... somehow fitting, given the even MORE retro core interface.

Getting a fully complete set of frames for every entity, with decent animation, is a huge task... but far from cost ineffective, and decidedly worthwhile, given the exceptionally approachable feel Stonesense offers.

I suspect I could sell this to people as an interface even more readily than the more advanced 3d interfaces.


Oh, yes, hi. I just popped out of the woodwork to reply to DJDD, yes.

[kaypy]

My take on an uni omnidirectional archery target.

Eventually, we should be able to detect the orientation on buildings and so have multiple sprites. But in the meantime...

A developer has stolen an Archery Target!

[CobaltKobold]

Even if you are EXTREMELY sparse with frames of animation, you're still looking at a minimum of two frames per action, with quite a number of actions. Even if you only bother with movement and attacking, that's 20 frames per creature shape. If you're also differentiating creatures by job, as is traditional, that's.. a lot.

Getting a fully complete set of frames for every entity, with decent animation, is a huge task... but far from cost ineffective, and decidedly worthwhile, given the exceptionally approachable feel Stonesense offers.

There's a thread in which Mayday points out the middle ground where you can break sprites into components to get animation easier, by moving them and suchnot...where was it...there

[Solifuge]

Hi OctopusFluff, and welcome to the Fortressdome!

In regard to sprites and facing directions, there is nothing hardcoded that we can read (yet?) that tells us a unit's facing direction. I'm not certain any sort of facing direction is hardcoded at all, though I've heard of Backstabbing attacks... there may be some sort of hidden facing direction value, but so far it would be left to something like checking for whether or not each unit moved during the last tick, and where they moved to. This would add up with a screenfull of dwarves, critters, and potential sieges, and makes it significantly harder to keep it rendering in realtime.

The biggest problem is as follows, though: with the sheer number of creatures to draw sprites for, drawing even 5 directions and reversing 3 of them is a LOT of work; There are approximately 230 default creatures. That means you'd be asking for 1,150 sprites. If you add in skeletons, zombies, and corpses you end up with 3,450 sprites. On top of that, some of these critters can have have Professions, Training, and Children, which can also be zombies, skeletons, or corpses, which adds the potential for as many as 10,000 default sprites alone, or more.

As the primary artist working on this, I can tell you that this is not something I can do. Not unless you want to pay me wages and let me do it full-time. And if you were to do that, I'd much prefer the money went to Toady.

[CobaltKobold]

urf. So many things to place into time.

[kaypy]

Wagon concept


Will still be 'fun' breaking this into building chunks (for the starting wagon) and ***absolutely no idea*** how to make it work as a merchant wagon

[CobaltKobold]

Sounds like you need to draw it with four(two) facings. :p

On a practical note, you should possibly remember that 1. wagon-as-creature is probably stored differently than embark wagon-as-building
2. merch wagons are said to be in their center square
3. you could make the system support facing sprites, but not require them- default to one sprite if they're not filled in, say.

[Octopusfluff]

Hi OctopusFluff, and welcome to the Fortressdome!

Hello.

In regard to sprites and facing directions, <snip...>

As the primary artist working on this, I can tell you that this is not something I can do. Not unless you want to pay me wages and let me do it full-time. And if you were to do that, I'd much prefer the money went to Toady.

Oh, I know this is an absurd thing for one person to consider tackling. My post was mainly aimed at DJDD's comments.

There's a lot of potential shortcuts that can be taken, though, and with a community like this, the load has the potential to be distributed. I stand by the fact that this is a worthwhile thing to try to do, but by no means am I trying to assert that it's something that is easy or short-term.

Ah well.

In the meantime, I think I'll continue with testing my capacity to adhere to the core tenet of DF.

[kaypy]

With appropriately sized creature sprites, it may be possible to simulate riders just by draw the rider (found from the creature flags)

(a) after other creatures
(b) about 8-16 pixels higher (depends on ridee height- may need a sprite config option)

[forsaken1111]

Maybe it's just me, but is facing even necessary? I would be happy with simple sprites moving around, no animation or facing or anything. The sprites and visualization bring DF to a whole new level of awesome by themselves.