On September 27, 2018, I left a comment on Part 4 of this series: “Where is part 5?” One minute later Tiogus replied: “Elias is supposed to finish part 5, thanks.”

He was right. Pieces of this post have been sitting in my head (and in a folder on my laptop called designs) ever since. I’m finally finishing it now for a very good reason: The Descent is coming back. It’s being re-released as Cave Glider, and this time it’s the game we dreamt about in 2014. More on that at the end.

This series is about one question: to build or not to build. Parts 3 and 4 were about code, and about the engines and libraries we should have picked instead of writing everything ourselves. This part is about the other dependency nobody warned us about: art.

(Tiogus promised that the next article would be about Condor Wars Redux. That story is still his to tell.)

2010: a pink wall and a paper plane

This is the oldest screenshot I have of The Descent. It’s November 12, 2010, 11:30 PM. Eclipse is open, the Android emulator is running, and the game is a pink brick wall, two yellow rectangles, a tiny paper plane and a score counter that says 2.

Placeholder art, and honestly, already a game. Remember that paper plane. It comes back.

2011: the digger

As Tiogus told in Part 3, in 2011 the hero became a digger drilling through the layers of the Earth’s crust. We brought in our first freelance designer (the one we called Claudia Pulcher in The Making of The Descent; the pseudonyms stay). She drew a beautiful green drilling machine in seven angles, and backgrounds that got hotter the deeper you dug.

None of it shipped. By August 2011 we were burnt out, Tiogus went back to school, and The Descent went into the freezer.

2014: the gliding man, and a cave full of secrets

When we brought The Descent back from the dead in the spring of 2014, the code side went well: Tiogus built a prototype with Cocos2D, and I moved it to SpriteKit. For once we didn’t write our own engine.

The art side was a different story. Our first mockups still used the old digger, drilling past little hidden caves in the rock. That was the plan: every layer of the earth would hide secrets. A treasure chest, a well full of fish, the gnomes’ kitchen, a secret stash, a buried lab, a snake watching TV, a lava beach with an umbrella, a baby dragon, a dragon’s eye, the seven dragon balls, a buried skeleton wearing a suspiciously familiar green cap. Easter eggs everywhere.

And we knew what we wanted it to look like: pixel art.

This time we tried to do things properly. In May 2014 I wrote a design bible for our new designer: the protagonist (a character we called the “GLIDING MAN”) with exact sprite sizes for each angle, obstacles built out of 2:1 rectangles with minimum and maximum sizes per level, backgrounds on a 12 × 43 grid, and a mockup of how level III would look on an iPhone 4. We even had a spreadsheet, paper_plane.xlsx, cataloguing obstacle patterns: right, left, double, and what follows what.

2014–2015: the no-show year

Our second designer, Quintus Sertorius in the making-of, came on board in April 2014. His first deliveries, in June, were promising: a pilot hanging from a hang glider with red-and-white chevron wings, clouds, obstacles and floating islands.

Then things stalled. In Colombia we have an expression for this: mamar gallo. It means stringing someone along: always joking around, always “almost done”, never quite delivering. From April to the end of July 2014, that’s what we got. Then we took a break of our own until October (that part is on us). From October until the end of February 2015, more of the same: missed dates, silence, files that never came.

When files did come, they didn’t always move us forward. In January 2015, eight months in, we received a completely new direction: a zeppelin, a man riding a bomb, a galleon, a mechanical fish, a tank, a dinosaur skeleton, the Aztec calendar stone, a holy grail. Interesting drawings, but not one finished level, and nothing like the game we had specified.

In February 2015 we parted ways. That made two designers in five years and zero shipped art. Along the way we also paid for artwork that never arrived, money we never saw again.

2015: a trade, and a style we didn’t want

By 2015 we had no budget left for designers. What we had was a skill to trade. I had been doing freelance work for Carlos Forero of Milmentes, so we made a deal: I would help with his website, and in exchange he would do the artwork for The Descent.

Carlos started in earnest in April 2015. Two months later, we had everything: the hero in seven angles, the caverns and the transitions between them, achievement badges and the title screen.

The catch: it wasn’t the style we wanted. It was flat and geometric, and we had dreamt of pixel art. At first we didn’t like it. But it was complete, it was consistent, and it arrived on time, which is more than five years of our “perfect” plans had produced. On June 22, 2015, I clicked Publish in Xcode.

And the hero? A paper plane. Five years, three designers, a digger and a hang glider later, we were back to the paper plane from that 2010 emulator screenshot.

What we had to cut

The easter eggs never made it. There was no budget left for dozens of hand-drawn secret caves, and every week spent on art was another week The Descent wasn’t in the App Store. The game shipped with six caverns and nothing hidden in them. The gnomes, the dragon and the snake watching TV stayed in a folder.

Build or buy, art edition

Looking back, our art story repeats every mistake we made with code:

• Art is a dependency, just like a library. We picked ours the way we picked the Android Canvas library: quickly, hopefully and without a plan B. Pick an artist you can rely on, not just one whose portfolio you like.
• Pay for delivered work, not for promises. Milestones, dates, and payment when the files arrive.
• Decide the style before you hire, and write it down. The design bible was the best thing we did in 2014. It came a year too late.
• Placeholder art is fine. A pink wall and a yellow rectangle were enough to know if the game was fun.
• A finished style beats a perfect one you never get. We didn’t choose flat art. It chose us, and it shipped.

2026: Cave Glider

Ten years later, we finally have what we were missing back then: the resources to build the game we actually dreamt about. The Descent is being re-released as Cave Glider.

The hero is a pilot on a hang glider, the “gliding man” from the 2014 design bible, finally flying. The feel of the original is preserved from the 2015 source code: the seven steps of banking, the descent speeds, the obstacle patterns and the scoring. Around it, the cave grew from six caverns to twenty (and counting), and the easter eggs are back: an explorer stuck headfirst in a narrow passage, a sleeping octopus inside a treasure chest, a tea break under a giant mushroom, Robby the Robot waving from a balcony, and, snagged in a ventilation grille, a small cream-colored paper plane. That one’s a nod to the plane that carried The Descent in 2015.

