Blendo News

Planning for Steam Deck Verification

Thu, 19 Feb 2026 00:00:00 +0000

Generally speaking, Steam Deck verification is something you do pretty late-ish in a game’s development.

However, if you don’t make some specific decisions early on, you may end up in a situation where it’s very difficult (or practically impossible) to retro-fit your game to fulfill all Steam Deck verification requirements.

So! I thought I’d write about some of these things.

(As always, don’t take my word for it – read the official documentation and do your own further research)

1. Text size

The Steam Deck screen resolution is 1280x800 and text should be at least about 12 pixels high.

As you can imagine, trying to “make all text bigger” late in development can potentially be very messy.

I suggest establishing some reasonable standard font sizes early in development.

My caveman way of testing this:

Play your game in 1280x800 resolution.
Take a screenshot.
Count how many pixels tall your text is.

2. Button glyphs

When playing on the Steam Deck, button prompts/controls should only show the Steam Deck button glyphs.

Here’s screenshots of Skin Deep with Steam Deck button glyphs:

Squeezing in these button glyphs (and removing/hiding any keyboard prompts) at a late stage can be painful. Similar to adjusting text size, making huge changes to UI can cause all sorts of unpredictable knock-on effects.

If possible, setting up infrastructure early on to accommodate swapping in different button prompts (keyboard, gamepad, etc) is one way to handle this.

Prompt images

To the best of my knowledge there isn’t an “official” set of button glyphs. However there are a ton of button image packs that include the Steam Deck glyphs.

A couple examples: Kenney Input Prompts | Xelu’s Free Controllers & Keyboard Prompts

Note: the official documentation recommends SteamInput API integration. I personally haven’t used SteamInput API in my projects – I’m sure it works fine, but just wanted to give a data point that it’s not explicitly required.

Deck check

In the Steam API, the bool IsSteamRunningOnSteamDeck(); function will tell you whether the game is currently running on a Steam Deck. This is one way to determine whether you should/shouldn’t draw the Steam Deck button glyphs.

EDIT 2-19-2026: a commenter mentioned you may want additional logic to handle a docked Steam Deck. Example: if the Steam Deck is docked and you’re using an Xbox controller, you’d instead display Xbox button glyphs.

3. The Whole Dang Game Needs Gamepad Support

The whole dang game needs to be playable with the Steam Deck’s controls. All the gameplay, menus, typing, the whole shebang…

Good luck! 👋

The Good News

If your game already has gamepad support, then you’re good. Your controls will just naturally work fine with the Steam Deck.

The Surprisingly Still Good News

If your game is only keyboard/mouse with no gamepad support, you may be in luck?

The Steam Deck’s control mapping system is robust. Your mileage may vary, but in my experience it does a good job at allowing you to remap your controls onto the Steam Deck’s sticks/buttons/triggers/touchpads: As the developer, you’re then able to use the Steamworks site to assign an “official” control scheme.

Et al

So, caveat: you don’t need to be Steam Deck verified. It is a non-trivial amount of work, and does take time/budget to get all of this working well.

Which leads me to my confession… I’ve mostly been playing on the Steam Deck lately, so selfishly I just want more Deck-friendly games on the Steam Deck. Haha. Yup. I want games. It’s true.

Fortunately, if your game is made with gamepad in mind, there’s a good chance it will just naturally work well on the Steam Deck – with the exception of the text size requirement, which anecdotally seems to trip up a fair amount of titles. Please, I beseech you… make font bigger 🙏

Blendo Merch Store

Mon, 26 Jan 2026 00:00:00 +0000

It’s Atom Zombie Smasher’s 15th anniversary! 🎉🎉🎉 To celebrate:

1. Launch of the Blendo Games merch store

Video games are very digital & intangible, so I thought it’d be fun to make some Blendo Games physical items.

We’re happy to announce the Blendo Games merch store! Live and open for orders. Wear a cool shirt! Slap a sticker on your laptop!

Featuring designs from:

Gravity Bone
Atom Zombie Smasher
Flotilla
Thirty Flights of Loving
Quadrilateral Cowboy

2. Updated Atom Zombie Smasher

Yes, you can update your 15 year old video game. It’s allowed!

Here are the changelog notes for the Atom Zombie Smasher 15th anniversary update (v2.2):

Timescale can now be 1%

The slowest timescale used to be 10%. This update now adds a new, even slower timescale: 1%. This is a quality-of-life addition that grants you more time to think and decide.

Can now more easily deselect unit

Pressing ESC willl now deselect the active unit. Sometimes you just want to view the cityscape without having a unit selected – this makes it easier to do that.

(Note: if you don’t have a unit selected, pressing ESC will open the pause menu. This is the same behavior as prior to this update)

Vignette fixes

The seams in the comic vignette images are now fixed. This issue was caused by images “bleeding” in their neighboring pixels, which created what looked like a seam or gap.

Behind the Scenes UI

The Behind the Scenes screen now correctly limits how far it scrolls, to prevent you from scrolling into outer space and beyond.

There were some buttons linking to social media that was no longer updated. These were changed to newer, updated links.

Showfloor demoing fix

In the past, Atom Zombie Smasher was shown at various expos and conferences and conventions. During these showings, it was helpful to have a button that instantly reset the entire game. Somehow this showfloor functionality snuck into the release version (oops 😅). This issue has been fixed.

Crashes will now ask to submit a form

If the game crashes, it now generates crash information and submits it into a form. This makes it a lot easier for us to receive information about any technical issues.

Mac startup issue

There were some outdated files in the Mac build that prevented startup. This is now resolved.

This update is live on Steam and itch.io. Big huge thanks to Ethan Lee for technical help on getting this update out the door.

And thanks to folks on our Discord for helping verify some fixes!

Et al

For the merch items, I handled the design work.

It was fun to revisit my art from past titles, re-opening dusty photoshop files I haven’t touched in years. I cleaned up the designs, fixed some stuff, and adjusted the art to fit the merch requirements/parameters.

It was quite the trip. “Oh cool, that used an ancient photoshop brush that I no longer have…” 😔

Looking forward to revisiting all of this again in the future!

Skin Deep: IGF Nominated

Fri, 09 Jan 2026 00:00:00 +0000

Skin Deep was nominated for the 2026 IGF Excellence in Design award!

Skin Deep’s designers were:

Suzanne Will (site | bsky)
Tynan Wales
Brendon Chung (site | bsky)

Click here to see full credits.

Skin Deep had a pretty long and winding design process, with a lot of iteration and experimentation. Suzanne and Tynan were incredible collaborators and were a non-stop font of great ideas, great solutions to difficult problems, and great practical know-how.

I’m so glad they’re getting recognition for this!

Additionally, Skin Deep got Honorable Mentions in:

IGF Excellence in Audio
IGF Seumas McNally Grand Prize

Wow! Skin Deep’s composer was Priscilla Snow (site | bsky) and the soundtrack is available here.

Priscilla did insanely amazing work on the Skin Deep soundtrack. Each track is so special and full of personality and just sound SO good. It’s really the perfect soundtrack imo.

Et al

I feel so lucky to have had the chance to collaborate with these amazing folks, and to also be listed alongside all of the incredible IGF nominees. What an insanely good lineup of games. Wow!

Click here for the full list of 2026 IGF nominations.

Skin Deep: Year End Roundup

Sun, 21 Dec 2025 00:00:00 +0000

I thought I’d gather up some year-end writeups that include Skin Deep:

PC Gamer: Best Immersive Sim

🔎 Read full article

PC Gamer named their Game of the Year Awards, and Skin Deep was their BEST IMMERSIVE SIM OF 2025!

(additionally, the anecdotes described in this writeup have been some of my favorite anecdotes of Skin Deep)

GameSpot: Best PC Games of 2025

🔎 Read full article

Skin Deep is on GameSpot’s Best PC Games of 2025!

GameSpot: Best Cat Game

🔎 Read full article

Skin Deep was GameSpot’s Best Cat Game!

Green Man Gaming: 10 Best Indie Games of 2025

🔎 Read full article

Skin Deep is on Green Man Gaming’s 10 Best Video Games of 2025!

Slant Magazine: 25 Best Video Games of 2025

🔎 Read full article

Skin Deep is on Slant Magazine’s 25 Best Video Games of 2025!

GamesRadar: Year in Review 2025

🔎 Read full article

Skin Deep was featured in GamesRadar’s Year In Review 2025, with perhaps my favorite headline ever.

The Guardian: video games you may have missed in 2025

🔎 Read full article

Skin Deep was featured in The Guardian’s video games you may have missed in 2025!

EDGE Magazine: PC Game of the Year Runner-up

Skin Deep was Edge Magazine’s 2025 runner-up to PC Game of the Year!
Edge Magazine #419, February 2026

Fun fact: EDGE Magazine’s PC Game of the Year was the fantastic Spooky Express – Spooky Express and Skin Deep share the same talented music composer: Priscilla Snow!

Rock Paper Shotgun: Bonus Games of the Year

🔎 Read full article

Skin Deep was featured in Rock Paper Shotgun’s Bonus Games of the Year!

Rogue: The Roguesies

🔎 Read full article

Skin Deep was featured in Rogue’s Biggest Surprises of 2025!

Eurogamer: The 50 best games of 2025

🔎 Read full article

Skin Deep was featured in Eurogamer’s 50 best games of 2025!

Eurogamer: readers’ top 50 games of 2025

🔎 Read full article

Skin Deep was featured in Eurogamer’s readers’ top 50 games of 2025!

Eurogamer: Games of 2025

🔎 Read full article

And last but not least, Skin Deep was featured in a very lovely writeup in Eurogamer’s ‘Games of 2025’ roundup.

Et al

I’m very proud of what we made together.

Skin Deep was a collaborative effort of artists, designers, programmers, writers, musicians, voice actors, and more sharing their incredible ideas, bringing in their personal experiences, and showcasing their expertise. I feel so fortunate to have made something alongside them.

Amazing things are possible when a group of creative people are allowed to be creative. I believe Skin Deep is an example of that.

Thanks all!

Edit January 1, 2026: Added more entries.

All about Nas

Tue, 16 Dec 2025 00:00:00 +0000

I recently got a NAS up and running. And it’s pretty fantastic??? It’s kinda changed how I use my computer (in a good way).

This kind of stuff has been around for a very long time, but it’s new to me! I’m enjoying it greatly.

What is NAS

I think different people have different uses for it. Our use case is:
it’s a big shared hard drive.

(In this case, “shared” meaning: shared within your local household.)

So, instead of storing certain files locally on your desktop/laptop hard drive, you instead store it on the NAS. This is great for things like:

videos
pictures
music
anything you want

Basically: stuff you want to share with other people in the household and/or stuff you want to migrate with you between your computer upgrades.

(If you’re more ambitious, there’s a lot more uses for a NAS. But I’m extremely ok with just treating it as a simple “big hard drive that just stores stuff”)

What does it look like

I used an old computer we had that was lying around gathering dust. It’s connected to our wifi router. That’s it.

(There’s also purpose-built NAS machines such as Synology, TerraMaster, etc. I decided to use an old computer largely because we just happened to have an old computer lying around)

How do you access it

At least in Windows, it’s basically treated like a separate hard drive.

In file explorer I enter the NAS’s address, something like \\192.168.123.123 and it shows me the NAS’s files. I can then drag files into or out of the NAS machine.

File transfer is pretty fast, about 100 megabytes per second. You can get setups where you can transfer 1 gigabyte per second, but my specific hardware didn’t allow for that.

What software does it use

I used TrueNAS. Free!

It was a surprisingly straightforward process to install it and set it up. There’s a handful of YouTube videos that do a clear walkthrough of the process.

I used a combination of these 2 videos:

What’s the deal

Things I like:

Your files are kept in a hard drive in your room, instead of floating in a cloud somewhere. This has pluses and minuses, but I like the simplicity.
It’s a setup we own.
It makes long-term file storage separate from your desktop/laptop computer.
It simplifies decision-making about files. Picture, video, or music? Just throw it on the NAS.

Et al

Big thanks to Dante for introducing me to the the world of NAS stuff.

Over the years I’ve definitely lost a lot of old files and old projects. Perhaps for the best??? It doesn’t really bother me – I’m glad I made them, they’re gone from the world but not gone from my heart, etc etc – but it is nice to now have an easy, straightforward, simple way to archive things.

Antibody One

Wed, 10 Dec 2025 00:00:00 +0000

I released a game today: Antibody One

Antibody One is a short 10-20 minute experience about being different kinds of cells inside the human body.

The game can be purchased here. Enjoy!

What is this???

Antibody One exists largely because of a few reasons:

1. The human body is crazy

The complex clockwork world that exists inside our bodies is crazy. It’s so elaborate and I’ve always wanted to make a game that explores its inner workings.

2. What if a game didn’t take 4 years to make

I like to make projects of various sizes. Whereas Skin Deep was a larger project with a larger team, I intentionally wanted to have Antibody One be very tiny.

This project took about 4 months of part-time work.

3. I wanted to try out ECS

I wanted to learn ECS programming. I hadn’t used it before, and I personally believe the best way to learn new tech is to make and ship a small project that uses it; hence, Antibody One.

This project uses Moontools.ECS – if you’re interested in ECS in general, here is an introductory talk given by Moontools.ECS’s creator, Evan Hemsley.

At a later date, I’d like to make a longer writeup about ECS. For now I’ll say I quite enjoyed my experience and look forward to exploring it more.

Thanks

Big thanks to Brody Brooks for providing programming support and untangling some gnarly technical issues. Thanks Brody!

Et Al

Antibody One was a rewrite of code/infastructure I previously used in Flotilla, Air Forte, and Atom Zombie Smasher.

There’s something nice about revisiting ancient code – it’s fun to peek at how I was implementing things back then (yikes 😬) and it’s satisfying to realize how much I’ve progressed since then.

And then yes, repeat this all over again 10 years from now…!

Game Release Miscellanea

Mon, 01 Dec 2025 00:00:00 +0000

Over the years I’ve accrued an informal list of miscellaneous gotchas and pitfalls for game releases & game maintenance, but I’ve never actually written them down… until now!

This is straightforward stuff and likely things you already know, but perhaps there’s tidbits you may find helpful. I hope it helps.

1. Keyboard layouts

Some keyboards use WASD keyboard layouts. Some use AZERTY or other layouts. I hardcoded my controls in some of my earlier work… I don’t recommend it!

2. Decimals parsing

Decimals are parsed differently depending on the region. Example: seven and a half is sometimes 7.5 and is sometimes 7,5

Example: if you’re reading or writing a decimal value from a file, incorrect parsing may result in problems.

3. Save folder

To the best of my knowledge there still isn’t a universally agreed-upon place to put save files, and every location has pros and cons. For Windows I’ve settled on %appdata%\YourGameName and it seems to work fine.

4. Crash reporter

Some time ago I started putting a crash reporter into my work. It puts the crash callstack text into a Google Form, and then the player clicks the form’s Submit button to send it to me.

5. Code comments

I sometimes hear the adage that truly elegant code doesn’t need comments… but I disagree!

I think comments are great, and I add comments pretty aggressively. Largely because when I need to re-visit code 10 years later for an update or patch, it’s very helpful to read past-Brendon’s helpful notes, know exactly what something does, and get a fix done in a few minutes instead of a few hours.

6. Build documentation

Related to above: I find it helpful to write “how to make a build of the game” documentation for myself. When you need to make a new build 10 years later, there’s a chance you may not remember all of the arcane build steps, build tools, and little details.

7. Profile folder (Steam)

For the Steam build, save your files inside a sub-folder that uses the player’s Steam ID number. Example: the save folder will end up something like: %appdata%\YourGameName\77901231231233301

This allows multiple Steam profiles to use the same computer without overwriting each others’ files.

8. Tags (Steam)

In the Steam backend, add tags (i.e. Singleplayer, Short, Action, Puzzle, etc) to your game. Might be superstition, but I believe developer-added tags heavily weight how the game is surfaced in the store.

9. Separate video settings (Steam)

My take is that video settings should not be saved in the cloud. The main reason being that if someone is swapping between different machines (i.e. desktop computer and Steam Deck), you generally do not want video resolution/quality/etc shared between them.

10. Messageboard setup (Steam)

I like setting up the messageboard in such a way that disallows posting in the ‘default’ landing page. Skin Deep example: https://steamcommunity.com/app/301280/discussions

This results in directing players to post in specific subcategories and prevents the landing page from becoming a dumping ground for everything.

Et Al

In short: it’s a miracle that any game actually works.

Glitch City thoughts

Fri, 14 Nov 2025 00:00:00 +0000

I’m one of the co-founders of Glitch City from back in 2013. And as of today, I’ve retired from helping run the space! 👋

For those unfamiliar: Glitch City is a community space here in Los Angeles, aimed toward artists and independent game developers. In the space we run community events, workshops, co-working, and more.

I’m excited I now get to experience it as a normal resident. There’s a lot of feelings here: astonished at what we’ve built together, emotional about moving on, and comforted it will continue in the hands of great folks.

In short: it’s been a long time. I’ve been helping run the space since opening day, for 12+ years.

A small handful of us run the space together. For the past several months I’ve been thinking about how much I like them, how lucky I am to know them, and how lucky Glitch City is to have them. If there ever was a ‘good’ time to retire, this was it, with good people at the helm.

Et al

Glitch City is a very special place, a very special community, and my hat goes off to other folks who are running or have run similar spaces.

Blender Video Editor

Mon, 04 Aug 2025 00:00:00 +0000

Blender is primarily known for 3D modeling, but for years I’ve also been using its Video Sequencer to make trailer videos, promotional videos, YouTube videos, etc. I think it works pretty great. And it’s free!

I thought I’d write a short primer on how to get started in Blender’s video editor.

(Note: this writeup uses Blender v4.0. However, I believe these steps apply to any version 2.8 and above.)

Setup

Setting up the editing environment.

Click the Editor Type button on the top-left corner:
Select Video Sequencer:
Click the Sequencer View button:
Select Sequencer & Preview:

Your layout should now look like this:

Setup done. Time to start editing…

Time to start editing

Adding clips

In Windows, open the folder that your video clip file is in.
Drag the video clip file into Blender’s timeline.

Done. You should now have a video clip in the timeline: Note: the blue rectangle is the video clip. The teal rectangle is the audio.

Note: you can drag in more than video clips. Try dragging in MP3 music, WAV sounds, PNGs with transparent backgrounds, etc – there’s a lot of things can plunk into the timeline.

Moving clips

In the timeline, left-click the center of the video clip.
Press G
You can now move the clip around.
Left-click to confirm the movement.
- Or press ESC to cancel.

Resizing clips

In the timeline, left-click the head or tail of the video clip. This is the lighter-colored start and end points of clips:
Similar to above, press G to move the head and tail.

Rendering

Time to watch your masterpiece…

Set video duration

You need to set the start and end point of your video. Click these numbers to set when your video starts and ends:

Render it

Rendering to an MP4 video file:

Click the Output button:
Change the File Format to: FFmpeg Video
Change the Container to: MPEG-4
Change the Audio Codec to: MP3
Click on Render > Render Animation :

The render will now start, and the output file will appear in folder: c:\tmp

Notes

To select multiple items, hold shift and left-click multiple items.
When moving anything (a clip, a head, a tail, etc), you can instead type in a number. This is helpful if there’s a precise value you need. Example:
1. Select clip in timeline.
2. Press G
3. Type in: 120
4. The clip will be moved 120 frames forward. Note: for the reverse direction, add a negative -
When moving anything, you can instead press and hold left mouse button to drag it around (instead of pressing G).
To change a clip’s properties:
1. Select clip in timeline.
2. Press N
3. A properties panel will appear, with settings to change the clip’s saturation, brightness, cropping, position, and more.

Et al

There is a world of further Blender video editing functionality not covered here – this writeup is just to get you up and running. The rest is up to you. Good luck!

Skin Deep: Papercraft Cats

Tue, 08 Jul 2025 00:00:00 +0000

Papercraft Cats

I made a Skin Deep papercraft cat and you can too. Here’s Palanka sitting on my desk:

Download here:

https://blendogames.com/files/skindeep_papercraft_series01.zip

This package includes cats:

Palanka
Little Lion
Fortinbras

What are the instructions?

There’s different ways to approach it. Here’s what I do:

Get these papercraft images printed at a print shop or office supply store.
Cut the pieces out with scissors.
Glue the tabs. I just use normal white glue.

Done!

Et al

I grew up making stuff with cardboard, plastic trash, papier mache, anything I could find lying around the house. Papercraft was one of these things, and it’s fun to now make makeshift “merch” like these cats.

You can see previous Blendo papercraft here:

Quadrilateral Cowboy: https://www.polygon.com/a/creativity-cover/quadrilateral-cowboy-papercraft-characters
Thirty Flights of Loving: https://blendogames.com/news/post/2013-03-08-maple-victory-papercraft
Blendo Big Boxes: https://blendogames.com/news/post/2012-09-10-blendo-big-boxes

If you make any of these, please send me a picture of it! 🙏

To view all posts in this series, click here.

Skin Deep: Enemy Brains

Mon, 07 Jul 2025 00:00:00 +0000

Here’s a short writeup on how enemy behaviors work in Skin Deep.

Goals

The goal was to make humanoid “space pirate” enemies that were fun to encounter and mess with.

The general vibe of Skin Deep’s enemies is inspired by:
The air pirates of Porco Rosso (1992)

The air pirates of TaleSpin (1990)

As you may guess from the images above: Skin Deep’s enemies are intended to be rascals, rapscallions, goobers, lunkheads. They present a threat but are also lovably dim.

However, they still needed to react to player actions in a way that was consistent, understandable, and predictable. As it turns out, even if they’re dolts, making them fun dolts takes a lot of work.

Background

We used idTech4 to make Skin Deep. idTech4 was used to make the game Doom 3 (2004), and as such, included core enemy functionality like animation states, behavior states, pathfinding, etc.

However, we needed to expand upon this to handle stealth, suspicion, investigation, seeing and smelling disturbances, non-combat idle states, and more.

Interest Points

The main component behind Skin Deep’s enemy sensory/investigation logic is what we called the “Interest Point” system. Whenever you see these little question marks in the game, it’s an Interest Point:

This approach was originally suggested by my friend Alex Belzer, who led me to this writeup about Mark of the Ninja’s implemention. It’s a really great writeup and was essential to our development. (also, Mark of the Ninja is really really really great)

The way it works in Skin Deep is:

Whenever anything makes a noise, or makes a smell, or exists, it can create an “Interest Point”. We usually represent it with a question mark icon in the world.
Enemies will perceive these Interest Points, and behave accordingly.

That’s a very broad overview. We liked how flexible, elegant, and effective this approach was.

Example Case

Here’s some examples:

You throw a teapot near an enemy:
- The teapot hits the ground. When it hits the ground, it makes a “noise” Interest Point that lasts for 1 second.
- The teapot creates and attaches a “visual” Interest Point on itself that lasts forever.
- The enemy hears the noise Interest Point. The enemy walks toward the teapot to investigate.
You jump in a trash chute and become smelly:
- Every 1 second, a “smelly” Interest Point is spawned at the player’s location. These Interest Points each last for 8 seconds.
- Nearby enemies perceive the smelly Interest Points and walk toward them to investigate.
- This naturally creates a behavior of the enemy “following a trail” of the player’s smelliness.

Nitty Gritty

More details of the Interest Point system:

• Ad-hoc Teamwork

We had a basic system for coordinating multiple enemies who noticed an Interest Point.

The original motivation was: it was pretty awkward when multiple enemies noticed the same Interest Point and all clumped up together at the same spot. It looks weird.

So, we prevent that from happening. In the case of 2+ enemies noticing the same Interest Point, we:

Have the closest enemy be the “Investigator”:
- This enemy approaches the Interest Point.
Everyone else takes the role of “Overwatch”:
- They also approach the Interest Point. However, they immediately stop moving when they reach any kind of visual line-of-sight with the Interest Point.
  
  This creates an improvised “teamwork-esque” setup where one enemy investigates while others keep watch from afar.

• Ownership

Interest Points have a concept of who currently “owns” them. This is to prevent the awkward situation where the same Interest Point gets investigated repeatedly by multiple enemies.

• DuplicateRadius

Interest Points have what we call a “duplicate radius” – this makes enemies ignore an Interest Point if a duplicate Interest Point happens nearby.

Example: if a series of explosions rapidly happen in the same spot, the enemy will only notice the first explosion that happens. This prevents a lot of unnecessary thrashing on what the enemy is paying attention to and makes the enemy behavior more readable.

• Switch cooldown

Enemies have a 1 second cooldown between switching to a new Interest Point. The purpose of this is to prevent the enemy from rapidly switching their attention, as the rapid switching felt awkward and made the enemy behavior difficult to read.

• Smells

Secret: did you know a smell is just a sound? (in this video game. not real life)

We treat smells as a variant of a sound Interest Point. Like a sound, smells are perceived without needing line of sight, and can permeate walls. This approach was inspired by how Half-life 1 handled smells.

The only difference is that smells are allowed to penetrate doors. (Smell interest points penetrate closed doors; Audio interest points are blocked by closed doors).

• Priority

Interest Points have a “priority” number that ranges from 0 (low) to 10 (high).

This allowed us to make the enemy prioritize certain Interest Points over others – for example, a gunshot sound is treated more urgently than a teapot falling to the ground.

• Interest Point definition

The Interest Points were all defined in a text file. Here’s the definition for the toilet flush:

entityDef interest_toiletflush
{
    "inherit"                   "interest_base"
    "editor_visibility"         "hidden"
    "priority"                  "0"
    "type"                      "noise"
    "noticeRadius"              "512"
    "duplicateRadius"           "128"
    "lifetime"                  "1000"
    "displayname"               "#str_def_interestpoints_100136"
}

Some other details about how enemy behaviors work:

Vision Box

In the first implementation, vision was based on a big cone:

This had some issues. Namely, it was challenging to tune. Whenever you adjusted the cone angle, it would affect both the narrow end at the large end. This made it difficult to find values that worked for both ends of the cone.

Instead of a vision cone, we opted to use a vision “rectangle”:

This gave us better results. Notice the tapered angles near the enemy – this was to make it easier for the player to sneak up on the enemy.

An issue came up, however. The vision rectangle is attached to the enemy’s head. If the enemy looks up or down, the orange vision rectangle likewise gets angled up or down:

The issue was the player could sometimes be directly in front of an enemy who was looking upward or downward, and not get noticed. This made the enemy eyeballs feel broken, and happened due to the player sometimes being just slightly outside of the vision rectangle, depending on the level layout.

The solution ended up being to add a vision half-circle that was always oriented forward:

This ended up solving the issue – the enemy now had a way to perceive a player who was right in front of them.

Credit where it’s due: parts of this vision approach are from this GDC 2014 Martin Walsh talk about perception and awareness in Splinter Cell: Blacklist.

We do a vision tweak between the enemy idle state and combat state.

When the enemy is in the idle state, the vision blind-spot angle is relatively forgiving, allowing you to sneak up to the side of the enemy without being caught. However, in the combat state, we shrink the blind-spot:

The reason for this is to incentivize the “non-alert” state in the spaceship, and to make it more difficult to escape enemies once the combat state does start.

IdleTasks

IdleTask is a system that was similar to Interest Point – this is a system that gives the enemy a specific objective to do. Example: when the enemy is injured and is in an idle state, we give them an IdleTask to visit a health station to heal themselves.

In hindsight, this probably should’ve instead been integrated into the existing Interest Point system. I think I kept separate it in order to simplify the Interest Point system (it’s been a while and I don’t quite remember all the reasons), but that had some trade-offs.

Et al

Enemy behaviors took a lot of time, iteration, playtesting, and energy, and was an ongoing process throughout most of Skin Deep’s development. Suzanne, Sanjay, Eric, Tynan, and myself put a lot of work into wrangling it together, and I’m proud of what we ended up with.

Further reading:

Source code to Skin Deep. Take a look at our enemy code.
Brook Miles’ writeup on Mark of the Ninja. This is largely what Skin Deep was based on.
Jeff Orkin’s talk about how enemies work in F.E.A.R. We didn’t take this specific approach, but it’s really great stuff.

To view all posts in this series, click here.

Skin Deep: Art Density

Wed, 02 Jul 2025 00:00:00 +0000

Density

Today I’ll be writing about the “density” aspect of Skin Deep’s art.

What do I mean by this? In this context, density means: how busy or detailed something is, and the game’s approach toward the concept of detail.

Example: Low density

I’d describe the art in Caravan Sandwitch as “low density”:

Large swathes of flat colors
Texture and model complexity intentionally kept minimal
Lots of “negative space” that gives breathing room to the visual elements.

Caravan Sandwitch (2024)

Example: High density

I’d describe the art in Battlefield V as being “high density”:

Textures are densely packed with small details
Visuals are complex, detailed, busy
Scenes are packed with many elements

Battlefield V (2018)

Which one is superior??

So which one is the ultimate art… which one is the champion in art battle royale?

Surprise! Trick question!

Like a lot of game development, there’s no single right answer for how to do the thing. The approach is dependent on a zillion things to consider:

what style fits the game you’re trying to make
what style fits the budget and time you have
what amount of time/resources does your style require to make art assets
how many people on your team have the ability to adopt and make assets in the style
what tools does the style require, how expensive are these tools, how many people on the team have access and experience in these tools
does the style use existing best practices and production pipeline, or does it require you to build all-new scaffolding
what style displays well in the game engine’s renderer. How much bandwidth do you have to make the renderer fit this style
what new thing is the team interested in learning
and so on, etcetera etcetera…

So yea, lots of practicalities and nuts & bolts to sift through. Like a lot of creative and tech decisions, it’s a mixing bowl of technical considerations + production considerations + intuition + whatever you got going in on your life.

Skin Deep art

For Skin Deep, we aimed for “low density” art:

Partly for production reasons. This would be more sustainable and achievable for our team size + resources.
Partly for gameplay reasons. For making an environment that was less-busy and more instantly understandable.
Partly to use an existing art style (from Quadrilateral Cowboy & Thirty Flights of Loving). We could use this as an initial springboard/direction and expand upon.

Skin Deep (2025)

80-20 rule

The general guideline was to have something mostly be flat/undetailed, but include tight pockets of detail.

