October 14th, 2011
Category: development

comment on this »

IndieCade 2011

Last weekend, the IndieCade festival took over downtown Culver City. You can think of it as an art walk where you get to play independent video games.

Gallery halls commandeered by gaming laptops and installations. A firehouse packed to the walls with folks playing really fun, weird stuff. It’s glorious. Brief notes on some of the things I saw:

  • AntiChamber – one of the most original first-person games I’ve seen. I imagine this is what would happen if Salvador Dali and Andy Kaufman worked on a game together.
  • Desktop Dungeons – I love roguelikes, so of course I love this. Somehow they’ve taken one of the most obtuse game genres, removed the obtuseness, leaving you just the the gooey fun center.
  • Johann Sebastian Joust – I consider the Copenhagen Game Collective folks to be the most punk rock of indie games. A motion-control game that doesn’t use a monitor or television? Slow motion ballet-battle? I love it. My best of show.
  • Skulls of the Shogun – Turn-based tactical squad game with hard counters and long-term and short-term strategies. This scratches a lot of itches for me (seven of them).
  • Proteus – I’ve written before about games that downplay combat and blowing things up, and was really delighted to get to see something like this in action. Do check it out.

 

This is just a few of the showings. For the full list of all the IndieCade 2011 games, check ‘em out here.

One of the most wonderful things about IndieCade is that it’s smack dab in the middle of downtown Culver City, so a lot of visitors were people who just happened to be passing by. There’s something wonderful about such a diverse cross section of the population getting exposed to these games – natch, not just games, but these beautifully daring pieces of work.

If you’re in the LA area, make it a point to visit next year.

October 11th, 2011
Category: development

12 comments

Ghost Writer

I was recently playing Deus Ex: Human Revolution. It’s well-made, and manages to fill the planet-sized shoes left by its predecessor, the original Deus Ex.

The DX games are renown for giving the player a sizable amount of agency. Naturally, whenever I meet an important story-critical character, I surround them with live grenades.

The grenades detonate. But as long as a character is critical to the story, the grenades don’t leave a scratch of damage. Why? Because, well, the character is critical to the story. Casablanca would be a pretty short movie if Ilsa was killed off after the opening credits.

You need to keep the love interest around because you need to ultimately ride off into the sunset together. You need to keep the villain alive because you need that climactic final showdown. You need to keep the spunky best friend alive long enough to generate a bond, then you kill him off to propel the protagonist into a raging rampage of a third act.

To which I say: yeah, but this is a video game. It’s interactive: you can poke and prod and steer, and the game can respond in kind. What happens if you lock the antagonist’s keys in his car? How will your love interest respond to your secret double-life of underground breakdancing?

One of the most fascinating aspects of games is transferring authorial control to the player. This is certainly not the only way or best way to make games, but it’s something I find most compelling about the medium.

Let’s take DX for example. Under the hood, DX is a variation on a Choose Your Own Adventure story. Decisions you make ripple out and affect other characters and the story.

For every decision fork, the developers have to create more content, resulting in “more” everything – more art development, more animations, more designer scripting, more writing, more recorded dialogue, more bugs, more QA testing – more of everything. It’s a production nightmare. I’m always very impressed whenever a game with branching structure turns out polished and complete.

I’d love to see someone take the general DX framework – an agent tackling problems aggressively, stealthily, diplomatically, what have you – and scale it down. Instead of several cities, make it take place in a tight, richly-detailed area. Say, a hotel restaurant.

On top of that, remove the Choose-Your-Own-Adventure scripting and have the characters behave autonomously (I’m going to be very hand-wavey and vague here, so bear with me). Instead of following a script, story characters “improvise” via granular AI decisions.

Let’s say at game start, character roles are randomly assigned.

  • There’s a crew of diplomatic envoys in town to sign the peace treaty. They love getting drunk, they love to party down.
  • There’s your jilted former lover, working undercover as a waitress. She has an itchy trigger finger and two strikes on her record.
  • There’s an enemy assassin. The sous chef. He’s in the middle of a crippling mid-life crisis.

Drop these personalities into a constrained area. See how they bounce off one other. See how you bounce them around.  On the AI systems’ own accord, various situations emerge:

  • The paranoid assassin grows increasingly suspicious. Not at you, mind you, but toward a textiles salesman from Omaha.
  • The diplomats party a little too hard. One gets alcohol poisoning and requires immediate attention.
  • Against orders, the undercover waitress blows her cover and saves the diplomat. This doesn’t escape the notice of the paranoid assassin. Incredibly, he grows even more paranoid.

 