And to close the loop on this series: we didn’t build an engine this time either. Cave Glider runs on Godot.

It’s in beta testing right now. We’ll share more very soon.

Tiogus, Part 6 is yours.

Today we’re releasing our newest game: a faithful web port of TetriNET 1.13 that runs right in your browser. No install, no finding a server on EFnet, no port forwarding. Create a room, send the invite link to up to five friends, and start dropping blocks on each other.

▶ Play TetriNET now

Faithful means faithful

We didn’t want “a Tetris game inspired by TetriNET”. We wanted the game. So we reverse-engineered the original TETRINET.EXE (a Delphi 2 binary from 1997) and rebuilt it from the disassembly:

• The rules, timings, randomness and network messages follow the original code. Pieces spawn the way 1.13 spawned them, gravity ticks at the same 1010-ms-minus-10-per-level rate, and even Delphi’s random number generator is reproduced.
• The windows are generated from the original Delphi form layouts, and the original graphics, sounds and music are used.
• The quirks stay. Every weird thing that made 1.13 feel like 1.13 is still there, on purpose. A few of our favorites:
  • The readme says levels cap at 100. The binary never checks, so they don’t.
  • Soft drop is fixed at 100 ms, so from level 92 on, pressing ↓ actually makes your piece fall slower.
  • Random Blocks Clear picks 10 random cells, empty ones included, so sometimes it clears nothing at all.
  • Clear Special Blocks doesn’t remove specials. It turns them into random colours.
  • You can attack your own teammates. We know. We kept it.

Every one of these was checked against the disassembly, and each one is documented. The list of original quirks we kept, and the handful of things we changed, lives in the project’s notes.

Two ways to play: Modern and Legacy

The same engine and the same server power two completely different interfaces, and players on either one can share a room.

Modern mode is a neon-arcade makeover: rooms with invite links, a lobby with partyline chat, the rules editor and the win list, plus effects and our own synthesized sound and music.

Legacy mode is the 1997 Windows interface, rebuilt pixel for pixel from the original forms, down to the StormCat Productions splash screen, the gray bevels and the “Attacks/Defenses” log.

What’s different

Moving a Windows game where one player hosted the server into browsers took a few changes:

• The server is a small Node process and everyone connects over WebSockets. The message strings are the original’s.
• The moderator (the first player, marked with * just like in 1.13) also gets the server operator’s powers: game settings, block occurrence, kicking players and resetting the win list.
• Solo practice. You can start a game alone to warm up. It ends when you top out.
• The server checks who’s talking. In 1.13 any client could send messages pretending to be another player. Not anymore.
• Music. Browsers don’t come with a MIDI synth, so the original TETRINET.MID plays through a tiny synthesizer we wrote for the web.

Still on the to-do list: the ban list, theme (.tnp) switching, and letting real 1.13 clients connect over TCP. The protocol is already there.

How to play

1. Go to tetrinet.helldoradoteam.com, pick a nickname and click Create room.
2. Send the invite link to up to five friends.
3. Clear lines to collect special blocks into your inventory. Press 1–6 to fire your first special at that player (your own number uses it on yourself) and D to discard it.
4. The last player (or team) standing wins. The top three score 3, 2 and 1 points on the win list.

Prefer the old look? Jump straight into Legacy mode.

Huge thanks to St0rmCat for creating TetriNET back in 1997. This port exists because we loved the original. Now go find five friends and send them a Nuke Field.

It’s been kind of a long development cycle but we decided to launch this release with some features which include the following:

1. Update to ARCore 1.20
2. Added support for OpenGL ES 3.0
3. Added Push Notifications
4. New monster: Added the Cacodemon!
5. Added ability to toggle God Mode in the Cheats section under the Settings menu
6. Made some changes to spawn pickup items closer to player to lower the difficulty
7. Capped the rendering framerate to resolve some FPS inconsistencies
8. HUD change: Added screen flash effect when picking up items
9. Fixed some crashes causing app instability

Here’s a preview of an early Alpha version of v2.3 that shows the Cacodemon in action:

We haven’t made a blog post on other releases after v2.0 (5 months ago!) so here’s what we’ve incorporated since then:

v2.2 - v2.2.3

1. Fixed some issues with OpenGL alpha blending
2. Added Firebase Crashlytics to debug an OpenGL Shader compilation issue in some affected devices

v2.1

1. Updated to ARCore 1.19
2. Enabled Depth API Depth Occlusion for supported devices
3. Made some rendering frame rate tweaks
4. Made a change to spawn monsters at least 2 meters away from the player

Download v2.0 now!

We added support for floating monsters (Lost Souls, Cacodemons, etc.) however v2.0 only spawns Lost Souls. We also added the Chainsaw due to popular demand, so you can saw “Pinkies” to the tune of I Sawed Demons.

Adding the Chainsaw required some changes to the sound effects implementation, so we refactored this code quite a bit. The Vanilla Doom code handles the playing and stopping of sounds, and the unique sound effects of the Chainsaw make use of this, particularly the switching between the idle, attack and hit frames of the Chainsaw. So we had to do some work in the sound code to replicate this same behavior in ARThings. We also updated ARCore to v1.17 in this version.

Anyways below are 2 videos that showcase these features:

We recently released v1.9 of ARThings, which included a couple of new features (addition of a new monster and weapon) and some under-the-hood improvements.

We also introduced 3 new achievements and some game difficulty balancing. We discovered some major bugs (pre v1.9) with monster spawning that made the game incredibly difficult - monsters spawn too frequently, and these bugs are fixed in v1.9.

