So at the end of 2010, Ludum Dare hosted the “October Challenge” .. This was the CHALLENGE:

Make a game — take it to market — sell 1 copy (or license it, or earn $1 in ad rev) in one month.

So, with my dream of making a commercial game out of Dynamite, this seemed like a perfect opportunity. With a single month time frame it was perfect for seeing what I could do.

Gameplay

Here’s a video of the gameplay. You’ll see it’s almost the same as Dynamite, though I’ve added several types of bombs, which kinda just makes things more complicated. One BIG advantage over classic dynamite is that the “shadow” along the one wall is actually visible so that makes a lot more sense logically, for the stealth part of the game.

Challenge Month

Oh man, it was a ton of fun! I blogged the whole experience. Here’s a “short version” of what went down:

I used the same free graphics I used in Dynamite for the character art.

And started whipping the game into shape really quickly. I was doing this all in my own custom 3D renderer. Which is a crazy thing to do, I think. At the same time, the progress in the first week was really exciting, and I was quite pleased with how the lighting and stuff was coming out. In this game the lighting had little purpose other than to “be pretty.”

Here’s a newer shot of my level editor. The level editor could be used in overhead mode (which was easier to use) or in the iso-view, which was way cooler.

And before the end of the month, I even added in sharing / community features for the level editor to the game. It’s crazy how much stuff I got done in that month!

Paid Beta

So on November 5th, I launched the Paid Beta of the game.

I gotta say, I was pretty stoked about the sweet game I had just made! But that was all about to change … well, eventually 🙂

I got about 50 pre-orders of the game, which was, honestly a bit underwhelming. Lots of indies talk about “we did this pre-order and it paid for our 3 person team’s dev for the last 9 months of development time”. 50 pre-orders paid for .. well .. not that much.

Refunds

So, people seemed to sort of like the game. But over the next couple of months of working on it, I was realizing that it wasn’t coming out as the epic desktop game I had originally envisioned. It seemed to be a better mobile title. So I cancelled the beta. Here’s an excerpt from my blog with the lessons I learned.

Here’s some analysis on the subject, and why it didn’t work for Stealth Target .. and at the same time, the factors I think that would be important to having a successful paid-beta project.

• Commitment to a larger vision. In the case of Stealth Target, I had a larger vision, but I eventually realized it was too grand for me to realize.  I’m more of a small-scale game kind of guy at this point.  Perhaps later in my game development career I’ll be doing larger projects, but right now, a “Galcon-sized” game is about as large as I can manage.  I think paid-beta games need to be larger to justify the whole “user-buy in to help fund an epic game” concept.
• Commitment to regular updates. I’m only one dev, and when I take a month to work on Galcon updates, and then take another month to take a break, suddenly the beta users haven’t heard a peep from me about the game in 3 months.  Pretty weak “paid beta”.  If I had a team and I had someone always working on the beta so it kept living despite my other obligations / plans, it might have gone better.
• Building a development team. Yeah, I just touched on that, but it really does make sense.  I could have a team, but my lifestyle doesn’t allow for it at the moment.  My hours are too random and my work schedule too unpredictable.  To have a team you have to have some consistency in your life, otherwise (I’m pretty sure) your team-members will get pretty tired of you.  I think having a team would help deliver the quantity and quality of content and updates to make a paid beta make sense.
• You can’t change your mind and be crazy. I still plan on finishing Stealth Target, however, I’m no longer planning on doing a desktop release of the game.  The paid beta was for a desktop version of the game.  So changing to a iOS-only plan really isn’t possible.  The only way to cleanly resolve this was to terminate the entire beta and issue refunds.  Really, for a paid-beta to make sense, the users have to have something they can depend on, and changing platforms mid-stream is just asking too much.

But the game was still in development, I was just switching over to targeting iOS instead of a desktop game.

Canceling the Project

So a couple months later I went to GDC with a build of the game in hand. I showed it to a handful of peers and demoing the game was extremely cumbersome, the user interface was .. well .. AWFUL. I could barely play the game on the iOS device I had in hand. I also was starting to feel that the visual feel of the game wasn’t “coming together” in a neat way at all. It looked 3D and all, but it was looking very dodgy overall.

Also, the code was starting to buckle under the weight of what I was doing. I was trying to add fancier lighting effects, which were not working very well 🙁

Adding things like shadows to the player and guard was not going to be possible. Shadows for different height pilars wasn’t working. There was an endless list of issues. And as you can see, the character art just plain looks bad when close up, which is how it was being shown in the game.

After demoing it to some friends at GDC, I decided to cancel the game. Which was really hard to do, I had put 5 months of effort into this game, and putting it down wasn’t easy at all. I realized that though I had some good ideas here, things weren’t working out. It would have taken me at least another 6 months to get the game ready for release and it wasn’t going to come out the way I wanted. I definitely think this was the right decision.