Now, regarding this mythical game I’m talking about: ideas are a dime a dozen, and execution is where things matter. This is far from being executable. It’s the opposite of bulletproof. It has more holes than a sieve, hence the hand-waveyness. It’s a phenomenal way to lose a frightening amount of money and resources and hair.

And I can’t wait to play it.

Some games that explore these concepts: Hitman, Facade, Alpha Protocol, The Sims, Dwarf Fortress.

 

 

October 4th, 2011
Category: development

2 comments

Pathways Redux Part II

To read Part I of this writeup, click here.

In 2004 I made a Doom 3 mod called Pathways Redux – a mini-remake of Bungie’s Pathways into Darkness. Here are some notes on its development.

Scope control

One summer, I took a television production course. The instructor showed us a pie graph with three sections:

  • High Quality
  • On Budget
  • On Time

He then told us that a production could have two of those things. Just two; never all three. He was a real cheery guy.

Me being young and idealistic, I didn’t entirely agree with him. But it made something click in my head. My hard drive had (and still has) a bewildering amount of incomplete game prototypes. I realized all I had to do was cut the scope of the game in half. Shorter project = less bugs, more polish, higher quality. And you get to actually finish making it!

Pathways into Darkness is a huge game. There was no way I was going to remake the entirety of PiD, so I focused on a tiny section. For Pathways Redux, I decided to tackle no more than an intro sequence and the first few levels.

First Impressions

PiD has a fairly elaborate series of events preceding the game.

  • An alien diplomat appears in the White House.
  • Your commando team is airdropped into the Yucatan.
  • You are separated from your team.
  • You make the solitary trek to the cursed pyramid.

That’s a lot of information! PiD starts you inside the pyramid. I decided to have some fun and try to pack all that information through an in-game sequence.

My first thought was to start you off in a military hangar in North Carolina. You and your crew would be briefed on the situation, then board the transport plane.

Then I realized: a slideshow briefing? Listening to some commander-type guy talk about a mission? This was lazy design. It was a boring, unimaginative way to convey a ton of information. Also, I’d already done this in a previous project, Bootleg Squadrog. So that’s strike two!

When I start a game, I want to play it. I do not want to watch a cutscene or listen to inane backstory. So I decided to instead start by throwing the player into the deep end of the pool: falling through the sky with a broken parachute. Way better than a slideshow!

Of course, the parachute sequence is soon followed by a page-long wall of text describing the backstory.  Nope, I have no good excuse for that.

Script-fu

Pathways Redux and Barista 3 (and Barista 1) were my first forays into text-driven scripting. Prior to this, I had used visual scripting systems. Visual scripting generally looks something like this:

  

Objects are are visually displayed. These objects are scripted via GUI-driven windows.

Text-driven scripting is done via plain ol’ text files. Here is the script to Pathways Redux’s first level: pathways_para1.txt

Depending on how your brain is wired, you’ll like one more than the other. Visual scripting gets the benefit of better error-checking and sanity checks, and, well, being able to visually see the connections between your script objects. Text-driven scripting grants you more control and flexibility. Doom 3′s scripting system gives a tremendous amount of control over the game world – it’s remarkable how much freedom you get.

I enjoy both systems, though I lean toward text scripting. Once a level or game reaches a certain level of complexity, I find visual scripting becomes cumbersome. It starts to feel like a middle-man you’re forced to talk to – a mild-mannered, helpful middle man, but a middle man nonetheless.

Level persistence

Doom 3 consists of a series of levels played in a linear order. Pathways, on the other hand, is a series of connected levels the player can visit and backtrack as they please.

The most straight-forward approach was to just connect the levels the same way Doom 3 did. If they want to revisit a previous level, just re-load that previous level. Right?

The problem with that is persistence. For example, let’s say the player picks up an ammo clip in level 1. If the player later decides to re-visit level 1, the game has to “remember” the player had taken that ammo clip earlier. If I just directly re-load level 1, that ammo clip will always re-appear at the same spot – that’s bad.

I got around this by taking advantage of Doom 3′s scripting system. Here’s a sample script chunk when level 1 is loaded:

		if (sys.getPersistantFloat("got_stepammo2") > 0 )
		{
			$ammo_bullets_small_8.remove();
		}

 