Below is a clip of a pre-alpha version of v1.9 showcasing a rough implementation of the Plasma Gun:

Below are the full release notes, we hope you enjoy!

1. Added spawning of Baron of Hells
2. Added spawning of Plasma Gun when killing Baron of Hells
3. Reduced the frequency of Chaingunners spawning
4. Added gib animation for Zombies, Imps and Shotgun Guys
5. Added some logic to make missiles explode when too far
6. Fixed thrust and friction implementation that was not working before
7. Added 3 new achievements - Picking up Plasma Gun, Killing Baron of Hell (Boss) and Gibbing a monster
8. Added spawning of Blue Armor
9. Added spawning of clips, 4 shotgun shells and cells
10. Fixed bug of monsters spawning when they’re not supposed to

This is a light release and the last one before the start of 2020. We introduced 2 Leaderboards:

• Most kills in a single round.
• Total kills for all rounds.

We also display Top kills in a single round in the HUD (displayed in green color).

I took a video of v1.8 today, which includes footage of unlocking some achievements - including unlocking and picking up the Super Shotgun before I was mowed down by demons:

1. Ability to test in a Android debug app (signed with debug certificate) with unpublished achievements using a tester account.

2. Ability to test in a Android release app (signed with release certification), fully signed by Google Play with a published Game Services configuration.

Google provides some documentation on how to setup Game Services for Android. This documentation clearly outlines the configuration process:

1. Setting Up Google Play Game Services
2. Getting Started with Play Game Services for Android

However, despite these guides some developers might face some stumbling blocks along the way. After dealing with this myself, I’ve outlined below some general guidelines on how accomplish the configuration for both Android debug and release apps published to Google Play.

Testing in Debug Mode

To test in debug mode, you need to create a Linked App inside the Game Services configuration that corresponds to your Android debug app. The Client ID used by this Linked App needs to use the SHA1 fingerprint of the Android debug keystore (debug.keystore). Typically, for Windows users this keystore is located in the following path:

C:\Users\{your Windows username}\.android\debug.keystore

To find the fingerprint of this keystore all you need to do is run the following in the command prompt:

keytool -list -v -keystore "C:\Users\{your Windows username}\.android\debug.keystore" -alias androiddebugkey -storepass android -keypass android

This command will spit out the SHA1 fingerprint of the certificate:

Certificate chain length: 1

Certificate[1]:

Owner: C=US, O=Android, CN=Android Debug

Issuer: C=US, O=Android, CN=Android Debug

Serial number: 1

Valid from: Thu Jul 07 15:17:58 EDT 2016 until: Sat Jun 30 15:17:58 EDT 2046

Certificate fingerprints:

         SHA1: [SHA1 fingerprint]

         SHA256: [SHA256 fingerprint]

Signature algorithm name: SHA1withRSA

Subject Public Key Algorithm: 1024-bit RSA key

Version: 1

You can then copy paste the SHA1 fingerprint into the SHA1 fingerprint of the Client ID needed by Game Services and you should be good to go.

If for some reason you can’t find the keystore there’s another way to find out the SHA1 fingerprint based on the Android app’s generated apk. The Android SDK Build Tools come with a nice little tool called “apksigner” that can be accessed through the command line via the following path

C:\Users\{your Windows username}\AppData\Local\Android\sdk\build-tools\{version}

The “apksigner” tool takes the path of an apk and returns information about the certificate that the apk was signed with. Below is an example of the command line:

apksigner verify --print-certs C:\{Your apk path}\app-debug.apk

This will spit out the SHA256, SHA1 and MD5 fingerprints of the keystore the apk was signed with:

Signer #1 certificate DN: C=US, O=Android, CN=Android Debug

Signer #1 certificate SHA-256 digest: [SHA-256 fingerprint]

Signer #1 certificate SHA-1 digest: [SHA-1 fingerprint]

Signer #1 certificate MD5 digest: [MD5 fingerprint]

Testing in Release Mode

