Monthly Archives: April 2020

Pax Nova

A game that has been on my radar screen for a while, Pax Nova, just came out of Early Access on Steam. Given my current interest in developing an engine for 4X games (among other genres) with Digero, I thought it was worth trying out.

I haven’t played the game long enough to give a full-on review, but I thought I would try to situate it within the larger space of current and former 4X games I have more experience with. Pax Nova is an interesting and ambitious title, and I’m hoping that the gameplay holds up as I progress through my first playthrough. We’ll see.

Pax Nova in action (image taken from here)

Pax Nova is/was developed by a small company out of Portugal called Grey Wolf Entertainment. Grey Wolf’s previous game was also a 4X, entitled Dawn of Andromeda. That game was…okay. Really, it wasn’t bad at all, and was a very competent real-time space-based 4X. Unfortunately, the real-time 4X space genre was already occupied by strategy giant Paradox Entertainment’s Stellaris. So DoA really flew under the radar. Still, if you’re something of a 4X completionist, it’s worth checking out.

Pax Nova is a much more ambitious title than DoA, however. While it has retained the space-based strategy component, albeit now in a turn-based format, Pax also focuses on planetside civilization development. This means that it combines the planetside play of a game like Civilization: Beyond Earth, with the space-wide strategy of a title like Galactic Civilizations. As such, unlike with DoA, Pax is charting a unique course among contemporary 4X titles. While Sid Meier’s Starships tried to connect up with Beyond Earth, as least in terms of lore, it was still a completely separate title, and a rather bare-bones effort as space strategy. Pax promises to fully combine the two theatres.

Pax arrives in the wake of planetside 4X title Age of Wonders: Planetfall, developed by Triumph Studios and distributed by Paradox. Planetfall was released last year, and is still receiving healthy updates and expansions. It is a fresh take of Triumph’s successful Age of Wonders formula, and is very slick and packed with content. Pax has a lot to live up to, in other words, and coming from a smaller game studio, it is difficult to imagine that it will achieve quite the same level of polish. However, I always believe that it is well worth spending time (and money) on works from small game houses, both to support indie gaming and to experience the often unique touches added by non-mainstream developers. And while it’s still too early for me to offer a full endorsement of Pax, I do like what I see so far.

I’ve only played so far with the more basic Terran faction. There is some initial lore about Earth becoming uninhabitable for some reason or another, and thus its people are charting a course for the stars. It’s enough to get things going, but it’s not quite as rich a beginning as you get, for example with the classic Alpha Centauri. I’m curious to explore how the other human and alien factions start out. Planetfall has a rather rich array of factions and species you can play with, though I find its own lore is a bit too unserious and thus underdeveloped at times. I’ll have to see how Pax compares.

The game starts planetside, and tasks you at the outset with building your first settlement. The landscapes you navigate aren’t as richly textured as Planetfall’s vibrant biomes, but they are still decently compelling, and compare favourably to the planets found in Beyond Earth. Settlement construction is interesting. After building your initial colony, you expand it via the construction of various districts, to which you then assign your citizens to manage. This sort of set-up is not new, but what I believe is unique is that each of these districts also has its own building queue, through which you can construct new units and improvements. Combat units, for example, are built out of the military district expansion. This means that your settlements can have multiple building queues, which I find to be a very effective innovation. Most 4X works make you choose between building new units and building new city improvements, and that decision seems somewhat artificial now that Grey Wolf has charted another path.

Beyond that, I still have much to discover about the game. I’ve had more than few units get wiped out by the alien critters that crawl along the planet surfaces, though it sounds like they get easier to manage with a few tech upgrades. Development times for the various units and improvements are very reasonable, letting you expand quite quickly in the early going; I find this to be a welcome contrast to the slower-paced Beyond Earth. The tech tree splits along three paths, and lead to the emergence of civilization eras that vary depending on your research choices. Tech advances often lead to improvements in the military units, which you can customize — a pretty standard inclusion in the genre now, but one that always makes things interesting. Combat is handled on the strategic map, as opposed to zooming into a tactical battle screen. This makes the game more like Civilization than, say, the Age of Wonders titles, and may be a problem for those who really enjoy the tactical side. Personally, I enjoy tactical combat, but it can be time consuming, so I can take it or leave it in the 4X space.

All in all, I really enjoy it when indie companies try out turn-based strategy, and especially 4X. The fact that Grey Wolf is offering a unique combination of planetside and space-based gameplay is another plus. And, while there is room for improvement in later updates, I find Pax Nova compelling enough to keep playing. I’m hoping that it will live up to its early potential.

