E. Darwin Hartshorn: //Boilerplate

Devgame Internship 4: Tiles

In videogames, tiles are used to create large levels with a few small graphics.  Here’s a fantastic example by someone else:


As you can see, you can create a large variety of backgrounds simply by laying tiles, like this, on a grid.

Continue Reading >>

Comment Toggles

I prefer my tools, such as my sprite editors to take up the whole screen.  But a straight-up screenshot of that size would be annoying.

In XNA/Monogame, you set the size of the screen thusly:

 graphics.PreferredBackBufferHeight = 720;
 graphics.PreferredBackBufferWidth = 1280;

Rather than go in and comment in/out these lines every single time I want to take a demonstration screenshot, I often do this:

graphics.PreferredBackBufferHeight = 720;
graphics.PreferredBackBufferWidth = 1280;

Then, when I want to disable my screen expansion, I just delete one Nathan Hale from the top comment block.

graphics.PreferredBackBufferHeight = 720;
graphics.PreferredBackBufferWidth = 1280;

Thereby turning the whole set into a comment block.

I use this in other ways as well.

thing.Width = calculatedSum /**/ + SOME_CONSTANT /**/;

Medium Must Match Message

This is a good article to read.

Auro wasn’t supposed to be “retro.” To me, the “retro game” aesthetic isn’t just pixel art, but an appeal to the specific sounds, feedback, and look and feel of a specific set of old school games. While it’s true that Auro was an homage to my favorite game art, I never intended for it to be “retro.” I just wanted to make great pixel art, yet it inexorably gets lumped in with the retro aesthetic.
But here’s the clincher. It’s not their fault.

“Retro?” Poppycock! I’ll have you know I’m quite jiggy with it!

The Artist’s Responsibility
Though I never intended for Auro to be a “retro-style” game, what I intended doesn’t matter at all, and it’s 100% my fault for failing to communicate in a language people understand.

As a game developer, time is the most valuable resource a human can give you. Nobody owes us their time or attention. As such, when someone gives us their time, an implicit agreement is made and we are now in debt to that person. We owe it to them to deliver value for their time, and to deliver it efficiently.

I am an illustrator/animator. The kind of value that illustrators/animators are responsible for is distinct among other types of visual artists. We must establish meaningful intent as close to instantaneously as possible. By meaningful intent, I simply mean that the audience has to internalize the concept, motion, emotion, perspective, etc. of a pieceright away. The second the audience asks “how can he bend that way without breaking his spine,” or  “Why is he shooting where he’s not looking,” we have failed them. They don’t owe us the time to look at our work in the first place. They certainly don’t owe us the time to squint their eyes and try to make sense of our work.

Meaningful intent applies to medium as well. In choosing to make our game with pixel art, we have accidentally taken on a war on two fronts. My job was to make Auro’s art polished, inviting, and clear to the audience, not to also educate the audience that pixel art is a deliberate style.

My main point dances around Mr. Reynolds’ point.  The consumers of Auro criticized it for its ‘pixelated’ art, not understanding that it was intentional.  Reynolds correctly places the blame on his failure to communicate, but seems only to brush in passing on how he failed.  The quote, “Auro wasn’t supposed to be “retro.” To me, the “retro game” aesthetic isn’t just pixel art, but an appeal to the specific sounds, feedback, and look and feel of a specific set of old school games,” is the closest I see to an explicit recognition of the issue.

The issue is that the medium doesn’t match the message.

Continue Reading >>

Pixel Art for Programmers: If You’re not Cheating, You’re not Trying (Shading and Colors)

Last week, we left you with this:

Spaz McDragon, Flat colors.

Scaled down so we can see it more objectively.

I’ve gone ahead and done a little more pixel-pushing and jaggy-correcting since then.

Pretty obvious, isn't it?

Pretty obvious, isn’t it?

Now it’s time to add some color!

First thing we need is a set of color ramps.  What’s a color ramp, you ask?  Glad you asked.  A color ramp is a set of two to five colors like this:



That ramp defines basically all the shades of green we are going to use, and has a roughly even fade from the almost black blue, to the almost white yellow, with our core green color in the middle.

I define the ramp using a program called Inkscape.  Here’s a screenshot of the file I used:



Building TheGreen Ramp

First, I use the rectangle tool to draw a rectangle.  Then I hit Ctrl+Shift+F to bring up the color options, and set the rectangle to that nice, green shade I want.

