David Pittman

NEON STRUCT: Desperation Column is the third game in the NEON STRUCT series, and the second that I’ve released as a free game jam.

The reason I’ve been doing game jams again recently is that sometimes I need the extrinsic motivation of a theme, a competition, or a deadline. I like making games, but it’s easy to get lazy, and an extra push doesn’t hurt.

This is the first game jam I’ve done in a very long time that put gameplay first. I’ve been doing narrative-focused stuff for a while, and that’s been great too; but this is pure action gameplay, and I’m at home here.

I started from a codebase that already had a lot of the things I needed for this game. I think that’s fine for a game jam, it’s the same as starting with Unreal or Unity + your fav plugins, but I definitely didn’t make this from scratch in a week.

The 7dfps jam has generous rules (read: no rules), but I wanted to finish on time AND make something good. So I knew I’d have to be careful about scope, and baby I LIVE for being careful about scope.

My initial parameters were: 1 weapon, 1 enemy type, 1 environment. That grew to 2 enemy types, plus an NPC type, and 3 environments (sorta); but the ultra lo-fi style meant those additions didn’t explode scope.

You can search bodies and containers, but there is only 1 resource to find: ammo. You have limited ammo mostly because it gives you a reason to search containers. And it maybe creates tense moments when you run out.

There are no health pickups, no upgrades or unlocks, no skills or perks. No conversation trees, no shops, no character customization. I’ve done all those things before, I still have the code, and I chose to not do them here.

The result is a minimalist game that is now one of my favorite personal projects: a pure distillation of the action/FPS mechanics at the heart of all my work. I think it’s the closest thing to Eldritch I’ve made in a long time.

And it broke me out of a mental rut where I’d felt like doing this sort of thing was too hard, or would take too long. It wasn’t, and it didn’t. It was a sheer joy to make this game, and I hope that shows.

I’m currently working on Slayer Shock, a role-playing shooter about hunting vampires in Nebraska. This game is thematically structured like a television series: each mission is called an “episode”, a group of episodes is a “season”, and each season ends when the player and their team stands victorious over the latest villain. (To be clear, that’s just flavor; this is not an episodic game in the usual sense.) The core elements of the narrative—heroes, villains, and plot points—are randomly chosen or procedurally generated to create unexpected stories.

While interactive game systems can generate thrilling player stories, they’re historically less successful at creating characters and plots with the charm and feel of authored stories. I knew from inception that if the narrative aspect of Slayer Shock were to be a unique selling point, interesting game mechanics were not enough. I would need to develop a separate system for generating memorable characters and coherent, engaging storylines. This isn’t without precedent—Dwarf Fortress builds massive mythologies, and Middle-earth: Shadow of Mordor creates memorable rivals—but it is not clearly solved for all purposes in all kinds of games.

In particular, the procedural and strategic structure of Slayer Shock means there is effectively no end to the narrative. Victory over one villain progresses to a confrontation with the next, allies join or depart according to their personal desires, and the game has to manage those events and try make it all coherent. To invent a narrative generator that could accommodate these demands, I would first have to understand how to write an infinite number of perpetual stories.

For research, I first looked to scripted television series (like Buffy the Vampire Slayer, which informs much of the tone and theme of Slayer Shock), but I found it difficult to extrapolate any general lessons from that format. Most television keeps its stories contained to the episodic unit, with big picture season or series plots developed in the margins, in ad hoc ways. While the reliable structure of “monster of the week” shows or procedural dramas could be instructive for other kinds of story generators, I found that they weren’t helpful for my purpose. I realized I wasn’t actually interested in the content of an episode, I was interested in what changed between episodes.

My next brief research stop was at soap operas. With their relentless development schedule (typically producing 5 hour-length episodes each week), melodramatic characterization, and penchant for twists and cliffhangers, I was sure there would be a wealth of available research on the structures and patterns and tropes of daytime serials. And perhaps such research is out there, but a cursory TV Tropes search didn’t return what I wanted. And, no offense intended to fans, but I wasn’t excited about the prospect of watching hours of soaps to internalize their design.

Around this time, I watched Max Landis’s “Wrestling Isn’t Wrestling” film*, and so my research path finally led to professional wrestling. Sometimes dismissed as “male soap opera” (a statement with so many layers of problems that I’m not even going to attempt to unpack it now), professional wrestling does in fact exhibit many of the same properties as daytime serials: a staggering amount of content produced every week; frequent, seemingly arbitrary twists; and exaggerated, simply-drawn characters. And as with soap operas, I could find a lot of information about specific plots, but relatively little about the general patterns of story development. If I wanted to understand the narrative design of pro wrestling, I was going to have to study it myself.

Note: For the purpose of this article, when I say “professional wrestling”, I’m talking about WWE’s mainstream version of “sports entertainment”. There are lots of forms of professional wrestling, but the exaggerated characters and angles of WWE are what I found useful to deconstruct for this purpose.

As a child of the ‘80s, I grew up with a vague awareness of pro wrestling, mostly by way of occasional appearances in video game magazines. Wrestling became unavoidable during WWE’s “Attitude Era” in the late ‘90s, and I could identify all the big stars despite never watching a single minute of it. I didn’t understand the appeal at the time—it’s fake, why watch a match where the outcome is predetermined?—and it wasn’t until I finally dug into it last year that I realized what everyone else already knew: it isn’t about the matches per se, it’s about the performances and the storylines. It’s theater.

The first narrative challenge I faced in Slayer Shock was how to make generated characters unique and memorable. My fear was that each villain would be interchangeable with any other villain; perhaps visually unique thanks to a randomized appearance, but functionally and emotionally identical to the rest. Here, I found wrestling especially instructive. Wrestling promotions face a similar challenge to develop a constantly shifting roster of dozens of wrestlers into distinct characters that can get “over” with the crowd. How does wrestling distinguish one bulked-up shirtless man from the next? They give them gimmicks.

The term “gimmick” encompasses everything that transforms a wrestler (i.e., the real person) into their character: behaviors, catchphrases, costumes, and more. It’s the supernatural horror of the Undertaker, it’s Stone Cold Steve Austin’s middle finger salute, it’s The New Day spilling out of an oversized cereal box in anime armor and unicorn horns.

The takeaway isn’t to craft a unique gimmick for every generated character, because that would be impossible. Instead, what I learned was to develop a library of common gimmick elements that mainly serve to distinguish one villain from the next. From that seed, I can let the characters grow in the player’s mind based on the actual events of gameplay. Even in wrestling, the best gimmicks take time to develop and get “over” with the audience; many wrestlers begin with either minimal characterization or with common, tropey gimmicks.

