Cronus

Cronus

The professor’s old station wagon was spraying up a cloud of dust as it creaked and groaned its way through the dark desert.  He couldn’t even remember how he knew this unmarked road existed.  But he was racing on it, recklessly, out to some point that he knew he would recognize when he saw it.  His only conscious thought was Richard Dreyfuss being uncontrollably compelled to build a Devil’s Tower in his mashed potatoes.

He felt a tingling on the back of his neck which slowly spread down his arms until his arm hairs stood on end.  A head rush followed and it felt like he might pass out.  He worried for a moment about losing control of the car and swerving off the road.  Just as he started to gather himself with a deep breath, he slammed on the brakes, almost involuntarily.  The car lurched to a stop and the trailing dust cloud rolled over the car, blocking sight in every direction.

He was here.  He stepped out of the car, coughing and waving his arms in the dust cloud.  After just a few steps, he was in the clear and could see the landscape.  It was the exact scene he had seen in the dream that terrified him just an hour ago.  The sun was just rising.  This is where the dream had ended.  He was no longer being unconsciously driven to do anything — he was just standing in the middle of the brush and dirt, waiting for something to happen.  Nothing happened.  He felt ridiculous.

He made a sun visor with his hand and scanned the horizon, looking for anything out of the ordinary.  Nothing.  How long should he wait here?  It was going to get uncomfortably hot soon and there was no guarantee that his fifteen-year-old car would even get him back to civilization.  He sighed and rubbed his eyes.  “I am losing my mind,” he muttered, and brushed his clenched fist over his mouth and beard.  He realized he hadn’t even washed his face or brushed his teeth this morning.  He had just bolted out of bed and ran to the garage and started driving.  He was still in his pajamas!

All the confusion settled into a simple feeling of humiliation.  This is not how tenured professors behave!  He turned to get back in the car and drive home.  It was 6:20 in the morning, so no one would know that he had been on this silly adventure.  He opened the door and bent down to sit, but was instantly frozen when his eyes caught the mysterious, dark figure about a hundred meters away.  He couldn’t move, one foot in the car, one foot out, half standing, half sitting.  The figure wasn’t moving, either.

He eased back out of the car to stand and look at this…  man?  It seemed to be a rather tall man in a dark robe.  Even though this sight should have validated his being here, it only made him feel more ridiculous.  Who is this?  Does he expect me to just stroll over to him and strike up a conversation?  Apparently, yes, that was the only course of action that made any sense.  After a few more seconds of hesitation and a glance in all directions to ensure no one was watching this secret encounter, he walked around the car and off the dirt road, into the brush.

The walk didn’t take as long as he wanted it to.  He was half way there before he expected to be and he stopped to stare at the figure.  This person was seven feet tall.  Not only was he wearing a long blue-black robe, but his face was covered with some kind of matching mask.  He, or it, was looking directly at the professor and standing absolutely still.  It was the most terrifying thing the professor had ever seen.  He wasn’t sure he could force himself to take another step.  Unexplainably, the fear quietly left his brain.  He knew that this strange figure meant him no harm.  Was it communicating with him?  Reading his mind?

He walked, confidently, right up to this incredible figure.  The mask was no mask; the robe was not like any robe he had ever seen.  This was not a human being.

A barrage of images and sounds poured into the professor’s mind.  They were coming too quickly to make any sense.  Then they stopped.  He covered his face with his hands as his brain worked to sort them all out into a meaningful order.  This being had just told him a story in only a few seconds.  An incredible story.  A story about the end of the world.  The professor’s eyes widened as this story began to sink in.  He looked up at the face of this giant standing in front of him.  For a moment, he thought that the story must be the whole reason he had been summoned out here.  No, that didn’t make sense because this creature had already demonstrated the ability to communicate directly into his brain.  He could have told this story in another dream.

The robed figure brought his arms out to his side.  The robe fluttered a little and, as if the situation could be any more unreal, the professor noticed that the robe was only brushing the ground.  There were no feet extending below it.  This being wasn’t seven feet tall, it was hovering a foot above the ground.  “Are you here to bring the end of the world?” the professor asked.  Of course, there was no verbal answer, but he knew that the answer was “No” before he even finished the question.

The true purpose of the meeting was now clear.  The dirt swirled around the being’s feet, or lack thereof.  He rose slightly higher from the ground.  In the circling debris, something was beginning to glow.  Brighter and brighter, until there was a ball of light hanging in the air between the two of them.  This was it — the device.

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!