History of Atari

In keeping with the idea of storing useful links in this space, click here to find the one-page version of Gamasutra’s history of Atari, 1971-1977, written by Steve Fulton. This appears to be the first of two articles written by Fulton about the company, with the second chronicling the “golden” years of 1978-1981 (that one you can find here, though I won’t talk about it today). There are innumerable pieces online and in print that discuss Atari in one way or another, but Fulton’s work includes a lot of interesting details that are hard to find elsewhere, and is well-sourced, with good quotations throughout.

The importance of Atari is the early history of video gaming is largely recognized, but, I believe, somewhat misunderstood. They are typically thought of as a titan in the industry that dominated for a time, then fell apart due to mismanagement and costly mistakes in their later years. Sort of like a Nintendo that ultimately lost it was way. Or maybe like an IBM without the (sort of) comeback. But a former might and power is generally assumed.

In truth, Atari was almost always struggling financially and competitively, getting by with lucky breaks, clever dealings, and ultimately a lucrative corporate buyout. Their corporate culture leaned more towards 1970s indulgences like drugs and hot tubs than it did buttoned-down engineering R&D. That’s not to say that they didn’t innovate — they certainly did, but much of their effort focused on getting working products out into the market ahead of the competition, rather than letting things bake in-house until they were just right. Yet somehow, they had a knack for success, at least for a while.

The Atari VCS/2600 home console is a perfect example of a product that had substantial technical limitations, but still managed to dominate the market for a time and grew to become a cultural touchstone. That might make sense if it had been the first home console to hit the home market, but that was not the case. The Magnavox Odyssey had beat in by five years (1972 vs. 1977), and the Fairchild Channel F had come about in 1976. Or maybe if it faced unimpressive competition, but by 1980 Mattel Electronic’s Intellivision had it soundly beat in terms of graphics and performance. It wasn’t even meant to be on the market as long as it was, hanging on until the North American video game crash of the 1983.

The classic Atari 2600 home console

What’s most amazing about the 2600 is that it was really only made to play variants of Atari’s older arcade classics like Pong and Tank. It was only through various acts of programming wizardly that it was even able to simulate more sophisticated arcade entries such as Space Invaders and Pac-Man (though its version of Pac-Man was famously disappointing). Many of its most sophisticated titles came from competitors like Activision and Imagic, whose products Atari tried to block from even entering the market. Yet it was titles like Activision’s Pitfall that really got the most out of the creaking 2600 system in its heyday in the early 1980s. Atari had made a limited system for a narrow range of purposes, that grew to become much more versatile and capable than was originally envisioned.

Competition and copycat-ism were a major story for Atari and its rivals, especially in the early years. Atari’s first two arcade games – Computer Space and Pong – are well-known to be recreations of earlier works. Computer Space was a version of Spacewar, the campus mainframe staple that was originally developed in 1962 by Steve Russell and friends. By the early 1970s nobody was claiming exclusive ownership over the game, so making a for-profit version of it didn’t trouble anyone. The same can’t be said for Pong, which was directly inspired by the tennis-style games developed by Ralph Baer for the aforementioned Odyssey system. Atari founder Nolan Bushnell had seen Baer’s system in action, and Magnavox even had documented proof of his presence at a demo session.

A licensing agreement and cash settlement ended the fight between the two firms, but Bushnell and Atari very quickly found themselves battling a variety of Pong imitators in the arcade space. Interestingly, Bushnell had patented the game soon after its release, but the company did not have the financial resources to fight its rivals while that patent was still being processed. Looking back on these events, that was probably a good thing in the long run, as a legal crackdown on variant versions of the game would have set a bad precedent. These days game companies tend to protect their audio and visual assets, but only rarely are lawsuits launched over similar game mechanics. It’s frightening to think of the potential alternative scenario.

One a successful game model was developed, moreover, Atari saturated the market with countless variants of the original design. Pong led to Superpong and Quadrapong, while Tank had several sequels. And all that time the company was typically in a tight financial situation, desperately trying to get product out into an increasingly saturated market. It didn’t even have enough money to launch the VCS itself, and required a buyout from Warner Communications 1976 to provide the necessary cash injection. Atari, in other words, was never an industry giant, or a fearsome corporate shark. Most of the time it was just trying to get by. And in retrospect, their products look somewhat weak and cheap as compared to the output of Japanese innovators like Taito, Namco, and of course Nintendo. Space Invaders, Pac-Man, and Donkey Kong are but a few of the titles that these firms produced that stood head and shoulders over most of Atari’s output. Yet Atari still had a pivotal role to play in the industry, and its history is worth knowing. I’ll look at Fulton’s second article on the company another time.