Then I duplicate the rectangle with Ctrl+D, and holding Ctrl, I drag it upwards.  Holding Ctrl ensures that it moves in a straight line.

I change the fill type to gradient, hit the ‘edit gradient’ button , and I change one node of the gradient to my shadow color (dark blue), and the other to my light color (pale yellow).  Then I add a couple of nodes, and change them to transparent.

Next I move the whole thing down so that the gradient rectangle covers the green rectangle:


And I line up five little squares underneath it and eyedropper colors from my navy-to-ivory-by-way-of-green gradient.

The best part is, all I have to do to create a corresponding ramp for any other color in the character is change the color of the green rectangle itself, then re-eyedropper the colors:



This keeps the shading looking consistent across the character.

So why use blue and yellow instead of black and white?  And why only five colors?

The answer to the first question is that light is seldom pure white, and so there is usually a sense of progression in real life from the color of the light, to shadows which seem to be the opposite color (such as yellow and blue).  Using this progression makes the characters and objects in the game world seem rooted in their world, as opposed to seeming like stickers slapped over a separately-painted backdrop.  It is also more visually appealing than a straight-up change of shade.

Here’s the final set of ramps for the character.  Note that all the ramps share first and last colors.  Note also that there are only fourteen colors total.  If we are wise, we will not even use all fourteen!



Right-O.  If you import the graphic with the ramps into GraphicsGale, you can just pick the colors right off the ramps, then flood-fill the relevant areas on the sprite.  Let’s see how Spaz looks after this:


That’s not exactly an improvement, and the colors may need some tweaking, but let’s see how shading goes first.

Right:  Here’s what not to do.  Do not pillow-shade.

Pillow-shading is when you work inward from the borders, from dark to light.  Like so:

Spaz McDragon Pillow Shaded

“But that’s not so bad,” you may say.  And indeed:  this was sloppily put together because of time constraints.  A more lovingly pillow-shaded sprite would look even better.

But it would still look like a shaped pillow, when it could look like it had depth.

So how do you know how to shade it if you’re not naturally artsy?

If you aren’t cheating, you aren’t trying hard enough.  Observe:

First, I fire up Blender, a free 3D modelling, animating, and rendering suite (and yes, I will be running tutorials on 3D, though probably not for a year or more).

Next, I start adding various shapes.  If you type Shift+A, a menu of things you can add pops up.  I’m going to pick Mesh–>Cube, here.

Hitting tab puts you in Edit mode, allowing you to edit the cube.

Hitting Ctrl+R puts you in loopcut mode.  Move your mouse around until a purple line appears around the middle of the cube, then left click, then right click.

Cube Loopcut


The loop should be automatically selected.

Spaz is a crescent shape, so I hit G (for Grab), and Y (for ‘Constrain to the Y Axis, which is forward/back in Blender’), and move my loop forward a little.  Left click confirms and puts the loop back down.

Cube Into Crescent


By the way, you can rotate the view with the middle mouse button.

You can hit A to un-select the loop, and holding Ctrl, left-click and drag a lasso to select the points you want to manipulate.  In this case, I want the top set.

Then hitting S allows you to scale your selection by moving the mouse and then left-clicking when you’re happy.  I’m going to scale it down, deselect all, grab the bottom, scale that down, and move it back (once again, G for Grab, Y for Constrain to Y axis).

Just as G grabs, and S scales, R Rotates, and like the other two, you can constrain it to any axis using the X, Y, and Z keys after you hit R, and you confirm the rotation with a left click.

Now I press Shift+A again, and this time add a cylinder.  I scale, move, and rotate it until it forms Spaz’s forehead ridge.  Pressing Shift+D creates a duplicate, which I rotate and move until it forms the ridge on the other side.

Adding Eye RidgesNo need to be exact here.  We’re not trying to create an awesome model.  That would take way too much time.

A pair of cones becomes horns.



A cone scaled way down in the X axis becomes spikes.



And a cylinder with one end scaled slightly down becomes a cute little pig nose.



And that’s all we really need.

Hit tab again to switch into Object mode.  Then add a plane.  The plane is going to be your lamp, so grab it and move it above and in front of the character, and rotate it to face the character.



Up at the top of the screen there’s a drop-down box that says  “Blender Render”.  Click that box and change it to Cycles Render.

Cycles Render is a raytracer that simulates bouncing light.  Now we just need to tell it what each object needs to simulate.

Right Click your mock-up character to select him.