The above instructions also apply for Release Mode, but with one small change: You need to use the SHA1 fingerprint of the certificate that Google Play uses to sign the release apk with in Google Play (called the “App signing certificate”, NOT the certificate you use to bundle your apk in release mode (called the “Upload Certificate”) from the “Build -> Generate Signed Bundle / APK” option in Android Studio.

Getting the SHA1 fingerprint of the App signing certificate is very simple. Go to Google Play Console, click on your app and navigate to the “Release Management -> App signing” section. In the “App signing certificate” section (screenshot below), use the SHA1 certificate fingerprint (masked in the screenshot below) for your release app Client ID.

The important thing here is to use SHA-1 fingerprint of the App signing certificate, NOT the Upload certificate.

In a nutshell, here’s the overall approach:

1. Testing Game Services for debug Android: Create a Linked App using using a Client ID using the SHA1 fingerprint of Android’s default debug keystore (debug.keystore).
2. Testing Game Services for release Android app in the Play Store: Create a Linked App using a Client ID using the SHA1 fingerprint of the “App signing certificate”.

After a small period of development hell, we finally released ARThings v1.6 last Saturday. This release is a big step into making ARThings more of a game experience versus just a mere technical demo. We’ve still got a long way to go, but we’re ok with taking baby steps and experimenting with new features.

The main addition in v1.6 is the integration of Google Play Game Services, supporting the following 3 achievements:

1. Killing 30 monsters in a row without dying
2. Picking up the Chaingun
3. Picking up the Super Shotgun

Below are the full v1.6 release notes:

1. ARCore 1.13 update
2. Google Play Game Services integration with 3 achievements 
3. AR Session filter -> limited camera capture rate to 30fps and prevented the use of depth sensor
4. Added the Super Shotgun (awarded as a gift but won't give you spoilers on how to get it!)
2. HUD changes

Version 1.6 ended up having a bug with Google Sign In, so we made an emergency v1.7 release with the following changes:

1. ARCore 1.14 update
2. Google Play Game Services update to 19.0.0
3. Disabled AR Session filtering -> camera capture rate and use of depth sensor is not limited anymore
4. Settings menu -> Added Player Id to Signed In message
5. Settings menu -> Added icon to achievement button
6. Settings menu -> Positioned Sign Out button at the bottom
7. Updated Sign In error dialogs to display more informational messages
8. Sign out -> Updated sign out handling code
9. Game Services -> Released achievements buffer to fix memory leak
10. Fixed memory leaks in Game Services static member variables

Below is a short video of v1.7 - it doesn’t showcase all the features of this release (like the Super Shotgun) since I was killed repeatedly before I was able to unlock it but I’ll post a video of the Super Shotgun soon!

We are happy to announce the official release of FilmScout for iOS and Android.

FilmScout lets you keep track of your favorite filmmaker’s projects. You can search for information on your favorite movies and TV shows, check the filmmaking team, explore their works, and follow them to keep track of their upcoming projects.

Right now, you can track filmmakers in the following roles:

• Director
• Screenwriter/Writer
• Composer
• Cinematographer/Director of Photography
• Editor

Feel free to write to us with any feedback you have!

SNS messages come in 2 types:

• SubscriptionConfirmation: Is sent when a subscription is created to confirm that the endpoint is up an running. The confirm_subscription method handles this.
• Notification: Once the subscription is confirmed, all the following messages will be of this type. These are the messages that are sent to a topic and then fanned out to every subscriber out there.

The verify_request_authenticity method is called first to verify the authenticity of the SNS message. It checks that the message is not empty and verifies its origin using the MessageVerifier class. Finally, the create method parses the message content accordingly.

I hope this can be of great help to everyone out there. Feel free to comment if you have any questions or feedback.

# frozen_string_literal: true

# Notifications coming from SNS
class NotificationsController < ActionController::Base
  before_action :verify_request_authenticity

  # @url /notifications
  #
  # @action POST
  #
  # Broadcasts a SNS message to an ActionCable channel
  #
  #
  def create
    case message_body['Type']
    when 'SubscriptionConfirmation'
      confirm_subscription ? (head :ok) : (head :bad_request)
    when 'Notification'
      message = JSON.parse(message_body['Message'])
      BroadcastExecutionNotificationJob.perform_later(message)
      head :ok
    end
  end

  private

  def verify_request_authenticity
    head :unauthorized if raw_post.blank? || !message_verifier.authentic?(raw_post)
  end

  def raw_post
    @raw_post ||= request.raw_post
  end

  def message_body
    @message_body ||= JSON.parse(raw_post)
  end

  def message_verifier
    @message_verifier ||= Aws::SNS::MessageVerifier.new
  end

  def confirm_subscription
    AWS_SNS_CLIENT.confirm_subscription(
      topic_arn: message_body['TopicArn'],
      token: message_body['Token']
    )
    true
  rescue Aws::SNS::Errors::ServiceError => e
    Rails.logger.info(e.message)
    false
  end
end

Let’s recount Helldorado Team’s various attempt at WAD building for a moment:

• Exhumed - began in 2012 as a single map for ZDoom. Much more progress was made compared to Confessions but after 3 weeks the team lost interest. Development resumed in December 2018 but yet again scope creep derailed the project when the team tried to incorporate countless features to showcase GZDoom advanced capabilities. The project was shelved by end of December.
• Septic Shock - After Exhumed, the development team decided to keep it simple. The goal was to build a single Boom-compatible map for Doom 2 and avoid the development pitfall every Doom mapping newcomer faces - getting carried away with ZDoom features. Development began in January 1st 2019 but the project was put on hold in mid February due to other priorities.

Despite the aforementioned facepalms, we’re proud to celebrate the breaking of this vicious cycle. Today we release Helldorado Team’s first Doom WAD - The Breach. It’s a Boom-compatible 2-map WAD for Doom 2. You can download the WAD by downloading the breach.rar file from the original Doomworld thread:

Doomworld: The Breach - 2 Techbase maps

How to play? If you are newcomer to Doom and its source ports, you can download a Doom source port such as PrBoom+ or GZDoom and drag and drop breach.wad over to the source port executable. The WAD requires Doom 2 so make sure Doom2.wad is in the same folder as the source port executable.

Screenshots below:

• Added the Imp monster
• Added player damage and player death, plus player’s ability to retry after dying
• Random spawning of health and armor items
• Some changes to the HUD

Check out some of the action below, any feedback is welcome for v1.5!

Download v1.4 from Google Play now!

Users have been clamoring for the introduction of health and player damage, so that’s what we primarily focused on for v1.4, in addition to the introduction of another monster - the Imp. We also introduced some minor HUD changes to display Health and Armor.

Check out some of the action from v1.4 (to be released soon) below!

This is a minor release with one major addition - the Shotgun Guy monster. The plan was also to add another weapon - the Super Shotgun. However this plan was too ambitious and the feature discarded for the time being. Another addition is the update to ARCore 1.10 - we hope this enhances the overall AR experience.

Thinking ahead we might add one more monster in 2019 and focus more on enhancing the gameplay experience.

Download v1.3 now!

Having played Ultimate Doom recently, I was captivated by the simplicity and seamless flow of E1’s techbase levels. Romero’s Knee-Deep in the Dead levels breathe layout, something not found for the most part in Sandy Petersen’s E2 levels, though they get better (E2M6: Halls of the Damned is a classic) as the player progresses through The Ultimate Doom’s The Shores of Hell.

Below is a compilation of Romero’s level design tips, including some insights from his “Devs Play” playthrough of E1M1: Hangar.

Level Design Tips

Always change floor height when changing floor textures

Nobody likes the basic square rooms with homogeneous ceiling heights. Varying floor and ceiling heights for different rooms are more pleasing to the eye.

Use special border textures between different wall segments and doorways

This is extremely important and distinguishes amateurish levels from high quality maps. Texturing shouldn’t be treated as applying wallpaper to floors, ceilings and walls, but rather as placing different materials on a scene (rock, stone, metal, wood, etc).

Be strict about texture alignment

All mappers should be obsessive about texture alignment, except in certain situations, for example - misaligned textures on a wall that leads the player toward a secret area.

Use contrast everywhere in a level between light and dark areas, cramped and open areas

Contrast also applies to sectors with different floor and ceiling heights.

Make sure that if a player could see outside that they should be able to somehow get there

Be strict about designing several secret areas on every level

If you build a map without at least one secret area, is it even a level?

Make the level flow so the player will revisit areas several times so they will better understand the 3D space of the level

Create easily recognizable landmarks in several places for easier navigation

Golden rule of level design - the “Horseshoe” layout

Romero mentions adopting a non-linear level design paradigm. The rule is simple, according to the Gamasutra article - make sure the player is likely to look at every wall of a room. This wouldn’t have been possible had the level presented the player with a linear path. This pattern is common in every first level of Doom, Hexen and Quake as well.

Valve Software also produced some similar thought-leadership in this area documented in their developer portal as the Loop layout element. In this layout, the “Loop” guides the player back to a previously explored area of the level, and while maintaining strict linearity, provides the illusion of non-linearity and progression.

Build your first level last

Romero started E1M1 early in the development of Doom, but was the last level that he completed. In this way he was able to use his learnings from the design of all other Doom levels and apply them to the first. In this progression, the first couple of levels are the weaker ones (sans the first), middle ones get better, and culminating with the stronger levels.

Don’t constrain player movement (aka don’t let detailing get in the way of gameplay)

Tom Hall wanted to detail E1M1 with movable chairs, but the chairs ended up interfering with smooth player movement. When mapping, consider the trade-off between focusing on detailing versus pure gameplay mechanics. The former can be sacrificed for the sake of gameplay.

Use fullbright textures

Use fullbright textures when appropriate. Fullbright textures ignore the surrounding light in a scene and render at full brightness to create the appearance of emitting their own light.

If you want to see out Romero’s playthrough of E1M1, where he offers his insightful level design tips, check out the video below:

Doomworld’s 2018 Cacowards recently came out and with it a series of amazing articles from Doomworld. You can check them out below

1. 2018 Cacowards: The quintessential Cacowards, celebrating 25 years of Doom. Also included is an amazing write-up on Erik Alm’s legacy as a mapper and how his enduring vision influenced other legendary projects.
2. Top 100 Most Memorable Maps: Curated list of the top 100 Doom maps produced by the Doom community. Either as single-map contributions or cherry-picked maps from multi-level WADs.
3. Top 25 Missed Cacowards: Projects that didn’t win a Cacoward but who looking back, should have been awarded one.

It’s been 12 years since Helldorado Team (formerly Brain Dead Studios, formerly Elioncho’s Engine team, formerly the Condor Team) announced the development of a Doom WAD - the never released Confessions from the Flesh. But today, after more than 10 years of projects sinking down the drain, prototypes never seeing the light of day, and other tech demos lost to numerous formatted hard drives, we can finally announce the release of our first 11-level Doom WAD (wow, it only took a decade): Auferstehung 2.

Auferstehung 2 is the unofficial sequel and homage to Nazi Auferstehung, named the Worst WAD of 2006 by Doomworld.

And now, from the depths of the Doom community a similar turd emerges, albeit not as worse, but still pretty bad. Following the footsteps of the predecessor’s creator (who used Slige), Helldorado Team leveraged Oblige to produce the 11 procedurally generated levels of Auferstehung 2.

Download Auferstehung 2!

Levels:

MAP01: Enter the Dominion
MAP02: The Prison of Despair
MAP03: Horrendous Temple
MAP04: Blood Shrine of the Beast
MAP05: The Nukage Shaft
MAP06: Thermal Terminal
MAP07: Pain from the Base
MAP08: Lockdown
MAP09: The Crossroads of Menace
MAP10: Arson Anthem
MAP11: Palace of Danger

Special thanks to:

• Andrew Apted for creating Oblige and making this project possible
• Dark Exodus for Nazi Auferstehung
• id Software for Doom 2
• Elioncho for emotional support

Tools used:

• GZDoom Builder
• Slade 3
• GZDoom (for playtesting)

How to play:

1. Drag and drop auferstehung2.wad into the .exe of your favorite Doom Source Port (for example GZDoom, Zandronum, etc). Boom-compatible port recommended.
2. Make sure Doom2.wad is in the same folder as the Source Port’s .exe file

We made some tweaks over the past couple of weeks and finally ARThings v1.2 is out. Click on the cool Doomguy below to check it out:

Here’s a laundry list of the updates we made:

1. Updated HUD graphics - Updated fire button graphics and added a new “switch weapon” button
2. Removed the ability to spawn monsters by tapping on planes. This was an experimental feature pre-v1.2 that has now been removed
3. Removed the tracking of vertical planes such as walls. This was not needed as monsters spawn on top of upward facing horizontal planes (such as floors).
4. You can now pick up and use the Chaingun
5. Updated spawner to spawn Shotgun and Chaingun ammo when you’re low on ammo
6. Updated spawner to spawn 3 different types of monsters: 1) Zombiemen, 2) Chaingunners and 3) Demons
7. Dead Zombiemen drop clips when dead
8. Dead Chaingunners drop Chainguns when dead
9. Added other effects such as blood and teleport fog when spawning monsters
10. Other bug fixes