The second lesson I learned was repetition. When wrestling finds an angle or a gimmick or a feud that works, they milk it dry. Sometimes this is tedious or boring: characters reiterate their ongoing angles in promo after promo, the participants of upcoming or recent title matches are repeatedly thrown into the ring again with no meaningful outcome, and the commentators do little more than remind the audience of the wrestlers’ gimmicks. But the reasons for this repetition are manifold and valid. It makes it easy for new or returning viewers to catch up on the storylines. It ingrains the gimmicks in the audience’s minds. But most importantly, wrestling is theater. Everyone involved is performing live for a crowd who showed up that night to see their favorite wrestlers. And from this perspective, it makes no more sense to criticize wrestling for its repetition than it would to criticize a band for playing their most popular song at every concert.

My takeaway from wrestling’s repetition is about how to maximize the limited narrative bandwidth in this particular game. With its procedurally generated levels, there is little room for narrative delivery during core gameplay in Slayer Shock. Plot development happens at the margins of gameplay, in between missions, just as it mostly happens in between matches in wrestling. With such limited opportunity for narrative content, it is critical to reinforce characters through repetition, and there is little time left over to substantially develop them beyond that.

Furthermore, the performative aspect is increasingly significant in games, except in this case, it’s not the developer performing to the player. Instead, it’s the developer and the player collaboratively performing to viewers on YouTube or Twitch. Here again, repetition can help ease viewers into the experience and provide unique memetic hooks for each audience.

My previous project was NEON STRUCT, a game loosely inspired by the excessive reach of the modern surveillance state. Worried that I wouldn’t do the subject justice, I labored over every line of dialogue, struggling to make the script cohesive and coherent, trying to force the game to fit the message.

With that in mind, the third guidance I find in wrestling is adaptability. Wrestlers get taken out of action unexpectedly due to injuries or personal reasons, but the show must go on. On any given night, they may feature anyone from supernatural beings to ex-MMA fighters to literally Donald Trump; but they always have to bring it back to two people grappling in a ring. To be fair, wrestling avoids tackling highly-charged political subjects like the surveillance state, but I actually believe the audience would buy it if they tried.

What I take away from wrestling’s occasionally astounding incohesion is that it doesn’t really matter. As a creative artist, I can take a hard turn and my audience will follow along if they’re on board with what I’m doing. The player and the viewer come to be entertained, and it’s always better to surprise them than to bore them. If they poke holes in the construction or logic of a scene later, at least I’ll know it comes from a place of passion instead of disdain.

And speaking of taking a hard turn, the final point I’d like to share about wrestling is the many ways I’ve seen that the wrestling industry mirrors the video games industry, and what we might take away from that.

• Like video games, wrestling is mass market entertainment that has grown by expanding into films and other media.
• Like video games, wrestling is largely delineated between a few major promotions (like WWE) and a vast host of independent promotions that you’ve probably never heard of.
• Like video games, wrestling has a majority of casual fans who are generally unaware or uninterested in what is happening in the independent scene.
• Like game developers, wrestlers often bounce between the majors and the indies, for a variety of reasons.
• Like game developers, wrestlers are intensely passionate about what they do.
• Like game developers, wrestlers often accept low salaries and strenuous schedules for that passion.
• Like game developers, wrestlers on the independent circuit are usually not making a living wage from their work.
• Like game developers, wrestlers can burn out young, and struggle to find similar meaning outside their industry.
• Like game developers, wrestlers are real people who make long-lasting friendships in their work.

Of course, the same could be said of novels, music, film, comic books, or virtually any other creative pursuit. I don’t mean to imply that all these fields are the same, and I certainly don’t believe that all these properties are good things. What I do find reassuring about it—in a year when the sustainability of independent game development looks uncertain for so many of us—is that our medium isn’t unique, and it isn’t going away. Opportunities may come in different forms than we’re used to, and we may have to look for the open windows when the doors close. But if an industry built around sweaty men in briefs slamming each other into the ground can remain a staple of entertainment across the US, I think we’re going to be just fine.

Slayer Shock will be released in Q4 2016 for Windows, Mac, and Linux, and is currently on Steam Greenlight.

23 July 2019: When I wrote this blog three years ago, I was unaware of accusations against Max Landis. Since then, he has been credibly accused as an abuser, and I do not wish to endorse him or his work. I have left the original text intact but removed the link to his video. These days, I recommend Super Eyepatch Wolf’s wrestling videos instead:

• Why Professional Wrestling is Fascinating
• The Undertaker: Long Term Story Telling in Wrestling

About ten months ago, I released Eldritch. I followed it quickly with Mac and Linux ports in November and a free expansion in December. I documented the process on this blog, and stated that “the story of Eldritch isn’t over yet.” I was correct, but not in the way I thought.

Sometime during Eldritch’s development, I had looked up H.P. Lovecraft’s birthday. I can’t remember exactly why. I was probably hoping to launch on that date as a tribute to the author who inspired the game’s world and creatures. But his birthday fell on August 20, and I was nowhere near being able to ship on that date in 2013. So I put that idea in my pocket. Maybe I could do a sale on that date next year, I thought.

In early 2014, around the time I wrote the post-mortem article, I was in preliminary talks to bring Eldritch to an unspecified console. Over the following months, I made decent progress on that port, despite my inexperience on the hardware. But with a limited budget and my own uncertainty about sales on the particular platform, I eventually chose to walk away from that and focus on my next project, NEON STRUCT. I began telling people I was done with Eldritch, that I had made the game I wanted to make and I was ready to move on to something new. I released the source code in April, ostensibly an act of some finality. I dove into production on NEON STRUCT, and Eldritch became my past.

With August 20 approaching this year, I reached out to Humble and Valve to set up a 24-hour sale for Eldritch. My representative at Valve offered to make Eldritch the Steam daily deal for that date, but asked if I would have an update to coincide with the sale. I didn’t have anything prepared; Eldritch was my past, right? But landing a highly visible spot on the front page of Steam was a bigger deal than I had expected. So I took a brief hiatus from NEON STRUCT and began preparing a Steam-centric update for Eldritch.

The community had requested trading cards and achievements since launch—as they do with every game—but I had chosen not to add those things for mostly personal reasons. I didn’t understand the appeal of trading cards, and I felt that achievements were antithetical to the “play it your way” mentality of the game’s design. A year later, my feelings on those have shifted. Achievements exist for players who like to get achievements; people like myself who value the “play it your way” design don’t necessarily care about achievements, or are perhaps the most willing to play a game multiple times to get all the achievements. Either way, the presence of achievements should not detract from a player’s experience. As for trading cards, I still think they’re a bit silly; but I have spent funds from my Steam Wallet to complete my Spelunky card set, so who am I to deny someone their trading cards? I’m happy to finally bring Steam achievements and cards to Eldritch.

