Small Delay

There’s a pretty long backlog of updates I need to get edited and posted out about the development process over the last six months, but dropping this short update in real time, because a lot of the copy says “releasing December 2020”, and that’s clearly in the rear-view now.

Sneak peek at the new look!

The goal was to launch the more open phase of public beta on the 17th of December, but in the weeks leading up to that, I had several great conversations with first one, then a second, incredible designers who were excited about the project and I was able to hire to take on the daunting role of cleaning up the visual garbage I’ve been subjecting early testers to and they started working through the screens, and have come up with some remarkable work, which they began implementing immediately.

With such a slick visual overhaul so close in the offing, it felt weird to arbitrarily ‘release’ with the old interface, when the new interface is so much clearer and inspiring for new players. So as soon as the new design starts rolling out to the server, I’ll be throwing the doors open for some more players!

Scary and exciting.

Starting Locations

One challenge with the old build of the game was instantiating ‘new stars’ for a new player to call home when joining the game. As a designer, you want them to have a little bit of a platform from which they can step up and take on the other players who have been playing a while, and have expanded out among the stars. But how to do that in a way that seems even remotely fair? The first time around, I used an algorithm to choose where the new player’s star would be placed, called the Archimedes Spiral. It took as input the number of previously-registered players, and made a somewhat galaxy-shaped spiral, expanding outward from a ‘galactic center’. But issues arose when it became more and more apparent that the stars were too close together, and there weren’t a lot of “other places” for a player to check out that weren’t already someone else’s homeworld. I could have tuned parameters of the spiral, but ultimately, the new stars were always appearing in a predictable pattern, so an experienced player could camp the end of the spiral arm with a Shipyard or a few heavy warships and make a quick PK on a new player as soon as they joined.

Mostly, I’m attempting to make the first pass at development a 1:1 replacement Ruby for Python and Rails for Django, but this was one area that I knew would be a problem as soon as beta testing began, so I chose to take on the challenge of re-imagining this as I rebuilt the new onboarding path.

This is an issue that has been gnawing at me ever since I put this game away 10 years ago (probably second-only to concocting ways of ‘rubber banding’ the exponential growth advantage of players who joined before you), so I had some ideas on how I might approach it.

Read More

Rolling Dice

Between working on Galactic Impact the first time in the late 20-aughts and today, I’ve done a lot more board gaming than video gaming, and that’s also where the bulk of my ‘game design’ brain has been. Comparing that world with video games is an interesting exercise, especially because there’s a lot of conversation about “app integrations” on the board game front these days.

This all came to mind as I was dove in to rebuilding “population growth” for Player’s “Worlds” in Galactic Impact. In the old version I did a blanket percentage growth calculation — for example, if the target was 1% growth, multiply the population by 1.01, save that as a the new population and call it a day. Got the job done, but was completely deterministic, which is somewhat unrealistic for population growth. (Also unrealistic when using that same calculation to determine the numbrer of deaths on account of hostile atmospheres).

Read More

Evolving 4X Terminology

It’s a core belief of mine that language is important — after all, if you and a listener don’t have a common language of some kind, you can’t communicate — so as I’ve been rebuilding Galactic Impact, I keep being struck by the word “Colony” everywhere in this type of game (Sending Colonists to another world… to Colonize that world when they arrive…).

Without doubt, the term is common parlance when we talk about setting up permanent human habitation on worlds in outer space, “a Moon colony”, “a Mars colony”, and beyond. In fact, NASA has entire articles about it. But in reality it’s a term rooted in a really horrific period of human history. It doesn’t often get this framing in History classes in the U.S., but Colonialism was a seriously fucked up era when entitled European empires showed up on foreign shores to kill, loot, and occupy as they saw fit. These actions redrew the map and world affairs in ways that are still visible four hundred years later, and lots of people around the world are still experiencing the negative downstream effects.

Read More

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.

Read More

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.

Read More

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.

Read More

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)

Read More

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.

Read More