Also, here’s a video of some “in-game” action from v1.2:

Picking a Doom Source Port

To port the Doom AI game logic we had to pick a Doom source port. We narrowed down the list to 2 contenders:

• Linux Doom
• ZDoom

There’s pros and cons with each of these but ultimately we settled with Linux Doom. By doing so we could deal with less complexity. The ZDoom codebase is much more modernized but quite extensive - it not only runs Doom but also Heretic, Hexen, Strife and other “Doom clones”. Learning ZDoom meant going through a much more extensive and technically sophisticated codebase. ZDoom’s AI and gameplay code architecture was revamped to include ACS, a flexible scripting system that developers could use to extend gameplay and AI behavior without having to write additional code to be compiled with the master codebase.

Having settled with Linux Doom, we unzipped the codebase and immediately faced with an even bigger challenge - working with legacy code. Doom was written in the early 90s, and as such the code was meant to push the limits of the hardware of that era (i386, i486, etc). If you get some time, I recommend reading Fabien Sanglard’s Game Engine Black Book, he does an amazing job describing the technical limitations id Software’s faced when developing Wolfenstein 3D. These limitations drove the technical direction of both the Wolfenstein 3D and Doom codebase.

So we went deep into the Doom source code. After studying the source code for a couple of days we encountered these technical pain points:

1. Reading C - Doom’s code is not Object Oriented. Functions are grouped into source files based on functionality. The code can be hard to come to terms with if you’ve been writing OO code for a while.
2. Absence of Floating Point arithmetic - To cope with CPU’s lack of floating point arithmetic during the mid-90s Doom uses Fixed point arithmetic. The gist of this is that floating points are represented using 32-bit integers. 16 bits for the integer portion and the remaining 16 for the fractional part.
3. Angles are represented using Binary Angle Measurement (BAM) - This is new territory if you’re used to storing angles as doubles (or floats) when working with computer graphics or trigonometric calculations. in BAM, angles are represented using the full range of values of a 32-bit unsigned int. The challenge with this is that some languages do not support unsigned int as a primitive data type (Java for instance). You have to provide your own wrapper functions when performing computations that result on unsigned integers. Another challenge with BAM is that to perform trigonometric calculations you have to provide your own special purpose sin/cos/tan lookup tables.
4. Usage of C function pointers - These are used heavily in the code, sometimes to mimic Polymorphism. C function pointer code can be hard to port with the right architectural approach, especially if the language you are porting to implements similar functionality using a different programming paradigm. Again, using the Java example you can accomplish this using Lambda expressions and Method References.

The Basics - Understanding Mobjs and States

Let’s now get to the basics. To understand how the Doom AI works we need to understand how objects, or Things (mobjs), are represented in the codebase. Things are monsters, items, pickups, fireballs, projectiles, or anything that is represented by a sprite in the game. For example, when you shoot a monster and you see a blood effect rendered as a sprite, the blood effect is a mobj.

Things are represented by the mobj_t struct defined in p_mobj.h. mobjs and have attributes such as (x,y,z) position, (x,y,z) momentum (used to simulate physics) and many other object properties.

Side note: The Doom coordinate system treats Z as the vertical “up” axis, as opposed to the Y axis. If you are coming from the OpenGL world this might be hard to stomach.

For the purposes of AI, a mobj (I’ll be using mobj and Thing interchangeably) functions as a finite state machine. Through its lifespan a mobj will cycle through various states as determined by the core engine AI logic. A mobj’s current state is kept as a reference to a State object:

state_t* state;

The declaration of state_t is defined in info.h and all state definitions in the game are stored as a global array:

typedef struct
{
  spritenum_t	sprite;
  long		frame;
  long		tics;
  // void	(*action) ();
  actionf_t	action;
  statenum_t	nextstate;
  long	        misc1, misc2;
} state_t;

extern state_t	states[NUMSTATES];

The state object has the following attributes and characteristics:

• sprite - Sprite to use to render the mobj for this state
• frame - Animation frame to use for this state
• tics - How many tics to run this state for (We will explain the concept of tics in the next section)
• action - Pointer to the function to run when transitioning to this state
• nextstate - State to transition to when this state is over
• misc1 - Miscellaneous attribute
• misc2 - Miscellaneous attribute

The list of all state numbers for all the different types of mobjs in the game are defined in the statenum_t enum in info.h.

To decide what states correspond to each mobj type there’s a structure called mobjinfo_t in info.h that contains this information. The engine stores this as a global array as well:

typedef struct
{
    int	doomednum;
    int	spawnstate;
    int	spawnhealth;
    int	seestate;
    int	seesound;
    int	reactiontime;
    int	attacksound;
    int	painstate;
    int	painchance;
    int	painsound;
    int	meleestate;
    int	missilestate;
    int	deathstate;
    int	xdeathstate;
    int	deathsound;
    int	speed;
    int	radius;
    int	height;
    int	mass;
    int	damage;
    int	activesound;
    int	flags;
    int	raisestate;
} mobjinfo_t;

extern mobjinfo_t mobjinfo[NUMMOBJTYPES];

Let’s provide an example with one of the Doom monsters, the Zombieman.

Here’s how the Zombieman’s mobjinfo is defined in the info.c file. Note that the Zombieman’s mobj type is MT_POSSESSED:

mobjinfo_t mobjinfo[NUMMOBJTYPES] = {
   .
   .
   .
   {
	// MT_POSSESSED
	3004,		// doomednum
	S_POSS_STND,	// spawnstate
	20,		// spawnhealth
	S_POSS_RUN1,	// seestate
	sfx_posit1,	// seesound
	8,		// reactiontime
	sfx_pistol,	// attacksound
	S_POSS_PAIN,	// painstate
	200,		// painchance
	sfx_popain,	// painsound
	0,		// meleestate
	S_POSS_ATK1,	// missilestate
	S_POSS_DIE1,	// deathstate
	S_POSS_XDIE1,	// xdeathstate
	sfx_podth1,	// deathsound
	8,		// speed
	20*FRACUNIT,	// radius
	56*FRACUNIT,	// height
	100,		// mass
	0,		// damage
	sfx_posact,	// activesound
	MF_SOLID|MF_SHOOTABLE|MF_COUNTKILL, // flags
	S_POSS_RAISE1	// raisestate
   },
   .
   .
   .
};