Adding cards and achievements was a good start, but it wasn’t a substantial update on its own. I wanted to add new content for people who weren’t also interested in those features; and secondary to that, I wanted to experiment with more Steamworks features like leaderboards. After pitching a handful of ideas around, I lighted on the concept of a small challenge mode that would fundamentally change the objective of Eldritch. Where the original levels were always about going from point A to point B (albeit in creative, player-directed ways), this expansion would be about mining the world for resources. Thorough exploration, not speedrunning, would be the dominant play style.

The result is a new dungeon, the Asylum of Azathoth. In this world, the player is charged with collecting and freeing trapped souls; but she has only three minutes in each level to do so before the chaotic deity Azathoth arrives to gobble her up. The difficulty and the pace of the Asylum are unlike anything previously seen in Eldritch, and I am eager to see what strategies players discover to maximize their soul count in the Asylum.

So, is this the end for Eldritch? I can’t say anymore. I have no further plans for it now, but it is a game that lends itself well to expansion. And every time I return to it, I recall how much fun Eldritch is to develop and to play. Maybe I’ll revisit it again in the future. For now, I hope you enjoy this update! Cthulhu fhtagn!

Last April, I began working on a game. In October, I released it. This is the story of Eldritch.

(Note: Sales info including pretty graphs is provided near the bottom of this post.)

Background

I’ve written before about the good times at 2K Marin; and if that were the whole story, it would seem ridiculous that I would ever leave that place. Sadly, it didn’t remain that way for long. The story of The Bureau: XCOM Declassified is a complicated thing, and perhaps someday, I’ll be up to the task of telling my version of it. It was a frustrating and depressing project that seemed to never end, and I watched many good friends and colleagues depart for greener pastures over the years. I contemplated finding a new job. I spoke with a few great developers about new opportunities. And I entertained the fantastic notion of “going indie” and making the games I had been longing to make for years.

In March, my wife Kim received a sizable bonus payment for her work on the Skylanders games. It was enough to pay off her student loans as well as mine, which she graciously offered to do. I suggested that I could instead take that amount and use it to fund a few months of independent development. We discussed it for a week, and the following Friday, I gave notice at 2K. Between Kim’s investment, my savings, my 401k, and a very significant number of unused vacation days, I estimated I had enough funding to survive until just about the end of 2013. It was time to get to work.

Making a Video Game

The development of Eldritch was a blur. I planned it carefully to fit my strengths as a programmer and designer, to minimize technical risks, and to be finished with enough time and money left to test, promote, and sell it. The core systems came together rapidly. I shared a playable build with a few close friends after less than two months, and continued to solicit feedback from trusted friends and colleagues on a monthly basis until its release.

The shape of the game hardened around the end of August. My original schedule had Eldritch shipping in December, but a combination of being well ahead of schedule and running a bit short on money urged me to move that up. I chose late October for the release date, avoiding (as much as possible) the hype haloes surrounding the Grand Theft Auto V and PlayStation 4 launch windows. That left me with just under two months to promote Eldritch before its release.

Marketing and Greenlight

With Eldritch mostly finished, I turned my attention to marketing. I created a website, captured footage and screenshots, cut a trailer, set up a Steam Greenlight page, wrote a press release, and prayed anyone would take my game seriously. Making the initial announcement was perhaps the single most nerve-wracking part of the entire development process. The response over the next 24 hours would determine whether I had made a huge mistake by going indie or making Eldritch.

On September 9, I flipped the switch: eldritchgame.com and the Greenlight page went live, a few dozen press release emails were sent, tweets were tweeted, and I held my breath. Within minutes, PC Gamer had posted a preview. Presale purchases began rolling in. Greenlight “Yes” votes trended above 50%. I exhaled.

Beta

I had done extensive playtesting with friends and family, but that group could only provide a narrow cross section of hardware for compatibility testing. Eldritch wasn’t the first game I would ship using my homegrown engine, but it was the first one I was asking money for, and I dreaded seeing a forum full of disappointed users who bought the game and then couldn’t play it.

My solution was to do a soft launch of the finished game, call it a beta, and try to fix all the major issues before the announced release date. For the purpose of compatibility testing, this worked well. I got a lot of useful bug reports, fixed at least one major rendering error, and even had time to incorporate a few small gameplay changes suggested by the early adopters. What I could have done better is to effectively communicate that the game was content complete. In this age of early access games and perennial updates, calling Eldritch a “beta” while presenting a Minecraft-inspired aesthetic invited players to misunderstand the state of the game and my intentions for it. (To this day, some users still mistake Eldritch on Steam for an early access game!)

An unexpected consequence of this phase of testing was discovering how many players felt betrayed by the relative ease of Eldritch compared to most other roguelike games. That was something I had never heard from my family and friends playtest sessions; and for my part, I still feel that Eldritch’s difficulty sits right where I wanted it: challenging for the majority of new players, but giving way to a feeling of mastery within a few hours instead of dozens or hundreds of hours. But happily, the beta phase provided the opportunity for me to make the eleventh hour addition of a more punishing New Game+ mode, which seems to have mostly satisfied the more hardcore players.

Greenlight

Shortly after launching the beta, Eldritch was greenlit for Steam. It took me by surprise; the Greenlight numbers had been strong, but there were still a significant number of games ranked higher than it when it was selected. I can only guess that the impending release date may have been a factor. I have mixed feelings about Greenlight (and the greater Steam developer experience), but my experience with it was obviously very positive compared to many other developers.

For better or worse, being on Steam is not an automatic windfall anymore. In fact, it looks like being on Steam may be the barest necessity for financial success for many developers. It’s a complicated topic which perhaps warrants a separate article.

Let’s Play

Eldritch has received a good amount of press coverage, from its initial announcement to reviews through the recent release of the Mountains of Madness expansion. I’m grateful for all of it, but nothing has made as big an impact on traffic and sales as being featured on high profile Twitch and YouTube channels. During the month when Eldritch was on Greenlight, I observed large boosts in “Yes” votes after each new feature video.

As YouTube and some major publishers continue to make it harder for these creators to monetize their videos, I encourage independent developers to make it easier. Get in contact with YouTubers, and make it easy for them to get in contact with you. Make preview builds readily available. Publish a written statement authorizing monetization of footage of your game. Game developers and YouTubers can have a very healthy symbiotic relationship, and if that’s something that the industry heavyweights aren’t interested in, indies will eat their lunch.