When the level is loaded, it checks the flag “got_stepammo2″. If the flag is True (the player has already acquired that ammo clip), then I remove that ammo clip from the world. Otherwise, that ammo clip is left untouched.

Is this a ridiculous way to do things and totally unfit for a production-length game? Yes! But for this mini-production, it was fine.

Dogfooding

When making a game, it’s important you’re also playing it yourself. This sounds like a no-brainer, right? Why would you possibly not want play the game that you’re making? Because: it can get extremely frustrating and demoralizing to play something incomplete, ugly, buggy, crash-prone, and un-fun.

It’s tempting to put off your testing until you get further along into the game. But you’d just be sabotaging yourself. By the time the project is that far along, the infastructure will be too rigid and it’ll be too late to do any course-correcting.

As I play through my own game, I jot down notes on things to fix or add. Afterwards, I address each item one-by-one like a grocery list. Here’s a page from Pathways Redux:

Most of it is written in spur-of-the-moment shorthand. This can get embarrassing when I finish the playtest and don’t remember what something is supposed to mean or find something illegible. On the bottom row is “SKELETON”, followed by a “(?)” because I no longer had any idea what the hell that item referred to.

Cubans

I intended to include Pedro, Juan, Javier and Carlos. Alas, the Cuban explorers never made it into the temple.

Et al

Pathways Redux was the first remake I’d ever attempted. On one hand, you have a clear template to build upon. “Finding the fun” is the riskiest part of game development, and it’s comforting to have that automatically done.

On the other hand, it did come to a point where I got bored on a creative level. I had a lot of fun re-thinking the UI, environment design, dialogue system, and storytelling methods; this was not a one-to-one remake. But ultimately, re-treading someone else’s work – no matter how absolutely amazing that work is, a la PiD – doesn’t have that same spark as springing something brand new.

In Pathways Redux, the action is meant to take a backseat to the story, characters, and environment. This action-light narrative-heavy type of game is sorely under-served. I’d love experience the hustle and bustle of booking guests for a late-night talk show. I’d love to fall into a web of intrigue and deceit in the Holy Roman Empire. Let me know when you finish making that – I’d love to play it!

September 30th, 2011
Category: development

6 comments

Pathways Redux Part I

I was digging through an old hard drive and found a small collection of videos and images from old projects. I’ll share them with you over the next few weeks.

Here’s the first one: a trailer for a Doom 3 mod I made in 2004, Pathways Redux:


Pathways Redux is based on a Bungie game, Pathways into Darkness. When talking about first-person action-RPGs, the usual suspects are games like Ultima Underworld, System Shock, and Deus Ex. Bungie’s PiD is often not mentioned, which is a damn shame – it without a doubt deserves a place.

What I found most impressive about PiD was its storytelling and world-building. Here’s your homework assignment: spend a day poring over the Pathways into Darkness Story Page, the Marathon Story Page, and the Myth Story Page. Despite how difficult it is to tell a good story in a game and create strong, cohesive universes, Bungie has achieved wonderful results in PiD, Marathon, and Myth.

And if you haven’t played those three, then you better go do something about that, hm?

In 2004, Doom 3 was on the horizon. I was giddy like a bull in a china shop. I grew up with Wolfenstein, Doom, and Quake, and was fairly familiar with their ins and outs. From a tech level, all the articles and previews leading up to Doom 3′s release basically said “Y’know all those things that kinda bugged you in the Quake engines? Well, we went ahead and did something about that.”

Models and level geometry now used the same lighting model?  Robust scripting system? Live-loading script changes while playing the game? In-tool lighting preview? In-game tool functionality? No more waiting 20 minutes for the compiler to bake shadows into level geometry? Skeletal animation system? Amazing in-game GUI system?

My mind = blown.  I’m sure it’s a boring feature list to many people – this isn’t stuff you’d highlight on the back of the box. But this is a list of Engine Features Brendon Really Likes.  Plus, it’s id Software, who have a high bar of quality in in game engines.

I remember waking up, driving down to Best Buy in Pasadena, and getting a copy of Doom 3 on its release day. I traditionally play slowly, but I blasted through the game and got modding immediately.