One of the things I’m thankful for is, by being an indie, I GET TO MAKE MY DECISIONS. So even though it was one of the hardest things I’ve done as a game dev, it was my choice. It wasn’t made by some corporate overlord, who suddenly took away the last 6 months of my life. It was my choice. I can’t imagine how hard it is to have part of your life taken away like that when you have no say in it. I’m very thankful that I’m able to make games as an indie.

Going Forward

Thankfully, six months later, I began work on what is now called Dynamite Jack. If you haven’t seen it, here’s the trailer, to give you an idea of how it came out.

Some of the lessons I learned because of the Stealth Target failure:

• Don’t use 3D. For a small-scale indie, using 2D is soo much easier. I’m able to do all these cool lighting effects without having to be some kind of genius.
• Don’t use weird controls. Arrow keys / Gamepad works WAAAY better for this type of player navigation.
• Don’t confuse the user with too many types of bombs. In Dynamite Jack, there is one. And it gets the job done.

Those aren’t LAWS for everyone, but learning those lessons while creating Stealth Target enabled me to finally create the game I wanted to make.

I’ll be blogging about more of the dev of Dynamite Jack over the coming week. The game is coming out on May 10th to Steam on PC and Mac.

While developing Dynamite Jack, my pal and co-host from Ludum Dare, Mike Kasprzak suggested that the deaths didn’t have enough emotional impact. So I added more awesome deaths. ROGER WILCO STYLE.

Enjoy the Anathema Mines Chamber of Commerce Video:

When I first added in these crazy post-death animation sequences, I kind of felt they might be a bit “over the top” for my game .. So I added an option to toggle them on or off:

But they are so much fun, well, I’ve got it default to have them on 🙂 But if you find them too gruesome (or silly), you have the option to turn them off.

During the game play, deaths are frequent, so they are only 2 seconds long. This keeps the flow and rhythm moving at a nice fast pace. The leaderboards of the game include the time it took you to complete the level as well as how many times you bit the dust 🙂

Anyway, the game is coming out May 10th! Hope you’ll enjoy it!

-Phil

Hey there… This happens to me sometimes. I want to be able to turn on a debug mode or a tool that will crash my code during runtime. I can use Xcode, MSVC 2008, or GCC under Linux. Anything. Though, XCode is preferred. This must work with C++, not just C code.

// I don't want to change my code.  I don't want to use Array templates.
// I just want a debugging tool that will crash my code when I do 
// array out-of-bounds, even if they are "safe."  Here's my example.

struct Goods {
    int x[10];
    int y[10];
    int z[10];
};

int main(int argc, char *argv[]) {
    Goods data;
    
    int k = 11;
    for (int i=0; i<k; i++) { data.y[i] = 1; } // SHOULD ERROR ON i == 10

    int j = -1;
    for (int i=j; i<10; i++) { data.y[i] = 1; } // SHOULD ERROR ON i == -1
 
    return 0;
}

Changing my code, using STL, using “new”, using “malloc” are not options.

Help me!
-Phil

So about six months after I created “Escape from Anathema Mines” during the Ludum Dare game jam, I created a game called Dynamite in the PyWeek game jam.

Theme

So the theme of PyWeek #1 was “Power” .. I worked with my brother-in-law Tim on this game, and we spent a fair amount of time working with the idea of using a “mind control power” over the characters in game. So I wrote some A* code to navigate things around and whatnot. This was boring. So I made it so you could blow something up. This was exciting. We decided “the power of dynamite” was what the game was about, since the dictionary definition of dynamite said something about “a powerful explosive.” Not my best “theme compliance” for a game jam, I’ll admit.

Gameplay

The best way to see the gameplay is to PLAY THE GAME if you have Windows 🙂 (Download the post-compo version, it’s a little shinier.) But short of that, watch me play through one of the levels. There’s a ton of interesting differences between this and Dynamite Jack. The most significant one is that in Dynamite you can “fail” really easily. You can block yourself into a corner by destroying the floor, and you can run out of bombs. Those are both design decisions I changed for Dynamite Jack.

Fun facts

Tim created all the music for this game, one of the tracks is based on a fiddle tune as well. You may be able to tell that the character art in this game is the same character art I ended up using in Dynamite Jack. It’s all from Reiner’s Tilesets. It definitely helped a ton to have that art work. It ends up looking really sharp in Dynamite Jack because I scale things down so small.

I also brought the “dynamite drop” sound effect from this game into Dynamite Jack. It just sounds so cool.

Post-Mortem