History of Civ

I’m writing this blog in part to house links that I keep perpetually open in my browser, at great cost to my RAM. So here is the full-page link to Gamasutra’s excellent article on the history of the classic (and arguably original) 4X game Civilization.

The history of the development of the original game is really interesting, and shows how the evolution of the entire genre could have gone in a different direction, had designer Sid Meier stuck to his original vision. 4X is largely the preserve of old-time grognards now — wargame warriors and the like who play their games to dominate and win. 4X designers have responded in kind, designing increasingly elaborate mechanisms through which players can achieve an ultimate victory.

But isn’t winning the whole point of any game? Well, sometimes. But Meier was largely inspired to create Civilization via his experiences with SimCity, which first came out in 1989 (Civilization was released in 1991). SimCity, as you may or may not know, billed itself as a “software toy” — that is, a game in which play and experimentation were more important than victory. Designer Will Wright somewhat famously compared the software toys his company Maxis designed to a physical toy like a ball (quoted here from the SimAnt manual, though I think it appeared in other places):

“With a ball, you can play tennis (a game). You can play catch. You can throw it at someone. You can bounce it. You can make up a hundred different games. Besides games, there are other things you can do with a ball. You can paint it, use it to plug a leaky roof, or just contemplate its roundness.”

It is worth highlighting just how much SimCity had an effect on Meier. So much so that Civilization was originally going to be a real-time game that focused mostly on zoning, just like the city simulator. The Gamasutra article explains:

“The prototype featured a SimCity-like zoning approach, where the player would demarcate areas of the world for agriculture or resources that would gradually fill in over time as the player waited. Ultimately, Meier found the real-time play style severely lacking in excitement. ‘It quickly became apparent that watching the civilization grow was like watching paint dry,’ recalls Meier. ‘The action was so [dull] that after a little bit of that, there might have been a game that intervened.'”

It was Shelley, who had worked at wargame powerhouse Avalon Hill, who helped steer Meier towards adopting a turn-based approach to the game that focused on the movement and actions of counters:

“In phase two of development, Civilization took a page from Shelley’s board game roots and became turn-based, losing the zoning process while gaining a more militaristic, Empire-like edge. Meier invented individual units to control and move around the playfield. ‘You had settlers who irrigated and could change the terrain and found cities,’ says Meier, ‘so we took the things that were zoning oriented and gave them to the settler.’ The more hands-on approach felt just right, and the basic gameplay of Civilization, as we know it today, was born.”

The switch to a turn-based framework obviously was a sound move, given the end result. Civilization was a remarkable game when it came out, and extremely influential. But the switch to a wargame model also brought with it a wargame ethos, I would argue. It is worth highlighting how much Meier’s original vision focused on settlement and development. While those activities were present in the final product, they were pigeonholed into the functionality of a single unit: the settlers. Much of the rest of the gameplay involved the development and movement of the various military units that became available as your society progressed. Combat, arguably, became the core feature.

I should mention here that I actually like wargames quite a bit. I enjoy their variety and intricacies, and the diverse ways that wargame designers attempt to recreate historical events, and/or rewrite history through the design of alternate scenarios. Wargaming in a huge and fascinating subject. But adopting a wargame framework ultimately had repercussions with respect to the ongoing evolution of the 4X genre. Many, if not most, players, focus their strategies on domination of the game universe, typically through aggressive military expansion. Most games do offer more peaceful paths to victory, but even in these cases, “victory” is the ultimate goal. This is far from the software toy vision pitched originally by Maxis in their Sim games.

Combat became even more important in the real-time strategic 4X games that evolved out of the original format in the late 1990s. Interestingly, it was Shelley, who played such an important role in turning Civ into a turn-based game, that led the way to real-time with the Age of Empires series. Age of Empires distilled out the essence of games like Civ into a more action-oriented, fast-paced product. Building was reduced to a subservient role, intended largely to backstop the construction of armies, which would ultimately rampage around the map to wipe out rivals. Experimentation was largely limited to trying out different formations and mobilizations of troops. Don’t get me wrong: these are great games. But they are also very narrow in scope and purpose.

Ultimately, I think that the relative decline (or at least stagnation) in the popularity of the 4X genre can be traced in part to this narrowing of horizons that occurred after Civilization became such a hit. One of my own long-term goals, expressed in projects such as Digero, is to experiment with the genre’s fundamentals, and to see if different sorts of games can be built out of them. The late 1980s and early 1990s were a wonderful time for wild experimentation in gaming, with designers like Will Wright and Sid Meier leading the way. It would be nice to recapture even a modicum of that spirit in the present time.

