Bay 12 Games Forum

around 10 times for me.

You CAN clear ground currently but the method is a bit ackward. Designate an area of ground as a stockpile, make it accept every type of item. Create another stockpile of similar size where you want the items to go, and give a transfer order.

All of the items in the first stockpile will be moved to the second one, which can be outside or in another convenient place. Since the first stockpile has a standing transfer order on it, anything added will not stay for long.

Its not foolproof, but its workable.

quote:

---

Originally posted by Tormy:
[QB]You also dont understand what me and some others are trying to tell you.

Now lets clear this up, because I am also messed up now regarding the DF "engine".
- What is this opengl based engine capable of? Can it use 16bit color image packs in the future?
- What is this 25x80 or whatever resolution stuff? I have played with  games in windowed 640x480 - 1280x1024 mode using the SAME tilesets, and there wasnt a problem ever. How come that if we change the window size in DF, the image packs are not working properly only in a given resolution?[QB]

---

Whao dont get me wrong, i have nothing against image packs. They just have a few problems that make them unsuitable for DF at the moment, namely:
1. Like i said, it invalidates some of the current indicator signs. A blue smiley face with a grey background is a mechanic lying prone for whatever reason. Same goes for an "L" which represents a lion.

Now if you replaced the sprite with the lion, you would have to add a seperate sprite for a prone lion. The problem is that the current game engine can not handle this. I asked Toady about something different awile ago and he said the current engine can not handle rendering objects on top of each other.

2. A picture has to convey a lot of information across. If you created a sprite of say... an elephant. You would need a seperate sprite for a prone elephant, wounded elephant, attacking elephant ect. To make each of these clear you need to make the sprites bigger and more detailed. The bigger the sprites, the bigger the game field has to be. It is currently rather small as it is.

In answer to your question. OpenGL can be used to do some crazy stuff, like run unreal tournament. However in regards to DF all it has to do is display a flat grid of tiles. From what i have read on this forum, the game needs a lot more code before it can do more complicated things.

I dont know exactly how the sprites work. But for the usual symbols the game looks at a picture, the smiley faces, wall symbols and such are all recorded in white on a pink background. When the game needs to display something, it picks that tile, makes the background transparent and assigns a colour to the symbol.

If you want a good example of a game in which the simple graphics add to the charm, look up Kingdom of Loathing. Its a browser game, no colour whatsoever, everything looks like it has been drawn with a black marker.

But dont discount it! The game is awesome because it has this unique atmosphere to it. Plus all the humor injected into it certainly helps. Playing it is like being in an acid trip, in black and white. I know thats an oxymoron, but i lack a better descriptor, just try it!  

[ August 14, 2007: Message edited by: Tamren ]

quote:

---

Originally posted by Core Xii:
<STRONG> The game will do that whether or not the flakes fall within the view. It's part of the simulation. And 'playing field' != 'view'.</STRONG>

---

No, weather and temperature can be toggled on and off in which case it will ignore such calculation entirely. If you turn off both you will notice a HUGE increase in performance and fps. It is most obvious in adventure mode when traveling overland on the main map. Its also very apparant if you have a slow walking speed because the computer must chug though multiple game cycles for every step that you take.

quote:

---

Originally posted by Core Xii:
<STRONG>For christ's sake, what is this, the '80s? You have a dedicated chip in your computer solely designed for that exact purpose. It doesn't matter if you blit 2000 images or 4000 images.

The only overhead of more tiles is DF having to iterate through more blocks. But I hardly imagine that's a strain.</STRONG>

---

Pfft, the only thing the graphics chip has to do in this game is display flat tiles composed of very few pixels. Anything in the game window will have at most, 2 polygons.  

The CPU is what tells the graphics card what to display and where. 1 Raindrop might not sound like much, but the computer has to calculate a LOT, and they drop everywhere.

The problem with showing more tiles is that it increases the amount of calculations that dwarf fortress needs to do. If you look at the river, all that wave action is generated by code, the processor has to crunch the numbers.

There are already an insane amount of calculations that DF has to do to handle stuff going on offscreen, if you say... tripled the amount of game field you view it would slow the game down to a crawl. My 2.4ghz processor can barely handle a 160 dwarf fortress without chugging as it is. And that is without multiple Z levels, water mechanics and what have you.