I think one of the big gameplay mechanics I like in that game is that when you sneak along the walls you are invisible to the guards. It kinda leaves the “lighting effects” to your imagination. But one of the problems with that is that it’s not very obvious. I used the different colored cursor to help the player be able to know where the safe zones were.

This game introduced the fun of having guards running to check out whatever you just exploded. I did the voice acting in this prototype of the game.

The idea of this game really stuck with me for a long time, so for the next several years I always talked about going back and re-making it.

TO BE CONTINUED …

(Dynamite Jack is coming to PC / Mac in mid-May. Check out the trailer to see the difference from the original shown here.)

I’m gonna dig into some of the tech behind Dynamite Jack, so hold onto your seats.

So, a lot of devs are into Component Object game design. That article is by a friend of mine who goes into a good overview of a lot about the model. Anyway, you could probably spend all day reading the resources he links to. The short version (as I see it): Ideal Component Object game design is like a Normalized Database. It basically means, it’s kind of a chore to get it working but it’s super flexible and powerful.

I thought that was interesting. So I went to a talk at 360iDev by Gareth Jenkins. He demonstrated how to do component architecture with real concrete examples, which really helped me get my head around the idea. But the most profound bit of the talk was the end, where I remember him saying something like:

“It doesn’t matter HOW you do this, as long as you DO IT.”

That was super freeing for me. The idea that it didn’t matter how hacky I did it, but it would still give me all the benefits was very helpful. So here’s how I do the component object model in Dynamite Jack:

struct Entity {
  bool active;
  bool has_player;
  bool has_guard;
  bool has_light;
  bool has_position;

  int player_state;
  int player_cartridges;

  int guard_state;

  float light_angle;
  float light_radius;
  float light_degrees;

  float position_x;
  float position_y;
};

#define MAX_ENTITIES 64
Entity entities[MAX_ENTITIES];

Now, you’ll see the cool bit is that I have access to all data without creating anything, so no free / delete needed. The simple bit is activating a feature is just a matter of setting “has_light” to on or off. That’s how I actually turn on and off the player’s flashlight in the game.

In the game code, I just loop through all the items and dispatch to various functions for each component type.

void sys_loop() {
  LOOP_ENTITIES() {
    if (e.has_player) { player_loop(e); }
    if (e.has_guard) { guard_loop(e); }
    if (e.has_light) { light_loop(e); }
    if (e.has_position) { position_loop(e); }
  }
}

And I have a similar function for handling events, and painting the screen. It made it really great for prototyping the game and changing features. The “cave trolls” in the game (see at the start of the trailer) had their AI replaced quite a few times, and being able to just hack new things on and change things around without breaking my other entities was really nice!

One of the other nice things about having it explicitly in code, as opposed to “registering” things magically, is that I can see exactly in my code what order the components are being run in, so if something depends on something else, I can be sure they are in the right order.

Dynamite Jack has 20 different “components” but they all lie in the same big structure. Another cool one is having an “action” component, which doesn’t even exist in the game, it’s just a timer to trigger some future event. With everything being an Entity, it just gets it’s own loop called, and is able to do whatever.

So, yeah, my method gives me only a single Class, as many components as I like, and the flexibility to mix and match stuff. The power to toggle components on and off. And a fixed amount of memory used. So easy “save to file” style serialization of the game state.

Anyway, that’s the tech for the day. I definitely recommend component systems, it makes it SO EASY to try new things with your game, and be able to tweak them until they work “just right”.

-Phil

P.S. If you’re looking for the code on how to do this, it’s all in this post. It really can be THAT SIMPLE 🙂

Hey there, here’s something I thought you might be interested in, a fast motion replay of me building a level for Dynamite Jack.

The level editor is not included in the game, because right now the interface is a little tricky 🙂 But if enough people are interested I’ll probably add it in an update after the game launches.

Right now it uses a combination of keyboard and mouse controls. It’s pretty fast for me to make levels, and I’ve designed it mainly for my speed in prototyping and editing together new levels. It has worked pretty well. The editor only has a single “layer” .. so the background and foreground are all one layer, which makes it so some stuff isn’t possible, but in general, it made things way simpler for me to build levels.

Cheers!
-Phil

The development of Dynamite Jack was a really involved and long-term project. The project started almost exactly SEVEN YEARS AGO. I’m going to do a series of blog posts over the next few weeks leading up to the release of Dynamite Jack highlighting both the features of the game, the development of the current version of the game, and the unique history that went into the development of this game.

Seven Years Ago Today …

The first prototype I created of this game idea was during the 6th Ludum Dare game jam. This was only my second game jam I ever participated in, and it was an amazing experience. I was learning how participating in game jams stretched me as a game designer, so instead of just saying to myself, “hey, I’ll make a Mario 3 clone today!” I was given a specific theme that I had to design a game around!

