They’re Coming…

Ready Room

Our hero, sitting alone in a ready room in an above-top-secret facility that the rest of the world will never know existed.  A countdown timer, ticking away, menacingly.  Only a handful of days left.  A map showing some kind of object that appears to be approaching our solar system from interstellar space.  She’s ignoring the countdown and the map and looking at something through the glass — something shadowy but dimly glowing.  She is anxious.

To Do:

Settling back into work after shuffling everything around can be tough.  Remembering where you left everything is the first challenge, then figuring out how to actually dive back into those tasks is another.  I thought I’d share my way of managing the pile of things that need to get done.

On my last project, which amounted to literally millions of lines of code, as well as some modeling, graphics, and even documentation, there were three places where I found that my “to do” list manifested itself.

One was my e-mail inbox.  “Hey Pat, we need a button on this dialog that does this and this.”  If I didn’t have time to do that exact task at that exact moment, then I would just close the e-mail and it would sit in my inbox until I got back to it.  So my inbox would fill and empty as requests came in and eventually got done.  That’s not ideal, obviously, because it has no real order to it, other than the order in which the e-mails were received.  No tasks had any sort of priority or progress associated with them.  However, the good thing about that system is that it’s really efficient.  A request comes in, I either deal with it or leave it immediately and get back to what I was working on.  It requires almost zero effort on the developer’s part, aside from maybe sending a reply like “Ok, I’ll get to that after I finish this other button I’m adding to this other dialog…”

The second method was the highly-structured bug database.  We went through multiple databases and “Assembla” was probably my favorite.  Every task has a “ticket” and every ticket has tons of customizable information.  Everything has a priority and an owner and each thing can be broken down into sub-tasks, and tickets can be related to each other in different ways, e.g., “Ticket 500 can’t be completed until ticket 475 is done,” and so on.  Every user that needs to know the status of a certain ticket can choose to receive e-mails any time something changes.  So, these tickets tend to turn into little discussion forums.  For a project as big as my last one, this kind of task management is almost unavoidable.  My only complaint about it is that it’s too much information.  You inevitably reach a point where you have a hundred “open” tickets at any given time and it can easily become overwhelming.  There are some nice tools within Assembla to help manage all that information, like filters and tags and sorting, but I never really felt like I had a handle on the big picture.  It was still just a giant wall of text that I had to stare at to figure out what I should be working on.

So, my third to-do list became a sort of “master” list.  I would maintain a text file that contained the subset of tickets that I really cared about, and it  would look something like this:

New text parser
 - regular expressions
 - add math functions
 - reverse parsing, save to file

Crash in 2D plot window (ticket 700)
 - Can't reproduce crash on XP
   - Windows 7?
 - Only happens while logging is active

… and the list would just grow in a loosely structured way.  Each task was roughly broken into smaller tasks and the more important things would generally move to the top, but there was no real system to it.

This third way of tracking things was the one I relied on most, and it evolved into what I currently use.  Instead of a nested list, I create an actual graph.  That’s what you see in the blurry image at the top of this page.  A graph might seem cumbersome, but it isn’t.  While doing some work completely unrelated to “to-do lists” on my last project, I discovered yEd.  yEd is one of the most beautifully designed pieces of software that I have ever seen.  It’s just one of those tools where everything is right where it needs to be.  Drawing a chart is so intuitive that it’s really no harder than typing in a list like the one above.  But the great thing about a graph is that it really does have structure and you can immediately see that structure with just a glance.

This approach really encourages the developer to work from big to small, which is tremendously important for us software guys.  I start at the absolute highest level and create a box that says something like “Make a game.”  Yes, seriously.  From there, there are only two choices:  A) complete that task and mark it done, or, B) break that task into smaller tasks.  Since I can’t sit down and finish the task “Make a game” in one sitting, I create other boxes that spread out like a tree from that box.  Those sub-tasks are things like “Music” and “Graphics” and “Create a blog” and every other thing I want to do to accomplish the task “Make a game.”  And that process of subdividing repeats until every single box is at a small enough level that it can be done a day or two.  The boxes at the smallest (leftmost) level are things like “Write an emissive map shader.”  Or, often, there are things that I need to do but don’t yet have enough information to even break them down into smaller tasks.  So one branch of the tree might end at a box like “Learn how to do depth-of-field blur,” for example.  And when I get around to reading up on depth-of-field blur techniques, I come back to my graph and fill out that branch.

