I don’t like estimates in this world. Perhaps you do. If so, and you’re so inclined, pick up this challenge. I’ll tell you everything I know to help you.

I was thinking before getting up, as is my habit, and began thinking about how difficult it is to figure out how long it is to do even a single story in the Dungeon program (and most of the programs I’ve worked on in the past decades). It occurred to me to publish this story as an estimation challenge, for CFP and for any estimation proponent. I’ll write what we know about the story at this point, and the challenge is to estimate it, in some agreed dimension of your choice, CFP, story points (we’ll have to scale some, I imagine), ideal Jeffries days, or whatever unit you choose.

The story is:

Provide the ability for a Level Design Team Member to control the placing of Dungeon Objects, including monsters, player starting point, Loot-containing Decor items and the Loot they contain, and free-standing Loot items.

I’ll tell you here what I know about these items, and of course if anyone actually picks up the challenge, I’ll answer questions to the best of my ability. If answering those questions requires any substantial chunk of time, we’ll try to keep track in, say, half-hour chunks. After all, if estimation costs are high enough, we need to be aware of that.

Now I have read the blurbs about CFP, and the story is that trained CFP people all come very close to the same CFP score for the same problem, so that might mean that they don’t need to know most of what I know. But in any case, I’ll happily share what I know. I’m not sure how we’ll do that, perhaps some combination of Twitter and articles here. Maybe even emails, which we’ll agree I can publish as parts of articles.

But for now:

All About This Story

The program is a dungeon crawl game. There are Levels in the dungeon, as many as we want. Each Level is made up of Rooms, which are rectangular, with some lower and upper bounds on dimensions. Rooms are placed randomly at present, but there is the possibility of placing them intentionally. That is not part of this story, and should have no impact on it if and when we do it.

Rooms are essentially made up of rectangles of Floor Tiles. Objects can only be placed on Floor Tiles. There are other types of Tiles, such as Wall Tiles, and so on. The game handles those and we probably don’t need to be concerned about them in object placement, except that the Level Designers want to be able to specify whether a given Object is or is not adjacent to a wall. They would like to be able to specify whether or not the Object is or is not in a corner as well.

Rooms are identified by numbers. A related story might give the Rooms a name, which Level Designers could specify for their own convenience. It is likely that if we provide Room Names, the name should be accessible in the game, so that an Announcement could be made that you’ve entered the Temple of Deadly Death or whatever. This is outside of the current story, but programmers should take the possibility into account in designing the form of the Level Specification that is surely at the center of this story.

Rooms are connected by halls. In random dungeons, halls are drawn in horizontal and vertical segments connecting the centers of two rooms. Room 1 connects to Room 2, and so on. Because Rooms are placed randomly, halls may intersect other rooms in arbitrary ways as they are carved from Room x to Room y.

hallway from x to y intersects room z

The Floor Tiles of Rooms and halls are legitimate locations for placement of Dungeon Objects. At present there is no way to designate a hallway tile, and in fact no Decor or Loot objects are ever placed there. Spikes can and do occur in hallways. At this writing, I don’t remember quite how that’s done but I’m sure it’s done in a usable way.

Dungeon Objects include

  • Loot - an object representing some treasure. When encountered the treasure is given to the player and the object is removed from the Dungeon; there are a large number of different Loots.
  • Decor - an object representing a container, such as a jar, box, skeletal remains, or a chest. Decor can deal damage, which Level Designers need to be able to control, and may or may not contain a Loot. The Decor manages applying damage and showing the Loot when it is encountered; there are a large number of different Decor.
  • Monster - there are many different kinds of monsters. Level Designers want to control which monsters are on a given level, and where they start out. Monsters move on their own, according to one of a handful of strategies. Level Designers want to control which strategy a given monster uses, so that they can place nasty monsters near particular treasures and so on.
  • Player - there is one player, and she is a Dungeon Object. She presently starts at the center of Room 1. Level Designers need to be able to control her starting placement, as they would for any other Dungeon Object.
  • Spikes, Levers, Switches - there are a few special objects that interact. This capability is not complete, but the placement of these should follow the same pattern as all the other objects.