I was most interested with all the scripting functionality and GUI goodies. I made a test project revolving around those things. Barista 3 was the end result. Whenever I work with a new piece of technology, I like to first dip my toe into the water and make a micro-tiny project. Barista 3 was a quick ‘n dirty project intended to poke and prod the Doom 3 engine and see what I could shake out of it.

It was also a fun experiment in making a first-person game without any shooting. Many of the Barista 3 comments I received were some variation of “there’s no shooting, wtf.” I think the intimate nature of the first-person perspective is wonderful for storytelling and exploration, especially when you remove all that extra noise from gunplay.

After completing Barista 3, I felt fairly comfortable with now attempting a more ambitious project.

I spent some time thoughtfully stroking my chin, considering what kind of project I wanted to tackle next. After a particularly satisfying chin-scratching session, the answer was obvious: a mini-remake of Pathways into Darkness, using the Doom 3 engine.

Next week I’ll talk about the gnarly details of how that all went.

Update: click here to read Part II

September 20th, 2011
Category: development

comment on this »

All about PAX

Last month I was in Seattle for the Penny Arcade Expo, PAX.  Atom Zombie Smasher was chosen for the PAX 10 – a showcase of ten independent games picked by the PAX folks. It was a great honor to be shown alongside such an amazing lineup of games & developers. This was my first time demoing my own game on a show floor, so it was A) very exciting, and B) mishaps aplenty (on my end, not the PAX folks).

If you’ve ever been to E3 or similar trade shows, I’m sure you’ve seen some incredible booth setups with giant castle facades, avenues of monitors, dudes in power armor, bikini girls, monster trucks, etc.

Meanwhile, I had:

  • myself.
  • two laptops.
  • 8.5″x11″ cardboard signs.
  • half a roll of scotch tape.

 

Here’s how I set up my area. The awesome PAX folks provided a table, a large television, and a great spot on the show floor:

 

The PAX 10 area comprised of several tables. The PAX 10 games were: Word Fighter (my table neighbor!), A Flipping Good Time, AntiChamber, Fez, Jamestown, Snapshot, Solar 2, The SplattersVanessa Saint-Pierre Delacroix & Her Nightmare, and my own Atom Zombie Smasher. Hanging out and chatting with all the devs was great; I get the strong feeling we’ll all be seeing one another again at future events.

At the end of each day I jotted down some random things in my notebook:

  • AZS does a really terrible job at selling itself through screenshots and videos. Unsexiness just oozes from every pore. But once someone actually gets their hands on it and starts playing, they really like it.
  • I’m glad I added a “Pax mode” that throws the player into the middle of the campaign with all the weapons. During day one, I realized I should’ve also added some sort of “rolling demo” mode that auto-plays the game itself, like arcade machines do when no one is playing. And the gag is, AZS already has a system that does that!  Argh. Next time.
  • I should’ve added some tutorial tips to the “Pax mode.” There’s a fair amount of moving parts in the game, and having even just a few “first-time player” overlays would’ve been immensely helpful.
  • Manning a booth by myself for three days was silly. Despite drinking water like a fish, by the third day my voice was so shot I sounded like Henry Kissinger (I do not normally sound like him).
  • I was surprised at how many people commented on enjoying the Dev Notes at the end of the AZS campaign.  I included it mainly because I love reading stuff like that, but who knew others did too? I’ll be including something similar in my future projects.
  • The G4 guys dropped by. Getting miked up with a Lavalier mic is quite an intimate experience.
  • You can never print too many flyer cards. I learned the hard way.
  • I need to bring a flashlight next time. Television touch controls + really dark room = Brendon never manges to change the volume.
  • The tower defense nature of the planning phase instantly creates assumptions. Once the action phase began, people often let go of the mouse, thinking the game would play itself automatically from that point on. I wonder if this is a result of not playing the tutorials, or if this is a common problem?
  • It was awkward having the television and laptop display a duplicate image. If there was some way to keep the game going with the laptop closed, that would be ideal.
  • I had an interview with Ryan Davis of GiantBomb. I’m a junkie for GiantBomb’s Quick Looks, so this was really wonderful.
  • I need some sort of Blendo T-shirt or button or something. It’s off-putting to have some stranger pop out of nowhere and start explaining the game to you.
  • Anthony & Ashly Burch stopped by to say hello!  So awesome. Go watch HAWP and Rev Rants, and love ‘em as much as I do.
  • About ten feet from me was the Minecraft booth. All day long, for all three days, that area was kerrrrazy party central. I was expecting it to be big, but that was bananas.
  • I had my first panel talk, with the fine devs from the PAX 10. We had a great chat, and I’m already itching to do it again.
  • I’m glad I had two stations set up. It was a last-minute decision to bring both laptops, and it worked out well.
  • One person asked for my autograph. I’m a total e-celeb.