Mac and Linux

I was very interested in doing cross-platform PC development with Eldritch, but I had no prior Mac or Linux experience. I didn’t want to jeopardize the Windows release, so I decided to ship first on Windows and then consider porting to other operating systems. This would also allow me to evaluate the early sales numbers and do a simple cost-benefit analysis to ensure that I would be likely to recoup the time and money spent porting.

Then I got bored waiting for the Windows launch and just started doing it. It took less time than I expected, and I released the first Mac and Linux candidates just three weeks after the Windows launch.

I rewrote the entire Direct3D renderer to remove dependencies on the D3DX helper library. In particular, I had been using D3DX to load .fx shader files and manage render states, and porting to OpenGL would require the engine to manage render states itself. I quietly patched the new Direct3D renderer into the Steam version of Eldritch, and incredibly, it caused zero new bugs and performed slightly better. With the new renderer in place, I was able to implement a parallel OpenGL version. I targeted OpenGL 2.1 because it seemed mostly equivalent to the Direct3D 9 feature set that Eldritch uses.

I also wrote parallel implementations for the windowing, input, and clock systems, replacing Windows API calls with cross-platform SDL calls. (In Windows, I can compile the game either using the Windows API or SDL; the released version still uses the Windows API because switching to SDL seemed unnecessary.)

Finally, I installed Ubuntu and began learning how to actually build an Eldritch executable for Linux. This (and the equivalent work on Mac OS X which followed) was the most tedious part of the port: lots of mucking about with unfamiliar IDEs, searching for obscure compiler flags, and rewriting MSVC-safe code to make gcc happier. It was boring to do, it’s boring to write about, and it’s probably boring to read about. Moving on, then.

Localization

Besides the Mac and Linux versions, localization was the biggest feature I wanted to add to Eldritch after release. I had designed the textual parts of my engine to be localization-ready many years ago, but had never actually had an opportunity to use it. I also knew that my system only supported the Latin alphabet and would need to be revised for Cyrillic-based languages.

I couldn’t afford to pay a localization team (my old friend, the cost-benefit analysis, didn’t see a lot of money in translating Eldritch), but after receiving a couple of unsolicited offers to translate Eldritch for free, I decided to test the waters and ask for volunteers. The response was amazing, and I am incredibly grateful to the folks who generously donated their time to translate Eldritch to nine more languages.

In order to support the Russian and Ukrainian translations, I needed to finally make my engine Unicode-aware. This process was surprisingly painless, because UTF-8 encoding meant I only needed to change code where I loaded strings or displayed them. When storing, searching, or modifying strings, I could still just treat them as null-terminated char arrays. The biggest roadblock to Cyrillic support almost ended up being the fonts I had chosen; only one of the three fonts has Cyrillic characters, so the entire game uses a single typeface when playing in Russian or Ukrainian.

Madness

The early response to Eldritch was almost universally positive, but even the positive reviews often cited a scarcity of content as a weakness. This response, coupled with the earlier frequent misunderstanding that the game was an early access title or would receive perennial updates, steered a lot of conversation about Eldritch in the direction of “what will the developers add next?”

My initial plan was to add nothing next. In my mind, Eldritch is a complete game, a short but endlessly revisitable adventure that respects the player’s time instead of dragging on. But it is also the sort of game that lends itself well to expansions. It is pure, unburdened by narrative, and straightforward to pin new levels, enemies, and weapons to the existing structure of the game.

When I was reading a lot of Lovecraft and mentally filing ideas away for inclusion in Eldritch, At the Mountains of Madness was a story I felt deserved more room than I could have given it in the original game. I borrowed its shoggoths but left the rest for another day, and the idea of an adventure set in the semi-abandoned cities of Antarctica was the only choice I ever considered for the expansion.

The decision to release the expansion for free was a risky one, which sadly didn’t pay off exactly as I’d hoped. While a few players had expressed a willingness to pay for more content, many more had commented on the brevity of the original release with a more disappointed tone. My plan was to release Eldritch: Mountains of Madness for free as a gesture of appreciation for satisfied players and of good will to those who felt slighted by the length of the original game. It would not generate any revenue directly, but a free expansion would provide another opportunity to promote the game and a good hook for more press coverage. Unfortunately, I didn’t consider that so much of the press would be shut down on holiday just around the time of the expansion’s release. I appreciate the coverage it has received, but it was not the well-timed tidal wave of promotion I had hoped for.

Costs

The primary cost of developing Eldritch was the burn rate of my own living expenses: rent, utilities, food, etc. I effectively took a 45% pay cut compared to my former salary, and I did my best to forego unnecessary purchases until Eldritch began generating income. Other significant costs included middleware licensing and contractor payments. All told, it cost somewhere in the vicinity of $22,000 to make Eldritch, $4,000 to port to Mac and Linux, and $5,000 to make Mountains of Madness. My first sales target was simply to recoup those costs (plus taxes) so that I wouldn’t have lost money making this game.

Sales

The time from Eldritch’s initial announcement (September 9) to its proper release date (October 21) was exceptionally short by industry standards, and I don’t know exactly what the effect of that may have been. Perhaps the prompt release helped capitalize on initial excitement surrounding the announcement. Or perhaps Eldritch would have been more successful with six months or a year of slowly teased information to build hype.

Inspired by Hitbox Team’s transparent Dustforce sales report, I’m going to share Eldritch’s sales over the past three months. Please be aware that the dollar figures shown below are the gross revenue, before Steam and Humble take their cut, and before taxes are paid. After fees, shares, and taxes, Minor Key Games makes roughly 43% of that amount.

By any measure, Eldritch is a success, but not a mind-blowing one. I would characterize it as a good start for the company, with plenty of room to grow. Its sales have been more than sufficient to hit my modest goals, and enough that I will get to keep making games independently for at least another year.

Eldritch became available for presale via Humble on September 9, the day it was announced. The announcement was echoed around various websites for most of that week, leading to a fairly wide initial spike before dropping to a steady rate of sales. There was a small spike on September 26, when the beta became available, but that event was not heavily promoted and the sales leveled out again.

Then the official launch happened, and the second wave of press coverage hit, and Eldritch was featured on the front page of Steam for a while. The day 1 sales immediately dwarfed the entire presale period. Launch sales were bolstered a little bit by inclusion in the Steam Halloween Sale (at the launch discount of 20% off), and then the daily sales leveled out once again after a couple of weeks. By this time, Eldritch had recouped its initial development cost.