Scrollbar Blues

I majored in computer science when I first went to university, many years ago. The primary purpose of a computer science education, as far as I can remember, is to make you feel constantly insecure about your coding abilities. Because no matter what kind of programming solution you come up with to solve a particular issue, it would seem, there’s always a more elegant, and in theory more efficient, way to do the same thing. So as I code, and especially as I edit my code, I’m always mindful of the fact that whatever approach I’m taking is almost certainly misguided in some respect. Plus I never have enough comments. And my variable names are too vague or generic. There’s always something.

I was reminded of all this today as I worked on a new GUI element for Digero: a scrolling panel. The exercise vividly made clear both the elegance of Javascript/HTML, and the reasons why it can be so painful (and why I’m developing Digero in the first place). Anyway, this kind of element is highly useful whenever you need to show a lot of information in a small space. You make a little window, put all the information behind it, and add scroll bars so people can navigate through everything that’s there. Now, in a lot of pure programming languages, this sort of thing would be kind of tricky to pull off. But since we can take advantage of the powerful functionality inherent in a web browser (NW.js uses a Chrome backend), it’s just a matter of putting one div inside another div, and turning on the necessary scrollbars in the outer div.

Hey, that was easy!

But here’s the problem: since Digero lets you add elements inside other elements, you are allowed to scroll the inner div up and down, and stick things on top of it. But if you’ve ever worked with Web technologies, you’ll know that elements become hopelessly confused as to where they’re located when you scroll them. When you scroll a div, it technically doesn’t move at all, at least relative to the div it is inside of. But of course it does actually move on the screen, in that you can see it scrolling.

So where is it? Well, that depends on who you ask, in the sense that querying different parts of the CSS scheme will give you different answers. The inner div hasn’t moved at all, at least not according to its parameters. But if you ask the outer div to return a CSS style value called “scroll-top” (or “scroll-left” if you’re going left and right), if will tell you how far the inner div has moved relative to its own position. So depending on your needs, you have to forge an alchemic mix of different values from different elements in order to know specifically where anything is.

Anyway, long story short, it was very difficult to enable the user to drop new elements inside of the inner div, and have those elements actually appear where the user specified. To make matters worse, when I did devise a solution, I needed to edit the necessary code in multiple places within the program. Each element type has its own construction code for whenever you draw it on the screen. The code blocks are very similar to each other, but there are enough differences that I had to write them out separately. But the code edit I needed to make appeared in every single instance, which meant that they had to all be edited by hand, one at a time.

This is where the insecurity creeps in. Because even though I said I had to create similar but different code blocks for each element, there is clearly a way I could have rearranged things so that I could have written out the code each block has in common one time, and then pointed each separate instance to that code when it needed it. Have the common code as a root, metaphorically speaking, and the unique code for each element as a separate branch underneath that root. I would have recognized that, more than likely, if I had actually planned out how my code was going to be structured in advance. But I’m terrible at planning. I tend to just dive into these project with little forethought. Even though I can code, in other words, I would make a lousy software engineer.

In the end, I made all the changes I had to, and it was a relatively painless procedure. But the whole exercise served as a reminder that, if other bugs reveal themselves down the road, I might have to go through the whole inefficient process all over again, and be reminded once more about how lousy my code is. But at least, for now, everything is working, and I can pretend that it always will be.


I have a couple of “big” projects on the go, but the one I have been focusing most on over the past couple of months has been Digero (Latin for “I arrange”, in a callback to my years studying medieval history). Digero is, essentially, Visual Basic in Javascript form — or rather, in Node.js form. I’m using the excellent (though perhaps poorly-named) NW.js framework as the foundation both for Digero, as well as for the programs made from it.

Not Visual Basic, but not not Visual Basic, either

Digero is the product of many years of wishing there was a tool like it out there somewhere, and never finding one. There are plenty of GUI HTML development tools around, though I’ve found it difficult to find one I like, and, more importantly, they are typically focused on the creation of websites, not standalone applications. There are also a host of Javascript/Typescript-based application development languages and frameworks (React, Angular, Vue), but I find these hard to work with as well, for the simple reason that they are not GUI tools.