.

The best part of PAX was getting to physically meet and chat with people and developers I’ve previously known only via email. With video games nowadays oftentimes having no physical media to speak of, beamed directly into your computer by digital voodoo, getting the opportunity to say “hello!” to fans is a rare and wonderful treat.

Here’s a picture of the PAX 10 panel talk. Check out the Blendo Games Facebook page for more PAX pictures.

Huge thanks to the PAX folks for all their hard work. It’s an amazing event – if you have any interest in video games, board games, comic books and the like, check out PAX!

September 15th, 2011
Category: announcement

1 comment

Blendo Games now on Desura

Blendo Games just went live on Desura. Atom Zombie Smasher, Flotilla, and Air Forte are now available on the platform. Check it out!

For those unaware of Desura – it’s a digital distribution channel created by the folks from Mod DB. It differentiates itself by having a particularly strong focus on mod content and independent developers. There’s some wonderful stuff there, some of it completely free of charge – do give it a look.

Check out our Facebook and Twitter pages for the occasional free Desura download codes. They go quick, so keep your eyes peeled!

September 13th, 2011
Category: atom zombie smasher, patch

comment on this »

Atom Zombie Smasher v1.89 released

Version 1.89 of Atom Zombie Smasher is now available!

A lot of people asked for the UI to accommodate any arbitrary amount of mercenaries. Previously, the merc buttons would just continue off the edge of the screen and be inaccessible. I updated the system to detect this overflow and make a new row of merc buttons. Here’s a shot of how it looks:

Here’s the full changelog:

- Gameplay: when no more zombie territories, humans win.
- UI: merc control bar now accommodates any arbitrary amount.
- UI: can press ESC to skip Territory Score screen.
- UI: can press ESC to skip New Outbreaks screen.
- UI: can press left/right to select upgradeable mercs.
- UI: can press Enter for Yes/No popups.
- UI: fixed Player 2 artillery cursor mixup.
- UI: added loading animation to File Share menu.
- UI: added URL tooltip in Behind the Scenes.
- UI: vid. resolution menu now shows current resolution.
- UI: helicopter name limited to 23 chars.
- UI: add help message for bad profiles.
- Mods: removed empty mods from database.
- Fix: custom resolutions are now saved.
- Fix: fix crash in Zed Bait.
- Fix: fix crash in Twitter feed.
- Debug: PAX Demo functionality.

The Steam version will auto-update. For non-Steam versions, grab the patch here:

http://blendogames.com/atomzombiesmasher/help.htm

 

August 20th, 2011
Category: atom zombie smasher, development

2 comments

Atom Zombie Tech

A fair amount of people have been asking me about the tech used in Atom Zombie Smasher, so I thought I’d make a writeup.  It boils down to three main components: SFML, Mono, and something I call BlendoEngine.

SFML

The Simple and Fast Multimedia Library provides low-level calls to your system’s audio, input, and graphics.  It’s actively being developed, is cross-platform, and is very lean.

Here’s a quick ‘n dirty example of how a sound file is loaded and played in SFML:

SoundBuffer dogbarkBuffer = new SoundBuffer("bark.wav");
Sound dogSound = new Sound();
dogSound.SoundBuffer = dogbarkBuffer;
dogSound.Play();

SFML excels at 2D rendering, but also does 3D, assuming you’re comfortable with OpenGL calls.  This is my first time with OpenGL, so the most I could muster up with my piddly graphics programming was basic rectangles (buildings, people) and square planes (particles, helicopter).

I use the C# (.Net) variant of SFML, simply because I find the C# language friendly and accessible, and I like its IDE (I use MS Visual C# 2008 Express Edition).  The downside of .Net is porting to non-Windows platforms.  This is where Mono comes in.

Mono

In order for my C# games to work on Mac and Linux, I use Mono. Programs written in .Net can only run on Windows machines. Mono is a framework that enables programs written in .Net to go cross-platform.