The Mac and Linux ports were released without much promotion in early November—an intentional (albeit questionable) choice to give them a gentler landing at the cost of some coverage. The next spike occurred during the Steam Autumn Sale, when Eldritch was offered at a 50% discount. Shortly after this, I wrote that Eldritch had sold 12,000 units at an average price of $12, and I thought that was the end of the story.

Then this happened. During Steam’s Holiday Sale, Eldritch was offered at an 80% discount ($3) in an overnight Steam flash sale (2 a.m. – 10 a.m. PST). I knew it was coming, but I had virtually no expectations for it. It looked like a poor timeslot, and I didn’t realize just how important front page visibility is during a Steam sale. When I woke up that morning, I quickly tweeted about the sale and then logged in to check the overnight numbers. I thought I was looking at the wrong numbers at first; Eldritch had literally doubled its units sold overnight! Even at such a low price, the revenue from the flash sale exceeded the total revenue of the Autumn Sale and the rest of the Holiday Sale combined. It was also during this sale that the Mac and Linux ports finally recouped their development cost, with an unexpected 11% of purchases during those eight hours coming from Linux users.

In its first three months on sale, Eldritch grossed over $215,000. After subtracting fees, taxes, and Steam and Humble’s shares, it has generated almost $100,000 for our company, or approximately a threefold return on investment.

What Now?

2013 was an amazing year for my career, and the story of Eldritch isn’t over yet. The total number of units sold (about 32,000) is still low enough that there seems to be value in my continuing to promote the game and build awareness. Further sales will surely continue to draw more players, and later, I would be interested in including Eldritch in Humble-style game bundles.

The big question is whether it is worthwhile to continue to develop Eldritch or move on to the next (possibly Eldritch-related) project. Features like mod support and Steam achievements continue to be highly requested, but the cost-benefit analysis for those doesn’t look great. Mod support would be difficult to do right (beyond simple features like texture packs) and would require a larger active user base to flourish. Perhaps mod support could help grow the user base, but we’re living in a post-Minecraft world, and I question how much excitement the addition of mod support to a game like Eldritch could realistically generate.

Thank you all for your support of Eldritch so far, and I hope you enjoy whatever we do in 2014!

As independent game developers, Kyle and I want to be more open and transparent about development than we could be in our AAA past lives. Kyle explained the reasons for this in some detail in his indie announcement, but my interpretation is: silence is a form of dishonesty. The ubiquitous “no comment” deflection serves mainly to obscure unattractive truths about a product. I would rather be frank (“Sadly, Eldritch won’t have cooperative multiplayer.”) than to lead a customer on (“We can’t talk about our plans for multiplayer yet.”).

So in September, I announced Eldritch for Windows only, and the inevitable question of other platforms was asked. I explained, in cautiously noncommittal terms, that I was certainly interested in doing Mac and Linux versions, but they would not be available at launch. In retrospect, I wonder if I should have been more open about the reasons (Eldritch was written on a custom engine that only targeted Direct3D, I had only purchased an FMOD license for one platform, etc.), but this answer seemed to satisfy people.

Of course, I would have liked to ship on Windows, Mac, and Linux simultaneously; but I had no prior experience with Mac or Linux development, no idea how long it would take to port my engine, and a very constrained schedule due to my budget. So I planned to ship on Windows first, then do a cost-benefit analysis to determine if and when it would be beneficial to release on the other platforms. For the cost, I estimated 4-8 weeks of my salary (inasmuch as I have a salary), plus the FMOD licensing fees for the additional platforms. That’s a relatively small sum, but my other debts take precedence. Benefits are harder to determine. Common knowledge puts the combined Mac and Linux gaming market share at around 10% of Windows. Being cross-platform also opens other doors, such as the potential for inclusion in Humble Bundle sales, but I could not rationally depend on that in my analysis. I finally determined that if Eldritch sold on the order of 15,000 copies (at full price on Steam), then it would become beneficial to move forward on the port.

Then something unexpected happened. I ran out of bugs to fix during the Eldritch beta. I added a New Game+ mode because I had the time to do it. I started to get bored. So I decided to investigate what it would take to make my engine cross-platform. Investigation turned into implementation, and after a couple of weeks, I was sitting on a relatively portable codebase. The estimated 4-8 weeks from my cost analysis vanished, rolled into the time I had allotted for finaling the Windows build.

At the moment, I have Mac and Linux alpha builds ready for testing, and I intend to send those to interested friends next week. A wide release is still pending the aforementioned FMOD license fee, although I am reconsidering its priority relative to my other debts in light of the new timing.

All of which is a very long-winded way to finally confirm that Eldritch is coming to Mac and Linux. I’ll follow up (probably on Twitter, in somewhat fewer words) when I figure out the release date, but rest assured that it won’t be long.

I quit my job in March.

I worked at 2K Marin for over five years, and I quit my job in March.

I didn’t make a lot of noise about it at the time, in part because I was still figuring out what I would do next, and in part because I didn’t want to draw any negative attention toward 2K Marin and the nascent XCOM project (now re-revealed as The Bureau: XCOM Declassified, which I’m thrilled to see is getting a much warmer reception this time around).

Making XCOM was a long and strange journey, and I hope to share some of those stories after the game is released; but today, I want to reflect on the early days at 2K Marin. Making BioShock 2 has been the highlight of my career so far, and I can’t imagine a more passionate and supportive team than the people I worked with on that project.

I had less than a year of professional experience under my belt when I applied for a job at 2K. I hadn’t yet shipped a game. I had a borderline stalkerish knowledge of the BioShock team. In retrospect, I don’t quite understand how I got the interview, much less the job, but I am eternally grateful to Alyssa Finley and Carlos Cuello for taking a chance on a huge BioShock/Irrational fanboy.

I was introduced to Jordan Thomas on my first day, but I didn’t actually know him by name. Only later, after coworker Johnnemann Nordhagen (now of The Fullbright Company) reminded me of Kieron Gillen’s fantastic PC Gamer article “Journey Into the Cradle,” did I realize that our creative director was the same man who designed Shalebridge Cradle and Fort Frolic.

I geeked out a lot in those days.

The early days of 2K Marin were a surreal experience, far removed from the norms of AAA game development. We were a tiny team, focused on bringing BioShock to the PS3 and full of heady ideas about a sequel. It felt more like a garage band than the newest branch of a multi-million dollar corporation. I was outside my programming comfort zone, maintaining Ruby scripts for a fragile build process, and I didn’t even care. The vibe was amazing.