Hence: 80% of an asset should be “flat”, and 20% should use high-density detail:
In these examples, the edges of the material have pockets of intricate details, of paint chipping, of light fixtures on the perimeter, of dashed red lines. The majority of the material, however, is intentionally kept flat and sparse.

As you can guess, “80” and “20” aren’t real numbers meant to be measured. It’s intended to express a vibe: high-density details should be used very sparingly.

Contrast amount

Related to this is the amount of contrast on an asset.

We wanted ‘space wallpaper’ for some spaceships. This was one of the earlier iterations of it:

The wallpaper pattern is gorgeous. However, we found it was pulling a lot of attention to itself. It’s relatively high-contrast, and is relatively intricate, resulting in it drawing the player’s eye.

The question here was: did we want a standard wall to pull this much player attention?

Nope – it’s a great-looking material, but didn’t work for gameplay. There is a “budget” for player attention, and it didn’t make sense to spend it on a standard wall.

So, we iterated and made a version that had the same vibe but was intentionally less attention-grabbing:

This can be eyeballed, but when in doubt, you can do a (very) rough “busyness” test by making the image greyscale and then applying a blur to it. Compare the 2 versions:
is busy vs. is not busy

Et al

If you play through Skin Deep, you’ll 100% absolutely find things that don’t abide by these guidelines.

Yup! Sometimes it makes sense to bend the rules, sometimes you just kinda run out of time, sometimes it’s fun to just do whatever. I personally think it’s fine to be less rigid. We’re not robots, and there’s something nice about visible brush strokes.

To view all posts in this series, click here.

Skin Deep: Storyboards

Mon, 30 Jun 2025 00:00:00 +0000

Vignettes

Internally, we called our story-focused levels ‘vignettes’. These levels are focused on progressing Nina’s adventures and various woes, and the player cannot die or fail in a vignette level.

Skin Deep’s narrative director Laura Michet has written about the process we used. During this process, we translated Laura’s written script into a playable vignette level.

Process

Here’s a very general overview:

Do a call. This call included the level designer, narrative director Laura, and creative director me. We reviewed Laura’s written script, brought up potential implementation ideas, reviewed what things were important to include, and got on the same page.
Write a document. The level designer writes a text document that describes how the vignette will appear/work. This was done through Google Docs. This document was then reviewed and we’d do some rounds of feedback – partly on direction, and partly on technical implementation/feasibility.
Build the blockout. The level designer would then build a fully-scripted but undetailed blockout version of the vignette level. This is built intentionally rough because we want it to be malleable in order to quickly change, add, delete, iterate, and shape into a vignette that worked well and felt good.
Brushwork. Once the blockout was in a good place, the level designer then builds the final version of the vignette level.

A very large part of this process is communication. How do you clearly share your thoughts, how does everyone get aligned in the same direction, how do you minimize miscommunication. Something that helped us communicate is storyboards.

Storyboards

We used storyboards quite a bit in Skin Deep’s development and would like to share some of them with you here.

For context, we didn’t make a mega storyboard of every single sequence in the game. Basically, we didn’t need to – Laura’s written script sufficed, or the text document sufficed, or the level designer would have a great perspective on it and then execute it. We made storyboards when needed, as a tool to express specific ideas.

⚠️Note:

I’m going to talk about some story sequences. It includes some spoilers!

If you don’t want to be spoiled, read the rest of this post later.

I drew these storyboards, but all credit to Laura for writing the script and Suzanne and Tynan for constructing and breathing life into these sequences. To be clear, this was a very collaborative experience with a lot of back-and-forth discussion, iteration, and ideation – the vignettes wouldn’t exist without this development crew.

Asteroid-92

Lens crack 1

This was the storyboard for the “lens cracking” sequence in the Asteroid-92 vignette level. The split-screen effect didn’t make it into the game – it was an extremely long shot, as we didn’t have any tech for it!

Lens crack 2

This was a proposed idea where the cinematic camera movement would cause glass shrapnel from the telescope lens to bust out, with the gag being that the cinematic camera is treated like a physical object that shatters the telescope lens. It’s pretty funny but didn’t make the cut for various reasons.

Lens crack 3

This was a description for the lens crack camera movement.

Title drop

This was a storyboard for how the title drop would work. Credit where it’s due: this freeze-frame effect was borrowed from the end of the 2014 Wolfenstein trailer video. That tiny zoom-in when it does the freeze is great stuff.

Penthouse

Cat door 1

This was a storyboard describing the gag about Little Lion’s big golden doors.

Cat door 2

This describes the spotlight gag. Notice that at this point in development, the level art is much more finalized. Sometimes the opportunity for gags become more apparent once more final geometry is in the game.

Photos

This describes the presentation for the photos. All credit to Suzanne for afterward making the photos then turn into physics objects and clatter to the ground afterward – it’s such a killer gag.

Flashback exit

This describes how we transition out of the flashback sequence. Notice how some of the level is more finalized than others – this storyboard was made when the level final brushwork phase was in-progress.

Convention

Diorama setup

This describes the general diorama setup. As you can see, the blockout has white debug text that describes what is going to be there eventually.

Diorama 1

This was the first diorama. In this iteration, the “dead bodies” were ragdoll dummies that piled on top of each other. After receiving this storyboard, Suzanne prototyped this idea out, and we quickly found the ragdoll pile was going to be a technical issue boondoggle. So, we instead decided to replace the ragdolls with more wooden cutouts.

Diorama 2

This was the second diorama. The final art for this sequence went into the game pretty late, so for time/budget reasons, we just show Nina and Little Lion’s giant heads (instead of them holding rifles).

Diorama 3

This was the third diorama.

Diorama 4

This was the fourth diorama. Shadow play! It was a lot of fun to think of what kind of diorama would one of Zena’s goons make with a budget of $20.

Sandwiches

This version of the sandwich sequence had a “video game objective UI” gag. Partly as a joke, and partly to clarify what the player’s goal was here. Ultimately we ended up not needing it, as players were able to understand what was happening without it.

MIAO Corp

Cat reunion

This describes the moment when the cats come to Nina’s aid.

Mech hatch

This was a proposed idea where we do a scene transition right when the mech hatch slams shut. We eventually split the next scene into its own separate level, so this idea became moot.

Mech ramp

Not a storyboard, but I just think this concept art for Little Lion’s cat spaceship is funny.

Wonky space

Catfight

This describes the big space battle. “LL” refers to Little Lion. As you can see, this is very light on details – all credit to Suzanne for interpreting this rough storyboard and doing the hard work of constructing the sequence in the game, giving it soul, and making it come alive.

Cat platform

This is not a storyboard, but I just like this picture of Little Lion sitting on his mechanical platform. Look at those paws.

Match cut

This describes the match cut of the gantry / door.

Big fan

This describes the mech stopping the fan. As you can see, there’s some parts that are less certain or are vague. I think if you don’t have a good idea, to just be honest and up-front about that and allow room for someone else come up with their own solution.

Good Twin Castle

Zena arena

In this iteration, Nina and Zena hold hands and rotate, as if they’re skydiving.

Zena wrestle

This was a description of the wrestle sequence.

Zena sync

This was one of the proposals for how the Nina-Zena sync sequence. This didn’t get further than a storyboard, as it didn’t really work for various reasons.

The Beach

Beach camera

This describes the beach vignette’s opening camera movement.

Beach fireworks

This describes the ending fireworks sequence.

Et al

As you can see, storyboards were made in all phases of development – sometimes the level doesn’t exist yet, sometimes it’s a blockout, and sometimes the final art is in. Storyboards were helpful at every step, as visuals and diagrams are a really great way to communicate and get on the same page.

Years ago when I worked as a level designer at a big game studio, I built a habit of always bringing a notebook and pen whenever I needed to talk to an artist or programmer. All of our cubicles had a whiteboard installed in it, but there was always a high chance it would already be filled up. I always brought my own paper to write on, because it became apparent that a hazy 10-minute discussion that was all words usually became a crystal clear 3-minute discussion if you just drew a little sketch.

When in doubt, draw a picture!

To view all posts in this series, click here.

Skin Deep: Map Kit release

Fri, 27 Jun 2025 00:00:00 +0000

Interested in making mods, or taking a peek into how maps are constructed?

Today we’re releasing the Map Kit, a Steam workshop item that consists of a bunch of sample maps for Skin Deep.

What’s the deal

This is a collection of small sample maps, that demonstrate a specific thing in Skin Deep. For example, airlocks, doors, windows, fuseboxes, etc.

The maps are all playable, but the Map Kit is particularly helpful when you open up the .map files in the level editor and see how things are hooked up. For example, if you’d like to see how to build locked doors, open up the Doors (barricaded) map to see how it’s done.

We hope this helps aspiring mappers, or folks who just want to see how things work.

Who made this?

The Map Kit was made by Skin Deep’s design crew: Suzanne Will, Tynan Wales, and Brendon Chung.

Additional resources

Check out the Skin Deep Mod Handbook, the official guide to getting started in Skin Deep modding.
Play through the Mod Museum, a behind-the-scenes tour of how Skin Deep works.

We hope you enjoy the Map Kit! Looking forward to playing your mods!

To view all posts in this series, click here.

Skin Deep: Source Code release

Thu, 26 Jun 2025 00:00:00 +0000

Happy to announce the source code for Skin Deep is available here:
https://github.com/blendogames/SkinDeep

What is this?

This the engine source code for our game Skin Deep. The underlying engine is idTech4 (otherwise known as the Doom 3 engine), and we used the source port Dhewm3 as our starting foundation.

Like idTech4, the Skin Deep source code is released under the GPL license. This basically means you are free to use the source code for personal or commercial purposes, with the caveat that you publicly release any source code changes you make.
However: please note that Skin Deep’s assets (art, models, textures, audio, levels, etc.) are not open-source and are not to be redistributed.
The original idTech4 was made in 2004, so we had to implement a lot of things that were now expected in a modern 2025 game. It was a lot of work!
Gameplay in Skin Deep is quite different from Doom 3, so the gameplay code likewise has a large amount of additions and changes.

What’s it written in?

The source code is written in C++. We used Visual Studio 2022 during development.

This writeup by Fabien Sanglard is a great overview of idTech4’s engine architecture.

Who worked on this?

A lot of hands touched Skin Deep. The folks who touched code were:

Enjoy the Skin Deep source code!
https://github.com/blendogames/SkinDeep

To view all posts in this series, click here.

Skin Deep is RELEASED!

Wed, 30 Apr 2025 00:00:00 +0000

Launch Day!

Very happy to announce that Skin Deep is NOW AVAILABLE:

Learn more about Skin Deep at its website.

To view all posts in this series, click here.

People made this

I wanted to talk about the people who made Skin Deep.

In the past I’ve usually worked either by myself or with 1-2 collaborators. For Skin Deep, I partnered with Annapurna Interactive. This allowed me to scale up production for the duration of this project.

I was extremely lucky to work with these collaborators on this project. Skin Deep would not exist without these folks.

Suzanne Will

Suzanne was recommended by a mutual friend. Suzanne and I share common history in that we both cut our teeth making Quake/Half-life/Half-life2 levels. During Skin Deep development I was constantly astonished by “how the heck is Suzanne this good at level design???” What a privilege to work alongside such a wonderful person, incredible collaborator, and brilliant level designer.

Suzanne made ship levels, made vignette levels, made textures, made models, contributed to gameplay systems design, and did programming work.

Hire Suzanne! Her portfolio is here.

Tynan Wales

Years ago Tynan and I collaborated together to make Quadrilateral Cowboy, and it was such a pleasure to be reunited with Tynan on this title. Tynan has previously been a designer on Bioshock 2, Tacoma, and a slew of other great titles. His kindness, warmth, absolute wealth of experience, and incredible imagination is incomparable.

Tynan made ship levels, made vignette levels, made textures, made models, contributed to gameplay systems design.

Hire Tynan!

Laura Michet

Laura is the narrative director of Skin Deep. She created Skin Deep’s characters, plot, writing, handled the localization and VO process, and hired and managed all 9 of the guest writers who wrote the cat emails. Skin Deep has a ton of incredible narrative content and the only reason it works is because Laura is such a seasoned pro.

Laura was previously a narrative lead at Riot and is currently narrative director at Heart Machine.

(We’re also married ❤️)

Laura originated, wrote, and devised the narrative, handled the narrative design and methods of narrative conveyanace, handled voiceover audio hiring/recording/selects process, designed the email message system, managed the email message writers.

Eric

I’ve known Eric for 12+ years. We’ve previously collaborated on a gamejam project together, Goldline, and he’s also worked on titles such as Unfinished Swan, Solar Ash, Dream Daddy, Train Frontier Classic, and more. Eric is able to draw so much from his vast experience and apply it to so many parts of the game – engine code, rendering, gameplay, UI, everything.

Eric programmed many gameplay systems, programmed many engine systems, rewrote and upgraded many parts of the codebase, and contributed to the gameplay systems design.

Hire Eric!

Sanjay Madhav

Years ago, Sanjay and I were both on the same team when we worked at Pandemic Studios. It was so nice to reunite with Sanjay here. Sanjay has previously worked on titles such as The Lord of the Rings: Conquest, The Saboteur, The Pathless, and more. Sanjay is one of those programmers that can gracefully handle anything you give them, and I’ve always been impressed by how he’s able to make the most surgically precise changes to code that do so much.

Sanjay programmed many gameplay systems, programmed many engine systems, rewrote and upgraded many parts of the codebase, and contributed to the gameplay systems design.

Sanjay is a professor at the University of Southern California, and his site can be viewed here. Hire Sanjay!

Priscilla Snow

Priscilla composed and made all the music in Skin Deep. Priscilla describes the genre-spanning Skin Deep soundtrack as a “fever dream” and I agree in the most complimentary way possible – every track is so beautiful in completely different and unique ways. Priscilla has previously composed soundtracks for A Good Snowman Is Hard To Build, Patrick’s Parabox, JETT: The Far Shore, and more.

Priscilla wrote, composed, performed, and mixed all of the music, created all of the radio segments, and created the soundtrack album art.

Hire Priscilla! Her site is here.

Mimi Kwan

Mimi made some models for the game, and also made the textures and models for all of the cats. There were a lot of fascinating logistics to figure out with Skin Deep’s low-poly cats – how does a cat wear glasses? How does a cat hold a purse? Where does a cat hang its lasso? – and Mimi was an amazing collaborator to work with, coming up with creative solutions to unique problems. If you need 3D model work, hire Mimi.

Mimi designed, modeled, and textured many cat models, and modeled various gameplay objects.

Hire Mimi! Her portfolio is here.

Tom Elgon

Tom made the rigs, models, textures, and animations for all of the human characters in the game. Truly incredible art, and truly understood what would work well in the game. Fun fact: Tom’s Save the Princess animation was the first work of Tom’s that I saw, and clicked with it immediately – do yourself a favor and check it out.

Tom designed, modeled, textured, rigged, and animated the pirate, elite pirate, bodyguard, and chef models.

Hire Tom!

Et al

It’s a miracle whenever any game is released. Games are such a tangle of things, of art and science and production practicalities all smashing into one another.

Skin Deep is no exception. I’m so glad I got to work with such a great crew on this.

There are more people who worked on the project, listed here, and I’m thankful to everyone. Without these people, this game wouldn’t happen.

If you see something you like in Skin Deep, please know this: it’s almost certainly from one of the wonderful folks listed above.

Brendon Chung (that’s me) was the creative director, project manager, and generalist of Skin Deep.

Brendon led the project direction, managed and coordinated the different disciplines, contributed to gameplay systems design, made models, made textures, did audio design, did level design, did gameplay programmming, made tools, and helped out wherever needed.

Enjoy Skin Deep!

Skin Deep: Sketches

Mon, 28 Apr 2025 00:00:00 +0000

Skin Deep will be released April 30, 2025. That’s 2 days from now!!!!!!!!!

Reviews of the game are now out:

Eurogamer - ⁴⁄₅ - “Skin Deep, though, is a perfect genre piece. It’s immersive and it simulates.”
PC Gamer - ⁸⁸⁄₁₀₀ - “Skin Deep is peak improv problem-solving unmarred by the dour dystopias this genre is built on.”
Gamespot - ⁸⁄₁₀ - “It checks all the boxes of a great immersive sim, where each level is a puzzle box and you hold any number of figurative keys to unlocking it. And, yes, you can flush the toilets.”

Wishlist Skin Deep here!

To view all posts in this series, click here.

Sketches

While making Quadrilateral Cowboy, I had some loose thoughts about some sort of first-person game that takes place in spaceships. For fun I used to draw a sketch every Monday, and some of these sketches would eventually lead to Skin Deep.

These were very rough concepts/jokes – so just to set expectations, please don’t expect these ideas to be in the final game.

I find it helpful to get ideas out, either in written notes or a small sketch, during the process of figuring out the shape of something.

Maximum FPS

Jan 19, 2015 | I love games that have unexpected verbs. Toot…

Arm sling operative

Nov 23, 2015 | Simulating injuries in games is always fascinating!!

Physicality

Dec 14, 2015 | For playability and production reasons, games often treat the player as a smooth capsule that glides around the world. I love the idea of the player body being cumbersome and uncooperative.

Inventory bag

Jan 4, 2016 | So that’s where FPS characters lug around all those bullets…

Medical kit

Jan 18, 2016 | “Space painkillers” lol

Space pumice

Feb 22, 2016 | “Space pumice scouring stick | professional use only”

Tools of the trade

May 15, 2017 | I believe the lance was from the movie Thief.

Pockets

May 22, 2017 | I was trying to imagine how much bags a person would need to strap to themselves to lug around all their first-person action game objects.

Hull door

May 29, 2017 | The little light is my spare bicycle light (lol)

Turret

Jun 5, 2017 | I was riffing on the portable turrets in Half-life 1 & Team Fortress 2, and came up with this little barrel thing.

Et al

I find conceptual sketches to be a good starting point. I think it’s a helpful step to take things out of your brain and start figuring out how something would physically appear/move/open/use/etc.

Once things start being built in the game engine, things have a habit of changing dramatically (at least in my workflow). A sketch is a sketch, while a playable video game has very different needs/requirements/demands/etc. An idea can exist as a perfect gem in your mind or on paper, and finding ways to translate and interpret its juice into the actual game is always a fascinating process.

Someone… please make a game where I can press [F] to toot.

Skin Deep: Stresstester

Mon, 14 Apr 2025 00:00:00 +0000

Skin Deep will be released April 30, 2025! In the following weeks, I’ll be writing about the processes and development of Skin Deep.

Wishlist Skin Deep here!

To view all posts in this series, click here.

Skin Deep stresstester

This week I’ll be writing about a robot we wrote to help break the game.

Skin Deep has a lot of moving parts in it. One of the challenges was making sure the game remained stable in these many interactions. To help us out with this, we made a robot named “Stresstester” that just continually played the game all day and all night long.

(long-time readers of this site will recognize that this name was previously used in the development of Atom Zombie Smasher, for the exact same purpose. Ha. This was coincidental. I guess the name just stuck with me…)

Stresstester (the bot)

What does Stresstester specifically do?

it loads a random map
it makes the player invincible
it makes the player roam around the level willy-nilly
it occasionally attacks enemies
it occasionally restarts the level
it occasionally does a savegame and occasionally does a loadgame

So yea, it turns the player into an ominous invincible robot. The enemies shoot at you urgently, hopelessly, forever…

Stresstester (the program)

Confusingly, there’s a separate program also called Stresstester (I don’t know why I did that) that is a companion to the bot.

This is a C# winform program that detects when Skin Deep has crashed out. When it detects this, it restarts a new instance of Skin Deep.

The end result is you potentially get to accrue multiple crash logs throughout the day/night.

Et al

Making this was interesting because you have to be pretty careful that the bot itself isn’t creating new issues or reporting false positives. You’re making a bot that is pretending to be a human being and is doing its best to make the game believe it’s just a normal human person doing stuff in the game world. Can you imagine how embarrassing it would be if some crashes it reported were caused by the bot itself?

(this did happen and yes it was embarrassing)

As mentioned in a previous post, a downside of the stresstest bot is that you don’t really know what happened. I don’t have a great way to ask the bot to describe specifics on the chain of events, or to get any insight on things. It’s just a bot. We can get a code call stack and manually dig through the logs, and that’s basically it.

For any real testing you’d want human beings that you can talk to. Stresstest bot does have its place though, so we’ll continue to make variations of it for future projects.

Skin Deep: Accessibility

Mon, 07 Apr 2025 00:00:00 +0000

Skin Deep will be released April 30, 2025! In the following weeks, I’ll be writing about the processes and development of Skin Deep.

Wishlist Skin Deep here!

To view all posts in this series, click here.

Skin Deep accessibility

This week I’ll be writing about some of the accessibility features in Skin Deep.

Game

For gameplay, we have options to:

Toggle blood effects: toggle blood particles & decals.
Toggle hit effects: toggle screen effects that happen when you take damage.
Toggle screenshake: toggle effects that shake the screen.
Toggle headbob: toggle ambient movement of screen when you move.
Adjust damage you receive: scale amount of damage inflicted on you.
Perception multiplier: scales duration of time needed for enemies to notice you.
One-hit kill: this makes enemies get destroyed in one hit.
Button prompts:
- by default, Skin Deep will automatically switch its button prompts to your current active control type.
- Example: if you use keyboard and mouse, it will show keyboard and mouse prompts. If you use a Playstation 5 gamepad, it will show Playstation 5 button prompts.
- The Button Prompts option allows you to force the game to show a specific type of button prompt.

Subtitles

For subtitles, we have options to:

Show subtitles
Show speaker name
Subtitle text size
Box opacity: adjust translucency of the background box behind the subtitle.
Speaker color: change color of the subtitle speaker.
Dialogue color: change color of the subtitle dialogue.

Video

For video, we have options to:

Adjust brightness
Adjust field of view (FOV)

Audio

For audio, we have options to:

Adjust master volume
Adjust sound effects volume
Adjust music volume
Adjust voice volume
Toggle speaker setup: options include stereo, surround, or mono.
Toggle reverb effects on/off: toggles atmospheric/echo audio effects.

Language

Language: Choose between 15 supported languages. Translated languages in Skin Deep include:
- English
- French
- Italian
- German
- Spanish (Latin America)
- Spanish (Spain)
- Japanese
- Korean
- Polish
- Portuguese (Brazil)
- Portuguese (Portugal)
- Chinese (Simplified)
- Chinese (Traditional)
- Russian
- Turkish
Translation prompts:
- The translation prompt is a small box that appears that displays translated text of what you’re looking at.
- The Translation Prompt behavior can be changed to be: Automatic, Always On, Always Off.

Keyboard/mouse

Keyboard/mouse controls: buttons/keys are fully re-bindable.
Toggle crouch toggle/hold: this controls whether crouch is a button tap or button hold behavior.
Mouse invert
Mouse sensitivity

Gamepad settings

For gamepad controls, players have options to:

Gamepad controls: buttons are fully re-bindable.
Toggle crouch toggle/hold: this controls whether crouch is a button tap or button hold behavior.
Invert look
Toggle vibration
Adjust stick deadzone
Adjust look sensitivity
Adjust look acceleration
Adjust menu cursor speed
Swap left/right sticks

Et al

We hope the accessibility features we’ve added help you enjoy Skin Deep. If you have comments or suggestions, please drop a note at the Blendo Games Discord or send me an email.

See you all April 30!

Skin Deep: Steam Verified

Mon, 31 Mar 2025 00:00:00 +0000

Skin Deep will be released April 30, 2025! In the following weeks, I’ll be writing about the processes and development of Skin Deep.

Wishlist Skin Deep here!

To view all posts in this series, click here.

Skin Deep on Steam Deck

Skin Deep is now officially Steam Deck Verified! ✔️

What does this mean? Basically, it means the game has been confirmed to play well on the Steam Deck.

In addition to being Steam Deck Verified, we’ve added lot of specific functionality to make the game work well on the Steam Deck. This week I’ll be writing about some of the things we’ve done to make the experience more enjoyable.

Controller Glyphs

Skin Deep will automatically swap its controller button icon images to your currently active controller you’re using. For example, if you’re using an Xbox controller, it’ll swap to Xbox button images.

In the case of the Steam Deck, we’ve included button icons specific to the Steam Deck. Additionally, when the game starts up, it will default to the Steam Deck control icons if it detects you’re playing on the Steam Deck.

Credit: button icons from Xelu’s Free Controllers & Keyboard Prompts.

Full Controller Support

In addition to keyboard/mouse controls, we’ve been spending a lot of time making the game work well with gamepads.

This includes functionality such as being able to set the stick deadzone, stick acceleration, the option to swap sticks, and the ability to re-bind the controls.

Video resolution

If the game detects you’re playing on the Steam Deck, we included a quality-of-life feature where the game will automatically select and use the Steam Deck’s screen resolution (1280x800).

Steam Cloud

We save your settings and save games to the Steam Cloud. This allows you to seamlessly play Skin Deep on different machines without losing your progress. For example, you can swap between your PC and the Steam Deck, and your progress will remain consistent.

Additionally, one thing we intentionally do not save to the Steam Cloud is: your video settings. We’ve found that players sometimes have different hardware & preferences on different machines, so video settings are kept per-machine.

Et al

We’re very excited for folks to try out the game, and we hope Steam Deck folks enjoy the additional functionality we’ve added.

See you all April 30!

Skin Deep: Blendo Localizer

Mon, 24 Mar 2025 00:00:00 +0000

Skin Deep will be released April 30, 2025! In the following weeks, I’ll be writing about the processes and development of Skin Deep.

Wishlist Skin Deep here!

To view all posts in this series, click here.

Blendo Localizer

Today I’ll be writing about the Blendo Localizer tool. Here’s what it looks like:

Context

For context: in Skin Deep, strings assets have 2 components:

the string has an ID name. Example: #str_hub_nina_900041
the string has a text value. Example: Feels like old times.

The reason for this text setup is so the game can be localized to other languages.

What does the tool do?

The Blendo Localizer tool does various things. I’ll note that this tool is not where we write/type strings into the game (we use a Google Sheet for that, as it makes sense to utilize its functionality rather than replicate it ourselves).

This Blendo Localizer tool is generally used to:

Find and fix text bugs.
Manage text assets.
Assist with localization.

Basically, it’s a general-purpose tool to help with text assets. It got used very frequently during the project.

Search

Having a frictionless way to search for text assets was a primary goal. Similar to the Blendo Wav Tool, assets could be found by entering loose fragments of text into the filter boxes.

Example:

I’m looking for a specific text asset where a cat mentions a potato and the moon.
I would put into the name filter: cat (because the string ID will include the speaker name “cat”)
Then I would put into the displaytext filter: potato moon (because the cat’s dialogue will somehow involve the words potato and moon somewhere in the sentence.)
…this would then filter the list of results to this criteria. Done! #str_cat_deli_00410 I'm over the moon for that potato.

It’s very basic but effective search functionality, allowing us to find assets in a few seconds at most. We found it worked very well – I recommend trying it out for your own tools.

AutoConverter

We keep all of our strings in a Google Sheets spreadsheet. One thing we needed was: a pipeline for moving the text out of the spreadsheet and into the game.

This was going to be a high-frequency task, so the goal was to make this pipeline as simple and fast as possible. This pipeline was called the AutoConverter.

Here’s the AutoConverter process:

In the Google Sheet spreadsheet, we download it in .CSV format (File > Download > CSV)
Blendo Localizer detects the newly-downloaded file, automatically converts it into the game format, and integrates it into the game. Done!

So yea, getting text into the game happens automatically behind the scenes. Once you download the CSV file from Google Sheets, the tool takes care of the rest without any clicks or intervention from you.

Basically, the tool “listens” to your download folder, and when it finds a CSV with a filename that matches a specific pattern, the tool converts it and integrates it into the game.

Credit where it’s due: this “listen” approach was from our programmer Eric, who used this approach in a prior tool he made for XNA asset conversion.

Localization

Additionally, if you have a handful of language CSV files, you can just bulk drag all of them into the tool window. The tool will convert them into the game format and integrate them into the game.

This is useful when receiving a delivery of localized languages.

Audio shortcuts

We ended up finding it helpful to be able to quickly access audio assets associated with a given string. We added these buttons:

This lets you find the .WAV file in windows explorer, open the .WAV file in your audio tool, or play the .WAV file.

Example: if we hear a line of VO that could use an audio tweak, we can quickly search for the VO’s subtitle line using the filter boxes, and then click the Edit .wav file button.

(This is largely only possible because in Skin Deep, the VO audio filename and the subtitle string ID name are identical)

Blendo Localizer has a Tools menu, for various functions:

Find stringID references

Strings can be used in many parts of the game: menus, in the world, in dialogue, in GUIs, in email messages, etc. Find stringID references found all references of a given string in the game. This was useful to find the context that a string was being used.

AutoConverter

This is an options panel that tells the tool whether to use the AutoConverter or not, what folder to listen to, and what filename wildcard to listen for.

View Stats

This prints out stats like word count, character count, and string count.

Check duplicates

This checks if multiple strings have the same exact text.

Check for unused stringIDs

This checks if any strings are not being referenced by the game.

Export to CSV

This is to convert the game strings back into CSV.

Check duplicate suffix number

This checks if multiple strings have the exact same 5-digit suffix number in their string ID.

List prefixes

Our string ID naming scheme uses _ underscores. List prefixes lists out all the string ID name prefix values, by looking at the values between the underscores.

Find empty strings

This lists strings that have no text in them.

SpaceFinder

This marks out spaces in a string:

This is most useful in some languages that use variants of spaces, or types of spaces you can’t see. There’s a lot!

Character Viewer

This gives information about each individual character:

For some languages, this is useful for find out exactly what character is being used. This uses information from the Unicode character database.

Example: sometimes a character that looks like a ; semicolon is sometimes not the semicolon you may expect.

Compare all languages

This compares the strings in all languages:

This compares all the languages to the base language (English) and prints out what strings are currently missing and if there are any extraneous strings.

Nuts and Bolts

Blendo Localizer was made with Winforms. It was written in C# with Visual Studio 2015.

If you think any of this may be useful, please feel free to adapt it to your own project:

Et al