Light and Darkness

The theme was light and darkness, which today I still think was one of the greatest themes ever for a game jam. It brought a ton of unique concepts out of all the developers who participated in that jam. My game was called “Escape from Anathema Mines”:

The Gameplay

To give you an idea of the gameplay, well, you can play the game on Windows, maybe. Or using pygame, if you know how to get that working. Or, you can just watch this video of me attempting to play the game today 🙂

Some differences in the gameplay from Dynamite Jack are – in the original, the flashlight could run out of batteries. The guard could hear you when your flashlight was turned on. And if you took too long, you’d run out of time for no apparent reason.

Fun Facts

The name “Anathema Mines” was inspired by a greek word I heard in a sermon meaning totally accursed. This seemed to match my feelings for being forced to work in salt mines, so I went with it for the name of the game. The speaker who taught me that greek word, Lyn, posed for the totally awesome title screen art of the game.

Also, the music in the game is based on a fiddle tune that I knew called “Tennpenny Bit” .. You can hear a rustic recording of a band I was in playing it about 7 years ago here listed under “Two Dinners and Sunday Brunch”.

The Post-Post Mortem

After a game jam I often write up a post-mortem of what went right and wrong in the dev of the game. I’ve posted that in verbatim below. I’ve included my “hindsight” comments highlighted in yellow, so you can see what I think of my analysis of the game seven years later 🙂

This year I spent around 2 hours planning before I actually started writing my game. I also bounced ideas around with some friends to come up with a really good game concept. I believe spending this time planning before actually creating really helped out in the fun factor this year. Last year my fun score was fairly low. My first jam game was called “Cuzco’s Goat Bloat Game” and it featured my pet goat Cuzco .. but it was crazy hard to play

I used pygame again this year to great success. I love pygame, and I still use it for jams sometimes. Python is the best. It was easy to get my game up and running and working quite nicely by the time the contest came around. I also used my own level and tile editors, which helped save a good deal of time. I also was able to use my MR-8 for recording sound effects, ModPlug and n-track for creating the music. I was quite pleased with the quality of audio I was able to create in about 2 hours. I also utilized friends to do play testing. This also helped in the fun factor, as I was able to get some good feedback on what parts of the game were fun, what levels were too hard, etc. I’ve done a ton of this for Dynamite Jack. It really helps. My wife, Nan, is the primary tester of Dynamite Jack, and if she doesn’t like a level, she won’t play the game again until I remove it from the game. I was also pleased to have enough time to create 5 levels for the contest, giving my game a fairly complete feel.

For next time, I am interested in learning a 3-D kit so that I can do fancier graphics. My game would have still been a 2-D game, but with the added light effects, I think that would have helped my production. I did just that for Dynamite Jack. Jack is written using OpenGL, but I have the game in 2-D mode all the time, so I never use any 3-D effects. I also don’t actually use the OpenGL lighting features, I pre-calculate all the lighting in my code. But being able to have vertex colors makes the nice shading in Dynamite Jack. Escape From Anathema Mines was written in PyGame which is based on SDL, and I only had simple blitting of images. The effects that I managed in this early prototype are actually doing a cool job of pushing the boundaries of what pygame was able to do.

The Good

• Prep: I made sure all my tools were installed and working before the contest
• Planning: gave me considrable direction and a better starting idea
• Tools: pygame, pgu (level and tile editors), ModPlug, n-track, Audacity
• Windows: knowing how to use py2exe
• Testing: Having lots of it. Game play came out good, and no critical bugs were in the contest edition.
• Time: Managing time from most important features to least

The Bad

• Tools: wish I had 3-D tool knowledge to do my lighting effects and hi-res graphics.
• Testing and Time: wish I had more time to do more to weed out the last few non-critical bugs, but you can only do so much in 48 hours.

Glaring omission here: the horrible controls! You can see in that video how I’m barely able to control the main character. He moves like a go-cart or something. I have no idea why I designed it with “rotate left” / “rotate right” / “forward” / “reverse” controls instead of just using the arrow keys as ARROW KEYS.

Going Forward

Going forward, well, my game only placed about 8th place in the competition, and nobody was super into the game at that point, so I didn’t bother to do anything with it beyond doing a few post-competition tweaks to the game. Thus Anathema Mines was put aside for quite some time.

TO BE CONTINUED …

(Dynamite Jack is coming to PC / Mac in mid-May. Check out the trailer to see the difference from the original shown here.)

Hey everybody! I’ve got a game coming out in May for PC / Mac.

Check out the website / trailer!

Be one of the first to Like the facebook page or follow the Twitter! I’ll be posting a ton of interesting stuff about the game over the next few weeks!

-Phil