Here Comes 2015

Happy Holidays, everyone!  2014 went by in a blur as we formed Level 17, and we’re charging into 2015 — the year we release our first title.  Exciting times!  As I’m sure you know, 2015 is also the year of many fantastic technological advancements

We’ve spent the holidays switching to a new engine.  The Ladon Device is now officially Unreal.  Moving over from Irrlicht isn’t a walk in the park, but the features of Unreal Engine are worth the trouble.  A shoot-em-up simply must look cool.  The visuals are half the fun of playing a shoot-em-up in the first place.  Unreal Engine packs in just about every visual effect seen in any modern game, from first-person shooters to casual puzzlers.

The image at the top of this post is one of the materials that Josh has been experimenting with.  This is the appearance of the material in Cinema 4D (his modeling software of choice).  It will look almost identical in Unreal Engine, which is a claim that very few game engines can make.  Unreal Engine is pushing game visuals a lot closer to pre-rendered quality.  We’ve come a long way from Parsec.

To give another tease about Ladon’s gameplay, “materials” will play a very large role.  The player will need to collect all sorts of exotic materials in order to build bigger and better components for their ship.  This is how Ladon crosses over the genre divisions.  Mining and crafting elements put the game in the “sandbox” category.  The extensive tree of upgrades that can be crafted border on an RPG-style game.  But the gameplay is shoot-em-up down to the core.

It’s going to be a fun year and a fun game.

Lighting the World

With the general shape of the background world in place, I started working on lighting it.  Most modern hardware (according to Irrlicht) supports eight dynamic lights, which just isn’t enough.  So, programmers use lots of tricks to support more than eight lights.  I decided to allow any number of lights, but only turn on eight at a time, based on what is currently being rendered.  For each object in the scene, the distance to each light is calculated.  The eight closest lights are turned on and the others are turned off.  The result is that only eight lights are ever actually “on” at any given time.  The result looks really nice in my test scene, I think.  If this approach doesn’t look right or isn’t fast enough as the scenes get more and more complex, I’ll have to investigate more complicated techniques, like, possibly, deferred lighting.

Creating the World

The World of Ladon is starting to take shape.  It’s a spherical world built from geometric shapes, mostly hexagons.  Hexagons are ubiquitous in Ladon.

working_in_flight

I was experimenting with constructing the sphere during a flight.  I ran into a problem that I should have seen coming, but didn’t — there is no way, mathematically, to tile a sphere with regular hexagons.  There are two approaches that come close, and each has advantages and disadvantages.

The first approach is to start with regular hexagons, tiled as they would be on a flat surface.  This is the common “honeycomb” pattern.  You can wrap this tiling around a sphere, but the hexagons will begin to overlap.  You can correct for this by changing the size of the hexagons as you go, but, depending on which way you choose to do the wrapping, you will run into “poles” at some points on the sphere.  At these points, your hexagons will essentially vanish to zero.  This is exactly the same problem that mapmakers encounter — the reason why Greenland appears to be as big as Africa on a map, even though Africa is about 14 times larger in reality.  By breaking the map up into sections, as mapmakers have done in different ways for a very long time, this approach can be fudged enough to work.  If your sphere is large enough, the viewer will probably never notice the difference.  Some of your hexagons just have to be slightly distorted.

The other approach is more mathematical.  A sphere can be “tessellated” into triangles.  You can then group these triangles into hexagons.  The big drawback to this approach is that none of the hexagons are regular.  They’re all distorted pretty heavily.  And worse, there are exactly twelve locations on the sphere that aren’t hexagons at all, they’re pentagons.  The most familiar way to visualize this is a soccer ball.  No matter how small you make the tiles, those pentagons don’t go away.

hex_tiling

The above image shows the two approaches side by side.  The regular hexagons on the left begin to overlap as they bend around the sphere.  The tessellation on the right fits together perfectly, but is made up of very distorted hexagons with a pentagon in the middle.

The problem with the distortion, in either approach, is that our 3D modeler needs to be able to crank out these hexagonal tiles.  If they aren’t all the same shape, roughly, then he’ll have to model each one individually!  I don’t think we pay him enough for that…

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