3d graphics would simply compound the problem, instead of a symbol you would need a 3d model, a texture to cover the mesh and animations for every action that character could do. That would increase the size of the game and make it run even slower. A 3d terrain viewer for planning and multi-level ranged combat would be nice, but having the game engine as full 3d would be a bit much.

what screen resolution are you using? there are options that let you change the scale of the game. The menus are pretty bad, no argument there but they are usable. Its something that will change down the road.

Does pumice leak? If so, it would be pretty easy to seal up with tar or resin or something.

Dunno if this applies but there is one bug that happens with weather turned on.

It seems that seeds that have been rained on are useless. So the farmer takes the seed to the plot and you get an error message. The seed just goes poof into thin air.

"It seems the forums don't support nested quotes so I had to edit a little for clarity."
-Yeah its kind of wierd. Most of the time i try to quote someone all i get is the last sentence of thier post. Which is why i end up doing this    :confused:

"I don't think that it should be an option, except in a mod."
-As of yet, we have no way of programming the methods of construction. We can mod in animals and change stats and the like, but that amount of moddability does not exist yet.

It does seem quite daunting on paper, but all of the stuff in my first post can be condensed into about 6 pictures. (which i plan to do later) In the actual game, it would not be more detailed than a set of numbers and symbols.

"You might have to do this in real life, but Dwarf Fortress is a game, and such details can be abstracted away."
-Well thats the thing, it IS abstracted already. You can do everything with a beam that you can do with a log. Beams are not mandatory in any way, but if you put in a bit more effort into making the beam out of a log, you get a piece of wood that is more suited to certain jobs. Say you needed to do a right angle joint. Got nothing but logs? no problem, you simply have to square the tips so that they fit together. In game terms this means you end up with some scrap wood and another job gets added to the process.

If you had used beams instead, all the work is done quickly and efficiently back at the sawmill. There is no extra work needed so you attach the beams and your done. Saving a bit of time here could be very important in a siege or a disaster of some sort. Like i said before, beams and logs are better are certain uses, but are for the most part, interchangeable.

"You could implement a system like this and have the dwarves automatically make the bits you need, but if you do there's no difference to the player between this and generic lumber units, making implementing the feature a waste of time. "
- I think you missed the point. Right now 1 tree = 1 piece of wood. If you simplify the new system you end up with 1 tree = 10 pieces of wood. That is still a great improvement. However, you still end up with the situation that 1 piece of wood = 1 piece or charcoal or 3 mugs. There is no actual improvement in efficiency, just the availability of raw materials.

Under the new system, it divides wood into different shapes and tracks the "leftover" wood and lets you use it. In the average game, most wood harvested is simply burned for a miriad of reasons. If you could collect the scrap wood generated from other jobs and burned it for fuel, you need far less wood in total.

Because of this, a thriving carpentry industry could supply your charcoal makers. Who would then in turn supply your steelmakers with charcoal. Otherwise the system becomes your standard cookie cutter RTS in which "carpentry used 10 pieces of wood today, Charcoal makers used up 12 pieces of wood today, Steelmakers used 8 pieces of wood today". Its much more satisfying to build and maintain a working economy than it is to hear "you must cut down 30 trees today"

"If you did implement it, but left everything manual, you'd end up with a terrible headache of a mess where you have to constantly refer to the wiki to figure out what you need to make every bit of wooden furniture, and new players would quit the game and never come back."
-The flexibility of the system ensures that would never happen. I could make a bed with a couple planks, or i could use rounds and firewood. I could even cut a log in half and make a bed that way too! It would be up to the player to decide what they want to make, and out of what material. Instead of "a bed requires 4 wood" the player could experiment to discover what works best with the cuts of wood they have access to.

The finished product would also differ a lot depending on what you use. 2 planks makes your typical chair, 4 legs and a back right? Well if you used 1 plank and a tree round instead, you could make a bar stool. The difference between the two, is that you can get on the stool from every angle, and the chair can only be sat on from 3 sides. You might think of this as irrelevant, but for some people it is more entertaining to know that my bar actually HAS bar stools instead of generic oak chairs#74-82. This could even carry over to adventure mode. A bar stool used as a club is less ackward than a 4 legged chair used the same way.

"On a final note, if you did implement this system in some form, the other industries would look very simple in comparison, prompting a redesign of their workings and aggravating the problems listed above."
-Frankly? They had it coming. And new problems only means new solutions.

[ August 11, 2007: Message edited by: Tamren ]

[ August 11, 2007: Message edited by: Tamren ]