Hello, everyone. Today, for only the second or third time in three years, this newsletter contains no actual links. Apologies. In my defense, I did keep working on Adventure Prompt, after coming up with a game idea that can properly showcase the engine’s specific features. A big selling point of the system is the ability for authors to employ many text adventure tropes just by setting some properties on objects. And it’s surprising how much can be done that way. Scenery/portal objects (they can double as doors that lead elsewhere) were trivial — just another application of exits. Vehicles took only 100 lines of extra code in the interpreter (though that was a 20-25% increase), and the only recent addition to the editor, apart from more documentation. I could have crammed a minimal scripting language in that much space… but that would have shifted the burden on authors. Which is the opposite of what an authoring system is for.
Easy stuff will be easy no matter what. The trick is making the hard stuff easier as well.
Next: to do some more refactoring before adding what little is left (reading material and hidden object reveal, mainly), and then to see about fleshing out that demo game, because while the map and puzzle structure came easily, I had a hard time thinking of descriptions. And that’s supposed to be my specialty.
See you next time, hopefully with more exciting news. Be well!
I don’t remember whether I played They Started It before or after coming up with the concept for Laser Sky. I had been toying with the Pyglet game library, pondering what sort of game it might be suitable for, and a shoot’em up was the most obvious choice. Not that the world needs yet another game about blowing stuff up. But making a sequel to Attack Vector and getting it right for a change is an old dream of mine, and any excuse to learn a promising new technology is a good one. The big problem was choosing a theme. And like the first time around, nothing I came up with seemed to have legs. Even a briefly considered idea for a cute’em up fizzled out (though that’s definitely worth revisiting). Moreover, it began to dawn on me that coding a sprite-scaling engine on top of a 2D library backed by OpenGL was kind of ridiculous. The new game had to be a good old-fashioned scroller… but then it couldn’t be a sequel to Attack Vector.
In the end, the concept for Laser Sky came to me almost fully-formed during a walk in the park. Trouble is, it involved vector graphics, and that precluded the use of an engine optimized for sprites. So, back to HTML5 it was. The first order of business was dusting off the game microframework I developed two years ago for the original RogueBot. (Which of course revealed a bug, duly fixed.) Making a ship move around the screen, and some basic enemies come at it, was easy enough. Then it was time for them to interact.
Hello, everyone. For once, I only have my own bad mood to blame for the shortness of this newsletter. As promised three weeks ago, my latest book, Make Your Own Programming Language, is live on Leanpub. It’s only of interest to programmers, especially those with a taste for retrocomputing and retrogaming. But you know my opinion: piecing blocks together in GameMaker is still programming, whether you realize it or not. And game design works best when you have at least a trace of process, as opposed to banging things together until they stick. So give it a try.
In unrelated news, all everyone’s been talking about lately is No Man’s Sky. That’s also the case of Michael Cook, who brings it up as an example of the language we use to discuss procedural generation. And you know… I couldn’t help but notice the fatigue of many reviewers when they mention how many millions of billions of planets there are in that game, and how they’re never going to see the vast majority of them. Which fortunately doesn’t really matter…
I guess the creators of No Man’s Sky forgot that the original 8-bit Elite was originally planned to have 282 trillion galaxies, or 2 to the power of 48 (presumably another byte was going to be used for the planets in each galaxy). And never mind that it would have made the artificiality obvious, especially on a home computer from the 1980s. But visiting 2000 star systems is a plausible goal for the determined player — there are just enough of them to make for a huge playground, yet few enough that you can actually remember some of your visits afterwards… and care. While enough content to fill millions of galaxies (a sizable chunk of the observable universe) just sort of blends into an amorphous mass. A statistic, if you will.
As an aside, let me underscore again than an 8-bit computer from the early 1980s, with just 64 kilobytes of RAM, could easily have handled a procedural universe on a scale comparable with the one in No Man’s Sky (if a lot less detailed). What exactly are we doing with a million times more memory and computing speed?
Is it a book? Is it a piece of software? It is a game? The second edition of Make Your Own Programming Language, that I finished writing today, has a little of all three. Most importantly, it tries to recapture the fun of making the computer follow your instructions, that forgotten quality of programming that used to lure so many people decades ago. It will soon be out to beta-readers, and then I’ll let you know.
In other news, Rock, Paper, Shotgun is running a series of articles on the future of procedural generation, specifically about spinning lore for computer role-playing games. Which would be pretty interesting, except for most roguelikes that would be overkill, while in more conventional CRPGs handcrafted characters, stories and settings are the whole point. Do games that aim to have emerging narratives even need that much detail, especially if it’s ultimately fluff?
Going forward, via Jay Barnson, here’s a Gamasutra article about Chrono Trigger’s Design Secrets, that manages to be useful even though I never played the game. And Jimmy Maher’s history of computer story games has reached the demise of Infocom; check out the quote from Marc Blank, who was stating who knows how long ago what myself and others have been blogging about all spring:
If all of a sudden you can ask any question, but there are really only three questions that are important to the story, you’re either going to spend all this time coming up with answers that don’t mean anything or you’re going to have a lot of “I don’t know that,” which is frustrating. I always suspected it was a dead end. The nice thing about the command-oriented game is that you can come up with a pretty complete vocabulary and a pretty complete set of responses. As soon as it becomes more open-ended — if I can say, “I’m hungry” or “I like blue rubber balls” — how do you respond to that?
To end on a nostalgic note, here’s a blog post about abandoned arcades, and the slow death game cabinets are sentenced to when left exposed to the elements. Thankfully, there is interest in rescuing these old machines as of late, so for the most part arcades are a bit of history we can expect to survive.
Until next time, don’t let the past be forgotten.
It wasn’t three weeks ago that I was linking to a very nice retrospective of the Gabriel Knight games. Well, here’s an even more detailed five-part postmortem of the famous trilogy. Apart from the wealth of technical information in the articles, I can’t help but notice two factors that I think were very important to the success and enduring fame of the franchise: the story came first — and it was a story the writer cared very much about, not just something written on order. Consider that when setting out to make a game.
Speaking of retrospectives, here’s one of Fantasy World Dizzy, my favorite in the series. And while on the topic of adventure games, the incredible Jason Scott just made public a treasure trove of Infocom documents (see here and here). Beyond their value for historians and game designers, it’s worth noting that they did write down all that stuff, and then someone went through the trouble of preserving it. Hooray for thinking of the future.
Last but not least, a moving story about somebody reviving an old Atari 800 and TV set from the same era for a gaming night in the family. Note that both antiques are still working perfectly, over 35 years later, and they’re no less fun than a modern console. A pretty good return on investment, wouldn’t you say?
In unrelated news, from a blogger I haven’t quoted lately comes an article about the importance of software specifications. Which is most welcome seeing how the complexity of modern software is all too often underestimated — and games are some of the most complex apps out there.
Have a nice week.
Oh my. Late again and for once I have no excuse. So let’s get started.
I’m the kind of player who, when sitting down to try out a MMO, spends a lot of time choosing and customizing an avatar. Nightwrath always gets impatient, but come on. Isn’t the avatar supposed to represent me well? This is why this article about dress-up games caught my eye. Not so much the examples they give — Hero Forge is much more to my taste. But that would require going into details. Point is, dress-up isn’t just for kiddies.
Moving on. On the 30th anniversary of the NES launching in the US, we get an in-depth retrospective of the console’s development. And apropos of nothing, here’s a personal history of the text adventure, a thoughtful and informed write-up. Last but not least, it turns out White Wolf has been sold again, from one computer game publisher to another. It remains to be seen what sort of vampire games we can expect this time.
At last we get to a headline actually related to game development. Well, the concept of a complexity budget applies to all software. It just happens that games are often among the most ambitious software projects, and it tends to kill them very dead.
Don’t make that mistake. Keep it simple… son.
Having been offline for the weekend due to yet another outage (so much for Talk Like a Pirate Day), I find myself late and with insufficient links to make a newsletter. Perhaps I could mention the latest toy I’ve been working on — RPN-40, a programmable calculator trying to stay simple and fun. Or perhaps Hardcore Gaming 101’s retrospective of C.P.U. Bach, which may seem off-topic. But think about it: in 1994, computers were already able to compose music. 21 years down the road, they are even able to design videogames. How can we harness that ability?
And speaking of that, via Michael Cook I learned of this blog post about procedurally generating cities. Having done just that (in a simplistic way) for RogueBot, I can certainly appreciate the work described.
— Danny Goodayle (@DGoodayle) September 17, 2015
Last but not least: Rock, Paper, Shotgun — which has been leaning noticeably towards my range of interests as of late — has an article about designing magic into fantasy worlds. Which of course applies to all media, not just games; the article doesn’t talk at all about implementation issues. Tip: you basically need a scripting engine to have magic in your game. The simplest implementations I’ve seen resemble the example in my article about code versus data. But the narrative angle matters just as much, if not more.
And that’s pretty much all I have for today. See you next time.
Welcome, readers. We’re having a short newsletter again, and all the news are about programming. Let’s start with Jay Barnson telling a war story about the perils of assumptions and arbitrary limits. I already shared my opinion in a comment over there, so I won’t insist. Speaking of opinions, John Carmack has one about the best programming language for beginners, and it turns out to be Racket, a Scheme dialect and IDE. And while on the topic of great programmers, Nature magazine of all places has a feature on Ada Augusta Lovelace, who was born exactly 200 years ago (minus four months), and went on to theorize the very notion of a programmable computer, and what programs might look like — including, if I understand correctly, the three fundamental control structures!
Last but not least, not feeling up to tackling a big project, I worked on another toy library this week. VGForm is a very simple JSON-based format for vector graphics, designed to be easily rendered with common graphics APIs such as the HTML5 canvas or AWT’s Graphics2D. It’s born from my early struggles with using vector graphics in games — too bad the idea didn’t occur to me earlier! But the best course of action is always obvious in retrospect…
On this note, thanks for reading and see you next week.
I’ve been learning and using Python quite extensively for the past few years, and every time I mention that to someone they go, “ugh! that language with the indentation-based syntax”. And I’m like, really? That in my book is a quality of the language. Seriously, don’t you indent your code meticulously anyway? Python simply spares you from also having to bother with curly braces, or extra keywords.
But the fact that people complain about that mostly tells me they haven’t used Python enough to discover some of its real downsides. It has plenty, and they’re becoming quite familiar to me as of late. So let me give you some good reasons to hate Python, before I explain why I favor it over other programming languages anyway.
It occurs to me that Inform 7 was so successful because it redefined interactive fiction authoring as writing prose, while Twine’s impact was due to redefining CYOA authoring as constructing a graph. Both were revolutionary — paradigm shifts in the truest sense of the word — because they allowed authors to practice their craft in the language of the craft itself. Where by language I don’t mean the specific symbols you work with, but more generally the system of communication you employ to describe whatever is on your mind at any one time.
The world of programming at large would do well to learn from these success stories. Because while Inform 7 radically changed the way people can describe games to a computer and each other, Haskell for example merely shifted the blame.