There’s thousands of text strings in the game. I don’t think tenable to trudge through thousands of assets, or to spend a big chunk of your day doing tedious manual processes. Your time on this planet is limited! Be nice to yourself!

I feel very lucky that I’m able to create these tools pretty quickly. I value the time they save, and I find them fun to make. Sure, some of this tool’s functionality ended up being pretty niche and not being used too much. And you know what? I regret nothing! I’d do the same thing again!!!!!! Tools! ⚙️

Skin Deep: Skin Deep BuildPackager

Mon, 17 Mar 2025 00:00:00 +0000

Skin Deep will be released April 30, 2025! In the following weeks, I’ll be writing about the processes and development of Skin Deep.

Wishlist Skin Deep here!

To view all posts in this series, click here.

Skin Deep BuildPackager

Today I’ll be writing about the Skin Deep BuildPackager tool. Here’s what it looks like:

Yes, this is yet again a tool that has one button.

To set expectations: the general concept of the BuildPackager (package up a build ready for players) is widely applicable. But the particular details of this tool apply specifically to Skin Deep, as this tool is only for Skin Deep’s particular file structure and folder setup.

Goals

I wrote this tool to package player-facing builds of Skin Deep. Example: a build of the game that gets uploaded to Steam.

This generally means:

Removing ‘source files’ for assets.
- This is stuff like: Blender .blend files, Photoshop .psd files, intermediate model format files like .FBX and .OBJ, reference image files, map backup save files, and other development files.
- A large majority of our assets have multiple source files. In Skin Deep, roughly 80% of files are development files that can be removed.
Removing developer test maps.
- Oftentimes when we add a new feature to the game, we’ll make a “test map” that just has that one object in it. Example: map “test_healthstation” just has one health station.
- These test maps allow us to quickly revisit, test, and verify things with the feature during development.
- They end up adding up to a relatively large amount of space, so we remove them during packaging.
Ensuring necessary files are present.
- Making sure that the .exe executable file exists.
- Making sure that the .pdb debug file exists.
- This is just a basic check to make sure we’re uploading something playable.
Compiling the maps.
- In the game engine, maps need to have their collision data and pathfinding data built.
- When packaging a build, we opt to just re-compile every map every time.
Upload.
- The tools upload the files to wherever they need to go, i.e. Steam.

This is all stuff that can be done manually. But, it’s quite a lot of steps and is very tedious, so it made sense to make a tool to automate this.

Why GUI

This uses a GUI interface. The BuildPackager would definitely work well as a command-line tool, and would probably be faster to build with that approach.

I personally like to use GUIs for my tools (instead of command-line). The main reason: I had some command-line processes in the past, and yes, they did work great. The problem was:

When I later needed to revisit the project a number of years later (i.e. 5-10 years) it was sometimes a bit tricky to re-learn how the command-line tools worked.
Whereas a visual GUI interface tended to be more immediately intuitive/useable years later.

Now, crossing my fingers that functionality/support for these GUIs don’t disappear anytime soon… 🤞

How it works

First, I compile a new executable in Visual Studio. I didn’t automate this, because I just never got around to it.

Then I click the giant Start button:

Here’s a step-by-step of what the tool then does:

BuildPackager verifies all the files it needs actually exist, such as the game executable.
BuildPackager rebuilds collision data and pathfinding data all of the game’s maps.
- This is done by running the game with some specific command-line parameters.
BuildPackager deletes all the files in a “staging area” folder for the build.
BuildPackager copies the game files to this “staging area” folder for the build.
- During this step, the tool curates which files to copy. It only copies over the files that we want players to have/see.
BuildPackager then calls the Blendo Steam Uploader tool with a command-line parameter, to make it automatically upload the fresh build to Steam.

That’s it. It’s very straightforward stuff!

Nuts and Bolts

Skin Deep BuildPackager was made with Winforms. It was written in C# with Visual Studio 2015.

This tool is extremely specific to Skin Deep, and is also extremely specific to the needs and file structure of this project. So, just to set expectations, this will probably not be immediately useable to anyone, without a lot of changes.

But at any rate, please feel free to adapt it to your own project:

Et al

Older titles from the Blendo games catalog still get updates!

Atom Zombie Smasher / Aug 2023 update - 12 years after release
Flotilla / Sep 2023 update - 13 years after release

I think it’s worth spending time making a basic build packaging tool and writing some internal documentation on your build processes. Mainly because the person you were a decade ago is probably not the same person you are now, and it’s possible you’re going to wish you had some help from your past self in learning how to re-package a build of your game.

I can uhhhh say this from personal experience 😅

Skin Deep: Blendo Build Machine

Mon, 10 Mar 2025 00:00:00 +0000

Skin Deep will be released April 30, 2025! In the following weeks, I’ll be writing about the processes and development of Skin Deep.

Wishlist Skin Deep here!

To view all posts in this series, click here.

Blendo Build Machine

Today I’ll be writing about the Blendo Build Machine tool. Here’s what it looks like:

Yup, it’s one huge button. “Create build.” That’s it!!!!

Goals

I wrote this tool to solve one issue: how to give the development build to every teammate.

The team consists of multiple people.
These people need to work on the game.
In order for people to work on the game, they need a build of the game.
Not just any build, but the latest version of the game, with changes that were checked in sometimes several seconds ago.

(For context, “development build” here means a build of the game with the most recent code/content/etc.)

Approaches

Here’s approaches I considered:

Use the cloud: Someone remotely initiates a build, and then a computer somewhere in the world creates and distributes the build.
Use myself: Have me create each build and then distribute it to everyone.
Use teammate’s computer: Have the teammate create their own build.

I think all three of these are viable, and all have pros and cons. I think it depends on what you’re looking for and how you all work.

I chose option #3, of having each teammate create their own build on their own personal computers.

I looked into a cloud solution, but this wasn’t something I had much experience in.
I didn’t want to create builds myself, as I didn’t want to become a bottleneck of someone waiting for me to do something.
And so, option #3 felt most viable. This enabled each teammate to create a build on-demand, whenever they like, regardless of timezone or my availability.

How it works

You click the giant Create Build button:

The tool then:

Grabs latest source code: it uses SVN to get the latest content & latest source code currently in the repository.
Compiles the latest code: immediately afterward, it uses Visual Studio command-line tools to compile the source code. This results in a new game executable.

The end!

Wait, that’s it?

Yea, that’s it.

To be clear: this tool ultimately boils down to automating some button clicks. Here’s how you’d manually do what this build machine does:

Right-click on project folder.
Select SVN Update from the context menu.
- [Wait for latest data to finish downloading, 1-60 sec]
Open the .sln file in Visual Studio.
Press F5 to compile a new build.
- [Wait for build to finish compiling, ~4 min]

I don’t think every process needs to be automated. But there’s a couple things in this specific manual process that make it worth automating:

If you forget to do one of the steps in this manual process, or do them out of order, it will silently fail and silently result in a wonky build.
It has some duration of waiting between the button clicks, which means you have to babysit your computer.
It’s a task that teammates do very frequently.

So, for those reasons, it made sense to automate this process with the Blendo Build Machine.

Options

Here’s the options for the tool. It’s mostly self-explanatory. There’s a fair amount of knobs you can turn to make it work for how you like to operate.

I personally like to have the tool just automatically start the process when I run it, and then automatically run the game when the process is all done.

Notes

If for some reason you don’t want teammates to have the game’s source code, then this won’t work for you.
A tradeoff is: this front-loads the initial setup time. Teammates have to install Visual Studio, which can sometimes be gnarly, so initial setup time can be a big task. We’ve done a fair amount of documentation to try to head this off.
Credit where it’s due: the initial inspiration for making this tool was from Seth Coster’s DevOps talk.

Nuts and Bolts

Blendo Build Machine was made with Winforms. It was written in C# with Visual Studio 2015.

If you think any of this is useful, please feel free to adapt it to your own project:

Et al

Laura and I used the Blendo Build Machine when we worked together on Tall Bagel, and we’ve since used it on other projects we’ve made together.

Can this tool be used for your game? Maybe! Who knows.

I personally think it’s fine & good to make a tool specific to your process/project, and then to never re-use it again. I find these tools to be relatively quick to make, so it’s very feasible to make a one-off thing.

I think you gotta just figure out what works for you!

Skin Deep: Blendo Wav Tool

Mon, 03 Mar 2025 00:00:00 +0000

Skin Deep will be released April 30, 2025! Some wonderfully talented folks and I have been cooking up Skin Deep together for a while, and are thrilled people will be playing the game soon.

Play the limited-time Skin Deep demo
Add Skin Deep to your Steam Wishlist
Read lovely Skin Deep writeups from:

In the following weeks, I’ll be writing about the processes and development of Skin Deep.

Wishlist Skin Deep here!

To view all posts in this series, click here.

Blendo Wav Tool

Today I’ll be writing about the Blendo Wav Tool. Here’s what it looks like:

Skin Deep has a lot of sound effects, a lot of music, and full voice acting (VO). There’s a lot of audio. As a result of this increase in scale, it became challenging to manage this amount of assets – and so, I made this Blendo Wav Tool.

To set expectations: this is all very low-tech straightforward stuff. There’s nothing here that can’t be done with Regex or a Python script. But having a specific tool for our specific workflow was something hugely helpful.

If you think you can make use of this, the Blendo Wav Tool’s source code and binaries are available here.

Here’s the various contexts in which this tool was used.

Finding/Sorting

Finding/sorting was what the tool was mostly used for in day-to-day usage.

Let’s say you…

hear a character play a wonky sound, so you want to edit the file.
are building a scene and need to re-hear the intonation of a specific line.
are fixing a bug and need to browse a specific category of audio.

So: you want to find and open the audio asset. But you…

don’t know the filename…
or don’t know what folder it’s in…
or need an easy way to browse a specific category of audio…

This was Blendo Wav Tool’s original purpose: to make it easy to find audio assets in the project. This is handled via these 2 search boxes:

the Folder filter filters by foldername.
the Filename filter filters by filename.

The file list automatically filters itself to your search parameters. So as you type each letter, you’ll see the file list curate itself down shorter and shorter.

There is an additional feature here that makes searching easier:

any empty space is treated like an AND operator.
What does this mean? It means if you’re like me and kinda but not exactly know what you’re looking for, this allows you to utilize the fragments you do remember.

Example:

I’m looking for Pirate B’s sneeze noises. But I don’t remember what the specific filenames are.
For my filename query, I type: _b pira snee
- This is because I know it’s Pirate B, and I know the word “sneeze” is involved.
- This results in searching filenames with: _b AND pira AND snee
This results in finding files:
- pirate_b_combat_sneeze_01.wav
- pirate_b_combat_sneeze_02.wav
- pirate_b_combat_sneeze_03.wav

In short: this allows you to type a few loose un-ordered fragments to quickly find the asset.

This is very un-fancy stuff, but combined with folder filter, results in being able to find anything in a few seconds. Your mileage may vary! But I get a crazy amount of usage out of this functionality, and would love to see this approach in more tools.

Credit where it’s due: using the space as an AND operator was part of how level design tools worked at Pandemic Studios, where I used to work as a designer. It was a good idea then and it’s a good idea now!

Tools

The Tools menu has various miscellaneous audio-related helpers.

Suffix duplicate check

Some audio assets have a 6-digit suffix. This tool does a check to see what assets share the same suffix number.

Vosk speech recognition

This does speech recognition to print what words are being said in VO files.

This ended up not really being used, as we ended up making a localization tool (that I’ll write about later) that served a similar purpose to this.

Compare wav files to scripts

This scans the game’s level scripting files and sees what audio assets are NOT being used. This was made to identify what audio assets we were and weren’t using.

to identify what assets were obsolete/deprecated.
to identify what assets haven’t been hooked up yet.

Scan suffix numbers

This was to help us find filename suffix numbers that weren’t currently being used.

File differ

This tool allowed us to paste in a big list of filenames, and then compare this list to what files we actually currently have in the game. The use case was:

we have a big spreadsheet of VO filenames we expect to have.
we want to compare the spreadsheet’s filenames to the filenames we currently have in the game.

This tool allowed us to find:

files that were missing or not yet implemented
files that were mislabeled
files that were now obsolete

Copy all files into a folder

Sometimes you want to filter the audio assets to a specific category, and then copy them into a separate folder (i.e. to send it off to an audio engineer, or to send to marketing folks, etc). This tool just copied the currently-filtered files into a separate folder.

Display Max Amplitudes

We had an issue where some audio files were very very very quiet. This tool just printed the maximum amplitudes of each audio asset, so we can identify assets that had this low-volume issue.

Detect silence (at file start)

This filters audio assets that have a period of silence at the beginning of the file. This was for audio asset bug-fixing.

Detect silence (at file end)

This filters audio assets that have a period of silence at the end of the file. This was for audio asset bug-fixing.

File drag

Additionally, dragging .wav files into the window will attempt to copy and overwrite existing project .wav files with the new ones.

The use case is if you receive updated/revised audio assets, this is a quick way to instantly plug these assets into the game without having to manually drill into various folders.

Nuts and Bolts

Blendo Wav Tool was made with Winforms. It was written in C# with Visual Studio 2015.

Libraries used include:

If you think any of this is useful, please feel free to adapt it to your own project. The Blendo Wav Tool is available here:

Et al

As I said above, this is all low-tech stuff. Sometimes that’s all you need.

It takes time to make tools, but I believe that time spent automating a little thing is time well-spent. Any time a process requires a lot of fiddly time-consuming error-prone bits that can be automated, my brain slightly melts and I think “why am I doing this???”

Tools… they’re good!

BagelTech

Sun, 08 May 2022 00:00:00 +0000

During 2020 and 2021, Laura and I made some games together, including:

Here’s Laura’s thoughts on it, and here I’ll be writing about the tech behind our Tall Bagel games.

Engine

We jokingly referred to our tech as BagelTech, but we ended up saying the the term BagelTech so often that it became the de facto name.

BagelTech is primarily powered by two libraries/frameworks:

FNA

FNA is a framework that handles graphics, input, audio, and more. For those familiar with XNA, FNA is a modern implementation of XNA.

I’ve been using XNA/FNA since over 10+ years ago (including my first commercial game Flotilla!) and I highly enjoy working with it. It’s free, lightweight, open-source, cross-platform, and flexible.

BagelTech is built on an accumulation of code I started way back in Flotilla. Here’s what it mostly looks like now:

camera.cs handles the player first-person camera movement.
helpers.cs is my junk-drawer of helpful functions.
inputmanager.cs handles game input.
program.cs is where the program starts.
screen.cs a ‘screen’ is: options menu, game world, inventory screen, etc.
screenmanager.cs handles the stack of screens (removing, adding, updating).
settingsmanager.cs handles save/load of options (volume, resolution, etc).
soundmanager.cs is where we handle audio.

If you’re ever interested in checking out FNA, I made an open-source FNA Starter Kit to help get you going. It includes most of what I describe above.

YarnSpinner

Laura did all of Tall Bagel’s writing and scripting. We wanted find a way to allow her to rapidly implement and test her work. I think you can create an amazing amount of momentum when working with a good pipeline, and we wanted that kind of environment here.

We had a series of goals. We wanted to be able to:

Implement content quickly/easily.
Have content be data-driven (i.e. in human-readable text files, not in code).
Test content quickly/easily.

YarnSpinner ended up being fantastic for this. YarnSpinner is a tool for game dialogue and game scripting. It’s lightweight, straight-forward, and is as extensible or minimal as you like.

Here’s a sample from Tall Bagel:

[time 3]Kim: I'm saving my dessert budget for egg nog.
[time 2]Jacob: But this is egg nog.
<<lookpitch kim 10>>
<<jostle kim 2.5>>
[time 3]Kim: No, it's egg nog ice cream!

The scripts live in a text file, and control what the characters say and do.

The [time 3] command determines how long their speech bubble stays on-screen.
We added various commands to control the characters, including <<lookpitch>> to make the characters look up/down, and <<jostle>> to make the characters shake in indignation.

If you’d like to see all of the various scripting commands we added to the game, we listed them all here.

Note: our Tall Bagel games (1, 2) are designed to be moddable. If you want to make a dinner party mod, please do!

Rapid Iteration

We wanted to be able to easily test things, to be able to fast-forward or skip to specific parts of the game. We added debug tools to facilitate this.

R = reloads all script files, without having to exit the game.
DOWN ARROW = skip current dialogue bubble.
RIGHT ARROW = skip to next chapter.
[ ] = select chapter from dropdown box.
ENTER = confirm chapter dropdown box selection.

Here’s how our debug view looks like in-game:

For any future Tall Bagels, I’d love to re-visit how we handle how we test – perhaps something more intuitive and GUI-driven that uses less cryptic keystrokes.

Thanks

Working on these games was a joy. It’s wonderful to work with Laura, it was wonderful to see these characters come to life, and it was wonderful to create tech built around our specific workflow and processes.

A big special thanks to Choroplethora for making fantastic music for our games, and to Ethan Lee for helping us make our games work on Mac/Linux (and for making FNA!).

Automation Tools

Mon, 05 Apr 2021 00:00:00 +0000

Some time ago I watched a fantastic DevOps talk by Seth Coster, and it inspired me to make my own set of automation tools. Here they are!

Blendo Build Machine

What does it do: Allows teammates to get the project’s latest source code and compile a new build with the click of one button.
How it’s useful: This tool removes me as a bottleneck for new builds. Teammates can generate a new build whenever they like.
Download: download / source code

Blendo Steam Uploader

What does it do: GUI interface for uploading builds to Steam.
How it’s useful: Simpler to use than the command-line interface, batch files, etc.
Download: download / source code

Blendo Itch Uploader

What does it do: GUI interface for uploading builds to itch.io.
How it’s useful: Simpler to use than the command-line interface, batch files, etc.
Download: download / source code

Discord Changelog Bot

What does it do: Posts all source control changelog messages into a Discord channel.
How it’s useful: Helps keep team updated on build changes.
Source code: source code

Trello Bot

What does it do: Posts Trello board updates into a Discord channel.
How it’s useful: Helps keep team updated on bugfixes/features.
Source code: source code

Et al

Mental fatigue sucks. An annoying manual process may only take several seconds, but compounded dozens of times every week, over months and months, will ultimately have a toll.

The purpose of these automation tools is to reduce friction, reduce manual processes, and reduce opportunities for errors and mistakes. I hope it helps!

Tools of the Trade

Tue, 01 Sep 2020 00:00:00 +0000

I wrote up a list of programs I use daily, partly to share what tools I use, and partly to have a backup list in case I need to do a fresh dev install on a computer that exploded.

(Which is to say, my computer exploded yesterday)

Enjoy!

Notepad++

For editing text files.

I get a ton of use from the LocationNav plugin that records the history of the text cursor, and allows you to navigate this history with ctrl+minus and ctrl+shift+minus. This is hugely useful if you’re constantly jumping between different parts of a text file.

Note: the LocationNav plugin only works with the 32-bit version of Notepad++.

Blender 2.79b

For making 3D models and doing video editing.

I would recommend using the newer versions. The only reason I use this older version is because my exporter scripts break in 2.8+, and I tend to only do upgrades when I’m between projects.

XNView

For viewing image files.

My current project Skin Deep uses the kinda-sorta uncommon TGA image format, so I use XNView to browse these images.

Greenshot

For taking screenshots.

I think pictures are one of the best ways to communicate. I set up my Greenshot like so:

prtscrn: takes screenshot of entire screen.
alt+prtscrn: takes screenshot of active window.
ctrl+prtscrn: takes screenshot of a selected region.
and most importantly, for Destination: Save directly & Copy to clipboard

Basically, this saves every screenshot in a folder, but also copies it to the clipboard so I can quickly paste it somewhere.

DarkRadiant

For level editing.

This level editor was made by a crew of talented folks for the Doom 3 mod The Dark Mod. They’ve graciously allowed this editor to work for vanilla Doom 3 work, so we’ve been using DarkRadiant to make levels for Skin Deep.

Audacity

For audio editing.

Blendo Productivity Tools

Various tools to streamline development.

I was hugely inspired by Seth Coster’s GDC DevOps talk and immediately made a small suite of tools to automate some of my manual processes.

More Blendo tools here: click here

Visual Studio 2015

For writing code.

PDF-XChange Editor

For making/editing PDF files.

I have to wrangle enough PDF files that eventually I realized I should just get a tool that makes it easy wrangle them.

VLC Media Player

For playing videos.

7Zip

For uncompressing archive files.

Spacesniffer

For visually viewing what files/directories are taking how much space.

Useful for finding why the heck a folder is way too big.

Filezilla

For doing FTP stuff.

WinMerge

For comparing two files (or directories) and viewing their differences.

Photoshop

For image creation/editing.

Discord

I use Discord for managing the Blendo Games discord and as one of the primary ways of communicating with the team.

It has seamless text, voice, and video functionality. I’m constantly surprised it somehow all just works.

OBS Studio

For broadcasting livestreams, and also for locally recording desktop/window footage.

I’m currently taking a break from my development streams, but this is the tool I use to do them.

Additionally, when I ask friends to playtest my games, it’s tremendously helpful when they record their playtest and send it to me. I like to return the favor, and I use OBS to record my footage.

TortoiseSVN

For accessing my subversion source control.

Workflowy

For jotting down notes. I like how minimal it is and how it’s easily accessible via desktop site & phone.

Dropbox

For sharing files with people.

Et al

I’m sure I’m missing some stuff, but this is a large portion of the tools I use.

I think it’s important to clarify – there is no one-size-fits-all for everybody; I encourage you to find the workflow and tools that work for you. Good luck!

DIY Film Festival

Thu, 21 May 2020 00:00:00 +0000

I recently organized and ran a (very small & very simple) online film festival for the art collective I help run, Glitch City. It was a live event, with folks chatting and watching videos together. It turned out well!

The goals were:

Keep it simple. I have a fulltime job and wanted to keep the scope of this project small.
Keep it quick and snappy. Since this was a live event, I wanted things to move fast and keep the down-time low.
Handle any amount. I wanted a setup that made it easy to slot in new entries.

If you’re interested in doing something similar, here’s a brief overview of how I set it up. I used:

OBS Studio: handled title screens, intermissions, video playback. (free)
Film Fester: a program I made to automate the intermission screens. (free)
Discord: this is where I streamed everything. (free)

The basic flow of the event was:

Do a short intermission where the filmmaker says a live intro to their video.
Show their video (note: the videos were all local files on my hard drive).
Go back to step 1.

OBS Studio

OBS Studio is sort of like a TV control room. You can swap between different shots, you can make titles appear, you can play videos and sounds, etc.

My OBS setup had three Scenes:

TITLE SCENE: this is what we showed at the beginning and end of the event.
- It just displayed the title of the event.
VIDEO SCENE: this is what handled video playback.
- This scene is very basic. It has just has one Media Source. Nothing else.
INTERMISSION SCENE: this is what we showed between films.
- The filmmaker would say a live intro to their video during this time.
- This scene displayed what we just watched, what we’re going to watch next, and an intermission countdown. This was semi-automated by the Film Fester program.
- IMPORTANT: behind the scenes, this is where we queued up the next video.
  - This scene had a Media Source that was a duplicate of the one we made in the Video Scene. To do this, add a Media Source > Add Existing > select the Media Source you made in your Video Scene.
  - Then, make the Media Source invisible (click the eyeball icon).
  - What all this means: during the intermission, we’d change the Properties of this Media Source to load the next video file we wanted to show. This allowed us to make a seamless transition to the Video Scene, since it was now queued up with the next video we wanted to show.

In order to stream from Discord, right-click on OBS’s preview window and select Windowed Projector (Preview). Maximize the window that appears. We’ll revisit this window later.

The basic OBS flow was:

Go to the Intermission Scene. During intermission, change the Intermission Scene’s Media Source properties to load the next video you want to show.
Go to the Video Scene. It will play the video that you pre-loaded in the previous step.
As the video plays, go to Film Fester and set up the titles/countdown display for the upcoming intermission screen.
When the video ends, go back to step 1.

Film Fester

Film Fester is a program I made to help automate some tasks involved in the intermission screen, such as selecting what titles to show and displaying the intermission countdown timer.

You can download and read more about Film Fester here: https://github.com/blendogames/filmfester

Discord

We wanted to do a live event, with people chatting, reacting to, and watching videos together. Discord has this functionality built in, and it worked well. (note: Windows 7 seemed to have trouble with this, but it worked fine on Windows 10)

Join a voice channel. This is where you’ll invite all the attendees.
Click the Screen button to share your screen.
Remember the Windowed Projector (Preview) window we popped out of OBS earlier? That’s the application you want to stream.

That’s it, done – your thing is now streaming for folks to watch!

Et al

It was hugely satisfying to run a little online film festival. I do a daily development stream for Skin Deep that’s a much simpler one-click operation, but it gave me enough experience to work out how to make this all somehow come together.

If any folks read this and start their own little online festival, lemme know!

Flotilla Source Release

Thu, 27 Feb 2020 00:00:00 +0000

In 2010 I made a game called Flotilla and today on its 10th birthday, I’m releasing its source code. Enjoy! The game is fun but the code is a bit of a mess and embarrassing!

Source code: https://github.com/blendogames/Flotilla

Flotilla was basically my first game as a programmer. I had previously coded bits and pieces for my mod projects, but nothing to this scale. There’s a ton of janky code and a lot of naive implementation of things, but somehow that didn’t stop Flotilla from being shipped and released?

This project was my C# coding education. I went through of Microsoft’s official XNA tutorials and built the game from there. I definitely didn’t really know what I was doing. But, I learn best when I can apply lessons to an actual project, so this approach works for me.

Flotilla’s source code is released under the zlib license, which basically means you are free to use the source code for personal or commercial purposes. (Please note Flotilla’s game assets (art, models, textures, audio, etc.) are not open-source and are not to be redistributed)

Enjoy: https://github.com/blendogames/Flotilla

On Decades

Wed, 01 Jan 2020 00:00:00 +0000

10 years ago to this day, I founded Blendo Games, a small independent games studio. 10 years and still going! What the heck!

If we want to dive further into time:

Prior to starting Blendo Games, I worked at a large game studio for 5 years.
And prior to that, modding and level design was my hobby for 12 years.

So I guess I’ve now spent about 27 years in Games World. That seems like a long time? And yet, I still feel like how I did since first starting hobbyist mod work: excited to make the thing, constantly being baffled by the thing, and putting things together one microscopic step at a time.

Some thoughts on Blendo Games’ 10 years:

On Heritage

My parents are from China and immigrated to America. I was born and raised here in the states. I have two names, I (kinda-sorta) speak two languages, and I bear two cultures.

Some years ago I gave a talk at a conference. At the meet & greet afterward, an Asian person mentioned how encouraging it was to see someone of Asian descent up on stage.

Honestly, the remark caught me off-guard – I felt a burst of pride and a better understanding of where and how I fit in the world. I am a proud Chinese American. For you out there who wants to make video games: I’m doing it now, and I hope you do too.

On Independence

I think when some people hear “independent” they see someone of dizzying talent, skilled in disparate fields, a self-contained dynamo. Maybe they can’t do everything, but their wizardry lets them achieve almost anything, allowing them to operate siloed off from the world. Right?

I dunno, I used to think that. In hindsight, I feel it was very poisonous thinking.

We all need help at some point, whether it’s with our lives, our projects, or anything else. Independence and resiliance isn’t about doing everything yourself, it’s about nurturing and giving to a support network wide enough to also help you when you need it.

Pulling Back the Curtain

I’ve been chronicling development of my current project Skin Deep via a regular development stream. And let me tell you: it feels so good to make it crystal clear there are good days where I get a bazillion things done, and then there are days where absolutely everything goes wrong and bursts into flames.

I feel there is sometimes pressure to always put on a good face, or to reassure people everything’s perfectly fine. I sometimes fall prey to this, and I hate it.

Things always can and always will go wrong. There will always be things that are simply out of our control. And I feel the more honest we are with that, the more healthy we can be about personal expectations and creative burnout.

Et Al

I was a different person 10 years ago. And 10 years from now, I’ll again become a different person. Who knows what to expect!

Wherever the cards may fall, I’m glad to be here, I’m glad you’re here, and I appreciate you taking the time to play the things I help make. I wouldn’t be where I am without the love and help from friends, family, and supporters.

Thank you all. Take care.

Discord Changelog Bot

Mon, 29 Jul 2019 00:00:00 +0000

In the #changelog channel in the Blendo Games Discord, it displays this:

It’s a live log of my source control changelog messages for Skin Deep. That means: whenever I check anything into source control, my changelog note gets displayed here.

I made this for a few reasons:

I’m sometimes asked what I work on in a typical workday. Well… here ya go!
I want to help demystify what game development is. It’s a lot of fun stuff, a lot of not-fun stuff, and a million small steps and missteps that hopefully add up to something.
It’s a zero-friction way to share updates on where Skin Deep currently is.

How it works

Whenever I check anything in, my source control client runs a small program to post a message to Discord. Done!

Bot code

My code to post Discord messages is one C# file. Here’s the entire source code for it:

using System;
using System.Collections.Generic;
using System.Net;
using System.Net.Http;
using System.Text;

using Newtonsoft.Json;
using Newtonsoft.Json.Linq;

namespace ConsoleApplication1
{
    class Program
    {
        private static string discordURL = "YOUR_DISCORD_WEBHOOK";
        private static readonly HttpClient client = new HttpClient();

        static void Main(string[] args)
        {
            if (args == null) //if no argument, then exit.
                return;

            if (args.Length <= 0) //if no argument, then exit.
                return;

            string changelog = args[0];

            if (string.IsNullOrWhiteSpace(changelog)) //if argument is empty, then exit.
                return;

            //We have a valid message. Send the message to discord.
            DiscordMsg discordMessage = new DiscordMsg(changelog);
            var discordMessageJSON = JsonConvert.SerializeObject(discordMessage, Formatting.Indented);
            var resp = client.PostAsync(discordURL, new StringContent(discordMessageJSON, Encoding.UTF8, "application/json")).Result;
        }
    }

    public class DiscordMsg
    {
        [JsonProperty("content")]
        public string content { get; set; }

        public DiscordMsg(string message)
        {
            content = message;
        }
    }
}

The program generates an .exe file. When you run the .exe, any included arguments are sent as the Discord message.