When a task is finished, I just color it green.  That way, the graph becomes a really useful and visual overview of the whole project’s status.  So far, I’m finding this much more productive than my old text lists.

If you’re wondering, the image above is the current to-do graph for getting Ladon to an Alpha version.  I guess I should get back to work!

Moving

Progress is slow this week because everyone is moving!  Ansel and the marketing department are moving into the chic space in the photo above.  Pat and Nicole are relocating, as well, so coding is on hold for a few days.

Once everyone is settled in, the focus will be on the next big milestone, which is to show some gameplay video.  In the meantime, we’ll have a few more character sketches to introduce the cast.

Our Hero

Garrett is finishing up work on developing our lead character, and I think she’s looking great.  We’re trying not to fall into the cliche of the female lead character having Barbie-doll proportions — yes, we’re pointing a finger at you, Samus.

Lead character sketch

Ladon’s Lineage

The above image is “Spacewar!” running on the PDP-1 [Photo: Joi Ito].  This is the earliest known video game.  It also happens to be a “shoot-em-up.”

The Ladon Device is also a shoot-em-up.  Since this oldest genre of video games is now over fifty years old, it isn’t easy to introduce something new to it.  The following is the list of shoot-em-ups that I have played over the years, which is what will shape Ladon.  This isn’t an exhaustive list of shoot-em-ups (there are plenty of those), and it isn’t a top-10 list, either.  And, no, “Spacewar!” from 1962 doesn’t make the cut.  I’m old, but not quite that old.

parsecThe first shoot-em-up that I played was called “Parsec” on the TI-99.  It was a side-scroller, which just means that the surrounding world scrolled past you from right to left, as opposed to top to bottom, etc…  Today, there so many variations of shoot-em-ups that some people categorize them into sub-genres based on things like which way the screen scrolls.  Back in 1982, when Parsec was the cutting edge in video games, there was no concept of “genres” of video games.  If you were lucky enough to have a video game console of some kind, you had about five cartridges for it, and each one was it’s own genre — you had one shoot-em-up, one maze type game, one sports game, and so on.  I can’t remember if I ever finished Parsec or if it even had an ending.  Many games back then would just continue forever, until some variable like the player’s score got too big and caused the game to crash.

AsteroidsAfter the TI-99, I had an Atari 2600.  There were several noteworthy shooters for the Atari.  The Atari’s joystick had one button and it was called the “fire button,” so it seemed like the system was kind of built with that type of game in mind.  Asteroids was the first one that I remember.  There were some unique things about it that aren’t common these days.  The player’s movement was physics-based, in a way.  As opposed to most shoot-em-ups, where pressing up made the player’s ship move up, in Asteroids, you had to turn the ship to face the direction you wanted to go, then move the joystick up to thrust in that direction.  There were no brakes, so, in order to stop going in that direction, you had to spin around completely and thrust in the opposite direction.  It was a really simple and subtle difference, but it made the game feel completely different from everything else.  It almost felt more like a realistic simulation of spaceflight than a shoot-em-up.  It also had the interesting “wrap” feature, meaning that moving off one edge of the screen just looped you back to the opposite side.  It all worked, apparently, because Asteroids was incredibly popular for its time.  Every pizza restaurant had an Asteroids console in the lobby, and I put quarters into most of them.

Lots of “top down” scrollers were popular on the Atari, like “Vanguard” and “River Raid.”  I remember trying to reach a certain high score (I think it was 100,000 points) in River Raid and take a picture of the screen because the game’s publisher was offering some kind of prize if you mailed the picture to them.  I think it might have been a T-shirt.  Sadly, I never pulled off the feat.  I reached the target score maybe two or three times, but never happened to have a camera handy.  We didn’t carry around camera phones at all times in 1983!