Control over placement needs to allow for specific placement of a single completely configured object. For example, a Skull Decor, containing a 6 point Health, poisoning the player when encountered, at position 4,5 in Room 8.

Naturally, it is not desirable to place most objects with this specificity. We need to provide, for example, a list of a few different types of Decor, a few different Loots, each with a range of points, a few different damage items, each of those attributes given a proportion, something like

15 instances of Skeletal Decor, Skull Decor, Vase Decor, Box Decor, in ratio 4,3,2,6, containing Health(3-7), Poison Cure, Rock, in ratio 3,1,1, placed randomly [except] in Rooms 5,6,7, 13.

The general approach of a Level Designer will be to choose a few specific Objects to be placed near each other (or far from each other), and then to specify the rest of the dungeon in a more open fashion as above. When the ratios are provided, they do not have to add up to the total number of items. They should just imply a ratio of one item to another, selected randomly.

We should probably also consider whether there should be placement without replacement from the pool of things, that is, place 3 Vases, 2 Boxes, 1 Chest. We’ll probably want to do this, so it should be designed into the system and estimated. We anticipate that it shouldn’t be much at all, a simple matter of working with the ratios …

We do anticipate a graphical tool for laying out a Level and placing items, but that tool will want to produce some textual description of the layout. The intent of this story is to define and implement that text description, which will be used directly by the Level Designers to define a Level.

So That’s All There Is To It

We just want a little textual description of the objects in the dungeon, with simple text control over their type, their attributes such as the power of a powerup, their numbers and their positioning, as to Room or Hall, near or far from Walls, and so on.

Then we want the program to accept that text description as the definition for a given level. Note that since we can specify things in ratios, we can create arbitrarily many levels with similar but unique characteristics.

The system should be changed so that the current level definitions, which are done in code, are instead driven by equivalent Level Descriptions, so that all level creation uses the same kind of descriptions and the same code.

The Challenge

The challenge is to take the estimation scheme of your personal preference and to estimate this medium-sized story. It’s obviously far smaller than the game, which has so far taken about 150 days of programming, at the pace we program here while writing an article that describes every line of code.

Ideally, the estimate should b able to be converted to time to implement the story, because what good are estimates if you can’t convert them to time and money?

I freely state that at this moment I have almost no idea how long it will take me to implement this story. I think I have in place all the most important preparations, having aligned the objects better, cleaned up how Decor and Loot work, and so on.

However, I have not designed the little text language, nor the overall code that will parse it and apply the language to the creation of things. And, because this is an incremental iterative effort, we will not produce such a design, nor even a more detailed spec, before beginning.

Our development method will be to choose an interesting sub-story, of a size we think we can do in a day or two, and do it. Doing it, we’ll discover what we like and don’t like about that first little bit, and we’ll choose the next thing to do in the light of the foregoing things. We will evolve code and design until our Level Design folks are satisfied with what we have, or until we decide that we’ve invested enough in this capability.

The latter is most likely: we’ll work on this until we all feel that we’ve spent enough time and money on it, and then move on to other Dungeon matters. Accordingly, we’ll try to work on the most valuable bits early, so as to maximize the value of what we produce.

The above will probably make estimation-oriented folx scream. How could we possibly work in such an ill-defined meandering way? It isn’t easy. Agile isn’t easy: it’s just simple.

We work on ill-defined problems. We use good developers who know the difference between good design and bad, good code and bad. We choose features that are most valuable. We get the program working and then make it better every day, working better and better. We release it to users often, so that they always have the best value in hand for the money and time we’ve spent. And when the next thing to do doesn’t seem worth it, we stop.

This seems random. But it isn’t. Quite the contrary, it is highly controlled, because we choose the most valuable next thing to do and integrate it into our working software.

In my view, the closer our effort comes to the ideal if iteratively and incrementally delivering the highest next value to our customers, the less it becomes possible to estimate it. We literally don’t know what we’ll do, though we have a huge pool of ideas for what we might do.

But I don’t like estimates in this world. Perhaps you do. If so, and you’re so inclined, pick up this challenge. I’ll tell you everything I know to help you.