Replace the YOUR_DISCORD_WEBHOOK parameter with your Discord’s webhook url. This can be found in your Discord: Settings > Webhooks > Create Webhook
This program uses the Newtonsoft Json.NET library.

Then, hook up your source control client to run this .exe file.

Source control client

Now you need to tell your source control client, “whenever I check anything in, run the Bot .exe file.” I use TortoiseSVN as my source control client, but this can be adapted to whatever client you use.

First go to: TortoiseSVN > Settings > Hook Scripts > Add…

This pops up a dialogue box. Fill it in with the appropriate info:

And that’s it. Now, whenever you check anything in, it will propogate your changelog message to your Discord. Enjoy!

Empire: Origins

Mon, 22 Jul 2019 00:00:00 +0000

I recently watched The Long Goodbye, a wonderful film. After watching any movie, I like to read about its development history and the people involved. During this, I learned The Long Goodbye’s screenwriter, Leigh Brackett, wrote the first draft of The Empire Strikes Back.

What! I definitely wanted to learn more about that.

The draft is a great read. All of Empire’s story beats are there, and it’s fascinating to see what things were changed and what was kept unchanged.

It can be downloaded/read here.

This dialogue bit from Han is great.

A bunch of Wampa creatures invade the rebel base on Hoth! I believe a remnant of this can be found in one of Empire’s deleted scenes.

I liked this moment where Luke senses the Empire/Darth Vader approaching the planet Hoth. The concept of people sensing one another across vast swathes of outer space is so compelling.

Extremely into the idea of rebel operatives wearing explosive necklaces that hold secret information.

Can very much see what Yoda (Minch) dialogue this ended up becoming.

Fun to see Darth Vader’s castle revisited in Rogue One, and the Emperor’s cloth-of-gold robes repurposed for Snoke.

Lando is, was, and will always be, the most dapper guy in the galaxy.

Luke meets his ghost dad!

This very much feels like a normal part of the creative process. Stories are hard to crack – every project starts somewhere, and this is where this one started.

Yoda (Minch) has one last lesson for Luke, in this predecessor to the Dagobah spooky-tree sequence:

The imagery of Darth Vader running his fingers through a starfield is incredible.

Luke is absolutely shattered by his experience. It’s so grim, and turns the dark side into this devastating cosmic horror. I love it.

Leia and Han talking about Lando:

When I was a kid growing up, any mention of the Clone Wars turned me into an animal. The Clone Wars was rarely mentioned, and when it was mentioned it was always in an off-handed manner. Details about it were always maddeningly vague.

And I guess a combination of all that made me ravenous. There was something magical about it!

I’ve always been morbidly curious about How My Dinner with Darth Vader in Cloud City Went, so it was fun to read this version of it.

ET AL

There’s a concept called analysis paralysis. One version of analysis paralysis is when you have to decide amongst an overwhelming/unrealistic amount of choices and are therefore paralyzed by indecision.

Creative work is very ripe for analysis paralysis. There’s literally a universe of possibilities – how do you ensure you choose the right things?

For me, the short answer is: you don’t. you can’t. (or at least I can’t.)

What you can do is: trust the process. Put stuff in, see how it feels, and course-correct accordingly.

Is there a singular, pristine, perfect solution floating in the ether somewhere, waiting to be plucked by you? Yes, I’m sure there is. I’m also sure that seeking this silver bullet is absolutely a trap that will doom you.

Trust the process, trust in continual improvement.

And somehow, just like Leigh Brackett’s The Empire Strikes Back screenplay, the draft oftentimes works very well and has a magic about it. Committing things to page/pixels/code/whatever can be daunting, and it helps when I remind myself that it’s just one step in the process.

Flotilla Refresh

Tue, 16 Apr 2019 00:00:00 +0000

I built Flotilla in 2010, using the XNA framework. XNA is great! However, XNA is no longer supported or updated, and Flotilla was having technical problems on some systems.

Enter FNA! FNA is a clean & modern reimplementation of XNA, and is made by Ethan Lee.

Ethan previously ported the Quadrilateral Cowboy digital artbook and Atom Zombie Smasher, and I was very fortunate to have Ethan work on porting Flotilla to FNA. He took care of everything and did such a great job. Ethan is a wonderful person and you should definitely hire him to work with you on your project!

GIMME THE HIGHLIGHTS

If you’ve been having technical problems with Flotilla, it works now!
There’s now a Mac/Linux version of Flotilla!
There are a few minor UI improvements.
Flotilla is now available at itch.io!

WHERE CAN I GET IT?

You can get Flotilla at:

Play List 2018

Mon, 31 Dec 2018 00:00:00 +0000

I was inspired by Alan Hazelden’s annual log of media he consumed and decided to try doing the same.

Seeing the entirety of my list was a real trip. I’d like to continue doing it this year. Try it yourself and see if it works for you!

🎥 = movie 📺 = TV 🎮 = game 📕 = book/comic ✈ = on airplane

JANUARY 2018

🎥

CHiPS ✈
The Way Way Back ✈
Phantom Thread
The Foreigner
Paddington 2

📺

Black Mirror
Star Trek Deep Space 9

🎮

Monolith
Ultimate General: Civil War
Sub Rosa
Destiny 2
Bulletstorm
Crimsonland
Jydge

📕

Authority / VanderMeer
Unbeatable Squirrel Girl / Henderson+North
Authority / Ellis+Hitch

FEBRUARY 2018

🎥

The Cloverfield Paradox
The Post
Walk Hard
Cars 3
The Adventures of Tintin
Sin City (Master Pancake Theater)
Black Panther
Annihilation
Mute
Serpico
Revolting Rhymes, Part 1

📺

Little Witch Academia
The Great British Bake-off

🎮

Jydge
Neon Chrome
Sub Rosa

📕

Fear Agent / Remender+Moore

MARCH 2018

🎥

Ingrid Goes West ✈
King of Beggars ✈
Jojo’s Bizarre Adventure: Diamond is Unbreakable ✈
Police Story (1985) ✈
Way of the Dragon ✈
Our Shining Days ✈
Big Hero 6 ✈
Three Billboards outside Ebbing, Missouri ✈
Mix (2017) ✈
Andromeda Strain (1971)
The Ritual (2017)
A Wrinkle in Time
Game Over, Man
Pacific Rim: Uprising
Hercules (1997)
Night Moves (1975)
Icarus (2017)
47 Meters Down

🎮

Where the Water Tastes Like Wine
Into the Breach
Synthetik
Sub Rosa
Far Cry 5

📕

The Pirates’ Mixed-up Voyage / Mahy

APRIL 2018

🎥

Crank: High Voltage
Mortal Kombat
Bølgen (2015)
The Lost Boys
A Quiet Place
Megazone 23
Repo Man (1984)
The Terror (2018)
Roar (1981)
Avengers: Infinity War
Paranormal Activity
Battle Royale

📺

Ash vs. Evil Dead
Into the Badlands
Episodes

🎮

Transmissions: Element 120
Warhammer: Vermintide 2
Drox Operative
Gone Vroom
Sub Rosa
God of War

📕

Ex Machina / Vaughan+Harris
Sex Criminals / Zdarsky+Fraction
Bitch Planet / DeConnick+DeLandro

MAY 2018

🎥

Isle of Dogs
Brawl in Cell Block 99
Forgetting Sarah Marshall
Lupin the Third: The Castle of Cagliostro
Deadpool 2
Solo: A Star Wars Story
Deliverance (1972)

📺

The Magicians
Halo: The Fall of Reach (2015)
Collateral (2018)

🎮

Octogeddon
Submerged
Raptor: Call of the Shadows
Sub Rosa
Tyrian 2000
Jamestown
Ikaruga
Sine Mora EX
Assault Android Cactus

📕

Y: The Last Man / Vaughan+Guerra

JUNE 2018

🎥

Rogue One
Halo: the Fall of Reach
Incredibles 2
Legend (1985)
Miami Vice (2006)
Pandorum (2009)
The Wages of Fear (1953)
Swordfish (2001)
Van Helsing (2004)
The Long Kiss Goodnight (1996)

📺

Aggretsuko
How to Get Away With Murder
Ping Pong the Animation
Star Wars: The Clone Wars (2008-2015)

🎮

Just Shapes & Beats
RymdResa
Capsule
Missile Dancer
Quake Champions
Raiders of the Broken Planet
Hard West
Sub Rosa
Rise of the Triad (2013)
Totally Accurate Battlegrounds
Squad (2015)
Star Traders: Frontiers
Sniper Elite 4

📕

The Invisibles / Morrison+Yeowell
Hulk: Planet Hulk / Pak+Pagulayan

JULY 2018

🎥

Mission Impossible: Fallout
Green Room
Westworld (1973)
Bangkok Dangerous
Heat

📺

Sense8
Steven Universe
Fullmetal Alchemist: Brotherhood
Pokemon XYZ

🎮

Heaven Will be Mine
No Man’s Sky
Sub Rosa
Moonlighter
Scanner Sombre
Space Tyrant
Oxenfree
Jedi Knight: Jedi Academy

📕

Star Wars: Dark Empire / Veitch
Star Wars: Rebel Heist / Kindt
Star Wars: Skywalker Strikes / Aaron
Star Wars: Doctor Aphra / Gillen

AUGUST 2018

🎥

Tampopo (1985)
Constantine (2005)
Troy (2004)
Interview with the Vampire (1994)
The Queen of the Damned (2002)
Hardcore Henry (2015)
Crazy Rich Asians

📺

Steven Universe
The Good Place
Avatar: the Last Airbender

🎮

Holedown
Diaries of a Spaceport Janitor
Sub Rosa
Donut County

📕

Superman: Red Son / Millar
My Lesbian Experience with Loneliness / Nagata
Descender / Lemire
Trail of the Catwoman / Brubaker
V for Vendetta / Moore
X-men: Grand Design / Piskor
Why Art? / Davis
Shaolin Cowboy / Darrow

SEPTEMBER 2018

🎥

The Game (1997)
Searching (2018)
Raid (2018) ✈
Gorgeous (1999)
Kung Fu Yoga (2017)
Crouching Tiger, Hidden Dragon: Sword of Destiny
Mandy (2018)
As Above, So Below

📺

Gilmore Girls
The Dragon Prince

🎮

Absolver
Sub Rosa
Spider-man (2018)

📕

My Favorite Thing is Monsters / Ferris
Ms Marvel / Wilson
Monstress / Liu

OCTOBER 2018

🎥

Ice Station Zebra (1968)
Murder Party (2007)
Dog Day Afternoon (1975)
Batman: Bad Blood
House (1977)
Die Hard

📺

The Chilling Adventures of Sabrina
Hilda

🎮

Assassin’s Creed: Odyssey
Good Morning Drifter
Sub Rosa
Divinity: Original Sin 2

📕

Exit Wounds / Modan
Sabrina / Drnaso
Monstress / Liu

NOVEMBER 2018

🎥

Overlord
The Purge
Le Samourai (1967)
Thor Ragnarok
Blade (1998)
Bram Stoker’s Dracula (1992)
Widows (2018)
The Thing (1982)

📺

Marvel’s Daredevil
House of Cards (2018)

🎮

The Haunted Island, a Frog Detective Game
Sub Rosa

📕

Nimona / Stevenson
Extremity / Johnson

DECEMBER 2018

🎥

Bahubali: The Beginning
Bahubali: The Conclusion
Robot (2010)
2.0 (2018)
Die Hard
Batman Returns
Spider-Man: Into the Spider-Verse
The Night Comes for Us (2018)
Aquaman (2018)
Home Alone (1990)
The Predator (2018) ✈
Maakhi (2012)
The Third Man (1949)
Shoplifters (2018)
Bumblebee (2018)

📺

She-Ra and the Princesses of Power
The Chilling Adventures of Sabrina
Terrace House: Boys & Girls in the City

🎮

Parkitect
Sub Rosa
Counter-strike Global Operations: Danger Zone
Red Dead Redemption 2
Twinfold
Tetris Attack
Picross

📕

The Fifth Season / Jemisin
Fun Home / Bechdel
Teenage Switchblade / Baker, Goux
Frontier #2 / Jo
War of Streets and Houses / Yanow
Before the Rain / Pomel
Vampire Horse and the Werewolf Bandit / McGrane

Carpet Tech

Thu, 08 Nov 2018 00:00:00 +0000

I was thinking about carpets. Specifically, the beautiful shag carpet in Event[0]:

When I played Event[0], this carpet mesmerized me. It looked so fluffy and soft. Glorious. It is the bar to which I compare all carpets.

Right now I’m building Skin Deep. A few days ago I had a sudden realization: my game has carpets. I get to make carpets. This was extremely exciting.

FINAL RESULTS

Here’s the final results of my carpet:

And here’s how the carpet looks in the model editor:

It’s pretty performant (it consists of eleven polygons) and looks like a carpet! I’m very happy with it.

HOW IT WORKS

I don’t know how Event[0] made their carpets, but I had an idea of a possible way to do it. I remembered reading this tech writeup of the fur tech in Shadow of Colossus, and was always curious about attempting it myself. This carpet was my perfect excuse to do so.

Basically, my carpet consists of a series of layers:

Each layer is a flat plane. The texture is a bunch of dots, representing the carpet fibers. When you stack layers tightly together, it creates the illusion of a fluffy carpet.

Here are some animations of the layers getting stacked up:

Click this image to get a better look at how the layers stack up:

THE PARTS

I used eleven flat planes. Eleven was an arbitrary quantity – I think you could use less layers and it’d still look good.

I used three textures, each of them 1024x1024.

This is the texture used for the bottom five layers:

This is the texture used for the middle three layers:

This is the texture used for the top three layers:

There’s a few things happening here:

Notice the texture gets more sparse as they rise higher. This is to give the carpet fibers some height variation.
Dark splotches are overlayed on each texture. This gives the carpet the illusion of having distressed areas, valleys, and matted-down parts.
At Ben Esposito’s suggestion, the carpet fibers start dark on the bottom layers and get brighter on the top layers. This baked-in lighting effect does a ton of heavy lifting in making the illusion work.

That’s pretty much it. This can be used for things like animal fur, hair, grass, foliage – try it out and see.

ET AL

When I was a kid, my dad told me that the more moving parts a machine has, the more likely something can go wrong with it. Whereas something like a hammer or screwdriver will almost never break, on account of them basically having zero moving parts.

Under the hood, video games are basically a writhing mass of a million malformed moving parts, hissing and teeming.

I like this “shell fur” solution a lot because of how low-tech and straight-forward it is. It is essentially a machine with zero moving parts. It is the opposite of a writhing mass. It is a solution that could’ve worked in 1996.

There’s something comforting and beautiful about that, and I love it.

Skin Deep Announced

Wed, 17 Oct 2018 00:00:00 +0000

Today I announced the development of Skin Deep, a game I’m unbelievably THRILLED to be making.

Watch the Blendo Twitch channel every Tuesday + Thursday at 10AM PT to see Skin Deep get built.
There’s now a Blendo Discord channel. Join in!
If you like what you see, please wish-list Skin Deep on Steam!

I can’t wait for you all to play this thing!

VR Demoing

Mon, 30 Jul 2018 00:00:00 +0000

I was invited to a cool bar to demo Flotilla 2 – it had a great turnout, and the venue was wonderful. I met a lot of great folks, and as usual with events like this, there was a metric ton of helpful feedback on the build.

I’ve done a fair amount of expos/conferences/showings for my past projects. VR demoing, however, is a whole other ball of wax. I found the sheer amount of equipment and logistics to be really demanding.

I wrote a list of what I ended up bringing. There are parts that are probably specific to my Vive setup, so your results may vary!

VR EQUIPMENT LIST

Folding card table to hold the television, computer, etc.
Painter’s tape to mark boundaries, starting position, line management, etc.
Speakers for audio.
Water bottle so you don’t die.
Power strips.
Extension cables.
Velcro cable ties to prevent spaghetti hell.
Spare shirt if you become a sweat monster during equipment setup (like me).
Light fixture with a clamp to illuminate specific things.
Tiny notebook and pen to keep notes during the night.
Television to show onlookers what the player is currently seeing.
- DVI/HDMI/etc cable to connect PC to the television.
- Signage to attach to the television.
- FAQ signage to answer basic stuff.
- Double-sided tape for the signage.
Computer that runs the VR build.
- Keyboard.
- Mouse.
- Power cord.
Vive link box for the Vive setup.
- The link box cables.
- C-clamp to keep the link box nice and stationary.
- A chunk of fabric so that the c-clamp doesn’t muss up the link box.
Vive controllers for the Vive setup.
- Controller charging cable in case a controller needs charging.
Vive lighthouses for the Vive setup.
- Power cables for the lighthouses.
- Photography light stands to hold the lighthouses.
- Attachment mount for the lighthouse to attach to.
- Zip ties to strap the mounts to the light stands.
- Scissors/blade to cut the zip ties.
Vive headset for the Vive setup.
- Moist wipes to clean the headset after each player.
- Lens cloth to clean the lenses if they get smudgey.

Things went well. The build ran smoothly, and nothing exploded. The one thing I’d add to this list is signage for the lighthouse poles: “Please don’t jiggle this!!!”

Quadrilateral Birthday

Wed, 25 Jul 2018 00:00:00 +0000

Quadrilateral Cowboy turns 2 years old today! Happy birthday to this video game.

To celebrate, I thought I’d do a little writeup about its early development.

DECK

The first thing I did was get the deck up and running.

It worked! It felt great to type on a little portable computer. A lot of the project depended on this interface, so I was glad it worked well.

Behind the deck you can see some doorways and railings. Those are look-and-feel tests – I think size metrics are important for good level design, so I try to make these decisions as early as I can.

CABLES

I wanted Quadrilateral Cowboy to focus on low-tech analog equipment. So originally, the intention was for the portable deck computer to always have to be plugged into a wall.

Basically, this meant cable management. Here is a 2012 video of an early attempt at simulating cables:

As you can see, the cable behaves like a wild animal. Near the end of the video, the cable rudely slams me back into a wall.

Quadrilateral Cowboy’s game engine, idTech4 (the Doom 3 engine), has a physics component, but this was my first time digging deep into its guts. I wasn’t having much luck but I felt the payoff would be worth it. Here was another attempt:

The cable was, yet again, an unruly beast.

I really wanted to get cables working. So, I kept at it, this time trying out Doom 3’s chains system…

…which I was unable to wrangle into something useable. Alas! The cables were not meant to be.

Deciding whether to cut your losses and move on is often a murky and wiggly choice. I personally feel low-tech solutions can get you very far – so if I’m having a lot of trouble with a complicated bit, I document it and then try a simpler solution.

In this case, the simpler solution was to have devices be wireless and… not use cables. And the game worked just fine!

However, months (years?) later, I… got cables working. Here is the piece of equipment called the Launcher:

Would Quadrilateral Cowboy be better if the cables had worked earlier? I don’t know. And honestly, I kind of don’t care? I think projects need room to breathe and grow and mess up and find their own path. And this was the path this project chose.

THE ELK

Look at this adorable biped.

One of my design goals was to not have any hostile AI characters in Quadrilateral Cowboy. There’s something compelling about you versus a building, and I wanted to explore that.

The Elk was intended to be a robot that you hijack and control. The idea was that it had some kind of security clearance, so you’d use it to infiltrate a secured area.

For various reasons, it slowly morphed into the tiny bite-sized Weevil: It was more interesting to sneak the Weevil into ventilation shafts and narrow cracks, whereas the Elk was more or less a full-sized human. So, goodbye Elk, hello Weevil.

TEXT TO SPEECH

For some time, I explored the idea of text-to-speech. The idea was to give players another tool in their toolset and give the world some extra character. But mostly, robotic text-to-speech voices always make me laugh, so I wanted to include it.

Here is the test run, in which I make the text-to-speech say “baboo” many times:

There ended up being a framerate hitch whenever the text-to-speech was called, and I couldn’t figure out how to resolve it. So, this was scrapped.

MAP

I really like the analog clock on the older version of the map:

But, the dang thing took up so much room and covered up so much of the screen. So, it was later converted into a more compact digital clock. Alas!

PROOF OF CONCEPT

Here is a run of a very early test area:

The pieces felt good, and more importantly, it felt like there was potential. And so, Quadrilateral Cowboy grew from there.

Happy birthday, Quadrilateral Cowboy. Thanks for reading!

Blendo FTP Uploader

Fri, 22 Jun 2018 00:00:00 +0000

Last year I switched this blog to a static site. It’s been great! However, one cumbersome thing was the process of uploading site changes.

So! I made a little program to streamline that.

DOWNLOAD BINARIES & SOURCE CODE

This is what the program looks like. The important thing here is the local filepath and remote FTP filepath fields.

local filepath: the folder on your hard drive containing your site content.
remote FTP filepath: the folder on the FTP containing the site.

When you click Connect to FTP, you’ll see…

2. UPLOAD

This window displays a list of all the changes that will be made. To confirm the changes, press the upload button. Done!

Specs

This program was written in C# using the default Windows Forms Application template. It uses FluentFTP library 17.4.2.0.

Disclaimer

This program is incredibly untested. Use at your own risk!

Et al

There’s something soothing about making mini productivity programs like this.

For me, part of it is how they’re so straight-forward. Whereas game development is a gnarled twisty process, little programs like these feel more akin to jigsaw puzzles. You slam it together and it’s immediately gratifying. The end.

Announcement Tasks

Fri, 08 Jun 2018 00:00:00 +0000

I recently announced my new project Flotilla 2, and wanted to share what I do when I announce a game.

This is the task list I wrote for the announcement:

The task list program I use is Workflowy. It’s a bulleted list that can be updated from your phone, desktop, tablet, wherever. I like Workflowy because of how bare-bones it is. You can find a ton of similar task list programs that’ll fit your specific needs.

There are so many moving parts in announcements/projects. For me, having a task list keeps these parts from getting lost.

Pre-announcement prep

I try to prepare all the announcement work beforehand, starting a month or two prior to the planned date. These tasks include:

Make the website.
Make the press kit.
Make the announcement video.
Make the storefront.
Write the email to press.
Write the newsletter email.
Write the announcement social media post. [1] [2]
Write the blog post.

The goal of doing all this work beforehand is to de-stressify announcement day. Because, as you can see: there’s a lot of prep work!

Announcement day

When the announcement day does come, I upload / release / post / make public all of the pre-prepared work I did.

Even though the work is all prepared and ready, it belies the fact that it’s a sizeable task to slam it all online. I try my best to release all of it at the same time, but I only have two hands so it takes a while.

This process ends up taking a few hours or so – partly because there’s so many parts, and partly because no matter how hard you prepare, there’s always, always, always some last-minute thing that was forgotten or needs to be tweaked.

Et al

When I released my first commercial independent game in 2010, I didn’t think much about marketing. I hadn’t done marketing before, and didn’t have much interest in it.

And the game sold well!

But, that was eight years ago.

I love making games. I want to keep doing it for a long time. And that project that you’re working on? I want you to continue making cool things like that!

Marketing is something I’ve been trying to better understand, and better integrate into how I work. It’s hard. There’s a million ways to do it, and I think it takes time to figure out what ways work for you.

Flotilla 2 announced

Wed, 25 Apr 2018 00:00:00 +0000

I’m excited to announce I’m working on a new project! My new game is Flotilla 2, a VR game about big battleships in space.

Flotilla 2 is a single-player turn-based tactical game. Combat revolves around maneuvering, flanking, and hitting the enemy where their armor is weak.

This is a sequel to the original Flotilla, and expands on the combat systems explored there. However, unlike the original Flotilla, Flotilla 2 requires a VR headset. I’ve been wanting to experiment in the VR space for a while, and the gameplay of Flotilla felt like a perfect fit.

Also on this project, I’m fortunate enough to have a crew of local Los Angeles developers collaborate with me. The Flotilla 2 level designers are:

If you like, you can add Flotilla 2 to your Steam wishlist or follow the game’s development on Twitter or the email newsletter. Thanks for checking out Flotilla 2!

Hi Hugo

Mon, 31 Jul 2017 00:00:00 +0000

I was having some fairly consistent problems with my blendogames.com blog/news page getting hacked and infected. It became very annoying! All the security and safety measures I attempted just weren’t working.

So! After a particularly nasty database problem I decided to just nix the page and convert it into a static site. It’s now more secure, simpler, and I have more control over it now.

It’s great. If you’re reading this now, well, you’re looking at the new site.

I used the Hugo framework because I like its simplicity, but there are plenty of options available if you’re looking to make a static blog. All of the old posts are still here, they’re just a little bit faster-loading and cleaner-looking now.

Enjoy!

On Company of Heroes

Thu, 25 May 2017 16:22:48 +0000

I often describe Company of Heroes as the RTS that has made it difficult for me to play any other RTS.

There are a lot of things that make Company of Heroes special to me. Here are some of them.

World state

Something memorable in Bungie’s Myth is in how bloodstains and scorchmarks are permanent:

The marks exist as a chronicle of sorts. Every moment stains the battlefield, ensuring you don’t forget a thing.

Company of Heroes takes that ideal and runs with it.

Buildings are chipped away until they’re ultimately destroyed, denying infantry a place to garrison:
Barricades can be smashed through, creating new paths for others:
Craters from artillery and explosions deform the ground, and become cover pieces for infantry:
Bridges can be destroyed (and repaired), opening and closing routes:

Your choices alter the battlefield, both intentionally and inadvertently. Sheltered bays are a flip-flop away from becoming deathtraps.

The terrain constantly shifts. Sometimes to your advantage, sometimes against you, but always in a way that makes the world alive, reactive, and consistent.

Resource model

Like Relic’s previous RTS outing, Company of Heroes focuses on territory control. This is done through their resource model.

Here’s how it works:

Each map is split into a series of territories:
Each territory bears one control point:
Control points are captured with infantry units:
And owning more territory results in faster resource accural:

Simple, right?

But! There’s a gag. The gag is: a territory only produces resources if it has a contiguous connection to your headquarters. Think of it as electrical lines – if the chain has a missing link, the flow gets truncated:

It’s an elegant system. It is rules-light and possibilities-heavy.

It opens the door to cutting off large swathes of an enemy’s supply line. Dramatic moments of everyone fighting over one tiny hill are consistently produced.

But most crucially, it builds the game on a foundation of one thing: pushing players out of their bases and onto the battlefield. Company of Heroes is aggressively anti-chuffa and cuts straight to the chase.

The game starts, and the very first thing you do is the thing you’ll be doing for the entire match: push, expand, and capture.

Combat

Positioning

Infantry units can take cover behind any chest-high object – sandbag wall, a farm tractor, a haystack, a crater, you name it.

Cover grants a substantial defensive bonus, putting any unit out in the open at a disadvantage.

Emplaced weapons provide enough firepower to lock down an area, but have a limited firing arc:

Tanks are heavily armored in the front but are unprotected in the rear:

A basic fundamental part of an RTS is moving units around. With Company of Heroes’ design decisions, every move order is compounded with a pile of circumstances to consider.

It becomes geometry and angles, guessing and second-guessing.

Where do you think the enemy most likely is, and how do you orient yourself in a position advantageous to that?
How do you best use that rickety barn to block enemy sightlines to your weapon emplacement?
You’re going to have some blind spots, so which blind spots are the most acceptable risks?

And because all of these factors are represented by physical in-world objects, everything is instantly readable and intuitive.

Flanking

Which leads directly to where Company of Heroes shines particularly bright. If positions and cover are directional, it opens the door to flanking.

When the enemy’s forces are arranged to expect you coming from one direction, it becomes a veritable wall. A wall that shoots bullets.

And what better way to deal with a wall than to simply go around it.

Circling around and attacking from the side or the rear is something that Company of Heroes’ design revolves around. And that design choice pays off in an incredibly satisfying way.

Not only does it just feel good to break an enemy’s iron defense with a small clever move, but it gives a sense of flow to the battlefield. Like the shifting terrain and like the resource model, units are always on the move and in a state of flux.

This is a game where a basic move order is consistently a brutal way to destroy a fortified defense.

Retreating

With the tap of a button, you can order units to retreat to headquarters:

During a retreat, you have no control of the unit. They automatically decide the fastest route back to headquarters, and run. A retreating unit sometimes gets killed, but they are overwhelmingly successful in making it home in one piece.

It’s a design decision that, had I worked on this game, I would’ve raised a stink about. It opens up a can of worms. How could this possibly be balanced. The amount of design implications and edge cases is staggering.

With that said: retreating is one of Company of Heroes’ best design choices. It’s one of the mechanics I most admire in the game. As a developer, it’s an incredible feeling to see a potentially problematic design choice be executed with such skill.

There’s a lot of things to like about it. The thing I most appreciate is how it bolsters the storytelling aspect.

When a character dies, that is the end of their story. They were born. Then they died. The end. As a net whole, I feel dead characters just remove potential story possibilities. (It’s one of the reasons I subscribe to Tom Francis’ Failure Spectrum ideal)

On the other hand, giving the player the ability to easily and frictionlessly keep characters alive – not forever, but at least longer? This results in a storytelling machine.

You end up with a grizzled rifleman squad who took out two bunkers and a halftrack. You end up with heroic last stands with that machinegun crew you’ve had since forever. You end up with strong character attachment.

When your battle-scarred weapons crew gets taken out – oof! – you feel it in your bones.

Et al

Company of Heroes proposes what a RTS can be. It breaks down what an RTS is, trims off cruft that has glommed onto the genre over the years, and rebuilds it in a way that is fresh, new, and unusual in an exhilarating way. When I first played it, it had that feeling of playing a game decades ahead of its time, and arguably, it still does.

It feels dynamic, it feels alive. It’s one of those games that has blood pumping through its veins.

All of its components – the terrain deformability/destruction, the resource model, and its combat model – touch and play with one another. I can’t overstate how systemic it all is, and how all of its system overlap. The same map will produce dramatically different outcomes, every single time.

This highly systemic approach is the reason why after every match, my officemates and I at my old job would convene and talk about all the wild things that happened during the battle. These post-game chats are some of my fondest memories of working at Pandemic, and also some of my fondest memories in playing games.

There are many ways to tell a story. Company of Heroes is one of the most impressive examples I know of.

On Benchmaking

Mon, 15 May 2017 20:15:13 +0000