We soon moved into a larger space and began growing the studio to develop BioShock 2. We hired a couple of fantastic AI programmers, Matthew Brown and Leon Hartwig, who I would later be fortunate to join on the AI team. I got to learn from an incredible design team: Jordan Thomas, Zak McClendon, JP LeBreton, Steve Gaynor, and Kent Hudson, to name a few.

I learned as much as I could. I gave as much as I could.

A tangent: I anchor the years of my life with particular events and use that to contextualize everything else. I guess everyone does this, but I feel like I’m particularly conscious of the process. I moved to Great Falls in 1992 (the year Super Mario Kart launched). Our apartment caught fire in 1998 (the year Unreal launched). I got married in 2007 (the year BioShock launched).

I don’t remember a lot of 2009.

I mean, I do. I remember drinking Anchor Steam and playing Persona 4 in a hot apartment. I remember jocular AI team meetings with Matthew Brown, Kent Hudson, Harvey Whitney, and PJ Leffelman. I remember staying late at work, gorged on bad Chinese food, trying to solve some elusive bug in the last level of the game. But I don’t have an anchor. When I try to contextualize events around that time, that entire year is simply the year I spent making BioShock 2.

And I’m okay with that.

Because that experience is everything I ever imagined game development could be. I loved the game I was making. I loved the people I was working with. I loved the work I was doing. What more could I ask for in a job?

I played BioShock 2 again this week. The last time I played it was the week it launched, in February 2010. Three years later, I still clearly remember the shape of the thing, but I’ve forgotten the details. Some parts are better than the version in my memory. Some are worse. I try to imagine what it would be like to have played this game as a fan, as someone who loved BioShock but wasn’t involved in the creative process for two years.

I can’t do it.

The game is inseparable from my memories of making it. I see the room where the player is first taught to use Electro Bolt to shock multiple splicers in a pool of water, and I immediately recall a bug that made splicers interrupt themselves halfway through a sentence. That room was my test case for that bug—it gave me an easy way to observe enemy AIs using dynamic VO barks without ever attacking the player. I am certain that if I revisit the game in twenty years, that bug will be the first thing I remember when I see that room.

I’m okay with this, too.

I loved BioShock. I loved it as a fan. I loved System Shock 2, as a fan. I wanted to work at Irrational because I was a fan of the games they had made. Years later, with older and wiser eyes, I can look back and be glad I never worked at Irrational. But I will never regret working at 2K Marin during 2008 and 2009. I think I appreciate BioShock 2 more as a developer than I ever could have as a fan. I will never have to question whether it was too similar to the first BioShock, or whether another visit to Rapture was really necessary. It doesn’t matter to me. I was a part of something special, the transient convergence of a hundred or so brilliant people, and that is more important than any video game could ever be.

(RIP Eden Daddy)

I have built most of my career on and around immersive games; in particular, that murkily defined subsection of first-person action games known as immersive simulations. That genre, defined by the titles of Looking Glass Studios, Ion Storm Austin, and Irrational Games, has experienced a minor resurgence during this generation. But the term “immersion” has also been co-opted as a buzzword for big budget games, where it may be used to mean anything from “atmospheric” to “realistic” to “gripping.”

Recently, Robert Yang wrote an article in which he suggested that “immersion” is now merely code for “not Farmville” and that we as developers should abandon the term.

Although I agree with Yang regarding the unfortunate overloading of the word “immersion,” I believe there is still value in using the word to describe that particular brand of games which evoke that particular kind of player engagement. I propose that instead of abandoning all concept of immersion, we establish a clearer understanding of what makes a game immersive.

Justin Keverne (of the influential blog Groping the Elephant) recently said to me: “I once asked ten people to define immersion, all ten said it was easy, all ten gave different answers.”

This is my answer.

Immersion not about realism

“Realistic” is an unfortunate appraisal in games criticism. Realism is a technological horizon: the infinitely distant goal of a simulation so advanced that it is indistinguishable from our reality. This is problematic for at least two reasons.

As a simulation approaches the infinite complexity of reality, its flaws stand out in increasingly stark contrast. This effect is customarily called the uncanny valley when referring to robotic or animated simulations of human beings; but I find Potemkin villages to be a more apt metaphor for its effect on video games, as a modern action-oriented video game needs to simulate much more than one human character. Games have advanced over the past two decades primarily along the axes of visual fidelity and scope, with very few games exploring the more interesting third axis of interactive fidelity. This arms race toward faux realism has produced a trend of highly detailed but static environments: doors and cabinets which cannot be opened, lights which cannot be switched off, windows that do not break, and props which are apparently fixed in place with super glue.

The second problem with the pursuit of realism is that reality is not particularly well-suited to the needs of a video game. Reality can often be dull, noisy, or confusing; it is indifferent to an individual and full of irrelevant information. A well-made level is architected, dressed, and lit such that it guides the player through its space. Reality is rarely so prescriptive; its halls and roads are designed to lead many people to many destinations. In fact, those non-interactive doors and lights which reveal the pretense of a game world are non-interactive specifically because they don’t matter. This paradox between the expectations of a realistic world and the prescriptive focus of a video game becomes more apparent as games move toward greater realism.

For these reasons, the pursuit of realism is actually detrimental to immersion.

Immersion is about consistency

In his postmortem for Deus Ex, Warren Spector described how the team at Ion Storm Austin cut certain game objects because their real-world functionality could not be captured in the game. It may not be realistic or even especially plausible that Deus Ex’s future world would lack modern appliances, but the decision to cut these objects unasked the more obvious questions about their utility.

Consistency in a game simulation simply means that objects behave according to a set of coherent rules. These rules are often guided by realism, because realism provides the audience with a common understanding of physical properties, but they are not beholden to it. Thief’s exemplary stealth gameplay is based on a rich model of light and sound, quantized into a small number of intuitive reactions. In BioShock, objects exhibit exaggerated responses to real world stimuli like fire, ice, and electricity; but also to fictional forces such as telekinesis.

Adherence to a set of rules provides the opportunity for the player to learn and to extrapolate from a single event to a pattern of similar behaviors linked by these rules. In their GDC 2004 presentation Practical Techniques for Implementing Emergent Gameplay, Harvey Smith and Randy Smith showed how simulations with strongly connected mechanics may allow the player to improvise and accomplish a goal through a series of indirect actions. When a player is engaged in this manner, observing and planning and reacting, she is immersed in the game.