SidearmsThe rest of the 1980s were really the golden age of the shoot-em-up.  There were so many of them that I couldn’t play them all.  The one that I remember liking the most was called “Side Arms.”  It wasn’t extremely popular but it just had a feel to it that I thought was perfect.  It had just the right amount of progression — there were five different weapons that you had to acquire, and each one could be upgraded, independently, by collecting power-ups.  Side Arms’ big gimmick was the “alpha” and “beta” concept.  In two-player mode, one player was the “alpha” and the other was the “beta.”  There was a special power-up that would cause the two players to combine into a single, more powerful mech.  For some reason that I can’t explain, this was the coolest thing I had ever seen in a video game.  The funny thing about the combined alpha/beta mode was that the alpha player controlled the movement and the beta player just fired.  So, in this mode, all the second player could really do was hammer the “fire” button as rapidly as possible.  It was awkward and didn’t really add anything to the gameplay, but it made the game my favorite, hands down.

The other shooters that I fondly recall from the golden age were “Defender,” “Galaga,” “Galaxian,” “Xevious,” “Sector Z,” “Life Force,” “Ikari Warriors,” “Commando,” “Zaxxon,” and a few little-known titles like “Land Sea Air Squad” and “Uridium.”  I’m sure there are others that I just don’t remember playing.  Ikari Warriors was different in that it had a special joystick.  You had to physically rotate the handle of the joystick to turn your player in the direction you wanted him to shoot.  It was a cool effect that I never saw in subsequent games, possibly because the special joystick was more expensive to make and had a tendency to break easily.

Darius

The genre peaked around 1990.  The two games that represented the real pinnacle of the shoot-em-up, for me, were “Darius” and “Raiden.”  Darius had the craziest arcade console that anyone had seen.  It had three monitors wedged in, side by side, to give it an apparent triple-wide screen.  I can’t imagine how many man-hours must have gone into hand drawing the graphics for all those gorgeous, widescreen levels.  I remember just standing back and watching other people play the game because it was just that visually impressive for its time.  The gameplay was also excellent, even without being revolutionary in any way.  It was just a standard side-scroller, but the depth of power-ups available kept it from ever getting boring.  The fish-themed boss enemies at the end of each level are still a fondly-remembered in-joke among us shoot-em-up enthusiasts.  They had ridiculous names like “Fatty Glutton” and their approach was always preceded by the ominous message, “Warning!  A huge battleship is approaching fast!”  Good times.

Raiden was a more standard shoot-em-up, but the level of detail that went into making it was impossible to ignore.  The sheer number of power-ups that you could attain was staggering.  And every part of the game was overly detailed.  Every explosion sent smoke and tiny pieces of shrapnel flying in every direction, as opposed to the standard, quick, circular flashes of color that served as explosions in just about every other game at the time.  Like Darius, the two-player, cooperative gameplay was just really well thought out and fun.

The creation of shoot-em-ups didn’t end in the early 1990s, but times changed.  Wolfenstein and Doom made the first-person-shooter genre popular and we never really looked back.  Games moved out of the arcade and onto the PC.  Darius and Raiden had numerous spin-offs, but everyone seemed to gradually lose interest.  The concept of the “bullet hell” shooter has found a little bit of popularity, recently, but shoot-em-ups in general don’t really scratch the surface of video game sales today, whereas they dominated them back then.

So, Ladon will be a game from a past era.  But, it will be modern in its visuals and will have a gameplay twist that has never been present in any shoot-em-up, as far as I know.  My hope is that it will appeal to both the nostalgic gamer of the shoot-em-up age and the modern gamer who is looking for something different from the repetitive (in my opinion) titles being released today.  What is the unique twist?  Stay tuned!

Nuts and Bolts

I’d also like for this blog to be a place to discuss programming.  I’ve been doing it for over 30 years (yikes) and I’m still learning how to do it right.  My previous project was well over two million lines of code in about a dozen different languages at last count.  The bulk of it was C and C++.  I have an extreme love/hate relationship with C++, as I think nearly every C++ programmer probably does.  Some things about it are powerful and useful.  Other things are just unnecessary and often even counterproductive.