My dad and I made a bench. Here’s the final result:

We started with a paper plan:

We cut a 2x4 to make the four legs:

The little slot in each leg was shaved out with the radial arm saw:

The legs and supports were joined with biscuits. We’re testing the fit here:

And here, a dry test to see if all pieces fit together:

The fit looked good. We applied wood glue, then attached clamps to keep everything in place as the glue dried. (The frame was slightly leaning to one side, so we also attached a clamp diagonally to push it the other way):

We joined the bottom support beam, again with biscuits and wood glue:

Here is the top of the bench. They’re a couple of 2x8 boards:

We glued the bench top together:

Then cut some biscuit slots into the bench top’s end pieces:

And glued the bench top’s end pieces on:

Finally, the bench top and the leg frame were connected together with a few lag screws:

And with that, it was done:

Et al

There’s a handful of steps I didn’t document, but this gives a rough overview of the bench’s construction.

As a kid, I grew up tinkering with scale models, kitbashing, woodworking, papercraft – anything that let me make a thing. My work is in video games – and I love it – but I can’t help sometimes missing that feeling of creating something physical you can hold in your hands.

Anyway, benches are great.

Blendo Games turns Seven

Sun, 01 Jan 2017 19:23:45 +0000

Blendo Games turns seven years old today.

Thank you all for the love and support.

Top 10 Games of 2016

Fri, 30 Dec 2016 00:00:00 +0000

I wrote a list of my top games of 2016 for Giant Bomb.

For my number one pick, I drew a little illustration. Enjoy!

Work archeology, Part 3

Mon, 03 Oct 2016 16:54:49 +0000

This entry is a continuation of Work Archeology, Part 2

For a quick recap on what source control is, please read Work Archeology, Part 1

Quadrilateral Cowboy

Now that Quadrilateral Cowboy has shipped, I thought it would be interesting to take a look at its source control patterns, from start to finish.

Monthly

The graph tracks how many source control check-ins were made per month.

There are a lot of peaks and valleys. My best guess for the January peaks is because that’s the time I say “well, _this_ is the year I’ll ship.”

The January 2014 peak is a perfect storm of Aaron Melcher doing Mac porting work at the same time as Tynan Wales and I were prototyping the multi-person heist systems.

Quadrilateral Cowboy’s release date was July 25, 2016.

Weekly

The graph tracks the total amount of source control check-ins per day.

The weekdays are all consistent, with Wednesday in a marginal lead.

In the latter half of the development I became more adamant about not working on weekends. I’ll get into that later in this writeup.

Hourly

The graph tracks how many source control check-ins were made per hour.

5:00 pm is apparently the hot-bed of my source control activity. Afternoons are generally when I’m most productive, and I suppose 5:00 pm is the end-point of that period.

My best explanation for the midnight spike is I used to have a tendency to want to wrap up a given task before the end of the day. Nowadays I don’t often do that, as I see a lot of value in hitting the ground running on a partially-completed task in the morning.

2012 vs. 2016: Weekly

Let’s compare how the weekly check-ins changed between the first year of development vs. the final year of development.

(Drag the white slider bar left and right to compare)

There are some noticeable changes. In the final year, I set firmer rules for myself regarding weekend work. Also, at the office I share, we do a Friday show and tell event, hence the Friday spike to jam in something juicy to show everyone.

2012 vs. 2016: Hourly

A comparison of hourly check-ins between the first year and final year of development.

(Drag the white slider bar left and right to compare)

In the first year of development (2012) I was basically burning at full-speed all day long, from roughly 9am to 11pm on a daily basis. I guess you get things done, but you also completely wreck yourself and end up becoming a human mess. Now that I think about it, perhaps this explains the erratic pattern on the green monthly chart above.

As development progressed, I hit a point where I decided to change how I carried myself.

The final year of development (2016) shows a bit of that. I made noon lunch into a rigid drop-everything routine. I began trying harder to maintain reasonable work hours, from about 9am to 6pm.

Though, there’s still that midnight spike. For the life of me I can’t figure that out, as I sure don’t recall doing many all-nighters recently. Shrug!

ET AL

The great thing about these records is that they cost nothing to make (well – I took some time to write the visualizer program that crunches all this data, but whatever). It’s basically ‘free’ data about your own work habits and the history of your project.

In my case, contrasting where I am now to where I started is definitely a trip.

I hope this gives you some good ideas of ways to automate the tracking of your own habits and hours.

On Far Cry 2

Mon, 26 Sep 2016 16:55:12 +0000

Let’s talk about Far Cry 2.

This is a game that does not want to be your friend. This is a game that throws you into a foreign land where you don’t know anyone, hands you a gun that jams all the time, and infects you with malaria – all within its opening minutes. It is belligerent, uninviting, and unwelcoming.

Far Cry 2 is easily one of my favorite pieces of work.

Admittedly, when I first began playing Far Cry 2, I had difficulty enjoying it.

About an hour later, it clicked for me. I stopped looking at it through the lens of my expectations, and instead looked at it for what it was aiming to be. This is not a game with a traditional power curve. This isn’t a game about feeling mighty.

There are many things I appreciate about Far Cry 2. Here are some of them.

MAP

Far Cry 2 treats many of its components like simulations. Guns degrade the more they are used. Weather patterns cause stormy days and sunny days. Enemies carry their wounded mates to safety. Wildfires dynamically spread across dry brush and climb up wooden structures.

The in-game map likewise shares the same approach. The protagonist pulls out a paper map and GPS device. If you’re standing in the shade, the map will be dark and difficult to read. If you’re driving a car, good luck focusing on both the road and the map.

Unlike many other games, the in-game map is not a safe shelter. The game world does not pause. Bullets whizzing through the air prior to opening the map will continue to whiz straight into your body.

By treating the in-game map like a simulation, the storytelling door is opened wider. That time you were looking at the map and your jeep soared off a cliff. That time you absatively posolutely needed to withdraw and had to shuffle through your pile of maps while under fire.

In my book, Far Cry 2 is in good company as one of the most effective in-game maps.

BUDDY SYSTEM

The surest way to grind momentum to a halt is to kill the player, reload the game, and have them replay a section over again. Stop, rewind, try again; wash, rinse, repeat.

Well now, let me tell you about Far Cry 2’s buddy system.

In an early section in the game, you make acquaintances with one of the mercenaries in the country. Like all the mercenaries in the Far Cry 2 universe, your new buddy is someone with a murky past that’s dubious at best.

Then at some point, because Far Cry 2 aggressively doesn’t care whether the protagonist lives or dies, the protagonist will probably die during some random gunfight. And when that happens, your character topples down. Your hands clutch the earth. Your face smashes into the dirt.

And it cuts to black.

But here’s the gag: the screen then fades back up, to you looking at the sky. Your mercenary buddy is at your side, firing wildly at your attackers while dragging you to safety. You’re patched up with pliers and bandages as your buddy defends you. To commemorate you returning to the land of the living, your buddy hands you a pistol.

And that’s not all: after you’ve been rescued and you’re repelling the last of the stragglers, there’s a chance your buddy may get wounded in the firefight. The relationship flips and now you’re the one saving someone’s bacon.

And – AND – that’s not all: once your buddy takes one too many hits, they shuffle off this mortal coil – permanently.

Your story goes on. A great little wrinkle is added, the world keeps spinning forward, and the momentum does not halt or hitch or hesitate for one single second. The game takes a failure state and sees it as an opportunity, flipping it upside down into a memorable moment.

I highly recommend reading Tom Francis’s excellent writeup about failure spectrums for a further dive into failsafes and storytelling.

WHAT, NOT HOW

Far Cry 2 tells you what a given mission’s objective is. Destroy the convoy passing by this road. Acquire this valued object. Rescue this character.

However, it doesn’t tell you how to do it. It does not hint at effective ways to do it. It does not place gameplay objects in such a fashion to nudge you toward a suggested play style. It does not rely on a row of dominoes for a canned let’s-burn-our-budget set piece.

It tells you what to do, but doesn’t tell you how. What, not how.

When control is relinquished, it frees up room for the player to join in, participate, and share the authorship. We’ve all been in that situation where one person just dominates an entire conversation. Far Cry 2 is a generous partner. A conversation is most engaging when both parties get to contribute.

By making a world that reacts to your actions, continues to run when when you’re not looking, and leans toward the simulation approach whenever it does anything, the game always has an interesting reply to whatever you say. By always keeping the player in control (Far Cry 2 is one of those rare games that lets you walk away while talking to someone, and it is glorious) the game has massive respect for player agency and the player’s time.

ET AL

A few things before I go:

I absolutely love how Far Cry 2 has basically zero connection to its predecessor. I find that sequels and adaptations are most compelling when they respect the heart and soul of the source material and burn everything else down.
A talk that had a tremendous impact on me was Patrick Redding’s 2008 GDC talk: Do, Don’t Show: Narrative Design in FARCRY 2. If you’re interested in storytelling systems, give it a listen.
There’s great stuff in Steve Gaynor’s Tone Control episode with Far Cry 2’s creative director, Clint Hocking, including a rather good anecdote about an animal-petting game mechanic.

On Fury Roads

Tue, 19 May 2015 08:06:59 +0000

Spoiler alert: Stop reading this if you haven’t seen Mad Max Fury Road yet.

Mad Max Fury Road just came out. There’s a lot of things going on in this film.

Some thoughts:

In an early sequence, Furiosa swerves the convoy off the main road. She diverts toward a rogue direction. A trooper swings over to Furiosa’s window. He asks what’s up. Furiosa barely acknowledges the trooper’s existence. The trooper may as well be a fart in the wind.

I found this to be a wonderful bit of storytelling. The crew follows Furiosa’s lead without an inkling of hesitation. Absolute commitment in the blink of an eye. Oh, Furiosa is going off-road for mysterious reasons? Crew, I guess we’re going off-road for mysterious reasons.

With so little, it says so much. We instantly grasp who Furiosa is. We grasp this group’s hierarchical structure. We believe Furiosa’s crew would follow Furiosa off a cliff. We fill in the blanks of how she achieved this respect.

And all of this is achieved

with smart visuals

and using dialogue as a last resort.

In the first sequence, we see Max jetting around in his V8 Interceptor car. It’s his Millennium Falcon, a storied supercharger, the iconic vehicle of the Mad Max universe.

And a couple minutes after the film starts, the V8 Interceptor is flipped like a turtle on its back. Undriveable. Dead. Kaput.

The V8 Interceptor next appears in the climactic showdown, having been refurbished by the bad guys. Max spots the car. He shouts “that’s mine!”

Moments later, the V8 Interceptor explodes. I love this.

Destroy the icon. Then, just for good measure, destroy it again. Burn it all down. I thought I wanted Max and his continuing adventures with his cool car, but, well, I got something a helluva lot better than what I wanted.

Prior to Furiosa going rogue, many things have already happened.

She busted the fugitive wives out of the vault. She composed an elaborate plan. She made a secret deal with a motorcycle gang for safe passage. She gathered up supplies for her operation. She rose up the ranks of the clan to become Imperator.

And right when the film starts, all that is skipped. The film begins by jumping straight to the final act. This is the boxing movie where the first scene is the climactic final fight. This is a Star Wars that opens with the assault on the Death Star.

Mad Max respects the viewer’s time by starting the story as close to the end as possible. The film excises as much as it possibly could, leaving nothing but the lean bare essentials of the story it wants to tell.

Admittedly, I had high expectations for Mad Max Fury Road. The director had previously made one of my all-time favorite films. So, I was tickled to find myself smitten within the very first few seconds of Mad Max.

Not the two-headed lizard scene. I liked that, but I’m talking about what preceded that.

I’m talking about the opening billing: “TOM HARDY as MAX ROCKATANSKY / CHARLIZE THERON as IMPERATOR FURIOSA” in grungy hard-core angry font.

Look at those names. Look at that presentation. For goodness sakes, look at those names. Rockatansky. Imperator Furiosa. Completely over-blown. Over-the-top. Over-loud. It’s a perfect fit for what this film is.

And somehow, the film maintains this tone. Every frame, from frame one to frame last, shouts that shred-metal aesthetic. Every frame feels like grungy hard-core angry font. Fury Road knows exactly what it wants to be, doesn’t care about what you want, doesn’t care about what other films are doing, and is unapologetic about it.

Blender Cables

Fri, 02 Jan 2015 23:57:34 +0000

My current project Quadrilateral Cowboy has a fair amount of dangly cables.

Here’s how I make them in Blender (I use version 2.49b):

Create a cylinder.
1. Vertices and Depth determine how detailed the cable will be.
2. Deactivate: Cap Ends
Rotate the cylinder to run along the X axis (the red line).
Apply scale and rotation to the cylinder:
1. Press: ctrl+a
2. Select: Scale and Rotation to ObData
Create a bezier curve.
1. The bezier curve and the cylinder should both be at the same origin.
Activate 3D on the bezier curve:
1. Open the Editing panel (press F9).
2. In the Curve and Surface area, click the button labeled 3D.
Add a modifer to the cylinder: Array
1. Change Fixed Count to Fit to Curve Length
2. In ob, type your bezier curve’s name. (default: Curve)
Add modifer to cylinder: Curve
1. In ob, type in your bezier curve’s name. (default: Curve)
Go nuts with the bezier curve:
1. Select the last node on the bezier curve.
2. Extrude the node. (press: e)
Optional: bake the curve:
1. Select the cylinder.
2. Press: alt+c
3. Select Delete Original

The Calling

Mon, 08 Dec 2014 18:56:21 +0000

I wrote and drew a four-page comic a couple years ago. It involves Santa Claus. Here it is:

For giggles, here is a time-lapse recording of the comic’s inking process:

Gravity Bone / Thirty Flights of Loving entities

Tue, 29 Jul 2014 16:59:45 +0000

Here’s the entity definition file for Gravity Bone and Thirty Flights of Loving.

Sixty-four custom entities were made. Search the file for “GRAVITY BONE CUSTOM ENTITIES” to find these custom entities. There’s some sparse documentation but you might need to peek into TFOL’s source code to find details on how things work.

I used GTKRadiant 1.3.13 to make maps for GB & TFOL. For GTKRadiant to recognize the entity definition file, place the file into the Thirty Flights of Loving folder: baseq2/scripts

Click here to download the entities definition file (80 kb)

Expat

Sat, 07 Jun 2014 22:11:08 +0000

I participated in this year’s space cowboy game jam. Here’s what I made:

Expat (7 mb, Windows)

Expat is a game about being a space bounty hunter. It plays with some ideas I’ve been wanting to try out for a while, and I’m looking forward to revisiting Expat sometime in the future.

Enjoy!

On Thunder Lizards

Fri, 16 May 2014 21:07:21 +0000

I saw Godzilla.

SPOILER ALERT: stop reading this if you haven’t watched Godzilla yet.

DISCLAIMER ALERT: stop reading this. I’ve never made a movie. This is me talking out of my butt.

Things gonna get crazy

The movie establishes multiple mega monsters roam the earth. You know what this means:

they’re gonna meet.
they’re not gonna see eye-to-eye on various things.
things gonna get crazy.

At some point in the middle of the movie, two mega monsters finally converge at the same location. It’s night time. It’s flooding. Tourists are running willy nilly. The military is launching everything. The two beasties, mano-a-mano, finally. They posture. They warcry. I prepare to experience every variety of shattering building. Things gonna get crazy.

We instantly cut to the next day. Morning sunbeams on a kid. He hangs out on a couch. The living room is sensibly-furnished.

Did totally awesome monster punching happen? Yes. We’re fed scraps of the mega monster battle on a television broadcast.

But who beat up who? Who won? What variety of shattering building was there? Were there suplexes? Who cares. We’ve seen destruction porn before. We know it’s early enough in the movie that both monsters will handily survive. They both gotta do stuff for one more hour, right? Nothing of consequence would’ve happened. A fuel truck might’ve gotten exploded.

The movie trims this fat. You don’t get your greasy junk food fix. You’re left a little unsatisfied, hungry for more. It’s surprising, it refuses to give you what you want, and we carry on.

That one shot

There’s a shot that (irrationally) got stuck in my craw. I’m going to ramble.

Because monsters are soon visiting town, Elizabeth Olsen dumps her kid into an evacuation bus. The bus door closes. Through the windows of the closed door, we see Elizabeth Olsen wave bye to her kid. A waving Elizabeth Olsen is outside the bus. The camera is inside the bus. Totally fine.

The bus starts moving. The camera remains where it is, staring at the closed bus door. Through the windows of the closed bus door, a blur of city passes by. This is where I get bothered: I couldn’t figure out how to read the shot. I interpreted it a few ways.

Maybe the shot is from the perspective of Elizabeth Olsen. Let’s go with that. But once the camera gets whisked away with the moving bus, this doesn’t hold water.

Maybe the shot is from the perspective of the kid. The kid is not in the shot, but we infer he’s close to the camera’s location. Okay, let’s go with that. He looks at the closing door, he looks at his mom waving goodbye, he… continues staring at the closed door as if he suddenly entered a catatonic state. I would’ve expected the kid to continue looking at his mom as the bus pulled away, but maybe I’m being a softie.

Maybe it’s from the perspective of the bus door. To which I ask: the bus door now a character? And: cool, bus door character.

“Geez Brendon, not every shot has to be from someone’s perspective.”
Agreed.

I guess this shot stuck out to me because the characters are going through very emotionally-charged stuff. Elizabeth Olsen will possibly never see her child again. The kid is suddenly dumped on a bus with strangers on their way to who-knows-where. But we’re left with this lingering shot of nondescript city features whizzing by. We don’t necessarily need to see a person in order to feel something; I just don’t know what’s being said here.

“Geez Brendon. It’s just a shot.”
You’re right! I’ll stop.

Baby arms

Godzilla is a tall lizard. Godzilla swims like a champ. Godzilla is positioned as a monster lizard mother nature, bringing balance to the world.

Yet in a fight, I don’t think I’d bet on Godzilla. At the finale, we finally get an uninterrupted view of the Godzilla vs. Big Mantises showdown. And what does Godzilla do? Godzilla uses his baby arms to kinda push the Mantises around. It’s not unlike high-school push fights where both parties shove one another with ”you wanna fight?” threats until the lunch bell starts 4th period.

Okay, so Godzilla’s arms aren’t his strong suit. Godzilla has a mouth with teeth. He does some biting. He gnaws and wiggles, but ultimately his clompers just aren’t anatomically suited for chomping bad guys. Godzilla can’t quite squeeze enough flesh in his mouth.

He has a tail and can swat things, which is like an insistent push.

He atomic laser breaths. It’s effective. And that’s the thing. It’s Godzilla’s ace in the hole - scratch that, it’s the only card he has - and it’s a bit jarring when compared to his mega monster foes, who can fly, have scary pointy talons, are agile with their lanky articulated legs…

But they’re not armored against atomic laser breath.

There was a disconnect. I suppose I wanted to see some push and pull between the mega monsters. I wanted to feel the give and take of a good conversation, but said with jumbo-sized hostilities. Instead, there’s a physical altercation before Godzilla decides to press the “I win” button a couple times, zapping the Mantises.

Humans

Human characters exist in the Godzilla universe. The movie admirably frames the mega monsters from the characters’ perspective. It does get a bit weird at times. Aaron Taylor-Johnson is apparently the center of these mega monsters’ lives, as he has literal face-to-face encounters with the beasts about half a dozen times.

Okay, so Aaron Taylor-Johnson is a monster magnet. That’s fine. What do the other characters do?

Juliette Binoche and Elizabeth Olsen serve as motivations for other characters. The movie hints at Elizabeth Olsen having survival adventures during the mega monster showdown, but it’s never explored.
Ken Watanabe warns the military they’re being silly. His decades of research is ignored.
Sally Hawkins warns the military they’re being silly. Her decades of research is ignored.
Aaron Taylor-Johnson is a bomb defusal expert. He claims he can defuse the nuke in sixty seconds. He never defuses any bomb at any time.
David Strathairn is intent on destroying Godzilla. At the conclusion when Godzilla slinks back into the ocean, David Strathairn doesn’t make a peep. I can only guess he had some off-screen epiphany where he changed his mind about Godzilla.
Bryan Cranston is an effective character. He makes decisions, he’s proactive, he has a character arc. In terms of contributing to the story, he doesn’t. He gives Ken Watanabe data that leads to the Nevada monster, but ultimately I think someone would’ve spotted the mega monster trampling casinos without the aid of Bryan Cranston’s data.

So what do the characters offer to the story? They’re a framing device for the monsters.

Soon after the monsters are established, military experts surmise the beasts are heading toward San Francisco. The beasts end up in San Francisco. The military devises a plan to lure the monsters with a nuke. This plan does not come to fruition, and in fact puts San Francisco in great peril.

Ultimately Ken Watanabe is correct in saying “let’s just bug out and let things sort themselves,” because human intervention just ends up complicating things.

Fine - it’s a disaster movie, and honestly, humans are gnats buzzing around forces of nature. What got me was how grim the characters all were.

Okay, it’s possibly the end of the world. Okay, things aren’t looking so hot. But I have to think people would still wear more than one feeling (harried). I’m not looking for a comic relief character. I’m not looking to have a joke quota be filled. I’m looking to have the humans be more human.

Face hurting

With all that said, I enjoyed the movie. Some things I thought the movie completely nailed:

The monsters themselves were masterfully realized. There’s mass. There’s scale. They movie delivers on them being towering deities. And that sound design - oh god, those wonderful roars.

The opening credits were wonderful. We get some conspiracy, some super science, some historical appropriation, and all of it conveyed so frictionlessly. Scientists at the Bikini Atoll shot atomic super guns at a mega monster? The government covered it up with a flim-flam story about nuclear weapon testing? Got it. I’m so on-board with this. It hurts my face how much I’m on-board with this. I love what’s being said and how it’s being said.

I most appreciated how much restraint there was. The mega monsters tangle on multiple occasions. These tangles happen off-screen. When we finally get to see actual monster punching, it’s the tail end of the last encounter. It’s the only battle that matters, and the movie is all the more satisfying for doing this.

Mantis sex

When the male and female mantises finally meet, I can’t possibly be the only one who was expecting crazy mantis sex.

Et al

Godzilla is a summer blockbuster. I went in wanting to see mega monsters do things that mega monsters do. The movie delivers that.

I’ve been involved in large game productions. It always felt like in order to make the project work, we had to win the lottery 1000 times in a row. Gotta win the gameplay lottery, gotta win the audio lottery, gotta win the art lottery, gotta win the tools lottery, gotta win the pipeline lottery, and so on. On top of that, you had to win them in every developmental stage from conception to release.

For something of Godzilla’s scope, the amount of required winning lotteries was a magnitude I can’t begin to imagine. When I see a production totally nail a specific aspect, it’s an amazing feat. When I see a production nail everything, it’s nothing short of a miracle.

But ultimately, when someone wins a game or reaches the end of a movie or book, they never think: “that one part was super bad. But you know what? I bet the creators were going through a rough patch in their personal life. And the investors flaked out on that promise. And the equipment malfunctioned that day because of that awful snowstorm.”

Instead, they think: “that one part was super bad. The creators are super dumb.” And that’s valid. Not true, but completely valid. What you deliver in the final release is the one and only thing that matters.

Go forth. Make things. The only person who’ll know the full story of that project is you. And that’s fine.

Analog Defender fanart

Mon, 24 Mar 2014 18:00:50 +0000

My fanart for Droqen and Patrick Dinnen‘s Analog Defender

Fanart for the place I died a thousand times

Fri, 21 Feb 2014 17:46:59 +0000

New comic: Paperman

Mon, 10 Feb 2014 17:46:09 +0000

New comic: Paperman

Blendo TGA viewer

Mon, 27 Jan 2014 19:46:24 +0000

Quadrilateral Cowboy uses the TGA image format.

Unfortunately for me, Windows’ default image viewer doesn’t support TGAs. I looked online for a free lightweight image viewer, but it seems TGA isn’t a popular image format and/or my Google search skills aren’t that hot.

So, I made an image viewer for TGA files. If you need an image viewer that views one and only one image format, well, I got you covered.

Written in C# and uses the SFML library.

Blendo TGA viewer Download: click me (500k) Source code: click me (500k)

Extended Memory: Steve Gaynor

Mon, 09 Dec 2013 17:03:47 +0000

We interview Steve Gaynor of Gone Home, Bioshock 2, Duke3D hell prisons.

Click here to listen.

Quadrilateral Cowboy scribblings

Mon, 11 Nov 2013 17:56:08 +0000

Here are some sketches from Quadrilateral Cowboy:

Extended Memory: Tynan Wales

Wed, 06 Nov 2013 17:59:49 +0000

We interview Tynan Wales, Independent Games Festival winner and Bioshock 2 designer.

Click here to listen.

Work archeology, Part 2

Wed, 30 Oct 2013 23:05:40 +0000

This entry is a continuation of Work Archeology, Part 1

Atom Zombie Smasher

Here’s how the development of Atom Zombie Smasher fared.

Monthly

The September spike is me implementing a sprawling metagame component to the game.

The October dip is when I learned my metagame was garbage.

The November spike is me working on the part that did work, the cityscape component.

Release: January 24

Weekly

Hourly

Quadrilateral Cowboy

Here’s how the development of Quadrilateral Cowboy is going so far.

Monthly

The other three monthly graphs consist of one mountain hump. QC has been a rollercoaster of humps.

Weekly

Hourly

Unlike the other hourly graphs, QC is one smooth hump (with a dip for noontime lunch). I’ve been trying to do a better job at keeping more regular work hours, so it’s nice to see that reflected here.

Et al

You need momentum to reach a certain speed, and you need time to gain momentum. For me, that time seems to be 2-3pm, with Wednesday being the most productive day.

With that being said: when you have to choose between you and your work, choose yourself. It’s lovely to be productive, but probably not worth it once you’ve become a burnt-out husk of a human being.

In short: eat your lunch.

Continued in Work Archeology, Part 3

Announcement time

Tue, 29 Oct 2013 13:00:48 +0000

I’m happy to announce today Tynan Wales will be joining the Quadrilateral Cowboy team. He’ll be working on everything design and will be bringing his expertise from a ton of games, including Bioshock 2.

Welcome Tynan!

Work archeology, Part 1

Mon, 28 Oct 2013 17:46:22 +0000

I was interested in taking a peek into my working habits. One way of doing this is by analyzing source control logs.

What’s source control? Imagine you’re typing a term paper. You neurotically press ctrl+S to save every few seconds, because you never know when your computer might decide to burst into flames.

Source control is basically the equivalent of pressing ctrl+S on your entire game project. Two big benefits are:

it gives me peace of mind knowing a backup exists on some remote server machine, and
if I break the game (this happens a lot), I can do the equivalent of “undo” and revert my game project to a previous revision.

Flotilla

By taking a look into how often you check in (save) files, you get an estimate as to when and how often you’re working. We’ll start by taking a look into the first Blendo game that used source control, Flotilla.

Monthly

To the right is my monthly check in tally for Flotilla’s development.

Release: February 27, 2010

Weekly

Here’s the total check ins per day.

I busted my butt every day, with Sunday somehow being the most busy. I don’t recommend doing this.

Hourly

Here’s the tally for total check ins per hour.

I got sleep. That’s good.

I worked all day long. That’s bad. Seriously, don’t do that.

Air Forte

I next made Air Forte. Here’s what Air Forte’s development ended up looking like.

Monthly

I used new technology for Air Forte.

New technology is a wonderful thing and a terrifying red flag. New technology introduces a lot of unknowns, so I tried to scope Air Forte to be as manageable as possible. As a result of that scope, Air Forte’s development cycle was shorter than Flotilla’s.

Release: July 17, 2010

Weekly

Sundays went from most-busy to least-busy (thank goodness).

Wednesday remains the most active weekday.

Hourly

See that dip at the 12 PM hour? That’s me not working, and instead eating lunch. Always eat lunch.

Et al

I’ll next continue with log data from Atom Zombie Smasher and the in-progress Quadrilateral Cowboy.

To be continued, dear reader.

And for those interested in the visualization program that created these images: it’s a program I wrote using the C# binding of SFML. Here are the files:

_Blendo SVN vis (binary)_ _Blendo SVN vis (source code)_

To use it: 1. Go to TortoiseSVN > Show Log > Show All 2. Select everything (ctrl+a) 3. Right-click > Copy to Clipboard 4. Paste into a text file. Save the text file. 5. Run Blendo SVN vis. Select the text file.

Continued in Work Archeology, Part 2

Thirty Flights of Loving prototype

Tue, 01 Oct 2013 22:50:00 +0000

Back in 2008 when Gravity Bone was being made, it went through a number of prototypes. At some point or another the game had grappling hooks, hacking minigames, handgrenade trick throws, granular door opening, and other experimental/goofy stuff during in its development.

One of those prototypes played with the idea of cutting and editing. This prototype would eventually become Thirty Flights of Loving. There’s always a first draft, so here’s video footage of that 2008 prototype:

I have to admit the gun was included mostly because I wanted to see how well I could fake some depth-of-field effects. If I remember correctly, the gun model consists of a couple of quad planes.

The prototype dialogue makes me cringe. Hats off to anyone tackling dialogue systems and dialogue writing.

Et al

When I got around to working on Thirty Flights of Loving proper (2013), almost 5 years had passed since the original prototype’s creation. Stuffing a project into a drawer and returning back to it years later is a luxury. You’ll have taken an all-new perspective, gained months’ worth of brain percolation, and will have let go of some preciousness and preconceptions about the work-in-progress. The common adage is “kill your babies,” but I’d append to that: “and keep ‘em in your drawer.”

Quadrilateral Cowboy at Indiecade

Wed, 11 Sep 2013 17:33:51 +0000

The Indiecade International Festival of Independent Games announced their game lineup, and Quadrilateral Cowboy was fortunate enough to be included. It’s such an honor to be listed amongst such great titles.

Come down to Culver City on October 3-6 to play amazing games, and come say hi. I’ll be the guy in the Blendo Games shirt. I’m 95% certain I won’t be wearing a hat.

http://www.indiecade.com/2013/games_preview

7DFPS: Photog

Wed, 14 Aug 2013 21:22:05 +0000

As mentioned in a previous post, I plunked out another multiplayer 7DFPS project. Here it is!