A Mono compiler (GMCS) is included in the Mono download package. I use this compiler to make a Mono-compatible executable; this is what the user executes to run the game. I also include the necessary Mono libraries in the game folder, so the user does not need to install Mono into their system folders.

BlendoEngine

This is the framework that handles “everything else” – gameplay code, UI, resource management.  It originated with my first title Flotilla (XNA 3.1), and was further developed and used in Air Forte (SFML 1.5) and Atom Zombie Smasher (SFML 1.6).

BlendoEngine is made up of “manager” components. While SFML provides low-level audio/input/graphics calls, my managers give me a way to more effectively access and utilize these calls.  Here’s some of them:

ScreenManager

A game consists of a series of “screens.” Screen examples: the Report-a-Bug screen, the end-of-mission screen, the cityscape screen.   These screens are placed on a stack; the top-most screen is considered in-focus and is the only one who receives user input.  When a screen is done, it just needs to call “this.ExitScreen()” and the ScreenManager will remove it from the stack.

AudioManager

This handles music and sound effects. It is loosely based on Doom3′s sound shader system, though their system has magnitudes more functionality.

Sounds are not called via their filenames, they are called via their sound shader (go to atomzombiesmasher/data/content/data to see the shaders or click here to see an online copy). The AudioManager randomly selects an audio file from the shader.  A record of its playback history is kept, so as to ensure you won’t hear the same sound bite repeated again until it has exhausted the entire pool.

For my next iteration I plan to add more parameters, things such as pitch, volume, and randomization weighting.

And the rest

There’s quite a bit more – InputManager, DrawManager, StorageManager, ConsoleManager, UI system, etc.  What I love the most is that with each new project, this engine framework gets more robust; the time between starting the project and starting actual gameplay code gets shorter and shorter.

Lessons Learned

Random technical gotchas learned over the years:

Mono on PC

For Atom Zombie Smasher I made the decision to make all three platforms (PC, Mac, Linux) use Mono, for the sake of keeping all the builds and save files consistent. However, on some specific system configurations, my PC Mono build refuses to start. I still can’t figure out what causes that. In the meantime, using the .Net build resolves it.

Where are you?

Not only is it important to know system specs, you sometimes gotta know what country it is. To separate numbers, some countries use periods. Some countries use commas. This screwed up all sorts of things, including the version updater (i.e. “1.21″ was being interpreted as “1,21″).

File Locations

There are warring camps who disagree on where savefiles & settings should be kept (here is what I ended up using).  Barring some official decree, for the PC build of my next project, I think “My Documents\My Games” is a more reasonable location.

Modularity

I found it important (and sometimes difficult) to keep a clear distinction between gameplay code and system (audio/input/graphics) code.  If you ever want to port over to a different library (i.e. XNA to SFML), keeping your library-specific code isolated in set areas makes the job much easier.

 

August 9th, 2011
Category: Uncategorized

2 comments

Atom Zombie Smasher on Ubuntu Software Center

Linux aficionados, Atom Zombie Smasher is now on the Ubuntu Software Center!  Here’s an action shot of it:

To access the Ubuntu Software Center, click on the Applications button in the top-left corner. Check it out, and browse through their library – there’s lots of good stuff.

July 14th, 2011
Category: atom zombie smasher, patch

2 comments

Atom Zombie Smasher v1.84 update

Atom Zombie Smasher v1.84 is now live. As requested, lots of gameplay and UI tweaks, and several stability fixes as well.

- Gameplay: Chooser gamemode no longer scrambles merc lineup.
- Gameplay: landmines now respect user’s gamespeed.
- UI: middle mouse click now opens Merc Chooser window.
- UI: Alt+Enter now toggles fullscreen/windowed.
- UI: added option to quit without saving.
- UI: added social feed.
- UI: added More Games menu.
- UI: increased Report-a-Bug window size.
- UI: campaign log export now includes hours/minutes in filename.
- System: Disable joysticks with “-joystick 0″ command line.
- System: Disable sound with “-sound 0″ command line.
- System: Added telemetry system.
- Fix: crash in 3D renderer.
- Fix: crash in region generation.
- Fix: crash in newsletter page.
- Fix: crash with empty mod names.
- Fix: crash in music system.
- Fix: crash in pathfinder.
- Fix: crash in text renderer.

 

The Steam build will auto update. The non-Steam patch can be grabbed at: http://blendogames.com/atomzombiesmasher/help.htm#versions