Someone on a retro gaming Facebook group I follow recently posted about an Amiga game called Conflict: Europe. A screenshot illustrates that it is your typical WW3 grand strategy type game:
There’s an interesting war room aesthetic going on there, as well. Anyway, what caught my eye was the fact that the poster mentioned that the game actually made you call a phone number in order to get launch codes for nuclear weapons. This is something I had to investigate.
It turns out that Conflict: Europe was released in 1989, and came out on multiple platforms. You can find the manual here, and on page 4 it indicates that there were versions for PC, Amiga, and Atari ST. This was an interesting time in the history of computer gaming, in that there were still a variety of viable platforms for commercial releases, but 16-bit architectures were beginning to assert their dominance. This progress was paralleled in the console market with the release of the Sega Genesis/Mega Drive system. Still, 8-bit players like the Commodore 64 were still hanging in there. Simcity, Maxis’ landmark original title, came out in 1989 and supported the C64, along with the newer platforms. Getting back to the 16-bit machines, at this point it might still not have seemed certain that PC machines would ultimately win out over the other platforms, though the increasing visibility of “clone” machines might have pointed the way.
It’s worth having a look at the cover of the manual, for its sheer incongruity with the rest of the game:
This man does not look happy.
It’s hard to figure out why they’d show a close-up of a soldier in a grand strategy game that plays out on a map. I suppose it does a decent job of portraying the apocalyptic battlefields of a theoretical WW3, but hopefully nobody bought this game based on the picture thinking it was an action-oriented title (they used the same image on the game box, in full colour!)
Anyway, there doesn’t appear to be anything in the manual indicating a phone number you have to call to get the nuclear codes. In fact, the codes you do need are given in the middle of page 12. Strange. However, I can confirm that the phone line did exist based on this academic article from what it called “The International Journal of Baudrillard Studies” (want to know who Baudrillard is? Check him out here.)
Here is the quote from the article that confirms the phone number:
“In a fascinating exposition of multimedia convergence, the player of Theatre Europe asks the ‘Warcomp’ (war computer) to instigate a nuclear attack. At this point, the game asks the player to call a telephone number, based in Coventry, a city itself carpet bombed during World War II, to ascertain the launch code, which must be done within 30 seconds of the request.”
The game itself is interesting as a war game, in that it tries to portray a realistic combat scenario in which nuclear weapons could play a role. But they also appear to be deeply troubled by the scenarios they envisage. This is a screenshot of a page from near the end of the manual, and is well worth reading:
Pretty dark stuff. And little did the authors know that within a couple of year, the “two armed camps” scenario would dissolve. I’m not sure if we’re any smarter these days, though. But at least nuclear annihilation isn’t quite the threat it once was. At least for now.
This morning, I started to work on my implementation of the classic 4X fog of war mechanic for a prototype sci-fi game I’m working on. If you don’t know, 4X fog generally comes in two layers. The first is total darkness on those parts of the map that your units have never been to. The second is partial fog on those areas of the map you have explored, but that you are currently not within range of. Each unit and settlement generally has its own radius of observation, and outside of those ranges, you’ll see at most the tiles of the map, but not any units from other players/factions.
This probably goes without saying, but implementing this system is quite tricky. In my Javascript-powered game engine, I actually layered one canvas over another so that I could draw a fog layer over the map. I then have to keep track of where player-controlled settlements and units are located, and reveal parts of the map accordingly. This becomes especially tricky when a unit is moving, as most 4X games adjust the fog on the fly as a unit moves from tile to tile. You can see the preliminary results below:
This was hard, man.
You might have noticed the minimap in the bottom-left corner, which also has to be updated as the player navigates the game world. Needless to say, I have a long way to go with this game, but the fog of war element seems to be working.
Anyway, this all got me thinking about 4X fog of war, and where it might have come from. As far as I can recall, this two-layer fog has been present ever since the first version of Civilization, is now pretty much ubiquitous across the genre, and is even standard on real-time strategy games as well. Was Civ the first game to use it? What was, for that matter, the first video game to use any sort of fog of war implementation?
Wikipedia is as good a place as any to start searching for these kinds of answers, if only to see what sources have been cited. As it happens, there is an entire entry on the website for the fog of war concept, with a sub-section on video games. This is what it has to say:
“The earliest use of fog of war was in the 1977 game Empire by Walter Bright. Another early use of fog of war was the 1978 game Tanktics designed by Chris Crawford, which was criticized for its unreliable and ‘confusing’ fog of war system.”
The reference to Empire is an interesting one, as Empire has been cited as an inspiration for Civilization in several sources. In Benj Edwards’ history of the game on Gamastura, he says the following:
“Meier was also a big fan of an early computer game called Empire, which combined Risk-like world domination with intricate city management. ‘At one point, [Meier] asked me to make a list of 10 things I would do to Empire to make it a better game,’ says Shelley. ‘That was some of his research on Civilization.'”
In his recent work Vintage Games 2.0, Matt Barton says something similar:
“However, Meier was also a fan of the classic computer strategy game Empire, a turn-based war game created by computer programmer Walter Bright in 1971.” (p. 184)
So was Empire really the first video game to use fog of war? The Wikipedia article cites this work as the source for the claim, which comes from a small press that appears to focus on military history. That’s…okay, as far as Wikipedia sources go. But I wanted to investigate further.
As it happens, Walter Bright created an entire website devoted to his classic wargame. The history page is well worth reading in its entirety if you are into gaming history. The site also contains a wealth of other valuable information, links to reviews of various versions of the game, and, perhaps most importantly, source code for the earliest versions of the game, including the first version for the PDP-10, written in Fortran, and a later version for the PDP-11, written in assembly language. Binaries for later versions are also available.
Evidence from the first commercial versions of the game, including a review from the September 1984 issue of Creative Computing, make it clear that fog of war was in fact an important feature. But was it there from the start? The PDP versions of Empire date from the 1970s, so Wikipedia could be correct in that they were the first computer games to feature fog. But more evidence is required to make a final verdict.
Unfortunately, I don’t know Fortran or assembly well enough to decipher the available code, which is pretty long in both cases, and divided into numerous files. However, for the Fortran version, there is a help file written in plain text, which you can check out here. A couple of areas are worth highlighting. The first deals with the game map:
“THE MAP IS A RECTANGLE 600×1000 MILES ON A SIDE. THE RESOLUTION IS 10, SO THE MAP YOU SEE IS 60×100. THE MAP CONSISTS OF ‘.’: SEA, ‘+’: LAND, ‘*’: UNCONTROLLED CITIES, ‘X’: COMPUTER-CONTROLLED CITIES, ‘O’: YOUR DOMINATED CITIES.”
Note that there is no mention here of areas of the map being shrouded in fog. Compare this to a similar section in the manual for the later IBM PC version of the game, available here, which does mention “unknown territory” represented as blanks.
The second part appears later in the document, and explains a game feature called “sensor probes”:
“SENSOR PROBES ARE DONE BEFORE AND AFTER EVERY MOVE. SENSOR PROBES SHOW ONLY THE 8 SQUARES ADJACENT TO YOUR UNIT. THE MAP DISPLAYS ALL THE MOST RECENT INFORMATION.”
This text makes it clear that there is a fog of war mechanic implemented in the game, in the sense that you can only “see” live information on the map around the areas where your units are located. On the rest of the map, you’ll only see units where you last encountered them. But what about the actual terrain on the map? Is that invisible until you explore it, just as it is with modern 4X titles? That is unclear.
Returning to the IBM PC version of the game, there is a section in the manual that describes a feature very similar to sensor probes:
“The entire map is unknown (blank) until you start to explore it. Beware, however, that you cannot detect enemy pieces unless you are right next to them. The actual map that you see on the display is a summary of all the most recent information that you have about the world.”
Note that the last sentence is virtually a duplicate of the one found in the PDP-10 version’s help file. More importantly, the manual indicates that you can only see the live locations of enemy “pieces” that are adjacent to your own, just like in the PDP-10 version.
In fact, this text makes it clear that the IBM PC version of Empire implemented a two-tier fog of war system, of the sort found in Civ and other 4X games. The game map is initially “blank” – that is, covered in black tiles – until you start exploring it. Screenshots of the game, including one found in the Creative Computing review, make this clear. This is from the Amiga version:
In addition to these blank areas on the map, however, there is a second layer of fog, in that enemy units are only visible if you are beside them. Or, if you passed by them earlier in the game, they are located in those tiles where you last saw them. Again, the Amiga screenshot illustrates this.
All of this evidence points to a very interesting fact: the two-level fog of war system, used in the first version of Civ, and in virtually every other tile-based 4X game since, was actually derived from Empire. The games are thus closely connected, perhaps more so than is generally assumed.
Does this mean that Walter Bright invented this mechanic? That’s still an open question, as least as far as I can determine. The PDP versions of the game clearly had one level of fog, in that you could only see live enemy units when you were beside them. But was the game map itself shrouded in darkness before you explored it, like how the second level of 4X fog operates? Unfortunately, I don’t have a PDP machine handy to check on this, and as I said I can’t quite grasp the code. My gut feeling, however, is that the entire map was in fact visible from the outset — I just don’t see anything in the help file, or anywhere else, that indicates that you have to explore the map to uncover its terrain. Again, though, I can’t verify this right now.
It would also be worth checking out the fog mechanic from Chris Crawford’s game, as mentioned in the Wikipedia article. I will save that for another time.
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 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.
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.
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.
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.
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.