What’s this? The game is called Photog. I recorded a short video walkthrough of its main mechanic, where one player plays as a cameraman for a third-person shooter.

Basically, the cameraman needs to follow his/her teammates and provide them with good shooting angles.

Edit: here’s a video of Photog’s first playtest.

How many players are needed? It’s designed for 4+ players. Each team consists of 1 cameraman and 1+ shooters.

What’s the combat like? You’re armed with throwing axes. There are ammo pickups and health pickups.

You can’t attack while holding the camera.

How do I aim while in third-person? There’ll be a giant crosshair dot in the world (blue or red, depending on your team). Move the mouse to aim.

What are the controls? WASD moves you. Left-click throws an axe, or drops the camera if you’re the cameraman.

F1 switches teams. TAB shows the scoreboard.

I want to play. Here ya go:

Download Photog v1.0 (5 MB)

Source code (9 MB)

Wait, are there any bugs or issues? Yes.

Et al

The first commercial game I worked on was a third-person game, and one of the design goals was that the camera should simulate someone holding a camera. So, there was a some camera shake, some idle swaying, and jostling when your squad was running full-bore down a street. It was a great effect, and its third-person camera system in general was very well done.

Some of us designers thought it would be a hilarious gag if the camera was represented by a camera crew, and you’d catch glimpses of them under very rare circumstances. Some guy with a boom mic, a camera operator, a focus puller hanging out on the side. This was one of those ideas you prefaced with “wouldn’t it be amazing if…”, knowing full well that it’s completely unfeasible for a multitude of practical and production reasons.

So, Photog is me finally getting around to making this camera-crew game. Everyone has a ton of “wouldn’t it be amazing if…” ideas, and a game jam is the perfect place to play with them.

7DFPS: Guru v1.1

Tue, 13 Aug 2013 07:32:20 +0000

Yesterday I released the initial version of Guru. Guru is about a blind person engaging in melee combat, inspired by a game my friend is working on. I playtested Guru with Ben and Tynan and the game didn’t completely explode. Some things became apparent:

In a 1v1 match, the guru almost always destroys the assassin. When the guru is outnumbered, the outcome is reversed.
It’s pretty fun to work on small multiplayer games that don’t really care whether people play it.
LAN parties need to make a comeback in a big bad way.

We played Guru for a bit and after some discussion I had a good list of things to add and change.

Heartbeat: to better orient the guru, assassins play a heartbeat sound. The heartbeat sound is non-directional.
Leap: the guru has a mighty forward leap (press spacebar). It can be used once every 7 seconds. Whenever the guru destroys an assassin, the guru can leap immediately.
Throwable: the guru has one throwing axe (press e).
Attack rate: lowered fire rate of guru axe attacks.

And finally, some fixes and tweaks:

starting an internet server (maybe) works now.
the default control setup for the guru rear attack was broken.
the options menu has a volume slider.
the “muffled footsteps behind you” is now more muffled.

Download guru_v1_1.zip (6 MB)

7DFPS: Guru

Sun, 11 Aug 2013 20:48:05 +0000

edit: Guru is now updated to version 1.1

I made a 7DFPS project. It’s called Guru. Guru is an asymmetrical multiplayer game.

Download guru_v1.zip (6 MB)

The above picture is what the Assassin team sees. Assassins are armed with big scary axes.

The above picture depicts what the Guru sees. It’s a black screen. The Guru is blind and also has a big scary axe.

How do Assassins win?

Assassins win by destroying the Guru.

How does the Guru win?

The Guru wins by destroying Assassins -OR- surviving sixty seconds.

I see a black screen.

Yeah, Gurus can’t see anything. Listen to the assassin footsteps and try to figure out where they are.

How many footstep types are there?

The map consists of a small pond, surrounded by a ring of dirt, surrounded by a ring of grass.

Footsteps behind the guru will sound muffled.

What can the assassins do?

The assassins can move (WASD) and attack (LEFT CLICK).

What can the guru do?

The guru can move (WASD) and attack forward (LEFT CLICK) and attack backward (RIGHT CLICK).

Is the guru axe amazing?

Why yes it is (how did you know to ask that?). The guru’s axe has an extremely long range.

If the guru’s axe successfully hits, the guru can immediately attack again. If the guru misses, the guru has to wait a couple seconds between attacks.

Is there any wonkiness I should be aware of?

There’s a ton of wonkiness.

Starting an internet server is broken. LAN servers should work fine.
The guru’s rear attack animation sometimes doesn’t play. (it should still apply damage regardless)
The muffled-behind-footstep effect doesn’t work correctly when there’s more than one guru.
The server browser sometimes doesn’t correctly update. You can manually enter the IP, or try quitting & restarting.
I wasn’t able to have players automatically switch teams at the end of a round. You can press F1 to switch teams.

Where can I download Guru?

Download guru_v1.zip (6 MB)

Source code (9 MB)

The game is totally crashing.

If you have a moment, please send me the log file so I can hopefully figure out why it’s crashing.

Run the game with: guru.exe +set logfile 1
Go into the “base” folder.
Send the qconsole.log file to my email, brendon@blendogames.com

Et al

A friend of mine is working on a blind swordsman game, and I wanted to see how it’d play in a multiplayer environment. I had also played In the Pit a while back and always wanted to play with the audio-game genre.

I cheated and started this project a few days before the official 7DFPS start date.

The “audio is muffled when something is behind you” was something I stole from The Last of Us.

The “casualty” voiceover is my love letter to Bungie’s Myth series.

Most of my games focus on single-player, so for this game jam I wanted to work on something a bit out of my comfort zone. Most of my time was spent reading Doom 3’s multiplayer code over and over again, trying to figure out how things fit together. As you can see from the ‘wonkiness’ list above, I wasn’t able to suss out a lot of things, but the gameplay parts should (mostly) work.

I enjoyed working on this quite a bit, so I’m going to try to plunk out another 7DFPS project where you’re the cameraman for a third-person shooter.

Doom3 Starter Kit

Mon, 05 Aug 2013 17:11:20 +0000

In anticipation of the upcoming 7DFPS festivities, I packaged a stripped-down version of the Doom3 engine (the engine I’m currently using for Quadrilateral Cowboy). Includes:

Minimal game assets.
Pre-compiled binaries.
A test map (test1.map)
Source code.

Other info:

Uses assets from http://wiki.iodoom3.org/Minimum_Assets
Compiles with (free) Visual Studio C++ 2010 Express.
Removes MFC references, so built-in tools no longer work.

Some learning resources:

Enjoy

Download (10 mb)

Extended Memory: Borut Pfeifer

Thu, 01 Aug 2013 18:52:11 +0000

Extended Memory episode 3, in which we chat with Skulls of the Shogun developer Borut Pfeifer.

Click here to listen.

Extended Memory: Sanjay Madhav

Thu, 01 Aug 2013 18:50:35 +0000

Extended Memory episode 2, featuring Pandemic/Neversoft/Spark/EA programmer Sanjay Madhav.

Click here to listen.

The Diplomat

Mon, 22 Jul 2013 18:03:54 +0000

In 2007, I made a short (unfinished) documentary, The Diplomat:

I’ve always loved the editing process, and wanted to do more of it. I found a goldmine of stock footage from archive.org, and thought it’d be fun to assemble something together.

I was never able to find time to finish it, so it’s left in this incomplete state. Enjoy!

Quadrilateral Cowboy screenshot

Wed, 19 Jun 2013 18:14:52 +0000

Everything’s diesel in Quadrilateral Cowboy.

Extended Memory podcast

Sun, 09 Jun 2013 00:55:58 +0000

My friend Sanjay Madhav and I recorded a podcast together: Extended Memory.

In Extended Memory, Sanjay and I chat with a game developer: where they started, how they got here, and why they always do that thing they do.

Our first episode of Extended Memory is now up. In this episode, Sanjay interviews me. Click here to listen.

Humble Weekly Sale group photo

Fri, 12 Apr 2013 19:05:22 +0000

I organized a group photo for this week’s Humble Weekly Sale:

(Ultimately, the rhino didn’t eat the bird, but not for lack of trying.)

And here’s a link to the above image with the text removed.

Hello World

Thu, 11 Apr 2013 17:32:18 +0000

This week I’m fortunate enough to be featured in The Humble Weekly Sale. My email inflow has skyrocketed, and amongst them I get a fair amount of messages like this:

I’m a student in high school and I’m really interested in making games, but I have no clue where to start. I was wondering if you could offer me some insight into where to start?

Everyone’s brain is wired differently. For me, my best suggestion boils down to:

Make stuff. Then make more stuff.

If you’re not into brevity, I’ll get more specific.

The Dive

Someone smarter than me once described game development as jumping out of an airplane with nothing but a needle and a silkworm.

I don’t think it’s important to have a great idea. I don’t think it’s important to be unique or innovative. I don’t think it’s important to be bulletproof, or for that matter, good.

When the ground is rushing toward you at a million miles per hour, what’s important? You make something.

People can’t play a design document. People can’t play a grand vision. People can’t play all the cool ideas you’ve planned out down the road.

People can play the game you make.

The moment you start making objects move on your computer monitor, that’s when a flip gets switched. That’s when all your theory and ideas are forced to prove themselves, and it’s there, in that collision of code and art and sound and design, where things happen.

You start sussing out what “feels right.”

Connections start connecting.

Discoveries are unearthed.

Your skillset crystallizes.

Most importantly, your toolbox gets bigger.

Don’t get stuck focusing on making it good or clean. Focus on making a game. Get good at implementation, and the game will follow suit.

The Show

I find it impossible to objectively view my own work, so I place a lot of value in playtesting. Order pizza and present your game to your family and your friends and the friends of your friends.

By “present,” I mean you stare at the player as they play your game. They play. You watch. They’ll ask you questions, and you reply with a stare. Silently. Gravely. With your steely butternut eyes.

The thing is, the player doesn’t know what the game is supposed to be, or how it’s supposed to play like. The verbal feedback they give sometimes matches up with the game design, but actions speak louder than words here, because actions can’t lie.

You’ll see them fidgeting with the mouse, not knowing what to do next. You’ll see them completely miss the giant glowing button in the middle of the screen. You’ll see them do everything wrong.

And so you stare, and don’t give a single lick of help as they click on every incorrect thing. You’ll have a notebook where you write down every horrible thing that happens, and this notebook becomes the new center of your galaxy.

Then you make a new build and find new friends to rest your steely butternut eyes on.

The Finish

The hardest part of making a game is the last ten percent. By now, your elegant work has matured into a tattered tower of popsicle sticks held together by wishful thinking.

But the game’s not done with you. The tower is gluttonous and hungers for more, making the tower more shaky, more warty, more farty.

And you’re going to release this warty farty thing into the wild.

More poetically, you’ll let your caged bird fly free.

More realistically, it’s going to be a bloodbath. It’ll be educational, it’ll be enlightening, you’ll emerge covered in a thick coat of goopy blood.

And you’ll restart the cycle all over again, because you know your next project is going to be ten times better, and damn that’s addictive.

Et al

I started dabbling in game development during elementary school and began earnestly putting time into it during sixth grade. This was stuff like QBasic, DEU, and Autodesk Animator.

Years later, Gravity Bone was my first game that I was satisfied with, in that its execution began to match my taste, and in how it found an audience.

That’s a span of about fifteen years between me first starting game development, to making something I liked. Fifteen years of making really awful stuff.

Actually, that last sentence is deceptive. It implies I no longer make awful stuff. Truth is, my hard drive is bursting at the seams with broken, clunky prototypes. After shipping Atom Zombie Smasher, I spent the entirety of 2011 making prototypes, all of which explosively failed:

Here’s the multiplayer space RTS:

Here’s the dungeon-master game:

Here’s the survival roguelike:

Here’s the hack n’ slash roguelike:

I fail frequently and I fail quickly. It’s a natural part of the process, and because I’m human, this parade of failure does get discouraging from time to time. Everyone has to find their motivations to push onward.

So, to wrap it up: make stuff. Then make more stuff.

Maple Victory papercraft

Fri, 08 Mar 2013 20:12:10 +0000

Here’s the papercraft template for the Maple Victory bottle: click here to download

And here’s how the finished bottle looks like:

Time for you to get printin’ and cuttin’ and gluin’. Enjoy!

Maple Victory

Tue, 26 Feb 2013 20:03:27 +0000

I’ll be showing Thirty Flights of Loving at the IGF this year, and thought I’d make some decorations to spruce up the kiosk.

Thirty Flights of Loving version 0.24

Wed, 20 Feb 2013 17:39:20 +0000

While watching people play Thirty Flights of Loving at Indiecade East, a few things popped up on my radar. I’ve uploaded a new build with the following changes:

UI: Added cl_enableconsole console command. This disables/enables the tilde developer console. It’s accessible via the controls main menu option.
Developer commentary: changed jump cut to read smash cut.
Game: fixed bug where “bloody Winston” skin wasn’t showing up.
Game: fixed bug where viewpoint locking wasn’t locking correctly.

QC Dev 005: Lamp

Thu, 31 Jan 2013 20:00:14 +0000

I was recently making this kitchen area for Quadrilateral Cowboy.

As the kitchen started to shape up, I realized I didn’t have a light fixture that would fit the room well. So I willed one into existence.

Meaning, I made a light fixture.

Research

When I make things, I spend a lot of time buried in research. This mostly boils down to finding images via Google kung fu and mining whatever I have in my brain or on my bookshelf. I’m more than happy to spend an inordinate amount of time finding the right reference image, because they give me details I’d otherwise overlook.

For Thirty Flights of Loving, this motorcycle was modeled after the Honda CB750:

And the museum area was modeled after the National Museum of Natural History in Paris:

For this light fixture, I did a few searches. Something caught my eye when I punched in ‘deco light fixture‘:

Look at it. It’s gorgeous. Now, to model this beauty.

Modelling

I use Blender for my models. I use version 2.49b, not because I’m a fan of old versions of software, but because my file exporters are set up to use this version.

I have a fairly basic rule: don’t let art become a chokepoint. That means low-polygon art, stuff that’s easy to later modify, and something I can make in a reasonable amount of time. I know my art won’t win a stand-up fight against any respectable game, so I go the opposite route and make art that would look perfectly at home in games made in 1996.

Here’s what I ended up with:

I now had 55 naked polygons, ready to be dressed up.

Texture

Here’s the texture, a 256x256 image. As you can see, it’s a very bare-bones texture:

After wrapping the texture around my model, here’s how it looked:

Shader

I’m using the Doom 3 engine to make the game. Every texture requires a shader, defined via a simple text file. Here’s the shader for this light fixture:

Shaders are capable of doing wacky things, but this one’s pretty plain. The only special thing this shader has is the additive blend (”blend add”), which makes the texture glow.

Putting it all together

Model + Texture + Shader =

There it is, in all its glowy glory.

Et al

First-person shooters are notoriously hungry for content.

When you make a third-person game, you can get away with lower-resolution assets. The camera is typically somewhere between 5-15 feet away from any given surface, so the world needs less detail.

When you make a first-person game, the player can press their nose against any given surface. There they are, with their nose smooshed against a wall.

This means the art has to look decent when inspected up-close. Cabinets, floors, tables, salt-shakers, egg-beaters, kitchen sinks - it all has to look good-ish. This is a monumental task to demand from artists, and would probably crush me like a bug.

And that’s why my light fixture is 55 polygons.

QC Dev 004: Autocomplete

Fri, 25 Jan 2013 17:50:10 +0000

While demoing Quadrilateral Cowboy at PAX 2012, a lot of people asked for autocomplete functionality when typing commands into the game.

I put it on my to-do list and it languished there for a while. The mere idea of an autocomplete system intimidated me, and in my head it ballooned into a beast of a task.

Then one day I started implementing it, and found it wasn’t that bad at all.

The Cat Plays No Part

Here’s the sample level. There’s three doors and a window. The cat plays no part in this example.

Now, let’s say the player types this in: d

And then presses tab to autocomplete it. What happens?

Collect

First the game iterates through all hack-able entities in the world and generates a list. In this example level, the list is:

door1
door2
door3A
window1

There, we now have a list of possible candidates.

Filter

We then filter out anything that doesn’t fit the player’s command. The player typed in ‘d’, and we compare that to the above list.

‘window1’ is immediately filtered out, since ‘window1’ starts with a ‘w’, not a ‘d’. You’re dead to me, window1.

That leaves us with three possible candidates: door1, door2, door3A

Evaluate

With this list of candidates, we further pare it down to the best autocomplete entry. We do this by comparing all the candidates amongst one another, and evaluating what they have in common. We compare them character-by-character:

Character 1: d All the candidates have this in common, so we continue.

Character 2: o All the candidates have this in common, so we continue.

Character3: o All the candidates have this in common, so we continue.

Character4: r All the candidates have this in common, so we continue.

Character5: 1 One or more candidates has a different fifth character. We immediately stop here, and we now know what all the candidates have in common: the first four characters, door.

Ship it

We send door to the autocomplete, filling in the player prompt with: door

Done!

Et al

I remember when Guitar Hero first came out, I was working late at Pandemic. Some guys bought the game and the plastic guitar into the conference room.

As I sat there watching our gameplay programmer tap colored buttons on the guitar, my first thought was “this is the dorkiest thing I’ve ever seen.” After a few minutes my opinion became “this is the best thing I’ve ever seen.” There was something in the room, an energy created by the role-playing aspect and a tiny plastic guitar. He’s a rock star! He played the hell out of that song! That guitar solo ripped my limbs off!

Quadrilateral Cowboy intends to use the keyboard as the role-playing peripheral, to get that thrill of being an internationally-renown deck jockey. If I someday see someone go the extra mile and play this game in a dark room wearing sunglasses and a trenchcoat, I’ll be a happy man.

QC Dev 003: Pomodoro

Wed, 16 Jan 2013 20:09:22 +0000

Here’s what Blendo Games looks like:

I got the standing desk a couple years ago, largely because sitting for ungodly hours every day made me squirrely. For folks who have experienced stand-up meetings, you’ll know that forcing someone to stand on their feet prevents a lot of dilly-dallying and puttering around. If you feel meetings aren’t productive, try removing all chairs.

(I got a high stool for those lazy times.)

Butt in Chair

When I worked at Pandemic, I’d occasionally come to work an hour early and leave an hour early.

In that first hour, there were no interruptions: no barrage of email, no meetings, no one needing anything from me, and no one for me to go visit. And in that one hour, I was usually able to get a 1000+ hours’ worth of work done. I’m exaggerating, but you get the idea. An isolation chamber is far from the ideal working environment, but uninterrupted periods of butt-in-chair are invaluable.

Once I started Blendo Games, the concept of going to work an hour early no longer applied. I wanted some way to emulate that period of productivity, and a friend pointed me to the Pomodoro technique.

Pomodoro

I follow the broad strokes of the Pomodoro technique. Here’s how I do it:

On my computer desktop, I run a small timer called Workrave. It looks like this:

For the next thirty minutes, I work. This means:
- No checking email.
- No checking phone.
- No browsing internet.
- No watching TV/movies in the background.
- No getting snacks.
- No musing about your existence relative to the universe.
- Nothing but work.
When the timer hits thirty minutes, take a break. This means: do anything you want. I don’t time my breaks, but they usually average 10 minutes.
Wash, rinse, repeat.

Et Al

Once you remove distractions from the equation, the equation becomes dead simple - focus on one thing, and nothing but that one thing. Thirty minutes doesn’t sound very long, but it’s enough to ramp up to incredible momentum.

Bzzt, then the timer hits. I’m always tempted to maintain that momentum and barrel straight through the breaktime, but I find doing that ultimately fries my brain.

Spend a day and try it out! I’d love to hear how it goes.

QC Dev 002: Clambering

Wed, 09 Jan 2013 18:55:10 +0000

I hopped fences when I was younger. My elementary school was locked up during the weekend, so to play on the equipment or the fields, you had to climb over a chain-link fence.

When confronted with a chain-link fence or ledge in a video game, the typical solution is: find a way around it. Commando Bulk McBeefenstein can’t climb the barrier, but 10-year old me can. Sad trombone.

There are FPSs that empower you with maneuverability - Thief and Mirror’s Edge come to mind. These games de-emphasize direct combat and redirect that energy into creatively traversing through the environment.

In Quadrilateral Cowboy, the game is largely about slinking through secure facilities, so player maneuverability was something I wanted to spend time on.

How to Clamber

In Quadrilateral Cowboy, the player character (PC) can clamber onto any ledge within hand’s reach. I’ll describe how the game verifies whether the PC can clamber something.

First, a traceline is shot upwards 140 units:

Traceline 2 is then shot forward 32 units:

Traceline 3 is then shot downward until it hits something:

Lastly, check if the PC crouched bounding box can safely fit here:

Two things can happen here. If the PC bounding box:
- safely fits: great! We’re done. Start the clamber animation.
- collides into geometry OR hits a surface unusable for any reason: return to Step 2 and increase the forward traceline length.

One good feature about this approach is how it handles two different clamber situations: clambering up wall ledges (as shown above), and clambering up a hole in the ceiling (i.e. an attic crawlspace hatch).

That’s a quick overview of how clambering works. After playing with it in the game, I realized it was woefully insufficient for clambering into what every first-person video game needs: ventilation shafts.

How to Vent

Checking whether the player can clamber into a ventilation shaft is slightly different.

First, a traceline is shot forward 48 units out of the PC’s eyeballs. In the example below, the player is looking slightly upward:

Trace downward until it hits anything:

Check if the PC bounding box can safely fit here:

If the PC bounding box:
- safely fits: then hooray for you! Clamber in.
- collides into geometry: attempt to nudge the bounding box away from walls until it finds a suitable spot.

When clambering, the game does the ledge check and the vent check. How does it decide which check to first do? Its prioritization depends on the player’s view angle.

If the player is looking upward, the ledge check is prioritized.
If the player is looking forward, the vent check is prioritized.

Et al

As a player, it’s wonderful to be empowered with abilities that let you be creative. Stacking boxes to reach a fire escape, creating a ladder out of sticky bombs, or the video game variant to social engineering.

Whereas Thirty Flights of Loving was a tightly-controlled experience, Quadrilateral Cowboy aims to give the player a variety of tools and let them loose in a sandbox to run around and experiment in. For super heroes, great power comes with great responsibilities. For video game players, great power comes with great ability to completely break your game. Players will find ways to use these tools circumvent and short-circuit the game.

And ultimately, I think that’s wonderful. The creativity a player brings in is one of the most exciting things about games.

QC Dev 001: Ghost Cursor

Wed, 02 Jan 2013 11:25:53 +0000

In Quadrilateral Cowboy, the player can place items in the world.

The player moves around a “ghost cursor” of the item. When the cursor is in a desired position, left-clicking makes the item appear at that spot.

This went through some iteration, and will almost certainly be further tweaked as development continues. Let’s take a look at how it works right now.

Tracelines And You

But first, some terminology: traceline.

In the picture below, I want to figure out what the player is looking at. So, I use a traceline. The traceline would start at the player’s eyeballs, and then shoot forward a very far distance.

The traceline then spits out a bunch of information. One of these pieces of information is collision: what did the traceline collide with. In this example, the traceline hit the wall, signified by the red circle.

I examine what the traceline collided with, and now I know what the player is looking at: the wall._ _

Tracelines can do more stuff, but we’ll leave it at that for now.

Bare Necessities

I like to start with the most stupidly easy & simple implementation and then work from there. In this case, the most SE&S implementation is to make the ghost cursor appear X units in front of the player’s eyeballs:

This has some issues:

The item would spawn in & drop down to the ground, forcing the player to make a dubious guess where it’ll land.
It relies on a lot on trusting players to have good depth perception, which first-person games are notoriously awful at (hence why platformers are great in 2D but suffer in 3D).

On The Ground

To address those issues, the next iteration had the ghost cursor snap to ground surfaces. This was done by having two tracelines:

Traceline 1: start from player eyeballs, shoot forward X units.
Traceline 2: start from Traceline 1’s end position, shoot downward X units.

There. Now we have a nifty ghost cursor that snaps to floors, tables, shelves, vanities, curios, whatever old-timey furniture you can throw at it:

Done, right? Not quite.

Against the Wall

This is where things break down. If the ghost cursor is positioned near a wall, it’s fine. But once you push it closer to the wall, the ghost cursor ends up lodged into the world:

That’s no good. Halfway into a wall is a highly inappropriate place for any self-respecting ghost cursor. To illustrate, Traceline 1 is hitting the wall, then Traceline 2 is tracing down to the ground, resulting in this awkwardness:

Now, we _can_ rely on the player to not place stuff so close to the wall. They’ll learn and get used to it, right?

Yes, they will learn your quirks. But if making your game lean is a goal, then stuff like this is definitely fat. Players have a finite amount of time and energy for you. Everything that goes into the project has to answer one question: is it respecting the player’s goodwill or squandering it?

Wash Rinse Repeat

The problem: the ghost cursor is lodged into the wall. Therefore, the most straight-forward solution would be to move the ghost cursor away from the wall. Let’s start there.

We add an additional check. If the ghost cursor is stuck in geometry, we:

Step 1: Modify Traceline 1 by shortening it by X units.
Step 2: Do the Traceline 2 downward trace. If the ghost cursor is stuck in geometry, stop everything and return to Step 1.

Once the ghost cursor is no longer stuck in geometry, then we know it has found a suitable place. Done!

That’s where the system is right now. As levels are completed, more gotchas and edge cases appear as the ghost cursor has to contend with increasingly bizarre world geometry.

Et al

There’s something exciting about creating a system and then putting it through its paces. While artistic creativity plays a large part of game development, it also tickles that pleasure center of creating a finely-tuned clockwork machine, brimming with a billion moving parts working in concert with one another.

Then one day your baby is released out into the wild and you hope those billion moving parts don’t violently implode on themselves.

It reminds me of a program I saw on PBS about an off-road racing competition. The catch was: the cars had no drivers, nor were they remote controlled. Robot cars, folks. There was something so exciting and satisfying about seeing these machines have to be ready for whatever one-in-a-million edge case might happen, and gracefully handle it when that edge case inevitably happens ten times in a row.

Played in 2012

Tue, 01 Jan 2013 01:37:24 +0000

Writeups on games I played this year. By writeups, I mean one sentence.

FTL My emotional attachment to its little pixel people rivals the original XCOM.

Max Payne 3 Very pretty.

Dishonored Tight-as-a-drum sequel to Thief in all but name.

XCOM (2012) Constantly makes you make the kind of decisions that give you premature grey hair.

Mark of the Ninja Expect to see all future stealth games pick and choose from Mark of the Ninja’s clever set of mechanics.

Syndicate (2012) Its “They Live”-esque vision mode is a great bit.

Skyrim Skyrim truly shines when you pretend its fast-travel doesn’t exist.

Silent Storm If you enjoyed XCOM, then for chrissakes play Silent Storm.

Brogue Makes bold and very welcome changes to the roguelike formula.

The Walking Dead Choosing between right and wrong is what most games do; choosing between wrong and wrong is what The Walking Dead relishes.

Spelunky Co-op + roguelike + smart design = one of the best games of 2012.

Spec Ops: The Line I like it when games are critical.

Far Cry 3 Is absolutely fantastic when the game embraces its open-world environment.

Borderlands 2 Has great humor from start to finish, which is particularly impressive because the game is jumbo sized.

Day Z This is the future of games, folks.

Batman Arkham City I felt like Batman, which is probably the best compliment in the world.

Blendo Big Boxes

Mon, 10 Sep 2012 18:55:34 +0000

Some weeks ago I made big box packaging for my various Blendo games, to decorate my PAX 2012 booth.

When looking for books to read or movies to watch, I gravitate toward the credits. Who wrote this thing, who directed it, what creative folks did what. Then I hunt down and enjoy everything those folks touched during their career. Making these boxes was my shorthand of “if you enjoyed Gravity Bone or Atom Zombie Smasher or Flotilla, maybe you’ll like this new thing I’m making.”

Some folks were interested in having Blendo big boxes of their own, so here’s the print template:

Download: blendo_bigboxes.zip (58 mb)

Here’s what you’ll get:

Here’s how they’re put together:

Here’s a step-by-step:

Go to a print shop. I printed on 11”x17” cardboard stock.
Score the dotted lines with a hobby knife.
Cut the solid lines with a paper cutter. Most print shops have available paper cutters.
Cut the tabs/flaps with a hobby knife or scissors.
Fold and glue the back’s flaps to the front’s sides.
Done. Put the big boxes on your shelf so they rule over your puny small boxes with a firm but prudent reign.

Et al

I used to have a collection of game big boxes. Then one day I realized they were taking up basically half of my closet.

I couldn’t bear to just toss them out so. So, I got scissors and cut out the fronts of the boxes, leaving me with little game posters.

For my research, I rifled through my pile of decapitated boxes until I found something that was perfect: Mean Streets. Look at that proclamation of 256 color VGA. Look at that Real Sound badge (which was genuinely spectacular, by the way).

I combined that with Saul Bass movie posters and Penguin book covers, and ended up with my big boxes.

I don’t quite miss the big boxes themselves, but I do miss the things that were included in big boxes. Fold-out maps, in-game newspapers, bits and bobs, thick spiral-bound manuals. I guess by now I’m used to digital downloads, but they just don’t have that tactile feeling of holding something physical in your hands.

One idea I was playing with earlier in Quadrilateral Cowboy’s development was including a “Thief’s Cookbook”, similar to Indiana Jones’ Grail Diary. Basically, the guide would tell you how to bypass or deactivate various types of security systems and have schematics for various corporate buildings. Here’s the gag: the guide wouldn’t be an in-game object. The guide would be a PDF you’d print out, staple together, and refer to while playing the game.

So, as alarms blare and guards chase after you in-game, you’d be physically flipping through your guide trying to find the darn page for “Reckermann Security model TK421 vault door.”

At PAX, one of my favorite moments was when someone playing Quadrilateral Cowboy realized what the game entailed. He reached for his notebook and pen and said “I’m going to need this.” He started writing the names of the various security cameras and laser tripwires, so that he could later punch them back in to the in-game terminal prompt.

And I loved it.

On Boothing

Tue, 04 Sep 2012 19:56:40 +0000

