Template tags and partials

So the first big difference I’m running into between the Old Way (Django) and the New Way (Rails), is that Django uses a templating tool like handlebars or mustache (I’m not sure how to tell which from what I’m seeing in the code here), which has the nice effect of really forcing the developer to separate the logic from the view.

Note: Django’s pattern looks more like Model-View-Template in practice, because what a Raisld eveloper would call a Controller, Django calls a “View” which then renders a template, rather than a Rails Controller/Action rendering a View Template.

Using Django templatetags

The challenge is, that in order to force this strong separation of concerns, when a developer (me) wants to render something more complex in Django, it’s necessary to define a custom ‘tag‘ or a ‘filter‘ that the templating engine can then load and use. In the world of “basically all programming languages do the same thing“, this is really pretty equivalent in outcome to a Rails ‘partial‘, though the latter doesn’t offer any guardrails to prevent the commingling of logic and display, which can be a problem for debugging. But a sawzall doesn’t prevent one from cutting through a power line either… doesn’t make it less awesome of a tool. The user just needs to be cognizant of what they’re doing.

Data Driven Design and Component Architecture

Oh shit, I got access to the old database. Not really a surprise, but as I’ve been digging through models, I realize that I’d done a lot of things well (even this long ago!) by using data-driven design, such that they could be modified on the fly, for example if populations were getting out of control, or mines didn’t seem to be turning enough ore to resource or whatever, the ratios that drive those economies could be changed with a database value in a table called “UniversalConstants” — a notion I later carried over into Terraformist. Also, the ShipDesigns, the different classes of ships that could be built But as I’ve been starting the process of rebuilding the model classes, I’ve had this nagging worry that some of that was going to be missing or lost. But it’s not! Sweet.

Perhaps surprisingly in 2020, Data Driven Design was somewhat of a newish concept back in 2009 (or at least it felt like it), and not something everyone was doing in game design, but I had a friend and early biz partner Paul who was really keen on the idea, and had forced me to read a paper on the topic the year we attempted to found a gaming studio in 2005.

Let there be stars

Yesterday, I went through some of the basic object modeling — Stars, Planets, and some classification systems for both of those things. The Star classifications are loosely taken from the Hertzsprung-Russel diagram, and will give the map a bit of color by having the Stars show up differently, maybe down the road these will have various impacts on their planets’ resource generation. The Planets each have an “atmosphere type”, one of several arbitrarily chosen gasses, which can have major impacts on how suitable they are for living on, or for setting up resource extraction.

Kicking off

Normally, when I’m leading an engineering team, or consulting for one, I’m always firmly in the camp of avoiding a full re-write of your codebase. If you’ve got a functioning product, and customers, you just can’t press pause on development there, leaving current customers without bug fixes or improvements while the team spends 6-12 months rewriting everything from scratch… But I digress. Luckily(!?) in this case I don’t have a functional system or any existing customers… just a dusty codebase. In fact, I did a little infrastructural work this weekend, just trying to power some things on, I got a warning that a component I was using was deprecated… not that uncommon, generally, but this deprecation warning was SO OLD that the component it was recommending I upgrade to HAS ALSO SINCE BEEN DEPRECATED. That’s how old it is ????

(Cue joke about Arthur in Hitchhiker’s Guide searching for files in a disused lavatory)

Dawn of Rails

Twelve years ago, I was frustrated with the technology we were using at work, and I set out to learn something else that I’d been hearing about, and wanted to try, Django. Nothing guides a learning project like a target, so I set out to build a game in the style of the old classics Master of Orion, or more specifically Pax Imperia (for us Mac nerds), but generally a web-based multiplayer “eXplore, eXpand, eXploit, eXterminate” (4X) style game. In fact, the original title, before I settled on a name was fourx

So, bit at a time, I built up what I needed to make this happen — learning each piece of the framework as I needed it, and each, successively more complex need for the game lead to incrementally covering most of the framework.