Organic Towns - A Spreadsheet And More Thoughts On The Overlap Of Gaming and Software

In thinking through the complexities of using the Organic Towns book, I've decided to start with a spreadsheet (which in developer-speak means an application waiting to happen. Though for single use, a spreadsheet is both simple and effective and maybe all I really need)

By starting with a spreadsheet, I can sort of see and play with what kind of data I'll need. I even formatted it a bit...

Fortunately, I know enough about spreadsheets to help automate a few things. As each building has a column for various modifiers, and can summarize those for the various DMs for trade, defense and all that. I've even automated the SP (Settlement Points) based on the population and the various adjustments based on the housing.

=ROUND(SUM(0.1*RC[-4]+SUM(R[10]C[-5]:R[49]C[-5])), 0)

Gives me 10% of the population + all the SP modifiers, the rounds to the nearest whole number. This process informs me how I'd probably set up the database, if I were to do this as an application (and I just may. It is not like I keep starting and stopping personal projects...oh, wait, I do!)

As I see things in schema way too much, I see the big picture as a town is a name and the pertinent parts, then several associated records: history (notes for the various rolls), a join table to associate buildings with the town and what level they are at, and the base table for the buildings themselves and what they do at level I, II & III. If this were to be expanded further, I'd even pull out the benefits and costs to yet another table, allowing us to easily go to 11, err, I mean IV. 

Anyways, a rough back of the envelope schema for buildings, assuming we keep the levels built-in, would look like this:

1. id - primary key. used when we create a list of buildings for a town
2. name - House, Brewery, etc
3. pre-requisites - pretty vague and not really needed for functioning unless we turn this into an actual application or web site. which, hmm, maybe I should get in touch w/Headless Hydra and see if this is something they would like to see...I could do something on the side perhaps.

And in writing that out, realize I'd probably extract out the various costs into its own table as well, something like:

1. id - primary key
2. buildingID - foreign key to the building this belongs to
3. level - I, II, III (though probably 1, 2, 3)
4. SP adjustment
5. Crime adjustment
6. Defense addjustment
7. population adjustment
8. Moral adjustment

Anyway, as I think way too much about software and schema sometimes, that is one way of looking at this in case I decide to make an application of some sort for this.

And to bring this back to gaming terms, this is a fair amount of work for something the players don't really see too much of. And it is definitely overkill in many people's eyes. Traveller 5 has the MOARN principle (Map Only As Really Needed), software has YAGNI (You Ain't Going to Need It) as guiding principles: essentially saying do not over-engineer as you are wasting time and energy. As all of you know, I really like world building just for the sake of world-building: it is fun for me, so on the gaming side, it is not a waste of time or energy as it is an enjoyable process. In software, things get trickier. For personal projects, this is not an issue. But at work (and I will be starting to work again very soon as I've had 1 2! job offers so far and have to make a decision soon) this becomes someone else's time and money. And while I do get paid to think, I also get paid to produce a viable product that is actually used. Or at least help lead the team to do that.

Over the years, I've gained a fair amount of confidence about where I think things should be headed to. Both in running games and in designing software. However, games and real life are closely intertwined: just like no game plan survives contact with the players, software does not survive contact with real users. So, over-engineering in either case can lead to dead ends, bits and pieces that are not needed.

Which brings me to wonder: should I apply agile principles to my gaming? While several pieces I do agree with (the primary one of customer (aka player) satisfaction is of utmost importance). But, being an opinionated person, I don't agree 100% with all the principles. The agile method is designed to get things done fast with the least amount of overhead. But for longer-term projects and games, you do need some of that overhead, and the vision for the long-term game. 

As a probably final note, almost thinking about perhaps figuring a way to get some of these meandering posts to be more organized and brought to other internet publications. I may want to start another blog on the crossover of gaming and software development so that I don't bore my gaming readers with all of this. Just a thought that I may let swirl around in my head. I've a feeling that a lot of software developers also game, though most probably game via a console or computer game versus actually rolling the dice, so perhaps the overlap is not as much as I think. And as I read a fair number of posts from software "experts" wondering if I could do the same thing (and I know that more and more of those posts are actually AI generated now, so people are getting really lazy!), but seen through a slightly different lens. As per my meandering career, my educational path has also meandered a bit as I have both an ancient (1986) computer science degree as well as a slightly more recent masters in philosophy (1997). Admittedly most people an equally or even more varied life and career, but I do like to think I am somewhat unique, then realize that everyone is unique. And thank goodness for that!

And a Venn diagram of my world building. I think the overlap is even smaller...