I set up and ran my first booth showing a few days ago at PAX 2012.

First, some history. I wasn’t expecting to have a booth. About a month before PAX, a booth spot unexpectedly opened up. Andy Nguyen at Pocketwatch Games (Monaco!) informed me of this and helped me nab it.

I’ve demoed on a show floor a few times before, but at those times, the show provided me with a free station, table, computer, signage, the works. This PAX was my first time planning, buying/creating the materials, and setting up my own booth area. I’m fortunate to have been supported by the soft cushiony hands of the Indie Megabooth - they made the experience very streamlined and clear.

Great, I now had a 10’x10’ booth spot, ready to show my new game Quadrilateral Cowboy. Now I needed to figure out what I just signed myself up for. In a few weeks.

Booth

A few weeks later, I found myself in Seattle setting up my booth. Tying up banners and wrangling computers very much had a Little Rascals “c’mon guys, let’s put on a show!” vibe. The always-amazing Ben Esposito and Marc Nguyen helped me set up, and the likewise-amazing Caleb Bladh helped me demo the game during the show.

Here’s how the Blendo booth ended up looking:

The television displayed a gameplay video loop.
The projector played the same video file, but started at a different point. The projector is a BenQ Joybee GP2.
I had two stations to play the game on.
I printed 500 Quadrilateral Cowboy cards, displaying the game URL.
I had some leftover Atom Zombie Smasher buttons + cards from a previous show.
Hanging from the television I had fictional “big box” packaging for my previous Blendo games. They were made with Photoshop + Kinko’s + hobby knife + glue.

It was a basic setup, and it worked well. People were able to enjoy the game, I met great folks, and I witnessed what playtesting-on-steroids looks like. Quadrilateral Cowboy had a good showing, and I’m looking forward to doing more shows.

With the niceties out of the way, let’s get into the nitty gritty.

The Nitty Gritty

At the close of each day, I wrote in my notebook on how things went. This resulted in my list of “things I need to do differently next time”, mixed with idle observations:

Have cards at the television. It’s called an attract video for a reason, and it was silly to force people to then walk to the table in order to grab an info card.
Have game website address at the television. If they’re not interested in grabbing a card, at least give them an address to file away in their brains.
Get more chairs. Two stations and two chairs is not enough. I had to either crouch or lean down while the player played, and now my legs will never forgive me. Tiny stools would’ve been perfect. Or alternatively, go with standing-height stations and have zero chairs. (Standing stations also make it easier for people wearing backpacks)
Bigger big boxes. It would’ve been more readable (and funny) to have jumbo big boxes.
Spinning big boxes. I hung the boxes with string so people could pick them up and read the back. However, apparently people are averse to touching stuff, so they’d instead walk around behind the television in order to read the backs. If there was some way to have the boxes rotate around, that’d be great.
Tiny big boxes. Have tiny versions of the big boxes at the stations, to get coverage for the entire booth area.
Boxes worked well. The boxes worked well as shorthand for clearly communicating what the previous Blendo games were.
More stations. Two stations was not enough.
Lighting. I remember the lighting at the previous PAX being quite dark, so I brought a desk lamp and flashlight. It ended up not being dark at all, so this was completely unnecessary.
Audio for attract video. I didn’t have audio for the attract video. It would’ve made the video more understandable if I did.
Speakers vs. headphones. More than half of the people didn’t want to wear headphones. I think speakers would’ve served better, and also would have the benefit of serving not just the player, but all the observers near the station.
Water. I drank water after basically every sentence I spoke. I still ended up sounding like a goose after three days, but nowhere near as bad as previous shows. My pee has never been more clear.
Buttons. I had some leftover Atom Zombie Smasher buttons from a previous show. Buttons are apparently like valuable treasure; they disappeared in record time.
Have buttons at the television. Same as having cards at the television.
Cards. I printed 500 Quadrilateral Cowboy cards. I ran out sometime during the middle of the third and final day.
Papercraft. The folks at Vlambeer and Zachtronic Industries had cool papercraft stuff going on, and I loved it. I was planning to make some Midnight Hobo paper bottles, but ran out of time - next time I’m going to give that a go.
Youngsters. It was so encouraging to see younger people with no technical background play the game, pick up its light programming fundamentals, and get excited about it. I remember a couple of young kids played all the way to the last demo mission, which was a fairly tricky one - they meticulously debugged their command calls until it worked perfectly, and it was so wonderful to witness that.
Attract video importance. The attract video is what grabs people. I had some excess in there I should’ve excised to make the video more snappy.
Company shirts. This is my first time wearing a Blendo Games t-shirt, and thank goodness I did that. At previous shows, it was so awkward to have to assure people I worked at Blendo Games. I got my shirts made at spreadshirt.com
Selling stuff. I’d love to try selling stuff next time, such as T-shirts. The Retro Affect folks were selling Steam keys for Snapshot, which I thought was brilliant idea. Now go play Snapshot.
Cards at each station. The cards were only available at the end of the table. Next time they should be available/reachable from every station.
Company signage. I had a fair amount of “what company is this?” questions, so the t-shirt and banner wasn’t enough.
Mousepads. For some reason I only got myself one mousepad, which doesn’t make sense considering I have two stations.
Smooshed tablecloth. The tablecloth was fresh out of the box, resulting in giant creases running down the entire length.
Closed laptop. I later learned there is a laptop power option to keep the machine running even when the laptop is closed.
Safescreen. There’s a good chance your monitor may in fact be a television. In this case, safescreen is a possible issue and should be tested as soon as possible. Some TVs make it incredibly difficult to find the safescreen settings hidden in its menus.
Common questions. It may be good idea to set up an information sign somewhere with common questions (release date, platforms, etc) to cut down on repeating yourself (and saving your voice).
Steam is a platform. One of the most common questions I received: will it be on Steam? When listing platforms, just include Steam. Yup, Steam is a platform.
Sponsors. The Indie Megabooth set up a sponsorship with the fine folks at Intel and Mad Catz. The TV, TV stand, desktop computer, and peripherals were provided for us - big thanks to everyone involved in that.

In closing, one last thing: it’s been so great to be part of this group of independent developers. Everyone was so supportive, and my booth neighbors Gaslamp Games, Vlambeer, DrinkBox Studios, and Fire Hose Games couldn’t have been more gracious.

Long live the Indie Megabooth.

Golden Idol on Pressure Plate

Thu, 05 Jul 2012 19:25:02 +0000

Yesterday, Mossmouth’s Spelunky was released.

Yeah, it’s the best. Here’s why:

Discovery

People like to learn. People like to find out new things and expand their minds.

Video games often have a bad habit of equating learning to a task. A task you must trudge through before you’re granted access to the meat and potatoes and allowed to have fun.

I dread the first several minutes of games because I know that’s when I’m going to get barraged with words. Words telling me what I’m supposed to be doing, inane story babble, and what this and that button does. I pay this tax because I know the real game is lurking somewhere after this tutorial level, upon which I realize all the tutorial words have already seeped out of my head like water from a sieve.

Spelunky equates learning with fun. It doesn’t pause the game and pop up a window explaining how to jump. It doesn’t lock you in a room and force you to listen to VO. Instead, it lets you loose in the world and makes you flex your curiosity muscles.

“Hey, there’s a bloody sacrificial altar. What happens if I blow it up?”

“Look, there’s a golden idol sitting on a pressure plate. What could possibly go wrong?”

“Hi shopkeeper, you have a lot of things we want. What happens if we rob you?”

_“Well, that ended in tears.”_ Yup, it sure did.

Systematic

Many games would work just as well, if not better, were they converted into literature or Michael Bay movies. (And no, that’s not necessarily a bad thing.)

Spelunky is an example of something that unquestionably works best in its current form. It does this by laser-focusing on systems-based gameplay, something very unique to games.

What’s systems-based gameplay? Basically, it’s when your various game mechanics are designed to poke and prod one another.

Basic example: the Arrow Trap is triggered when someone or something moves near it. How does one safely trigger an Arrow Trap?

Pick up a rock and throw it at the trap.
Don’t have a rock? Pick up one of the other players and throw them.
Lure the giant freaky spider toward the trap.
If there’s a spiderweb, stand behind it so the arrow gets snagged in the webbing.
Go on Youtube and find solutions from incredibly creative people.

Layering these systems upon one another results in wonderful chain-reaction situations the game’s developers never imagined. There’s something fantastic about creating a unique moment that will never happen again, but more than that, the game generates these unique moments with such apparent ease.

In short: a variety of these rich interplaying systems + 4-player multiplayer + my sloppy thumbs = good times with Spelunky.

Et al

Spelunky lets you screw yourself over royally. As a testament to how tightly the game is made, this self-screwage never feels unfair or out of the blue. The game doesn’t screw you over, _you_ and your dumb decisions screw yourself over. With the looming horror of permadeath and lack of safety net checkpoints and savegames, the decisions you face suddenly become life-and-death in significance.

Mix all these things together, and you end up with a darn fine piece of work.

The Roguelike is a game genre I’m very fond of. Their main tenets are things I love: procedural worlds, player-generated narratives, systematic gameplay, and an adamant anti-chuffa stance. Spelunky takes and runs with these promising aspects, while doing that thing that great work does: that twist, of flipping the genre into a platformer, of making a roguelike that doesn’t require memorization of twenty-seven hotkeys, and letting (really, encouraging) you and your friends to throw one another toward giant freaky spiders.

So yeah, Spelunky is the best.

Atom Heart Smasher

Thu, 14 Jun 2012 07:46:13 +0000

I was digging through my old stuff and thought I’d share a tiny prototype:

Atom Heart Smasher Click here to download (7.2mb)

I grew up on a healthy diet of adventure games. Space Quest, Hero’s Quest, Monkey Island, Sam & Max - I fell in love with the characters, the stories, the absurd geography. I eventually made my own little adventure game, Pilot Light, and later tried my hand at a more ambitious attempt, Atom Heart Smasher.

AHS was a side-project I worked on after work hours in 2007. Like a lot of my prototypes, I used it as an opportunity to try something new to me and something stupid.

The new-to-me part was the heavy use of dialogue. I love to write. But for my games, I try to stay sparse on text. I feel games are at their best when you’re interacting and playing them – it’s a tough sell to force the player to just sit there and read your prose. With that being said, I thought I’d make this a game where the player just sits there and reads prose.

The stupid part I wanted to experiment with was the overall structure. I wanted to make the game based on a series of branching outcomes. For example, you make an early decision whether to call an ambulance for Lucky Luca, or to let him rot in the desert. When you later play as Lucky Luca, that decision would determine the scenario you’d play: 1. escape from ambulance custody, or 2. rot in the desert and search for water. Choices made in those scenarios would determine later scenarios, and so on and so forth.

Games that are fun to play are sometimes not so fun to develop, and vice-versa. Playing AHS is fairly enjoyable, but developing it was a mixed bag.

For one, the branching overall structure was indeed stupid. It’s production & content hell (duh doy), and I didn’t like that restarting the same game over again was a fundamental part of gameplay. It felt tedious and disrespectful of the player’s time.

Secondly, the dialogue-heaviness drove me kinda crazy. Writing it was fun. But as a developer, it drove me crazy that a huge part of the game had the player just sitting there reading swathes of text. “Swathes of text” is a good description for a lot of games out there, (incredibly successful ones at that) so this boils down to personal taste.

Lastly, it was around this time I became interested in making games with systems-driven mechanics. I’ve long been interested in games that explored this space - the simulated world of Thief and the systems-heavy X-Com are my two top titles - but being able to create and implement game systems requires some level of technical expertise. I was familiar with various game tools, but programming was something I was still learning.

I started teaching myself programming around the year 2000, by poking around the Half-life source code and John Carmack’s Quake2 code. When I say “poking around,” I mean I tweaked random numbers and excitedly looked for what changes it made in the game (note: that excitement was never justified). It wasn’t until 5+ years later did I feel proficient enough to make completely self-contained games (Grotto King, Gravity Bone), and it wasn’t until 10 years later that I coded my first game from scratch (Flotilla).

When I finally gained some loose semblance of coding skill, I slowly steered toward developing more systems-driven gameplay, placing more authorial control in the hands of the player instead of the developer. But time and time again, I find myself using adventure games as a reference point and feeling that itch to make one myself. I don’t think it’s any fluke that some of the most notable games out there - System Shock, Deus Ex - are a hybrid of the best parts of adventure games combined with more systems-based game mechanics.

(and yup, I shamelessly repurposed the the title of this game for Atom Zombie Smasher)

Day Z

Mon, 14 May 2012 08:17:10 +0000

I see someone I played Day Z for the first time today. This is what happened:

In short, Day Z is full of things I like to see: player-driven stories, a gameplay focus on systems interplaying with other systems, and interactions that extend beyond plopping bullets into fleshy surfaces.

It’s rough around the edges. It’s mean and ugly and probably smelly, and I say all that as a compliment. It’s unafraid to be downright boring at times. A lot of games make it their responsibility to push you to toward the ending - then you have things like Day Z that make you pull your dehydrated, starving body toward a glorious, crunchy demise.

Anyway, try it out.

Update:

Some of the comments were asking how to get/install Day Z. Here’s the steps I took:

Get and install “ARMA II: Combined Operations”. I got it from Steam, so I’ll be writing about the Steam version.
Exit Steam.
Start Steam again via the “Run as administrator” option.
Run “ARMA 2”.
Quit ARMA 2.
Run “ARMA 2: Operation Arrowhead”. In the dialogue box that appears, select “Play ARMA 2: Operation Arrowhead”.
Quit ARMA 2: Operation Arrowhead.
Go into your ARMA 2: Operation Arrowhead folder.
Create a folder named @dayz
Within that folder, create a folder named Addons (it should now look like this: steamsteamappscommonarma 2 operation arrowhead@dayzAddons)
Download all the files from http://www.dayzmod.com/downloads.php (site unfortunately seems to be down at the moment. Perhaps poke around and try to find out if the files are being mirrored elsewhere.)
Unpack all the .rar files into the Addons folder.
In Steam, right-click ARMA 2: Operation Arrowhead > Properties > Set Launch Options
Enter this: -nosplash -mod=@dayz
Run ARMA 2: Operation Arrowhead. In the dialogue box, select “Launch Arma 2: Combined Operations”.

FLITE synthesized speech

Mon, 23 Apr 2012 21:49:24 +0000

For the past couple days I’ve been working on getting synthesized speech into the Doom 3 engine. After wrangling with it this morning, I got it up and running. There’s still a few kinks to work out (I’ll get to that later), and I haven’t yet decided whether to go forward with it, but I think there’s a lot of promise and applicability toward games.

The speech system I used was an open-source library called Flite. Most of my previous posts have been design and art oriented, so I thought I’d give a technical overview on how to integrate speech into your project. I’m still fairly green around C++, so this is probably more helpful for me than you.