Here’s the thing: I’m not the biggest fan of GUI tools. Nine times out of ten, code is more precise, efficient, and stable with respect to solving any programming problem. If you wanted to learn programming and wanted my advice, I would steer you strongly away from GUI coding playgrounds like Scratch and towards real learning languages like Python. Programming languages are fascinating constructions in their own right, and you can’t appreciate the mechanics and design philosophies behind any computational object without knowing their essential intricacies. But every once in a while, a use case will come along that a GUI tool will serve best. And UI construction in HTML/Javascript is one of those cases.

When I create programs out of NW.js, I don’t like to use HTML. I have to supply each individual program with an HTML page, of course, so that it has something to display onscreen, but I tend to pass on pages that are more or less completely empty. Every UI element I use is created dynamically using Javascript code, typically within the “window.onload” function. This may sound inefficient and/or painstaking, but I much prefer it this way. I don’t like working with HTML. It’s not real code. I’d much rather start with a blank page, and then tell the computer exactly what I want things to look like using a real programming language like Javascript.

The problem is that creating HTML elements using Javascript is a huge pain. It can easily take at least a dozen lines of code to create an element, name it, and apply all the necessary CSS styling to it. You have to include a line just to tell the program you want to position each element absolutely, as opposed to relatively. And each line has to take the form “[element variable name].style.[style name] = [whatever]”, which is annoying to keep typing out and/or copying and pasting. And you have to remember things like how values such as “top” and “width” have to end in “px”, or they won’t even work. It’s a huge, tedious pain. And I know that jQuery simplifies the process somewhat, but it’s still a bit of a slog. Plus I’m something of a Javascript puritan in that I tend to avoid jQuery.

Here’s another thing: I absolutely love Visual Basic. I’ve been playing with versions of it since the mid-1990s. I find the balance it strikes between GUI tools and actual code to be just about perfect for developing Windows-based programs. I even find it useful for games, or at least specific genres of games. In fact, I’ve always wanted a tool like Visual Basic that was more focused on game development. I also find Javascript the ideal language for creating many types of games (a topic for another post). So Digero is meant to strike the compromises I’ve been looking for in a programming environment for a long time.

I’m at a point right now where I’m focused largely on making turn-based strategy games, especially those in the 4X genre. I have yet to create a complete game of this sort, and I think one of the major reasons why is because the GUI elements are so difficult to make (or at least that’s what I’m telling myself). I don’t know if I’ll have the patience to ever complete one of these games, but I’m hoping that Digero will take me closer to doing that. Plus it’s an interesting application to make in its own right. In later posts I’ll highlight some of its features, or at least that’s the plan. I have some other stuff I’m working on to. I’ll get that posted here eventually.

Sanity Check

I’ve started blogs before, and they’ve never lasted. Starting up another one in 2020 is definitely a bad idea. This isn’t 2002 anymore.

I think the problem was that I was writing for audiences that I knew weren’t really there. That’s why, this time, I’m writing all this for me.

I got back into programming about 10 years ago. The first thing I completed was a Pac-Man clone. Pac-Man is always something I wanted to take a stab at. Thanks to the Pac-Man Dossier (now hosted on Gamasutra, though it wasn’t when I used it), I was able to make stuff like ghost movement as close to the original as possible, though I never added the fruit, which is actually a pretty major omission. Anyway, I pulled the assets from MAME, including the Ms. Pac-Man art and mazes (don’t tell Bandai Namco). I was happy enough with the results, which you can still check out here.

Fun with copyright infringement

Like I said, that was a decade ago. Since then I’ve gone through a number of projects, most them ending up half-finished. But that’s okay. Each one (in theory) builds off of the last, and my overall programming skills (in theory) improve with each iteration. What’s missing, however, is any sort of record of the work I have done. I can remember bits and pieces, and a lot of my old code is stored somewhere I can maybe access, but I have little trace of the day-to-day work, and how my thinking evolved over time. This blog will hopefully ensure that the next 10 years (ambition!) won’t become similarly lost to time.

My writing is going to be bad at first. That’s something I have to accept. In my limited blogging experience, I was never able to develop a voice I was comfortable using in the long term. Even now I feel like one of those self-important middle-aged men, penning his memoirs in his home office, determined to win fame and fortune by sharing his supposedly hard-won wisdom. That’s why I’m determined to focus on an audience of one. I want this to be something that at least I can look back on, and maybe use to search for links to interesting stuff I’ve found and then forgotten. I keep way too many tabs active in my browser. If this effort helps to reduce them, it at least serves that purpose.

Also, of course, we’re in the middle of a plague right now. It will be interesting to see how that works out. Prediction: the United States, at least, is in big trouble.