There should be a panel on the right.  Click the button that looks like a glass sphere.  That’s the materials button.

Changing Render stuff


And hit the button that says New.

That’s all for Spaz!  Now the lamp.

Right-click the lamp to select it, and hit the button that says New again.

There should be a button that says “Diffuse BSDF”.  Click that button, and select “Emission” from the box that appears.  Then click in the box labeled “Strength”, and change it to 60 or so (think strength of a light in Watts.

Now smack the button on the bottom left that looks like a white sphere:

Display Type


Select “Rendered”.

Rotate your view with the middle mouse button until you get the angle you want for your game.  Viola!  Blender has given you a reference for how the lighting will work on your character.

Cheating with Blender


Back in GraphicsGale, using your Blender Screenshot as a guide, select one, and only one, shadow color for each shadowed area, and fill in shadows in similar fashion.

Shading Spaz with Blender


Lookin’ good!

The sprite is excellent as-is.  In fact, some games use this two-tone style to great effect.  Hyper Light Drifter uses a two-tone style that’s even flatter, and it looks gorgeous.  Of course, HLD has a very muted, faded look to it, whereas I’ve always been more of a chiaroscuro guy myself.

But I’m going to go ahead, make a few more tweaks, and just barely break the two-tone rule (but with a light touch).  Mostly adding detail (like nostrils and pupils), and fixing bits and jaggies here and there.  The eyes and horns are supposed to be shiny, so I went and added highlights to ’em.  And here we are:

Spaz McDragon Shaded

So, for comparison: Lines, Filled, Flat, Pillow-Shaded, and Final:

Spaz from Sketch to Final

Ah, but we are missing something, aren’t we?  Where are Spaz’s wings?

The wings are going to be created and animated separately so that we can have Spaz flap around with very minimal effort on our part.  Which gives us next week’s subject for Pixel art for programmers: Animation basics.






Secret Coding: Making Object Oriented Programmers Tear Out Their Hair

First programming tutorial!  Ha!

Okay, before we get too excited:  I’m not going to teach you to program.  I’m going to teach people who can program how to program games.  So, the first thing you’re going to need to do is learn a little C# if you don’t already know some.  Google C# tutorials.  Or go here.  It’s where I learned.

That website will walk you through installing C#, as well as how to code in it.  To write programs in XNA Game Studio, which is a set of game programming libraries for C#, go here.

To those of you who are watching the game industry closely, and are now wondering “Why XNA?  Isn’t XNA dead?”  I can only reply 1: XNA is not dead so long as MonoGame exists, and 2: I’ve spent the last couple of years coming to terms with XNA.  It’s where I’m able to help you.

Unity might be simpler to learn.  It may even be better.  It’s certainly the direction things are going, and I won’t tell you not to check it out.  But XNA is what I know, and what I teach, and there’s still some life left in it.

Cool beans.

This first part is theory (explaining what we’re going to be doing).  Next week, we’ll actually do something with all that theory.  Of course, if you’ve just run across my site, and it’s already been more than a week since I wrote this, you can just skip right ahead.

It’s time to dive in to the strange, alien terrain of coding that isn’t exactly as Object Oriented as you may like.  I’m going to tell you to do some relatively complicated things today, and if you’re already a pretty good programmer, you are going to want to punch me right in the face before I’m done.  The reason is I’m using (or trying to use) a methodology called Entity Systems (ES), which is a different way of doing things than Object Oriented Programming (OOP), and thus Good ES Programming Is Often Bad OOP (GEPIOBO).  (Okay, that last acronym is ridiculous.  Ignore it.  I’ll probably never use it again.)

I think it’s better to show you how things work rather than starting by explaining the theory, which will come in more next week.  What you need to understand starting out is this:

If I were showing you how to use OOP to make games, I could teach you to do step one, get a rectangle on the screen, in six lines of code.  Seriously.  You can make your first XNA game project displaying rectangles and even pictures on command in the time it’s taken me to type this sentence.

But it will take us a bit longer to get our basic ES framework in place.  Like, maybe a half-hour to an hour.

The trade-off is that once we’ve gotten that framework into place, actually making the game will go much faster.  As in months or years faster.

Starfighter X took me about two months to build.  I could rebuild it using ES in a couple of days.  And it would be awesomer.

The other part of the trade-off is that making a game with OOP is like Real Chemistry.  You carefully map out a chemical chart, mix together a few things that look exactly like water, and if you get the mixture wrong, it just sits there and looks like water.  Or burns you.

ES is like Mad Scientist Chemistry.  You throw random colorful ingredients together, and it always results in a dramatic explosion, and when the colored smoke clears there’s a really strange animal sitting on your desk that you’ve never seen before, and you can’t stop cackling like a maniac.

I’m not even kidding.  It really is exactly like that.

But remember:  GEPIOBO.  If you are already a decent programmer, suck it up, hold off judgement, and wait ’till you see how things work.  Then, pooh-pooh it if you like.

Step one:  fire up Visual C# Express, and start a new Solution.  Select “Windows Game”, name it, then as soon as it’s finished loading, hit F5 to run your game.


It burns!  It freezes! Take it off us, my Precious!

It burns! It freezes! Take it off us, my Precious!

Man, I hate Cornflower Blue.  The evilest, most hateful color on God’s Green Earth.  That has to go.

Terminate your program, and scroll on down through the code that Microsoft has so conveniently provided you.  You should find a bit that looks like this:

/// <summary>
/// This is called when the game should draw itself.
/// </summary>
/// <param name="gameTime">Provides a snapshot of timing values.</param>
protected override void Draw(GameTime gameTime)

// TODO: Add your drawing code here


Schweet.  Check out line 7: “GraphicsDevice.Clear(Color.CornflowerBlue);”.  That line does exactly what you think it does.  Why not highlight the word “CornflowerBlue” and replace it with another color?  Black is always popular.

Even Greater Accomplishments

This color represents how I’m a nonconformist, rebelling in perfect lockstep with all the other nonconformists!


How’s that taste of Real Ultimate Power?  Feels pretty good, right?  Well, it had better tide you over, ’cause we are going to leave behind powersville for a little while so that in the future, we won’t have to leave it ever again.

Right-click on your solution in the solution explorer.  Select “Add -> New Project”

Yes it is.

That’s not mildly insulting…

Add a Windows Game Library.  Give it a rockin’ awesome name like “AtomSmasher”.  Make sure you right-click on your game project and Add Reference, then add AtomSmasher, as otherwise your game will not know that it exists.

Right-o.  AtomSmasher is going to contain our Entity System.  Let’s start by renaming Class1.cs to ES.cs.  Visual C# will kindly offer to rename all references for you, and I suggest you accept its offer.

Here’s the code we’re going to write for starters in ES.cs:

Entity System 01


I’ve underlined the word ‘static’ in the class declaration because it’s important.  Static means that you don’t create ES objects.  Instead, you access the class directly.

Now, anywhere in your game code, you type in something like int Vorgon = ES.Next; and your variable (Vorgon) will be assigned a unique number.

Why is it unique, you ask?

Well, let’s take a look at the rest of that code.  First we have ‘cur’ which is shorthand for “Current Number Which is Definitely The Biggest One We’ve Assigned.”  We start it off at negative one.  Every time we ask ES for the Next number, barring other circumstances, it increase cur by one, and then sends us back the result.

Next on the list after cur is Available, the only thing so far that has a sensible name (but we don’t care about cur because we’re never going to do anything else with it ever again1).

Available is a Stack.  That is, it is a collection that can hold an ever-expanding list of stuff.  The catch is the stuff is stacked up like a bunch of plates.  We can Push a new plate on the Stack, or we can Pop the top plate off the Stack, but if we try to yank a plate out of the middle or (Yog-Sothoth forbid) off the bottom, Bad Stuff Happens.

Stack has angle brackets around the word ‘int’.  That means it’s a stack of ints.  It could be a stack of anything, but we are using ints.

The next thing is, handily enough, Next.  A property.  First, it checks if there are any numbers on the Available Stack.  If there are any, it Pops the top one off and sends it back.  If not, it increases cur, and sends that back.

So, when we are done with Vorgon and no longer need it, we can send it back to ES.  ES will Push it onto the Available Stack, and the next time our program needs a unique number, it will get a gently used number instead.

That’s what the Kill(e) method is for.  When we call Kill, we are telling the Entity System that we no longer have any use for the unique number we are killing.

So, so far, we have a way to fetch a unique number, and a way to give back the number when we are done with it.


These numbers are the Entities in “Entity System”.

These numbers are all there is to the Entities in “Entity System”.  An Entity is a number.  No two Entities are allowed to be the same number, lest weird stuff happen.

As the name Entity Systems suggests, the second thing we need to implement after Entities is…



Add a Folder to the AtomSmasher project called “Components”.  Then, add a class called Art.cs.  Here’s the code for Art:

Art Component 01


Let’s esplain all this:

Art is a class to hold all of our Art components.  We don’t technically need a class just for the Art components — we can (and I once did) just shove all the components into ES.cs — but it’s easier to find the component you want if you sort them by category.

The component, or rather, component dictionary, is “public static Dictionary<int, Rectangle> VisibleRectangle;”.

Like Stack, a Dictionary is a special sort of list2.  Unlike Stack, which works like a stack of plates, a Dictionary works like… well, a Dictionary.  You store things in the Dictionary under a Key.  When you want the thing you stored, you just use the Key, and the Dictionary looks it up for you.

Inside the angle brackets, we have two data types:  int, and Rectangle.  The first is the data type we are using for the Key, in this case a number.  The second is the data type we are filing in the Dictionary, in this case a Rectangle.

We are calling it “VisibleRectangle” because this dictionary represents rectangles that are drawn on the screen.  So, the goal is, each VisibleRectangle in the Dictionary will eventually be drawn on the screen.

That happens in the Systems in Entity Systems, but we are getting way ahead of ourselves here.

In the class’s constructor (static Art()), we initialize VisibleRectangle with a size of 128.  This is a rough guess of how many rectangles we will need on the screen at a time.  We can fine-tune this up or down later, but making guesses like this is handy because if we ever need more rectangles than we have pages in the Dictionary, the Dictionary will be forced to make a new, bigger Dictionary, and copy everything from the old one into it.

It’s not hugely important, and you shouldn’t spend time worrying about it unless and until you are running a game and it starts to slow down, but there you go.

The way we are going to use this in code is this:  when we have an Entity, we can add any Component to it by simply filing that Component in the appropriate dictionary under the Entity we want it to belong to.

The way to do it is this:

int Vogon = ES.Next;
Art.VisibleRectangle[Vogon] = new Rectangle(x, y, height, width);

So, now you know why Entities are just unique numbers.  Any Entity can ‘own’ one of any component simply by having that component filed under its ‘name’ (that is, the number it consists of).

That leads us to Art.Kill(int e).  Inside the kill method, we remove the entry for whatever number we’re sent from the dictionary (and no worries — if there isn’t an entry, the program will just move on as if nothing happened.

That means that in ES.cs, we are going to have to add a couple of things.

First, up at the top in the using statements:

using AtomSmasher.Components;

And then, in ES.Kill(e):


Right.  We have a way of getting new Entities (ES.Next), and a way of filing visible rectangles under our Entities (Art.VisibleRectangle[Entity] = Whatever).  Now we need code to actually draw the rectangles, right?

Well, yes, but first, we need access to our art supplies.  And as I, sadly, have run out of time to run this article, I am going to leave that off for part two.


1. Yes we are.  It will show up again when we write ES.Nuke().  But that’s a little bit down the road.

2. For those who are wondering, it’s a Hash Table.


Pixel Art for Programmers: Silhouette and other improbable French words.

Programmer art.  It can be awe-inspiring (Like anything by Dean Dodrill or Derek Yu), it can be messy-and-sketchy taken to an art form by way of awesome thematic unity (I refer you to the work of James Silva), or it could be utterly awful, an eyesore beyond all eyesores (names withheld to protect the guilty).

Odds are if you are a mad code-monkey set on a life of fame and fortune as a lone-wolf developer, you fall into the last category.  Me?  I can draw.  I was an artist before I was a programmer.  I’m not brilliant, but click that link and check out my deviantArt page — if you are looking for art tutorials, odds are you would consider hiring me to do your art.  Provided you had the money, and the style was right, of course.

(And hey, if your game is truly awesome, and I have a reason to believe it will get done, contact me at the email on the About page, and we can talk turkey.)

I think I can help you out.  I’m a decent (but not fantastic) programmer, and a decent (but not fantastic) artist, and with these two skills, perhaps I can serve as a bridge between programming and art so that you can walk across my burly1 shoulders to the promised land of awe-inspiring (or at least awesome thematic unity) programmer art!

Let’s do this crazy thing.

So, my next series of games, the Super Crossover Arcade series, is going full-on retro with pixel art because I can make pixel art look good at a relatively fast pace.  And over the course of several tutorials, I’m going to let you in on all of my dark secrets, as I can’t find many decent tutorials out there besides Derek Yu’s.

The first dark secret is the power of the silhouette.

Continue Reading >>