Set up the environment. In the project’s Library Directories, add Flite’s “lib” folder (in my case, C:/sdksflite-1.4-release/lib).
In the project’s Include Directories, add Flite’s “include” folder (in my case, C:/sdksflite-1.4-release/include).
In the project’s Additional Dependencies, add:
```
fliteDll.lib 
```
cmu_us_rms.lib
Copy these files into your game’s folder:
```
fliteDll.dll
```
cmu_us_rms.dll
The environment is now ready. Now we can dig into the code. Open up whatever file you’d like to include speech in. Add at the top of the .cpp file:
```
extern "C"
```
{ #include “flite.h” cst_voice *register_cmu_us_rms(); cst_voice *fliteVoice; };
In a function where things are initialized, add:

flite_init() fliteVoice = register_cmu_us_rms();
And finally, we get to play the audio. Call this line when you want the audio to play:
```
flite_text_to_speech("Baboo wizard.", fliteVoice, "play");
```

Done! Now your game will say “baboo wizard” at the most exciting and inopportune times during gameplay. I get chills just thinking about it.

This was an extremely basic “hello world” example, so a few things to keep in mind:

When “flite_text_to_speech” is called, the game pauses while the speech is read. I’ll have to find out how to resolve this.
I was unable to find any obvious way to adjust the speech’s volume.
The speech is routed not through Doom 3’s audio system, but through Flite’s audio system. I’m guessing this may cause surprise gotchas and jankiness down the road if I let them remain separate as they are now.

I’m now looking forward to playing tons of games featuring Mr. Robot Voice saying incredible things to me. Go forth and get crackin’.

Atom Zombie Primordial Soup

Tue, 20 Mar 2012 22:25:32 +0000

I gave a talk at GDC this year: “Nuke it From Orbit: The Making of Atom Zombie Smasher”. During the talk, I showed some footage from early prototype versions of the game. Here’s a short video of a very early iteration of Atom Zombie Smasher:

Controls

At the time, the primary platform was the Xbox360. The controls were:

X = artillery strike.
Y = carpet bomb.
B = napalm bomb.
A (tap) = move infantry.
A (hold) = call helicopter.
Left stick = move cursor.

One of my goals was to make the controls easy enough to learn in a few seconds, so I intentionally avoided using the triggers, bumpers, d-pad, and right stick. Although AZS later transitioned to PC/Mac/Linux, the game retained its approach to controls, in that all the player really needs is a 2-button mouse (there are some keyboard shortcuts, but they consist of secondary and tertiary commands not required to play the game).

On an unrelated note, my favorite playtesting feedback was that my napalm bomb fire effect “looked like cauliflower.” If I received this feedback more often, I probably would’ve kept the napalm bomb in the final game (or, make the game all about vegetables).

Gameplay

My first attempt at AZS (prior to this video recording) had a different victory condition. If this video is 1.0, let’s call its predecessor version 0.1.

In 0.1, the goal was to wipe out all zombies within a set time limit. At your disposal was a variety of bombs, airstrikes, and other miscellaneous explosives. There’s something compelling about the idea of creating a human firebreak, and I felt that this victory condition fit that idea perfectly.

But, what you see in your head doesn’t always survive translation to what you see on the screen. That’s why implementation and prototyping is so important to me. I implemented the “destroy all zombies” game in 0.1, and immediately didn’t like it for various reasons:

It was too fast-paced and twitchy. The infectious chain reactions were fun to see, but when your job was to destroy all the zombies, it made the game feel too chaotic & messy.
It got tedious. It was satisfying to wipe out large swathes of zombies, but chasing down those last stragglers at the end of the level was awful.
It was too easy to reach that “point of no return” limbo state where you’re unsure whether the level is still winnable or not.
I hate time limits.

I recognized potential in the zombie infection mechanic, but needed to tweak something to make the game work. After some thought, I started playing around with a roving King of the Hill scenario, where you had to defend randomly-chosen “rescue zone” hotspots. Every X seconds the hotspot would randomly roam to a new spot, and your job was to make sure the zombies wouldn’t overrun that spot.

That worked well, but I had some problems with the mechanic. The main problem was that I had to make the hotspot chooser reasonably smart. Instead of just randomly picking any spot, I had to make sure the spot was a reasonable place. When random generation is in the mix, I think it’s easy for a game to feel unfair. If the random hotspot chooser constantly chose awkward or difficult spots, that would be a shelf moment for me - the moment I put the game on the shelf and never play it again. So, I had to find a spot that had people to rescue, not too many zombies, didn’t have incoming bombs, etc. The AI brain required to handle this was rapidly growing out of my control.

Then I thought, “why not let the player just manually place the hotspot?” It was a duh-doy moment. Instead of making some wacky AI brain to handle this system, I let a wacky human brain handle it. This became the helicopter rescue mechanic, and ended up in the final version.

Et al

This prototype shed light on a lot of gameplay miscellanea:

Like the last straggler zombies in 0.1, it was now sometimes tedious to rescue those last straggler humans in 1.0 - levels were ending with a whimper, not a bang. Eventually I put in the day-night cycle, where zombies start pouring in from every which way during the evening. This served as an “apocalypse timer” in which levels were nigh-guaranteed to not drag on. And it made levels end with a lovely bang.
Having the same four weapons every level got old fast. This led way to the randomized monthly mercenary roster.
Buildings were intended to serve as level design chokepoints. But the spaces between buildings were so wide that they were basically useless. This eventually led to the constricted streets and alleys in the final game.
For storyline purposes, there were some levels where you were aided by Cpl. Tabajaras and his Howling Commandos, an AI-driven infantry squad that ran around the map shooting zombies. This is one thing I wish I had kept around. It always made me laugh when they’d walk straight into your falling bombs.

Anyway, that’s my short history of the early Atom Zombie Smasher prototypes. In closing, take with you this key knowledge: prototyping, do it.

Thirty Flights of Loving teaser

Wed, 29 Feb 2012 03:33:55 +0000

A short time ago, the Idle Thumbs crew contacted me and asked if I was interested in making a small game for their Kickstarter. I’m a huge fan of Idle Thumbs, so I jumped at the opportunity.

Today we released a teaser video for that game, Thirty Flights of Loving:

All credit for this video goes to the Idle Thumbs crew - they put it all together, and boy did they do a great job. Get the game early by supporting the Idle Thumbs kickstarter.

While you’re at it, put Idle Thumbs on your playlist. The Idle Thumbs podcast archive is vast, insightful, hilarious, freeeeee, and absolutely essential if you’re at all interested in video games. Start from episode one. Go!

IndieCade 2011

Sat, 15 Oct 2011 00:17:34 +0000

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.

Ghost Writer

Tue, 11 Oct 2011 09:49:26 +0000

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:

Pathways Redux Part II

Wed, 05 Oct 2011 07:41:41 +0000

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!

Pathways Redux Part I

Fri, 30 Sep 2011 08:13:13 +0000

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

All about PAX

Wed, 21 Sep 2011 07:19:36 +0000

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 Splatters, Vanessa 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!

Blendo Games now on Desura

Thu, 15 Sep 2011 21:42:23 +0000

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!

Atom Zombie Tech

Sat, 20 Aug 2011 20:46:22 +0000

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 DocumentsMy 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.

Atom Zombie Smasher on Ubuntu Software Center

Wed, 10 Aug 2011 00:47:55 +0000

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.

The Lincoln Letter

Wed, 25 May 2011 07:48:11 +0000

I’ve always loved comic books. So, some time during college, I made a few myself. Here is The Lincoln Letter, a story filled to the gills with educational value.

Whenever I make a game, I spend a large amount of time iterating and experimenting. The start of a project is particularly daunting - the game can go in any direction, so having to choose just one path can sometimes be paralyzing.

This little comic project was no different. Here’s a rough draft of the above story:

The script went through the wringer a few times. Then the script and the layout had to be reconciled: fitting together the text bubbles, images, and flow from one panel to the next. With those pieces, the process became a matter of figuring out how to best put the puzzle together - tweaking word usage, moving the panels around, cutting material.

This is not unlike reconciling between art & gameplay. A basic example: a modern military shooter game. Gameplay-wise, I want players to instantly recognize who is and isn’t on my team. Art-wise, I want the game to look gritty and realistic: everyone wears dark camouflage uniforms. So how do I instantly differentiate friend and foe if everyone wears very similar uniforms? There is no one correct way to resolve this discrepancy - just a lot of different ways to fit the puzzle together.

(Personally, I’d add pink bunny ears and call it a day.)

GDC 2011

Wed, 18 May 2011 09:13:02 +0000

I attended the Game Developers Conference up in San Francisco this year.

This was my first GDC, and I got a lot out of it - interesting discussions, meeting lots of like-minded strangers, and reuniting with friends I haven’t seen in years. It was held for about a week starting on February 28, so the timing on this writeup is comically poor. (let’s pretend you’re reading this a couple months ago.)

Monaco

I loved hearing Andy Schatz talk about Monaco’s history, namely, in how Monaco originated as a side-project borne out of frustration from another project. In a matter of weeks, this quick ‘n dirty diversion became an amazing full-fledged game (that’s at the top of my “things I gotta play” list).

I imagine this happens surprisingly often. My game Flotilla bore a similar development cycle - Flotilla began as something to take my mind off another project that was being pouty with me (a very early version of Atom Zombie Smasher). I wanted to teach myself how to code 3D graphics, and Flotilla’s space combat fit the bill.

This also reminded me of something my college professor said. He said that viewers can instantly recognize whether the filmmakers enjoyed making the film. Enthusiasm and energy have a way of just leaping off the screen. Alas, the opposite is also true - if you or your team is miserable, your misery and disgruntledness just oozes out of your work.

Another World

I wrote about Eric Chahi in a previous post, but one thing I wanted to add was how _crazy _is it that just one guy made the entirety of Another World. There’s such a beautiful recklessness in Another World’s design.

Chris Crawford

This was one of the best talks of the conference. Chris Crawford talked about very early video games & development and compared them against their modern counterparts. It was fascinating to see how in a lot of ways, “the more things change, the more they stay the same.”

It brought to my mind what I think is one of the more exciting aspects of small-studio independent development: failures are okay. Development time is fast enough and cheap enough to absorb failed experiments. Sinking and making a new & better rowboat is do-able. Sinking and making a new mile-long oil tanker? Lucy, you’ve got some ‘splainin to do.

IGF Awards

My game Flotilla was nominated for an award! I got to sit in the fancy-pants roped-off area. I didn’t win anything (Amnesia won it, and deservedly so) but just being there was damn exciting.

Populous

It was a joy listening to Peter Molyneux talk about Bullfrog’s history and Populous’ development. I especially loved hearing how much of the game design was made ad-hoc through happy accidents, futzing around in multiplayer, and discovering via the debug tools that “hey, lowering and raising terrain is actually kinda fun.” I love that excitement of discovery, and game development provides no shortage of it.

When you take a look at Bullfrog’s work, it’s really quite spectacular to see how diverse and forward-thinking their lineup is. Populous, Syndicate, Magic Carpet, Theme Park, Dungeon Keeper. The fact that all of those came from one company is very impressive.

There was a great surprise at the end of his talk. He fired up Visual Studio C++ on his system and attempted to compile his pet project. It unceremoniously fizzled out several compile errors. He eventually tracked down a pre-compiled binary and ran it.

It was Populous! But not just Populous, it was Populous with all the niceties you’d expect from a current game. The UI was modernized, the screen resolution was crispy, and multiplayer supported 256 players. It was wonderful to see that an established developer like Mr. Molyneux still enjoyed mucking around in the code on fun hobby projects.

(doubly fun when you realize this Populous redux will likely never see the light of day due to legal/licensing reasons)

Strategy Games panel

This was a nice way to end the last day of GDC. The panel was a who’s-who of strategy game developers - lead designers of Starcraft II, Civ 4, Civ 5, and the Age of Empires games. One point brought up was the need to streamline strategy games, a genre often characterized with over-complexity and obtuse UI. I couldn’t agree more. I feel the user experience is of utmost importance - getting lost in a bank of 100 UI buttons is rarely a good way to start a game.

And to top it off, my game Atom Zombie Smasher was mentioned by the moderator Tom Chick during this panel talk. It caught me completely off-guard. Somehow, I managed to resist the temptation to whisper to my neighbor, “I totally made that game!“

Civil Resistance

Wed, 11 May 2011 09:05:57 +0000

I’m currently re-playing Half-life. At the moment, I’m heading into the mysterious Lambda lab, where I’m told the last hope of resistance lies.

It’s a game worth re-playing, and it holds up remarkably well. But there’s another reason why I decided to fire Half-life back up. And it’s sort of embarrassing.

Here it is: the first time I played it, I cheated my way through Half-life. Back when Half-life first came out thirteen (!) years ago, there were two sections of the game that consistently twisted my nipples and made me cry uncle: the underground rail-train chapters, and the Xen chapters. The former is because the soldier enemies are soul-crushingly brutal, and the latter is because I’m terrible at jumping puzzles.

But now, I’m playing it honest. No more cheat codes, none of that monkey business. I’m enjoying it immensely; I guess somewhere in the past several years I picked up how to not play terribly. And in spite of inspiring a new wave of single-player first-person shooters in the intervening years, Half-life still impresses with its clever scenarios and puzzle-solving elements, not to mention having a deft hand at sprinkling its story bits.

I love the world that Half-life creates. I love the variety of obstacles and the mysteries it raises. What’s the deal with the G-man? Was the resonance cascade intended to happen? Who sent the military? What was the extent of Black Mesa’s dabbling in teleportation experiments? Why is Gordon Freeman preternaturally inclined to bludgeon everything that moves?

Facetious as it is, that last bit got me thinking. During the introductory tram ride, we’re informed Gordon Freeman is an MIT Ph.D graduate, and is now a research associate in New Mexico’s Black Mesa Research Facility. After the lab disaster, Gordon Freeman proceeds to spend the next several hours shooting rifles, throwing grenades, and firing rockets into hundreds of military personnel and extraterrestrial wildlife.

So, as a thought experiment: what if Half-life was designed with zero combat? I’m not talking about a “remove bad guys” hack, I’m talking about if the game was designed from the ground up in such a way that Gordon Freeman never holds a gun. In fact, take any game with great worlds - Ultima Underworld, System Shock, Pathways into Darkness, Deus Ex. In these games, there are many things you can do that don’t involve guns - could a full-length game be built around those things? Is run’n’gun combat a necessary part of this game genre? Is killing things needed in order to be commercially viable?

The Portal games do just that. They’re first person shooters in that they’re played from the first-person perspective, but they eschew conventions of guns, ammo, reloading, and monsters running around. Players concentrate solely on puzzle-solving; Valve makes this even more frictionless by setting Portal in a test lab, creating a convenient mechanism for shuffling players from one puzzle arena to the next puzzle arena. It should be noted Portal is considered a relatively short game, as compared to its Half-life brethren; would Portal’s puzzley gameplay have worked if it was 11 hours long?

I made a snack-sized game some years ago, Gravity Bone, that had this goal in mind. I wanted to make a game with a rich, colorful world of espionage and mystery, but arm the player with very un-gun-like “weapons”: a tray of wine, a ball-peen hammer, a Nikon camera. It was an experiment, and I was surprised to hear from a lot of people that they wanted more of this. Gravity Bone takes maybe 10 minutes to complete; I’d love to see how this type of game would stand up in a longer format.

One full-length game that has taken and run with the no-guns approach is Amnesia: The Dark Descent. In most games, you shoot bullets into monsters, and the monsters drop dead. Not so in Amnesia. Basically, Amnesia is a thriller in which monsters can (and will) eat you, so your best weapon is to run and hide in a cupboard like a scaredy-cat. And boy is it effective. Every several minutes I have to pause the game and take a break, because I get way too wound up by all the spookiness.

In closing: less guns; try it, you might like it.

How Braaaains Work

Wed, 04 May 2011 06:28:44 +0000

Some time ago someone asked me how AI is implemented in Atom Zombie Smasher. So, here’s a short writeup on it.

Braaaains 1

In my first attempt at zombie AI, they began as mindless automatons. Here’s how they first worked:

Find a random place to walk to.
Walk there.

That’s what zombies do, right? They like to take walks. It looks disgustingly simple, but was surprisingly effective. The zombies spread across the map in a fairly natural-looking way.

A problem arose when the human population dwindled down to very small amounts. When just a few civilians were left, the game became awkward. These last holdouts had an extremely good chance of surviving for a very long time, due to how zombie wandering was left completely up to random chance.

As a result, the finale of a map tended to drag in an anticlimactic way.

Braaaains 2

For my next attempt, I tweaked the zombie AI:

Select a random civilian.
Walk to that civilian’s position.

Zombies were transformed into extremely efficient civilian-hunting machines. This fixed the problem of map finales dragging on - when just a few humans were left, they were promptly devoured.

A new problem arose: the game was now nigh-impossible. Once a chain-reaction infection starts, it’s difficult to stop. Due to how these new hunter-zombie powerhouses behaved, these chain reactions were now happening from the moment you started the map to the time you stopped. Furthermore, the cold efficiency in which they behaved was more akin to a special weapons team rather than rumpled zombies.

Braaaains 3

For my third (and final) version of the zombie AI, I combined the above two systems together:

Zombie makes a random decision:
25% chance the zombie hunts a random civilian.
75% chance the zombie wanders the map randomly.

This achieved the “rrgghh, brains!!” mindless behavior expected of zombies, but also ensured civilians were getting eaten at a reliable rate.

But really: implementing zombie behavior is a bit of a cheat. One of the nice things about zombies is that if they behave stupidly, it’s generally accepted - after all, they’re zombies. A zombie is expected to act like a drunk fella, aimlessly stumbling around and making questionable decisions.

The hard part was implementing believable civilian AI.

Civ Brain

Civilians are the currency in the AZS world: the more civilians you save, the better. As a result of that, it was important that civilians were fairly capable of self-preservation. Here’s what runs through a civilian’s brain:

If I’m near a zombie, run away from it.
If I’m in range of a rescue helicopter, run toward it.

Civilians get a “panic” speed boost when running away from zombies, allowing them to outrun pursuers. During this panic state, civilians wear blinders - they run toward their destination with complete disregard for their safety. As a result, a panicked human during the beginning of a zombie outbreak has a good chance of surviving; panicking during the peak of an outbreak, not so much.

An unintended effect of this speed boost was that the little civilian dots were given a wonderful little personality. On screen, you see a civilian dot wander near a zombie and high-tail it the other way at a sprinting pace. The abstracted visuals make it easy to fill in the blanks - you can imagine the civilian’s surprise at seeing the zombie, the crazy flailing-arms as they run away screaming, having no idea what street they’ve ended up on.

Et al

I find AI to be one of most difficult parts of game development. It’s very demanding on both a technical and design level. AI is not my strong point, so AZS mostly designs around that - zombies are not expected to be intelligent, and civilians are prone to panic & hysteria during the end of the world.

Games with good AI are rare finds. But when a game nails the AI, it makes a world of difference. The Halo games are good examples of this.

I’ll end this with a bot for Quake II that I thought was particularly clever, the Eraser Bot. Basically, the Eraser Bot learns from players. As you run around the map, you drop an invisible “popcorn trail” wherever you go. The bot then uses this data for its pathfinding. As you play more, you generate more path data, making the bots “smarter.” They begin to hunt you down with ruthless efficiency, taking unexpected shortcuts and sticking crazy trick jumps.

Maybe I’m just terrible at shooters, but I found the bot’s effectiveness to be pretty frightening!

Urban Renewal Kit

Wed, 20 Apr 2011 18:36:30 +0000

Over the years I’ve become interested in procedurally-generated content. On the gameplay side, it provides a tremendous amount of replayability. On the production side, the bang-for-the-buck value is phenomenal. I thought I’d take a moment and talk about how levels were created in Atom Zombie Smasher.

Street work

The level first starts off as a blank slate:

At this point, it’s just a big empty plot of dirt. I find a random spot and lay down a street:

Then, I start laying down the major “avenue” streets. These streets are laid down in a such fashion to guarantee very large city blocks:

The major city blocks are now defined. I now divide these giant blocks into smaller pieces. One-by-one, every city block is measured; if it exceeds a certain threshold size, I divide it with a street.

With that, the streets are all done!

Buildings

Now that the roads are completed, the level is ready to be filled with buildings. The building population system is fashioned after how you pack furniture: first you pack all the big items (the sofa), then you take care of the small stuff (the sofa cushions). In this case, I first start with the large skyscrapers:

Notice the little empty plots of land neighboring the buildings. Tiny one-story buildings are now crammed into these these spots:

Finally, some of the buildings are replaced with stunningly beautiful city parks:

Done! People are then distributed throughout the streets, ready to be either rescued or eaten alive.

Et al

This is an extremely straight-forward way of creating a city - there aren’t really any surprises in how it works. It’s based on a grid, making it very easy to check for intersections, overlaps, building sizes, and such. It’s fairly fast; the load time is hidden when the map zooms down from the world map to the city map.

If I was to return to this, I’d integrate more gameplay rules into the city generation. For example, creating “districts” (residential, industrial) characterized with certain buildings, building behaviors, population types.

Furthermore, something I’d like to try to tackle is non-perpendicular streets and buildings. This would allow for things like curved roads, round-abouts, etc., and introduces more variability than a straight grid provides.

At any rate, give procedural content generation a try. I specifically love how such content gives every player their own one-of-a-kind experience, a custom map that only you will ever get to play. This is something very unique to video games. My favorite description of Atom Zombie Smasher is from Tom Chick, who said it “uses tiny dots to create moments of drama.” I certainly didn’t author any insightful dialogue or thought-provoking art – the game systems organically conjure moments where civilians are put in back-against-the-wall situations.

Some wonderful games that focus on procedural content - Darwinia, Dungeon Crawl Stone Soup, Minecraft, and my beloved X-com. I will never forget my best sniper in X-com, Abraham Lincoln. You had a clean shot across the map, and you nailed it like the best damn 16th president of the US of A.

If you haven’t played these games, then do so!

Unkempt Activity

Wed, 13 Apr 2011 07:20:11 +0000

I visited the Game Developers Conference this year and was fortunate enough to listen to Eric Chahi’s Another World retrospective. Another World remains one of the most beautiful and forward-looking games I’ve ever played. It was a game with a fantastic cinematic feel, made before games with cinematic feels even existed, and commits itself so wholeheartedly in creating a bizarre universe you’re aching to explore.

Something I loved hearing: after Eric Chahi created Another World’s introduction sequence, he then thought, “okay, so the character gets zapped and disappears. I guess I now better figure out what happens to him.” In hindsight, this improvisational style seems obvious. First you’re racing from a cave flood, the next moment you’re in the cockpit of a gladiatorial warmachine. I have no doubt Eric surprised even himself during development, and it’s that spontaneity that gives Another World so much charm.

On my own projects, I usually begin with a rough idea and just start implementing it. I find the most interesting ideas never just float around in the ether. They’re buried inside the creation process, waiting to be unearthed.

A broad example is level creation. At one time, I used to spend a lot of effort in the paper sketch phase, planning out how a level would work. The catch was: once I laid down my first few blocks in the world and viewed it from my character’s point of view, I’d see new, better connections everywhere. ”Ooh, adding a tunnel going under there would work great!” That unplanned tunnel then starts the domino chain-reaction redesign of the neighboring areas, and the paper sketch becomes instantly outdated.

(Though, I do think paper sketches and documentation are important. It serves both as a good starting point and a way to get a grasp of the high-level “big picture.” If there was a way to feed paper documentation into a machine and pop out a completed game, that would make the process a whole lot easier, albeit less fun.)

A friend once described this approach as Termite Art-esque, referring to the Manny Farber White Elephant Art vs. Termite Art essay.

Good work usually arises where the creators seem to have no ambitions towards gilt culture but are involved in a kind of squandering-beaverish endeavor that isn’t anywhere or for anything. A peculiar fact about termite-tapeworm-fungus-moss art is that it goes always forward eating its own boundaries, and, likely as not, leaves nothing in its path other than the signs of eager, industrious, unkempt activity. […] The best examples of termite art appear in places other than films, where the spotlight of culture is no where in evidence, so that the craftsmen can be ornery, wasteful, stubbornly self-involved, doing go-for-broke art and not caring what comes of it.

Though I’m completely bastardizing the point of the essay, I love that description of nibbling forward purely for the love of nibbling. Is it a smooth ride? No. Will it function well? Probably not. Will it appeal to a mass audience? Not a snowball’s chance in hell.

But it’s damn satisfying on a personal level. There’s great joy in diving headfirst toward a direction you think is interesting. That joy is reflected in your work, and players instantly recognize it. When people write to me asking about game development, the best suggestion I always have is: just start making something!

Primordial Soup

Wed, 06 Apr 2011 09:11:35 +0000

While tidying up my hard drive, I found some old Doom II maps I made back in the wild and woolly days of the twentieth century. Everyone starts somewhere, and for me, Doom II mapping was where I got interested in game development.

According to the timestamp on the map files, I made these maps somewhere around 1997-98. Yes, while all the cool kids were playing GTA and Quake 2, I was going nuts over making Doom II maps. I’d love to say I was making a profound artistic decision, but honestly, it was entirely because my computer just couldn’t handle new games. I had an ancient 486DX computer, way out of league from the fancy new-fangled Pentium machines.

But, that didn’t bother me. Just being able to make little worlds and then exploring them was absolutely thrilling. I grew up playing games with stories and characters, specifically the Sierra adventure games and the LucasArts adventure games. So, my first instinct was to make maps with some sort of narrative. Considering the game engine wasn’t designed for this (and combined with the fact I was still learning how to even use the tools), achieving this was remarkably difficult.

Siege.wad

See that door at the end of the hall? I was so intensely proud of that door. The door is slightly ajar; squeezed beneath it is a bloodied corpse. Beside it is a wall switch, presumably to activate the door.

But here’s the gag that (I thought) made this door brilliant - the wall switch did nothing. You press it, the door doesn’t move. In order to open the door, you have to click on the door itself. In my mind, I saw the player having to manually lift up the metal barricade with his hands, straining against the door’s whining servo motors. It looked so amazing in my mind!

And then when you actually play it, it just looks like a bug. The designer forgot to link the button to the door - how lazy!

Sewer.wad

I struggled with creating some semblance of a scripted sequence. Basically, everyone in Doom II just wants to shoot you - there’s no real latitude given there. You do, however, have control over the environment. As a result, most “scripted sequences” basically boiled down to “walk onto a pressure plate and a wall opens.”

In this case, a wall of crates slides down to reveal some baddies. Why would a contractor construct a facility where the crates slide down a few feet? I have no idea why.

Portal.wad

Somewhere around this time, previews for Half-life were popping up. And it blew my mind. Levels based on realistic environments? A strong focus on storytelling? Allied characters who helped you out? It was like Valve peeked into my brain and said “let’s make the perfect game for this guy.”

I made this map in anticipation of Half-life, modeling the facility as if it could be a liveable, useable place. There’s a warehouse, an office, a break room, all of which I thought was very novel at the time.

The level also foretold the name of a future Valve game. My divination powers used to be so strong.

SDF1.wad

This level is an unashamed recreation of the first level of Dark Forces. What a spectacular game. I’m not sure what voodoo magic LucasArts was dabbling in, but that amazing string of X-Wing, Tie Fighter, Dark Forces, and Jedi Knight made it all worth it.

Strife.wad

And here, at long last I achieved something I had been trying to do for a long time: a scripted sequence with a character. It’s a terrible sequence, but dag nabbit, it’s a sequence nonetheless.

The premise is that you and your commando sidekick are sent into a dangerous enemy hideout. Your buddy steps into the teleporter and is zapped there. You follow suit, and in a grotesque freak accident, teleport at the exact same spot where your buddy is. The laws of physics demand no two objects can exist at the same spot. Your buddy bursts open, like a hefty bag of tomato soup dropped from a ten-story building.

It’s a terrible sequence.

Morbidly Curious

For the morbidly curious, all of the above levels can be downloaded from this link. And if you think the above stuff is bad, you should see the stuff I lost in my hard drive crash. Yikes.

And on a closing note, I’ll mention an very impressive mod I recently played, Research and Development. It’s a great set of levels that de-emphasizes combat to a wonderful extreme. If you haven’t played it yet, then do so now. Go ahead, I’ll wait.

It’s interesting to see how mods have changed. Simply, making mods now is so much more complex. Making a mod for Doom II was basically “connect-the-dots” - put down four vertices, connect them with four walls, and bang! You got a room. Since then, making a map has exponentially grown more elaborate. Shaders, normal maps, specular maps, scripting, pathfinder mapping, visibility, cinematics - yes, people are more tech-savvy now, but the barrier of entry has likewise shot up at an alarming pace.

I feel to some extent that modern independent game development has co-opted mods. I think the same people who would’ve been constructing Quake mods as a hobby are now indie game developers. With the internet as a viable distribution outlet and so many tools freely/cheaply available, it seems there’s little reason to not just roll your own game - depending on your skillset, it’s sometimes even easier to make a stand-alone game. I see that same crazy “let’s make something bonkers” spark in indie games that I once saw in the days of QPong, Lithium CTF, and Team Fortress.

People want to be creative, and love expressing that creativity. Hence, the success of things like LittleBigPlanet and Minecraft. Making mods gave me my start, and I’m certainly curious to see how mods will look like and change years from now.

Card Shark

Wed, 30 Mar 2011 09:50:20 +0000

Atom Zombie Smasher was recently released on Steam. As a result of that, my backlog of feature requests and bug reports has shot up by a bajoolion percent. I thought I’d take a minute to breathe and talk about how I handled task management.

This picture shows the ancient technique used on Flotilla and Air Forte: index cards and a pink tissue box.

What powers this infernal machine? Here’s how it works:

When I think of a new task or notice a bug, I write it on an index card. Example: “Make walk animation.”
The card is placed next to its friends on my heater.
When I need something to do, I take a look and decide which card to tackle.
When I complete the task, I toss it into the tissue box.

That’s it. You might be thinking, “Wait a minute! That’s nothing more than a to-do list. I’ve been hoodwinked!” To which I answer: you’re not that far off. Though, I did end up ultimately preferring the index cards over a traditional list, for reasons I’ll get into later.

For reference’s sake, here’s the size of the final deck from Flotilla:

For those playing at home: the top card reads, “Only start skirmish if all players have ships.” At some point, Flotilla had a bug where a player could start a skirmish battle with no ships in his fleet. This resulted in extremely brief battles.

(For Lean and Agile development fans: if you squint really, really, really hard, you’ll find this was all very loosely inspired by the Kanban board technique, which we used to great effect at Pandemic. If you have a medium-to-big team, do investigate it.)

The Age of Notepad.exe

For Atom Zombie Smasher, I decided to go a different direction and used notepad.exe to keep track of all my tasks. Here’s how that text file ended up: click here to read it

I wrote tasks down, and when I completed them I appended “XXXXXX” in front of them; the equivalent of throwing them into the tissue box. I assumed it would be a 21st century digital version of my index cards. But I felt it didn’t work out nearly as well.

For one, just take a look at the file. It looks like someone barfed out letter soup. There are code snippets, crash logs, half-baked sentences. I fell prey to using this file as a junk drawer.

On Analog

Something has to be said about analog vs. digital. I was fortunate to have once edited a film project on a musty old Moviola flatbed machine. By this time, digital editing was the norm, so getting to use this ancient analog metal beast was a rare treat.

The room smelled like wet dog and sawdust. Absolutely everything was time-consuming. And I loved it. I loved splicing the film and threading it through the tiny wheels. What I loved most was that it forced you to think about every decision. Are you sure you want to make that cut? Making a splice takes time. I think what you really want is to move the cut there instead.

That cut was probably also a wrong decision, but damn did it force you learn the hard way. You had to make sure something was worth your time.

That thoughtfulness was what my .txt file lacked. It was too effortless to throw random crap into it. As a result, its signal to noise ratio was terrible. When I needed to find a new task, I had to wade through a lot of things that honestly shouldn’t even be there. Granted, this is probably just my own shortcoming; I’m sure you’ll fare much better!

Distinguishing features I liked about having index cards:

It’s a physical object. When the index cards start snaking their way across my living room floor, I immediately know something has gone awry.
I find it easier to visualize the relationship between all the cards - dependencies, importance, etc. It encourages you to touch ‘em & move ‘em around.
It’s surprisingly effective at rooting out the stupid. Taking the time to uncap a pen and write on a card requires just enough commitment to block out most half-baked ideas.

And really - the ritual of throwing a completed index card into a pink tissue box is way more satisfying than it should be.

On Vignettes

Wed, 23 Mar 2011 23:04:49 +0000

Last night I opened my email inbox and found a message from a fella named Jeff Shyluk:

[…] Speaking of vignettes, because I am so pleased with the patch, I drew up a special one to thank you for your hard work and dedication to quickly patching up AZS!

I love it! And despite Jeff having never seen a picture of me, he has captured my chin with an eerie level of accuracy. Check out more of Jeff’s work at his blog.

So today I thought I’d write a bit on the vignette sequences. The vignettes use the conventions of a comic book to convey story & information to the player. For those who have no idea what I’m talking about, the first few seconds of this video display a vignette in Atom Zombie Smasher.

Initially, I was leery at putting them into the game. Any time the player is not interacting with the game, I get a bit nervous. Why am I watching this dialogue sequence in this video game? If I want to sit still and watch people talk, why am I not doing that in a media better suited for that, such as film or literature? Why am I being forced to watch this… thing?

Ultimately, I have no defense for that. I enjoyed making the vignettes, and that’s the main reason why they’re included.

The vignette system was first created for use in my game Air Forte. You can see a brief clip of one of Air Forte’s vignettes in this video. The system is very basic. First, I drew one “page” of the vignette. Here’s the first page:

Then, in the game, a virtual “camera” zooms into a panel. After a set time (or when the player presses a button), the camera swoops over to the next panel, mimicking the human eye reading comic strip panels. Text was displayed during runtime, letting me do little tricks like integrating the player’s name into the panels. (Also note some panels are empty. In Air Forte, the player can choose the appearance of their player character. Riffing off that, I inserted an image of the player character into these blank panels)

When it came time to make Atom Zombie Smasher, I expanded the vignette system. First of all, vignettes no longer had to be one enormous image. Vignettes were now composed of any arbitrary amount of images stitched together. For example, this vignette of Mr. Tabajaras and his grandparents is composed of three separate images: the empty sheet (green), the hero image (yellow), and the panel filler (red).

Doing this A) dramatically reduced the amount of work required, B) reduced loading time, and C) reduced the game’s file size. In the old Air Forte system, I would’ve needed to create a new master image for each of Atom Zombie Smasher’s 30+ vignettes. This is especially irksome when two vignettes are _almost _but not quite perfectly identical.

The weakness of this stitching system is that I still think the Air Forte’s results were better. I love Air Forte’s spilling over of the hero images, non-square-shaped panels - all of these custom touches are achievable in AZS, but would require a fair bit of more additional functionality.

The change I was most happy with: AZS vignettes are data-driven. The Air Forte vignettes were hard-coded in the executable, whereas AZS stores the vignette data in simple text files. The vignette data for the above AZS example can be read here. The first few lines describe the image positions, and the bracketed blocks describe the panels - how long to linger on the panel, how far to zoom in, what text to display, and so on. To help me out, I wrote a debug tool, “BlendoComic,” that can fine tune the values on-the-fly (press ctrl+F11 to see the debug tools).

I’d love to see someone make their own vignette - poke around AZS’s content folders and try your hand at one!

The Locksmith

Wed, 16 Mar 2011 17:56:34 +0000

By now, everyone who bought Atom Zombie Smasher from blendogames.com should now have received an email with a free key for the Steam version of the game (and if not, email me at brendon@blendogames.com and I’ll sort it out). Getting these keys to these people was a bit more involved than I expected, so I thought I’d write about it.

Here’s what I had:

A long list of email addresses of people who purchased Atom Zombie Smasher from blendogames.com
A long list of Steam codes for Atom Zombie Smasher.

The goal was to send one Steam code to each email address. I began with making a spreadsheet: Column A had Steam codes, Column B had email addresses. I exported this spreadsheet to the .CSV format, which is a basic text file.

I now had a simple, machine-readable .CSV file with Steam codes & email addresses. I then wrote a quick C# program, “KeySender,” that read the .CSV file and emailed a Steam code to each address.

KeySender took very little time to write. It was very basic in functionality and cannibalized enormous chunks of code from Atom Zombie Smasher, notably the Report-a-bug feature (to send emails) and the the text file parser (that reads mod files, vignette files, etc).

After a few test runs with dummy info, I plugged all the customer data into KeySender and hit the “Go” button. And off it went. It was working very diligently, shooting emails with all the pep and vigor of a cold, emotionless robot. Its little progress counter ticked up, up, up…

And then KeySender started barfing.

KeySender now hurled out error messages about failing to send the email message, over and over again. I shut it all down and took a look into KeySender’s innards. I couldn’t find anything wrong with it. No, the root cause was something more sinister: my email host flagged me as a spammer.

I use Gmail for my blendogames.com correspondence. After some digging around, I discovered Gmail has a safeguard that limits how much email you can send in a given time frame. And if you breach that limit, you are locked out of your email account for 24 hours!

And so, my beloved KeySender, with its cursed efficiency, barred me from my own blendogames email account for 24 hours. Oh KeySender, you rascal.

So, next time I do this I’ll have to find another method. Before making KeySender, I was at first thinking of making a web page where the user would input their order data to receive their Steam code. But, I disliked forcing people to dig through their email history, find their order data, punch the data into a website - that’s the opposite of a smooth experience. Secondly, the only way of making absolutely sure all these people get contacted is through their email addresses, so I would’ve been in the same 24-hour-send-limit boat either way.

Anyway, in closing: I forgive you, KeySender.

Atom Zombie Smasher released on Steam

Mon, 14 Mar 2011 20:23:02 +0000

Atom Zombie Smasher is now available on Steam! Here’s the link to its Steam page: http://store.steampowered.com/app/55040/

The Steam version is bundled with both the PC and Mac version, and is complete with a bevy of Steam Achievements to grapple and grope with. And that’s not all! In addition to a lower price, there’s also an extra discount - for one week Atom Zombie Smasher is only $8.99 on Steam.

So what are you waiting for? There are zombies demanding to be smashed.

Bug Hunt

Wed, 09 Mar 2011 09:03:13 +0000

A couple days ago I released a patch for Atom Zombie Smasher that fixed a rather nasty bug. Tracking down and resolving this bug was a fairly long ordeal, so I thought I’d share a bit on how I handle QA as a one-man team.

First of all, a bit of history. When I was working at Pandemic, we had a sizeable QA team. As new features and levels trickled in, QA would comb over them and try their damnedest to break the game in every obscure way possible. One of my tasks as a designer was to make the tutorial levels, so I tended to receive extra helpings of “how is that even possible?” special-case bugs.

Something particularly effective was when QA was integrated into our DLC development. Basically, QA began QA’ing starting from day one of DLC development, and were seated amongst the designers & artists. This resulted in extremely fluid communication, not just from immediate face-to-face talking, but by sheer osmosis of everyone being seated in the same aisle. These simple changes helped make this my favorite development experience at Pandemic, in which we produced a high-quality package ahead of schedule while keeping the bug count absurdly low.

(And QA had the best usernames during multiplayer playtests. I’m looking at you, LindsayRohan and LorenaHobbit.)

I’ve since started Blendo Games, where I’m now a one-man team. I wear the designer hat, programmer hat, artist hat - whatever hat you got, I’ve worn it. From my previous hobby projects, I’ve learned doing QA by yourself is A) silly, and B) doomed to fail. Once a game was released “into the wild,” it amazed me how quickly people found ways to twist and break everything.

And that got me thinking: the general public has an uncanny knack for finding the rarest of bugs, so why not leverage that? Here’s how I implemented it:

Report-a-crash: when a crash occurs, the game sends me an email. The email details the call stack, giving me a reference point for where to start looking in my code.
Report-a-bug: users can write and send me a quick message, accessible via the pause menu. The point of this is to make communication as frictionless as possible. (The flipside of this is forcing the user to quit or alt-tab out of the game, find my email address, fire up the email client, get sidetracked by other emails, etc. By the time I do all that, I’ve already gotten distracted by something shiny outside my porch window.)

It’s not a new idea, but it was new to me! I gave it a trial run in Flotilla. I was leery as to whether people would actually take the time to use the Report-a-bug, but I was taken aback: I got a lot of helpful feedback from a lot of people.

Example! Here’s a Flotilla Report-a-bug message from a helpful stranger:

Subject: ACCEPTED CASINO OFFER BUG

Message: HI, I ACCEPTED THE CASINO’S OFFER TO WORK FOR THEM AFTER I GAMBLED AWAY MY FLEET. UNFORTUNATELY, AFTER DOING THAT I WASN’T ABLE TO GO TO ANY OTHER PLANETS. PRETTY SURE THIS IS A BUG BUT I’LL LET YOU DETERMINE THAT. :) NEEDLESS TO SAY, I’LL BE FIGHTING MY WAY OUT NEXT TIME.

It has worked well. I get bug and crash reports, and within a few hours I’m usually able to release a patch that fixes them. I’ve since continued to use this user-driven system for Air Forte and Atom Zombie Smasher, adding incremental improvements here and there (for one, it now uses normal normal sentence case, so it no longer looks like PEOPLE ARE ALWAYS SHOUTING AT ME).

Which takes me back to the beginning of all this: that one particularly nasty bug in Atom Zombie Smasher. Since AZS was first released, I’ve been getting crash reports relating to the Zed Bait, a weapon used in the game. The crash message’s call stack gave me a general location of where to look, but was vague as to specifics. It’s one thing to know that a bug is happening, but I had no steps as to how to reproduce this bug on my machine.

So, I made a robot. By that, I mean I wrote a very basic component that allowed the game to autonomously play itself. Because my robot was never meant for public consumption, it’s plainly named “StressTester.” The point of StressTester is to bang on one game feature over and over again for hours on end. Here’s the StressTester routine for finding the Zed Bait crash:

Create a new city.
Place a Zed Bait.
Wait 10 seconds and place another Zed Bait.
When the victory/defeat screen appears, return to step 1.

I activated StressTester and went to bed. Next morning, I awoke and discovered StressTester had gained self-awareness. It asked, “do you want to play a game of thermonuclear war?”

I misspoke, that didn’t happen. I awoke next morning and found the game had successfully crashed. I now knew exactly what line of code the game was crashing on and in a couple minutes I fixed the problem. Done and done.

Yes, StressTester was successful in that it led me to the crash solution. But, it fails in that I have no idea what specific steps StressTester took to get to that crash. StressTester has no concept of what it’s doing, it just blindly taps buttons. As a result, I still have no idea how to reproduce that bug.

Nope, you need warm human beings for that, specifically folks trained for QA. In the meantime I’ll make due with what I got!

Atom Zombie Smasher: Steam release date

Mon, 07 Mar 2011 23:19:38 +0000

Atom Zombie Smasher is now available on Steam! Here’s the link to its Steam page: http://store.steampowered.com/app/55040/

So what are you waiting for? There are zombies demanding to be smashed. Save the date! Atom Zombie Smasher will be released on Steam next Monday, on March 14. Anyone who has already purchased Atom Zombie Smasher from blendogames.com can expect to receive a free download key for the Steam version.

I’ve spent the past few weeks adding Steam achievements to the build. There’s a number of them that should be rather challenging. And by that, I mean, I’d be surprised if anyone manages to unlock all of them. I’m quite happy with how the entire game is looking right now - a huge thanks to everyone who has sent in feedback and bug reports!

Blendo News

Planning for Steam Deck Verification

1. Text size

My caveman way of testing this:

2. Button glyphs

Prompt images

Deck check

3. The Whole Dang Game Needs Gamepad Support

The Good News

The Surprisingly Still Good News

Et al

Blendo Merch Store

1. Launch of the Blendo Games merch store

2. Updated Atom Zombie Smasher

Timescale can now be 1%

Can now more easily deselect unit

Vignette fixes

Behind the Scenes UI

Social buttons

Showfloor demoing fix

Crashes will now ask to submit a form

Mac startup issue

Et al

Skin Deep: IGF Nominated

Et al

Skin Deep: Year End Roundup

PC Gamer: Best Immersive Sim

GameSpot: Best PC Games of 2025

GameSpot: Best Cat Game

Green Man Gaming: 10 Best Indie Games of 2025

Slant Magazine: 25 Best Video Games of 2025

GamesRadar: Year in Review 2025

The Guardian: video games you may have missed in 2025

EDGE Magazine: PC Game of the Year Runner-up

Rock Paper Shotgun: Bonus Games of the Year

Rogue: The Roguesies

Eurogamer: The 50 best games of 2025

Eurogamer: readers’ top 50 games of 2025

Eurogamer: Games of 2025

Et al

All about Nas

What is NAS

What does it look like

How do you access it

What software does it use

What’s the deal

Et al

Antibody One

What is this???

1. The human body is crazy

2. What if a game didn’t take 4 years to make

3. I wanted to try out ECS

Thanks

Et Al

Game Release Miscellanea

1. Keyboard layouts

2. Decimals parsing

3. Save folder

4. Crash reporter

5. Code comments

6. Build documentation

7. Profile folder (Steam)

8. Tags (Steam)

9. Separate video settings (Steam)

10. Messageboard setup (Steam)

Et Al

Glitch City thoughts

Et al

Blender Video Editor

Setup

Time to start editing

Adding clips

Moving clips

Resizing clips

Rendering

Set video duration

Render it

Notes

Et al

Skin Deep: Papercraft Cats