The attributes in the mobjinfo object define the states to transition to and the sound effects to play for a particular mobj type when entering the following core mobj states handled by the engine:

• Spawn State - state to transition to when the mobj is spawned in the game. This is the “idle” state where the monster just stands and does nothing, checking its field of view until it spots a player to chase and attack.
• See State - state to transition to when the mobj spots an enemy (in this case the player) and should chase it. Inside the code this is sometimes referred to as the “Chase” state.
• Pain State - state to transition to when the mobj takes damage
• Melee State - state to transition to when the mobj is ready to perform a close range melee attack. Only applies to mobjs that perform melee attacks. For the Zombieman, notice that the meleestate attribute is “0”, which corresponds to the NULL state, since the Zombieman doesn’t have a melee attack.
• Missile State - state to transition to when the mobj is ready to perform a ranged attack. Only applies to mobjs that perform ranged attacks such as a Zombieman firing his rifle or a Cacodemon belching a fireball.
• Death State - state to transition to when the mobj is killed
• XDeath State - state to transition to when the mobj is killed via explosion (gibbed)

Now let’s look at the complete list of Zombieman state definitions as defined in info.c:

state_t	states[NUMSTATES] = {   
    .
    .
    . 
    {SPR_POSS,0,10,{A_Look},S_POSS_STND2,0,0},	// S_POSS_STND
    {SPR_POSS,1,10,{A_Look},S_POSS_STND,0,0},	// S_POSS_STND2
    {SPR_POSS,0,4,{A_Chase},S_POSS_RUN2,0,0},	// S_POSS_RUN1
    {SPR_POSS,0,4,{A_Chase},S_POSS_RUN3,0,0},	// S_POSS_RUN2
    {SPR_POSS,1,4,{A_Chase},S_POSS_RUN4,0,0},	// S_POSS_RUN3
    {SPR_POSS,1,4,{A_Chase},S_POSS_RUN5,0,0},	// S_POSS_RUN4
    {SPR_POSS,2,4,{A_Chase},S_POSS_RUN6,0,0},	// S_POSS_RUN5
    {SPR_POSS,2,4,{A_Chase},S_POSS_RUN7,0,0},	// S_POSS_RUN6
    {SPR_POSS,3,4,{A_Chase},S_POSS_RUN8,0,0},	// S_POSS_RUN7
    {SPR_POSS,3,4,{A_Chase},S_POSS_RUN1,0,0},	// S_POSS_RUN8
    {SPR_POSS,4,10,{A_FaceTarget},S_POSS_ATK2,0,0},	// S_POSS_ATK1
    {SPR_POSS,5,8,{A_PosAttack},S_POSS_ATK3,0,0},	// S_POSS_ATK2
    {SPR_POSS,4,8,{NULL},S_POSS_RUN1,0,0},	// S_POSS_ATK3
    {SPR_POSS,6,3,{NULL},S_POSS_PAIN2,0,0},	// S_POSS_PAIN
    {SPR_POSS,6,3,{A_Pain},S_POSS_RUN1,0,0},	// S_POSS_PAIN2
    {SPR_POSS,7,5,{NULL},S_POSS_DIE2,0,0},	// S_POSS_DIE1
    {SPR_POSS,8,5,{A_Scream},S_POSS_DIE3,0,0},	// S_POSS_DIE2
    {SPR_POSS,9,5,{A_Fall},S_POSS_DIE4,0,0},	// S_POSS_DIE3
    {SPR_POSS,10,5,{NULL},S_POSS_DIE5,0,0},	// S_POSS_DIE4
    {SPR_POSS,11,-1,{NULL},S_NULL,0,0},	// S_POSS_DIE5
    {SPR_POSS,12,5,{NULL},S_POSS_XDIE2,0,0},	// S_POSS_XDIE1
    {SPR_POSS,13,5,{A_XScream},S_POSS_XDIE3,0,0},	// S_POSS_XDIE2
    {SPR_POSS,14,5,{A_Fall},S_POSS_XDIE4,0,0},	// S_POSS_XDIE3
    {SPR_POSS,15,5,{NULL},S_POSS_XDIE5,0,0},	// S_POSS_XDIE4
    {SPR_POSS,16,5,{NULL},S_POSS_XDIE6,0,0},	// S_POSS_XDIE5
    {SPR_POSS,17,5,{NULL},S_POSS_XDIE7,0,0},	// S_POSS_XDIE6
    {SPR_POSS,18,5,{NULL},S_POSS_XDIE8,0,0},	// S_POSS_XDIE7
    {SPR_POSS,19,5,{NULL},S_POSS_XDIE9,0,0},	// S_POSS_XDIE8
    {SPR_POSS,20,-1,{NULL},S_NULL,0,0},	// S_POSS_XDIE9
    {SPR_POSS,10,5,{NULL},S_POSS_RAISE2,0,0},	// S_POSS_RAISE1
    {SPR_POSS,9,5,{NULL},S_POSS_RAISE3,0,0},	// S_POSS_RAISE2
    {SPR_POSS,8,5,{NULL},S_POSS_RAISE4,0,0},	// S_POSS_RAISE3
    {SPR_POSS,7,5,{NULL},S_POSS_RUN1,0,0},	// S_POSS_RAISE4
    .
    .
    .
};

Before diving deeper into these states, let’s go back and cover the tics concept that I mentioned briefly.

Gametics and Thinkers

Doom doesn’t manage the concept of game updates in terms of milliseconds since the last game update. A gametic is the equivalent of a single game update - basically one iteration of the Doom game loop. During this iteration the engine performs one frame update and executes basic game loop activities such as capturing input, executing gameplay logic and rendering to the framebuffer.