Immersion is broken by objects which behave unexpectedly or which have no utility at all. When a player attempts to use one of these objects, she discovers an unexpected and irrational boundary to the simulation–an “invisible wall” of functionality which shatters the illusion of a coherent world. Big budget games seem especially prone to this failure condition, as they contain large quantities of art which imply more functionality than the game’s simulation actually supports.

Immersion is a state of mind

As I suggested above, a player becomes immersed in a game when engaging with its systems with such complete focus that awareness of the real world falls away. Immersive sims, a more strictly defined genre, may exhibit certain common features such as a first-person perspective or minimal HUD. While these aspects may be conducive to player immersion, they are not strictly necessary; any game which produces this focused state of mind is immersive. (In fact, one of the most immersive games I have played recently is the third-person Dark Souls.)

Outside of video games, there is a term for this state of mind of complete focus and engagement: flow.

Immersive video games are those which promote the flow state via engaging, consistent mechanics, and sustain it by avoiding arbitrary or irrational boundary cases.

Further reading

Adrian Chmielarz recently published a piece criticizing the ways in which highly scripted games break immersion, and suggested a contract of sorts in which players would forego game-breaking behavior if developers would smooth over the edge cases that reveal the boundaries of a game’s scripting.

Casey Goodrow wrote a response to Chmielarz’s article in which he further highlighted the tense relationship between immersion and realism and argued that a player who breaks a game by boundary testing its systems is actually immersed in that game.

My favorite games of the year, in no particular order:

Dishonored
This was my most anticipated game of the year and it didn’t disappoint. Great mix of stealth and BioShockish combat. Fantastic controls. Unique art direction. Story is nothing spectacular, but it’s hard to find fault with anything else.

Borderlands 2
Better in every way than the first, but especially in the writing. I didn’t expect some of the year’s funniest and most poignant moments from a Borderlands.

The Walking Dead
Maybe the best written characters and scenarios in any game ever. I’m still not done with this one.

Spelunky
I’m also not done with Spelunky and may never be, because it is fiendishly difficult. But that’s part of a Roguelike’s addictive appeal, and this is the most fun, polished, and accessible that a random/permadeath game has ever been. It’s my Desert Island Game of the Year 2012.

FTL
I logged more hours in 2012 on FTL than anything else, but that’s mostly because I kept it open at work so I could jump in and take a few turns during long compiles. Like Spelunky, it’s a pretty lightweight and accessible game with roots in the Roguelike genre, but it runs in a different direction with less chaos and more meaningful choices.

Far Cry 3
I had mixed feelings about Far Cry 2—it seemed like a great game that actively hated the player for being a part of it—and I understand why some critics are disappointed that Far Cry 3 is a more colorful, easier, and less meaningful take on the same premise. But it just works for me. Sometimes I just want to play a stupid game where I can punch a shark in its sharky face, and this is that game. Far Cry 3 also gave me some of my favorite emergent moments of the year, like when a tiger wandered into the camp I was sneaking around and caused a fantastic and unexpected diversion.

Dark Souls: Prepare to Die Edition
This is cheating, because Dark Souls originally shipped in 2011, but I replayed it on PC (and about 2/3 through again in New Game+) and probably spent more actual time in it than any other game this year. Fantastic design and world building. Minimal yet significant narrative. Incredibly tense and rewarding multiplayer component.

XCOM: Enemy Unknown
Firaxis did a great job maintaining the spirit of the original while modernizing and streamlining the controls and interface. Its relative commercial success is a good sign for the industry, because everyone said turn-based strategy games couldn’t sell in 2012. Now that they’ve been proven wrong, maybe we’ll get more games like this and Valkyria Chronicles.

Mark of the Ninja
Not my favorite stealth game this year (that’s Dishonored), but a beautifully executed deconstruction of the stealth genre. Stealth games should be taking pointers from this game for years to come.

DayZ
I didn’t play much of this, but the few hours I did play were some of the most engaging and tense hours of sitting quietly I’ve ever done in a video game. It’s got a whole lot of rough edges, but the experience is something special. I hope the standalone version fixes the big problems and pulls me back in.

Fez
Shrug. It’s Fez. Deal with it.

Incidentally, 2012 was a huge return to PC gaming for me. I played every one of these games on PC except for Mark of the Ninja and the XBLA-only titles Spelunky and Fez.

Procedural content generation has fascinated me for a while, but until recently, I’d never had a project where it was an appropriate solution. After disappearing down the rabbit hole of making a content-rich indie FPS, I decided that my next project should have minimal content needs. This led me to start a new game, Second Order, which would follow some guidelines for maintaining scope.

• Infinitely large, pseudorandom, procedural world
  • Time invested in developing the world provides infinite possibilities instead of only one static world
  • Removes any potential for scripting, which saves development time and reinforces player-driven design goals
• Data-driven game configuration
  • Procedural generation algorithms are defined in text files (which end users are free to modify)
  • Entity definitions use a component-based or composition model and are also defined in text files
• ASCII graphics
  • Very constrained visual tools
  • Less potential to feature creep toward shinier graphics
• No audio
  • This constraint makes me sad, because audio is often the secret sauce that makes a good game great
  • But audio is not essential to the goals of Second Order, and it would likely create a dissonance with the low fidelity of the visuals

I was not too familiar with procedural generation considerations, and ended up solving a few problems which are probably quite common to this sort of game.

Because the world in Second Order is infinite, I cannot generate it all at once. Like other games with procedural terrain, I generate the world in chunks as the player approaches unexplored regions. This presents the first challenge: pieces of the world are pseudorandomly generated in an arbitrary order, yet must be consistent regardless of the order in which they are generated.

The solution to this problem is to not actually use any random calls during world generation. Instead, my noise functions are seeded at the start of the game and remain spatially consistent for its duration. (I won’t go into detail about noise functions here, as I feel those are well and thoroughly documented in other places; but if you are familiar with Perlin noise, I am simply referring to the initialization step of seeding the precomputed arrays with random values.)

The second challenge is that the terrain must be continuous across chunk boundaries, which effectively ruled out doing any kind of neighbor-aware multi-pass algorithms. For example, I might have wanted to do a two-pass generation where I first generate a smooth terrain, then erode it by simulating rainfall and soil displacement. But that kind of erosion algorithm is global. Each tile’s second pass value is dependent on its neighbors’ first pass values. At chunk boundaries, there may not be neighboring data (because the adjacent chunk is outside the player’s proximity sensor and has not been generated yet). This meant that multi-pass algorithms would need to extrapolate from available data to evaluate boundary tiles, which would produce discontinuities along the boundary when the further chunk is eventually generated.

