Having ‘done’ borders, I’m learning what I want. ‘Making App’ vs ‘Shipping App’. A bit of philosophy, a bit about why I write these words.

You’ve probably noticed that when we use some provided library code, at least some of it really doesn’t work the way we’d like. Often we have to bend and twist our own code to meet the needs of what’s provided. It’s always irritating, and, for me at least, it’s more irritating when the code that is making me torque like a pretzel is my own code.

Many, perhaps most, developers today are under high pressure to do more and more, faster and faster. They feel that they don’t have time to make things right, probably not even enough time to make things work. Been there, done that, and even though I know some things now that I didn’t know then, I’m not sure that I wouldn’t still end up without the time to make things right.

And yet … and yet … when we find ourselves writing the same sort of almost but not quite boilerplate code over and over, a little time spend making the code better could pay off in a net savings of time, and a bit less frustration.

Part of what I hope to communicate in the five million words on this site is that small changes that only take a few minutes can add up to a code base that is more flexible and lets us move faster than we otherwise would. I honestly don’t know how well these ideas would work in Real Life™, but I do know that if I lived in Real Life™, I would try to work much as I do here, as I believe it would let me go faster and I am certain it would let me work with more of a sense of confidence and accomplishment.

This concern for the tools we use to build the system is the core of GeePaw Hill’s notion of the “Making App” and “Shipping App”. In those terms, by making our Shipping App better, we have identified some serious needs in our Making App.

Let’s get down to cases, in particular what we’ve learned about our floor tiles from what we’ve done so far. Here’s a list just offhand: there is surely more to be concerned about.

  1. Our current set of tiles is incomplete and will be totally replaced by the new batch I bought a couple of days ago.
  2. The new tile set will still be incomplete. We’ll need to make at least some border tiles if not others.
  3. The tile filenames are no help at all, being called Tile (29).png and the like.
  4. There are two or three different styles of tiles, some looking like pavement, some like, well, mud.
  5. The same artist makes at least one other set of tiles that might be interesting.
  6. The textures representing things found in the dungeon seem to require a different scale than our floor tiles. (Just noticed this yesterday.)
  7. Selecting tiles for the 15 different possible borders is tedious and error-prone. Descriptive consistent file names might help.
  8. We use a random distribution of floor tiles. There might value to a similar random selection capability for borders as well. Currently there is just one possibility for any given border.
  9. We need some kind of asset system to help us.
  10. Loading a large number of assets from files takes time. We should probably only load assets that we need, perhaps in a lazy fashion to spread the delay over time.

I could go on. The point is, while we have a quite decent initial mapping of tiles to floor and borders, it’s clear that someone here is going to be doing that job again and again. The code we have makes that job difficult and error-prone. We need to improve our Making App.

In our little Dungeon project, we’re a very small team, and we almost always agree, since it’s just me and I really only have one personality that I’m aware of. It is but a small thing but it is mine own. But we can imagine a group of Dungeon Layout Engineers designing the many exciting rooms that a real product would need, and if they were each to spend too much time carefully choosing tiles and typing ‘Tile (3754).png’, they would probably rise up and rebel, and rightly so.

For the good of the overall project, there are times, many times, when improving the Making App is more important than improving the Shipping App, although I would always always always be sure to maintain a visible flow of Shipping App features.

For some of what is needed here, I think we can make pretty good decisions. I’m inclined to say that we should come to some agreement on asset names, and either rename the files to that scheme, or create a simple asset name to file name mapping table that would help. I’m inclined to think that the table approach will be better than renaming all the files, and perhaps even more flexible.

I’m inclined to think that the asset names should follow some naming convention that is easy enough for humans to type and use, and that the program can use as well. I think that we can do some quick changes that will make the tiling job easier, perhaps easier both for the person who chooses which tile goes where, and for the programmer who processes the tiling information and draws the dungeon.

My higher purpose will be to show how small improvements can help us go faster than we would without the improvements. And we’ll do that in the next article.

Summary

There is a need to improve what Hill calls the “Making App” as well as the “Shipping App”, and we will go forward with best speed and quality if we pay attention to both.