Doom’s engine is clamped at 35 tics per second (35 iterations of the Doom game loop every second), so a single tic should take no longer than 1000/35 = 28.57 milliseconds. This is the behavior of Vanilla Doom, however some source ports have removed this technical restriction and allow uncapped framerates.

To understand the game loop, lets look at some code. The Doom main game loop makes a call to the G_Ticker() function in g_game.c. A call to P_Ticker() (defined in p_tick.c) is made as long as the game is running a level (gamestate=GS_LEVEL):

//
// G_Ticker
// Make ticcmd_ts for the players.
//
void G_Ticker (void) 
{    
    .
    .
    .
    // do main actions
    switch (gamestate) 
    { 
      case GS_LEVEL: 
	P_Ticker (); 
	ST_Ticker (); 
	AM_Ticker (); 
	HU_Ticker ();            
	break; 

      case GS_INTERMISSION: 
	WI_Ticker (); 
	break; 

      case GS_FINALE: 
	F_Ticker (); 
	break; 

      case GS_DEMOSCREEN: 
	D_PageTicker (); 
	break; 
    }
}

P_Ticker() handles game updates for the following:

• All Players in the game (via a call to P_PlayerThink)
• Mobjs (via call to P_RunThinkers)
• Other things that we don’t care about right now

//
// P_Ticker
//

void P_Ticker (void)
{
  .
  .
  .
  for (i=0 ; i<MAXPLAYERS ; i++)
	  if (playeringame[i])
	      P_PlayerThink (&players[i]);

  P_RunThinkers ();
  P_UpdateSpecials ();
  P_RespawnSpecials ();
  .
  .
  .
}

Let’s digest all of this for a moment. You might think that to run game updates for all mobjs in the game you would just call an update() method passing the mobj as a parameter and do this for every single mobj in the game.

Doom handles game updates for mobjs a bit differently. Every mobj in the game has a Thinker object that manages the execution of game updates per frame for that specific mobj. The structure of a Thinker object looks like this (declared in d_think.h):

// Doubly linked list of actors.
typedef struct thinker_s
{
    struct thinker_s*	prev;
    struct thinker_s*	next;
    think_t		function;

} thinker_t;

As mobjs spawn in a level, their Thinkers are created and added to a doubly linked list (hence the prev and next pointers). This happens in the P_SpawnMobj() function (in p_mobj.c):

//
// P_SpawnMobj
//
mobj_t*
P_SpawnMobj
( fixed_t	x,
  fixed_t	y,
  fixed_t	z,
  mobjtype_t	type )
{
    .
    .
    .

    mobj->thinker.function.acp1 = (actionf_p1)P_MobjThinker;	
    P_AddThinker (&mobj->thinker);

    return mobj;
}

Likewise, as mobjs are removed from a level (for example a projectile mobj hits a monster and needs to be removed after the explosion), their Thinkers are removed from the doubly linked list (P_RemoveMobj function in p_mobj.c):

//
// P_RemoveMobj
//
mapthing_t	itemrespawnque[ITEMQUESIZE];
int		itemrespawntime[ITEMQUESIZE];
int		iquehead;
int		iquetail;

void P_RemoveMobj (mobj_t* mobj)
{
    .
    .
    .

    // free block
    P_RemoveThinker ((thinker_t*)mobj);
}

Every Thinker object has a reference to a function (attribute think_t function) that executes an mobj’s game updates. This function is P_MobjThinker() in p_mobj.c:

//
// P_MobjThinker
//
void P_MobjThinker (mobj_t* mobj)
{
   // We'll go through this code later
}

P_RunThinkers() simply iterates through each mobj’s Thinker and executes its Thinker function - P_MobjThinker():

//
// P_RunThinkers
//
void P_RunThinkers (void)
{
    thinker_t*	currentthinker;

    currentthinker = thinkercap.next;
    while (currentthinker != &thinkercap)
    {
	if ( currentthinker->function.acv == (actionf_v)(-1) )
	{
	    // time to remove it
	    currentthinker->next->prev = currentthinker->prev;
	    currentthinker->prev->next = currentthinker->next;
	    Z_Free (currentthinker);
	}
	else
	{
	    if (currentthinker->function.acp1)
		currentthinker->function.acp1 (currentthinker);
	}
	currentthinker = currentthinker->next;
    }
}

We can think of P_MobjThinker() as the function called for each game state update for each mobj. This function will take care of movement, physics simulation and cycle between AI states.

We can summarize the above behavior with the following pseudocode:

G_Ticker() // g_game.c
{
	switch(gamestate)
	{
		case GS_LEVEL:
			P_Ticker() // p_tick.c
			{
				P_RunThinkers() // p_tick.c
				{
					// Iterate through all thinkers in level (linked list)
					foreach(thinker in thinker linked list)
					{
						function = thinker.function;
						// Execute thinker function
						// Runs P_MobjThinker() function in p_mobj.c
						function.run();
					}
				}
			}
	}
}

In the next article we’ll continue our deep dive into Doom AI game logic and the technical details of P_MobjThinker().

While you wait for the next article we recommend reading:

• Doom Monster Behavior

Click below to check it out!

We’re currently on v1.1 which has the following features:

• Click on a horizontal tracked plane to spawn either 4 shotgun shells, a Zombieman or a Heavy weapon dude
• Shotgun shells, Zombiemen or Heavy weapon dudes spawn randomly on detected horizontal planes
• Blast away Zombiemen and Heavy weapon dudes with the proverbial Doom shotgun

Some technical facts:

• Monster AI code is based on the Doom Linux codebase
• OpenGL ES 2.0 is used for rendering

Special thanks to:

• John Carmack for answering some questions via email related to framerate clamping in the Doom Linux codebase
• Fabien Sanglard for letting me proofread his upcoming Doom Game Engine Black Book. This was instrumental in helping me understand Doom monster AI