My solution to this is simply to forbid multi-pass algorithms and develop techniques which produce desirable results in a single, (mostly) neighbor-independent pass. I find it useful in places to evaluate a subtree on a neighboring coordinate, as I will describe in more detail below. This works fine (because spatial consistency is guaranteed) as long as that subtree is not mutually dependent on the value of the local coordinate–that would cause infinite recursion.

Finally, as described in the guidelines above, I want the procedural generation algorithm to be not only data-driven but actually completely defined as content. The ambitious and unstated goal is to eventually provide Second Order as a platform for making new action games, so I don’t want there to be any assumptions in the code about the nature of the terrain.

To that end, the code’s view of the algorithm is very generic. It essentially runs a functional programming “shader” on each tile in each chunk.

To illustrate this process, here are some examples of both organic and constructed terrain being generated in the engine.

First, a simple terrain of sand, grass, and water is produced by thresholding two noise functions. At the bottom of the tree (on the right side of this graph) are the generator nodes. If speaking in terms of shaders, consider these as textures. They are the source of all subsequent values in the program. The green leaf nodes are generators which emit a floating point number, and the red leaf nodes emit a terrain struct containing visual and collision info. The switch nodes take a floating point as input, compare this value against some configurable thresholds, and pass through the value of the appropriate child node.

BiomeNoise is a low frequency noise generator which defines the macro landscape features: deserts, large bodies of water, and the grasslands in between. The output of this node is a floating point number which is used by the BiomeSwitch and Ocean nodes to select which of their children to evaluate.

TerrainNoise is a high frequency noise generator which defines micro details within the grasslands: smaller bodies of water and sandy regions surrounding them. Note that the black spots in this image are not an artifact of the noise function; these are simply empty holes where the TerrainNoise function did not need to be evaluated (because the biome noise was above the desert threshold or below the ocean threshold, and BiomeSwitch selected its Ocean or Sand children instead of TerrainSwitch).

The switch nodes are used to combine the terrain structs according to the values of the noise functions, and the result is an infinite, non-repeating terrain.

This is actually the terrain that Second Order is currently using, albeit without the streets and buildings layered on top of it. The method I use for generating man-made terrain produces rather unrealistic (regular and axis-aligned) features. As such, I don’t recommend this as a way to build interesting cities; instead, it is intended to show how complex procedural geometry can be built in a single-pass functional program.

This graph is similar to the simple terrain one, but now the midrange biome is a MUX (multiplexer, or Boolean switch) between streets and the grassland we saw above. The blue nodes are new, and indicate that the node has a Boolean output.

(Sharp-eyed readers may note that I’m not being as efficient with my Boolean operations as I could. !(A&B) would be one fewer operations than (!A)|(!B). I also wouldn’t need to use the NOT operators at all, except that I will later use those same generators for buildings, with streets filling in the negative space between the buildings. In any case, these generation shaders are relatively cheap, and I sometimes find it useful to have these masks of intermediate steps to reuse for future operations.)

I begin by generating noise in one dimension. This generator is named BuildingGenX, and will later be used to generate buildings. As such, the streets will be formed from the inverse of this data, so as to fill in the space between buildings. (Note that, as before, the black holes in this and subsequent images are regions in which this function did not need to be evaluated.)

The floating point values are quantized at a given threshold to produce a Boolean mask. This represents the space which buildings might inhabit in this dimension…

…and that mask is inverted to produce the space in which streets will exist.

I repeat these same steps with another generator in the Y dimension and combine the results of each mask with an OR operator.

Separately, I produce a mask from the terrain noise generator. This represents areas which are sufficiently far from the sandy and watery regions in the grasslands biome.

These two masks are combined with an AND operator to produce the final mask for streets.

The MUX selects the street terrain info in all the spaces where the street mask is high, and fills in the rest with the grasslands terrain.

Finally, we want to create buildings in between the streets. Buildings present some new challenges, because I want interesting floorplans (not just rectangles in between the streets) and I want the walls to always be one tile thick.

The graph has grown significantly here, but the patterns are the same as what we have seen before. Floating point numbers (green) are generated on the right, quantized into Boolean values (blue) and combined through the middle of the graph, and used to select the appropriate terrain info (red) at the left.

One new node I introduce here is a white noise generator in one dimension.

When quantized, this tends to produce thin lines which are ideal for corridors.

By generating and combining many corridor and room masks (in much the same way as the streets were created before), I produce this mask which represents the complete potential floorplan for all the buildings in the world.

In order to generate walls of a consistent thickness, I use an outline operator. This is the neighbor-aware step I alluded to earlier. It evaluates the floorplan mask at its local coordinate and each adjacent coordinate and emits a boolean if its local value is false and it is adjacent to any tile whose value is true.

I then OR the floors and walls masks together and AND the result with a high frequency noise mask to produce this, the actual space in which buildings will be created. (The high-frequency noise is used here to create the appearance of damage or wear to the buildings, suitable for the weathered world of Second Order.)

Before drawing the walls and floors, I use another combination of the corridor and room masks to punch out doorways at the ends of some hallways.

A series of MUXes is used to select between the various parts of the midrange biome: terrain, streets, and buildings with its walls and floors. This is the actual terrain which I am using in the current version of Second Order.

The last part of my procedural generation is to place entities. I won’t explore that topic in depth, as the fundamental ideas are the same: generate some noise (in this case, two-dimensional white noise), filter it, and switch based on many of the same masks that are used to generate the terrain (so we don’t end up with cacti in the ocean, or enemies spawned in the walls of a building).

The complete graph for terrain and entity generation looks like this:

You can download Second Order now and edit the configuration files to experiment with its procedural generation. While the game is running, you can export the procedural generation graph with the G key, or export any nodes tagged with “ExportStage = true” by pressing Shift + G.

…but very little to say at the moment. WordPress was super easy to install, so that’s cool. I may migrate my old Blogger content over here eventually–it depends largely on whether I continue writing or not.

In the spirit of my sometimes-weekly project updates from that blog, here’s a choice selection from my recent SVN checkin comments:

REMOVED A SEMICOLON ALL RIGHT GO TEAM

I’ve actually been doing primarily content creation and not programming this year. I’m currently just trying to put together a vertical slice consisting of the first level of the game, to include three weapons, two enemies, and all core gameplay components. When that’s done, I’ll solicit feedback, first from game-savvy acquaintances, then perhaps a second round with less ludically-inclined family and friends. From there, the plan is to build out the remaining (3 + tutorial) levels for a release sometime next year. It’s taking a very long time to make this game, but it’s still fun and I’m looking forward to sharing it.