Friday, April 8, 2011

pre-alpha-2 – 2 – I like to move it

The polishing saga continues, but just to have some content I added one small but useful new feature. But I am only going to talk about it by the end. That's how I roll.

I went over major parts, refactoring left and right. There is still lots to do, but most of the 3D refactoring of coordinates is done. Except for floor actions. Floors are kind of awkwardly implemented and I need to find a new way to do that first.

Such major refining will unavoidably modify the total number of lines of code. How much of a difference does it make? I don't have the exact number, but it is at least 1000-1200 lines of code. But not up, down. Right now the project has about 1200 less lines of code, even with the new feature and the number will continue to decrease for a while. Same functionality, only much more robust and better structured. This is normally a good thing, but I am not that enthusiastic about it. I am known as normally a quality over quantity coder, as in I tend to write short and powerful pieces of code that tend to be a lot shorter than in someone else's hands if I am allowed to code in my style and with the tools of my choosing. I am always happy when I can reduce the number of lines of code and improve the quality at the same time. But not this time. A lot of people have a knee jerk reaction: quality and feature completeness is equivalent to the number of lines of code. It would be a lot easier to gain credibility if I had a large code base in the beginning that slowly increases. So I won't get such conversations:
"So, I heard you are working on Dwarf Fortress clone?"
"No, it is not a clone, it is..."
"Cool, how many lines of code have you written?"
So the new feature is moving! Often you want to move an object from a position to another. There are some implicit forms of movement, like hauling to stockpiles, that do not count as moving. I mean more explicit forms of moving, where you choose the source and destination square and issue an explicit move order. The obvious example is when you move around a chair, but another example is when taking a bed from a stockpile or not and putting it in a room. This is called the placing operation. In DF, after you build a bed, you need to press 'b' to open up the building menu, press 'b' again for beds, choose the location and press enter. This will move your bed to that location and mark it a "constructed" or rooted in place so it will not be hauled away. In the future I might allow you to move something from the item browser, but for now I have condensed all move operations into one: you select two points, the source and the destination. One must be empty, the other must contain something. And then you select the move command and that's it. This is used for normal moving and also rooting stuff into place so they effectively become part of a room.

There are a lot of details that I still need to figure out. What if you select two squares that both have content and select move. Right now that does not cause an action, but maybe it should swap the content of the two cells? Right now you can even select a plant. Moving a plant is actually replanting it a new location. I think that this is better than adding a new option for replanting an item. But maybe there should be some limits. I'm sure plants don't like to be moved around that much. Selecting a square with a stockpile will move both the content and the stockpile. Maybe it should only move the content. There are arguments for both versions.

Here is a video showing the move action, because movement is best described by seeing the movement:

I gave a short description of the pre-alpha progress and described the new feature. So why am I still talking? Oh yeah, that's right. It is rant time!

Let me talk about stockpiles a little. Now this genre of games is very underrepresented. There are few games if any and one of my goals is to change that. But for such an underrepresented genre it still has its fair share of tropes and stockpiles are not an exception.

Let me list some common features of stockpiles and tell if you've heard of them before. Even better, tell me if you agree that they don't make any sense logically speaking:
  • Stockpiles are magical entities that allow your characters to see things right in front of them. Have you ever encountered The Situation™ where you can't use an item because it is not in a stockpile? You cut down or produce something, an industry need is, but you can't use it until it is placed in a stockpile. While this is silly, I do get how it has come to this. Picking up stuff from a very specific space with fixed properties is a lot easier than picking up stuff from random locations. I mean coding it is easier. I'll have non of this nonsense in DwarvesH. As long as you have the resource, you can use it. Stockpiles are a tools, not a requirement.
  • Stockpiles can only hold one item. So in one stockpile cell you have a mouse liver, and in another one a huge block of rock. both are full and can't accept more items. But if you bring a box or cabinet to a stockpile, it can hold more livers. Probably 20. This is again silly. In DwarvesH you will be able to pack the same amount of items in stockpiles with or without a container. This does cause the problem that containers turn out to be largely cosmetic. But I can still give some bonuses to stockpile accessing in time and things in a container can last longer. I'm sure your mountain of crafts that is lumped together on the ground is harder to access selectively and more detrimental to each craft when compared to the same amount of items arranged orderly on a shelf.
  • I am sure there was a third and equally silly limitation that I just can't remember right now.
Eliminating these limitations also makes stockpiles harder to manage. To compensate for this, I'll change the type of stockpiles dynamically. If you fill up a square from your furniture stockpile with chairs, it will change from a general furniture stockpile to a chair stockpile and will only accept chairs until you move all the chairs out. I do not consider this a limitation as the ones above. It is a helpful tool, that is worth so much more with graphics when you can actually tell with a glance that you furniture stockpile has a square with chairs, one with table and one with beds. Not counting problems caused by the isometric engine where high cells cover other cells, you will even be able to count the chairs in that given square, again just by looking at it. Of course, you can click on it to get information that might not be available visually.


  1. Anonymous (okay it was me) posted a comment a while back in this thread regarding stockpiles
    I always thought it would be cool if DF acted like each dwarf was not all knowing, with each dwarf psychically and magically knowing where each item in the fortress is.

    the "bookkeeper" task could have a dwarf actually go from stockpile to stockpile, and then update a "register" in a designated location (or more than one designated location).

    If a dwarf needs an item, he would go check the workshop that produced that item, and the corresponding stockpile (say a workshop can be "tied" to one specific stockpile. . . more on this in a second.) If the stockpile is empty, he'd go check the register. If the register did not show an item, he'd assume the bookkeeper has not updated the information yet, and then check in each appropriate stockpile for the item he needs. When he determines an item is not in the fortress, he'll make a notation in the register, a flag will appear for the USER, and the task will be suspended.

    As far as a workshop-stockpile relationship, how about allowing a stockpile to be corresponded directly to a workshop, as both an inbound and outbound area for that shop. This would be optional, but if you have designated a workshop-stockpile relationship, the dwarf will use materials located in that stockpile before wandering the fortress, and also will deposit constructed items into the designated pile after construction.

    Thus, if you wanted to make an oak table, use the described "move" command to move an oak log to a workshops stockpile, and then tell the workshop to make a table.

    As an alternative to a bookkeeper, you could have an option to have Dwarves individually update the register with every move task. this would take up time, but sometimes slowing stuff down is a good thing.

  2. Also, to address the questions in your post, a "container" could make searching for an item faster, in addition to making the bookkeepers job much easier and faster.

    Imagine a dwarf angrily flipping through a cluttered bin looking for a featherwood toy boat...


  3. To Anonymous:

    That is an interesting idea, but before I could do something like this I would have to create a new time compressor. Currently it is very detrimental to make dwarves walk, so I try to make them walk as little as possible.

    I am designing in my head a new compressor that makes time go a little bit slower, making long jobs take longer in real time, so they are more manageable and more forgiving when you forget to issue enough orders and end up wasting a lot of potential productivity and which will make walking faster. Then implementing a register would be possible, even having a dwarf who has only on responsibility: updating the register.