Love it or hate it, Ladon will be written in C++.  It is still considered by most to be the “language of games,” as far as I can tell.  It isn’t interpreted, garbage collected, or “just-in-time” compiled, like most more modern languages.  It’s still compiled directly to native machine code.  I think a lot of people expected to be using Terahertz processors by now, so that the difference between interpreted and compiled code wouldn’t even be noticeable.  Somewhere around ten years ago, we hit a wall as far as raw clock speed.  Intel and AMD (and now even graphics processor makers) continue cramming more transistors into each chip, but the clock speed hasn’t moved past about 3 to 4 GHz in a decade.  Now, we get more and more cores.  That’s an important trend to watch if you’re a coder.  It means that if you really want to push your game’s performance, you can’t just be good at writing clever, efficient algorithms.  You also need to know how to write effective concurrent code, i.e., multi-threaded code.

Modern games do so much these days that there’s plenty of work to go around.  The graphics can go in one thread, the AI in another, physics in another, sound in another, and so on.  It makes me nostalgic for the days when writing a game looked like this:

   while(!game_over)
   {
      get_keyboard_input();
      move_the_player();
      move_the_enemies();
      check_for_collisions();
      draw_the_player();
      draw_the_enemies();
   }

Ladon is currently using Irrlicht as its engine.  That may or may not change as work goes on.  It has been through several engines already — first was Irrlicht, then Ogre3D, then Unity, and now back to Irrlicht.  The great thing about Irrlicht is that it is extremely lightweight.  It’s also fully open source and free.  So, in the early stages of development, Irrlicht is a nice way to go, because it really doesn’t force anything on you.  The downside is that it is fairly minimal in terms of what it can do.  You’ll end up writing your own code to do things that are built into other modern engines.  I guess some people might not call that a “downside” at all, though…

The Ladon Device

What’s this game all about, anyway?

The 11th Labor of Hercules, Photo: Luis García

It’s called “The Ladon Device.”  The name “Ladon” comes from Greek Mythology.  Ladon was a dragon with a hundred heads that guarded a tree of golden apples.  Details about Ladon are hard to find, and that’s what I like most about him.  I considered a lot of potential names and this was the one that stuck.

The game isn’t set in ancient Greece.  In fact, it’s a futuristic setting where the player will battle alien machines sent to destroy the Earth!  The story does tie back to Greek mythology.  This is the origin of the “device” itself.  The device is a piece of alien technology that mankind will ultimately use to defend itself from extinction.

Yes, I know, it’s all a big tease.  Well, come on, you don’t want to read the last page of the mystery novel first, do you?  The actual story will be told through the game.  Finishing a level will reveal another page or two.  The primary reward for finishing the “story mode” of the game will be getting to read the entire story.  Another reason I can’t go into too much detail about the story right here and now is that it isn’t complete.  Ladon is still very much under development.  The story is mostly written, but the artwork has barely begun.

What I can say now is that the gameplay borrows from several different genres.  It is definitely not a first-person-shooter.  While it’s hard to deny that the FPS has defined the modern era of gaming, I also feel that it has been done to death.  Ladon will have the feel of some of the oldest video games around, but with some very modern updates.  In the end, we want it to be both cutting-edge and “retro,” in a sense.  More importantly, we just want it to be fun.

It’s going to be a challenging game to make, but we’re putting everything we’ve got into it.  Stay tuned!

The Adventure Begins

Thanks for visiting the Level 17 blog!

This is where you can follow the development of our first game, “The Ladon Device.”  Throughout the development of this game, we want you, the reader, to be involved in shaping it.  We want to know what you love about games, as well as how and where you like to play them.  We want to build a community that appreciates well-thought-out games with ridiculous attention to detail as much as we do.  If that sounds like something exciting to you, then follow us on this adventure and share your thoughts here.

We have a lot of fantastic ideas about what we want to do in this first game.  We’ll be frequently updating this blog as we implement them.

You can read more about us here.

In this brave new world of social media, there are plenty of ways to get involved or to just keep up with the latest developments.  You can register with us, if you like, or post some comments anonymously.  You can provide an e-mail when registering if you want to be notified when there’s a new post, or subscribe to our RSS feed.  You can also follow us on Facebook and Twitter.