I hammered out a small game in around 9 hours as a pre-Ludum warm up.  Mostly I did it to explore the Flashdevelop IDE and Flex 4 SDK, along with the Flixel library to get right into coding game logic.  Thanks to my friend for pointing me in that direction!

It’s a silly little platformer game where you drive a jumping tank around.  It’s a kinda-sorta remake of the first game I ever made on my first IBM PC, using GWBASIC.

Anyway, this will be my first Ludum Dare and I’m quite excited about it!

I flounded a bit.  I admit, I wasn’t really prepared for the islands theme.  But I think I finally hammered something out that should be A) doable in the time allotted, and B) fun, C) something I can code up easily.

The idea is that you are a volcano god.  A jealous one.  (Is there any other?)  You’ve got your happy little islands, filled with worshiping natives, but then you become aware that some other miscreants on OTHER islands are worshiping another volcano god.  This will not do!

Here’s my concept screenshot:

So, it’s time you start putting all that worship energy to good use — by launching fireballs at the other god’s islands!  Every time you hit one island, you kill some of the natives, but also knock off a few who then swim to nearby islands.  This increases the worship power coming from a single island (allowing the god to fire it faster), but if all islands are sunk, the other god is out of the game.  Who wants a god that nobody is left alive to worship?

Well, okay, it sounds simple and maybe a little stupid, but it’s the best I’ve seen.  Props to Ember for giving me the idea!  Anyway, it’ll be fun coding all those little native behaviors!

I’m moving pretty slow, I admit.  But I do have a little bit to show.

Jealous Gods: Prototype #1

There’s not much to see, but all the internal structure data is in the game.  Level definitions, where to position the islands, what their initial populations are, etc.

Right.  I faffed about too long in Photoshop, making my little pixel islanders.  But they’re done, at least.  I won’t have to animate them anymore.

Latest build is “playable” if you click on the screenshot.

Tags: screenshot

FWOOSH! WHEE!

Now, to make the fireballs actually do something to my poor little islanders…

Tags: screenshot

Still participating!  Unfortunately, due to interruptions (including a rather nasty storm!), my progress hasn’t been so great.  I had a good start, but the last 24 hours has been awful!

You can see my progress below.  Everything is working, there just needs to be a game.   You can launch fireballs at the other god’s island, and the AI will do the same back to you, but the mechanics are still mostly not there.

Link on the image below to try it out!

Tags: screenshot

Well, it’s done.  Kinda.  It’s broke — first level works OK, but all levels beyond are bugged.  You can still beat the game, but the AI won’t put up a fight after the first level. Fixed!

Click the link to play:

Jealous Gods by ChainedLupine

I’m way tired.  I’ll post more about it later.

Tags: final

I already posted a mini-postmortem in my submission screen, but here’s my expanded version.

First up, I want to give a big shout out to everybody who contributed to Ludum Dare, and to those who made this entire site and contest a reality.  It’s great to see so many people active a community focused on game development.  While this was my first Ludum Dare 48, I’ve participated in community-driven game competitions before and it’s always been a blast.  LD48 was no exception.

Here’s a summary:

• Lack of working debugger/inspector meant much gnashing of teeth.
• Unfamiliarity with Flixel library/AS3 specifics cost me time.
• Spent too much time getting art into a state that was usable.
• Generally spent too much time arguing with my tools, and not enough refining gameplay.

Friday:

The islands theme sort of threw me for a loop.  I wasn’t expecting it, and in fact had down-voted it. But, in retrospect, I admit it’s a good theme.  It’s open enough that people were able to do some really cool and interesting things with it.

After grousing over the theme for a bit and finally having a flash of inspiration, I sat down and sketched up concept art.  I half-expected it to end up as my final art, so I spent more time on than I might normally.  Later, I’m glad I did this.

Now I had a gameplay idea, concept, and a bit of art.  The next step was dumping the art into separate sprites and making sure they were properly configured to work in Flixel.  This part cost me a fair amount of time.  My original idea to use Cosmigo’s ProMotion and do strict pixel art would have been easier on my mouse-hand.

I then created a project in FlashDev and made sure that all of my assets would load up properly via Flixel.  After that, I coded the scrolling background.  My original sketch had everything on one screen, but I felt a bit constrained so I enabled a larger, scrolling playfield in order to make the game level more expansive.  However, I wasn’t able to properly enable the off-screen indicators for enemy islands/fireballs, so I felt that hurt the gameplay in the end by making the game a little confusing.  It would have just been simpler to keep everything on-screen;  Most of the levels I designed did this anyway.

The final bit I accomplished before turning in for the first day was to sketch the little animated islanders in Photoshop.  Photoshop is not meant for pixel art, I’ve found.  It’s incredibly annoying to use for this task.   More time wasted!  But once I was done, I had idle, running, swimming, burning, and praying animations.  This is all I needed from the little guys, so I could at least sign off on them.

After writing the Native class and making sure the little guys spawned properly, I decided to call it a night.

Saturday:

Ugh!  Nasty storms!  They kept me offline until later in the day.  Boo!

Once I finally was able to get back into my form, I started work on the most critical aspect of the game;  Animated fireballs that could be launched at the other islands.  This part was fun, but my unfamiliarity with Flixel started to rear its ugly head.  This resulted in some digging in Flixel code in order to grok the purpose of the FlxEmitter class and how to bend it to my needs.

Then, more time tweaking it so that I could have a dozen fireballs onscreen without grinding my system to a halt.  At the time, I was unaware of the profiling functions in Flixel, so I could have cut out some of the guesswork with this.

Next I finished the animation state code for the islanders.  They convincingly milled about on my islands, and occasionally went to their knees and prayed, but at the time this was just a visual effect.

The final thing I completed before calling it a night as implement the fireball arc code, so that they fell convincingly, and the collision code, so that the fireballs landed on the islands.  The collision code kept me up for a while.  There was some silly little overlooked error that prevented the fireballs from exploding properly.   I don’t even remember what it was, exactly.

Sunday:

Hoo boy!  Down less than 12 hours, I didn’t have a working game at all.  I just had pieces.

The spawning code for islands worked.  You could launch fireballs and they would impact the other islands, set natives into poofs of flame.  This was all fun, and such, but not a real game.

First up was writing the prayer-power system.  Islanders prayed, increasing power, which powered the fireballs.  I also coded the health/power bar system and drew two little Tiki heads to represent the gods.  Unfortunately, I didn’t have enough time to add in an expanded graphic of your islanders worshiping your Tiki (the horned red-eyed god), which would have clued a player in which of the two sets of islands they controlled.  (Hence the odd left gap in the dialog boxes, and the confusion some pointed out about where to aim the fireballs. :))

This was all cute, but disaster struck!  Sometimes, when destroying an island, my islanders would swim to a nearby island and join it (as intended).  However, they wouldn’t stop joining.  The game quickly crawled to a halt when over 50,000 sprites were rendered.  Oops!  A lack of a Flash debugger really hurt me here.  I wasn’t aware that the Flex SDK comes with fdb, so I had to debug the old fashioned way:  Hack and slash until the problem went away.  I eventually narrowed it down to a bug in the abandonment routine, which checked to make sure the islanders were swimming towards a still-existing island.

The final pieces were falling into place, but I was quickly running out of time.  I wrote a very simple AI, which simply only had one job due to unfinished game mechanics:  Select where to aim on the screen.  That wasn’t too difficult, but a subtle bug would later come to bite me concerning AI aiming…

There were two components left for what I considered a”complete” game:  The bumper code, which is my term for things like overall game state transition, level changes, and so on.  And the construction of at least three levels.

The bumper code wasn’t hard to write.  Just simple state transitions, a quick five minute title/won-the-game screen.  But this is when the subtle bug reared its ugly head.  I had less than 15 minutes to the deadline, but when you switched levels, the AI pulled a brilliant move of randomly flinging fireballs instead of aiming at the player-controlled islands!  Argh!

I went ahead and submitted the game as-is, not realizing that we are given a chance to fix such game-breaking bugs after the deadline.

I managed to find the cause of the bug a mere five minutes after I hit submit;  When changing level states, I wasn’t clearing the AI targeting parameters.  As simple as the AI was, it just targeted the same (now non-existent) island location as before.

This was due to oversight caused by my rushing.  Instead of taking the sane route of simply switching game-states between levels (and storing persistent info elsewhere), I tried to cram everything into the same state and just cleared the commonly data structures between levels.  I mean, the game isn’t that complicated, right?  This is where having no working runtime inspector/debugger really hurt me.

In Closing

All-in-all I had a blast!  And the resultant game is, IMHO, worthy of pursuing as its own complete project entirely outside of LD48 even if it doesn’t come close to winning.  I couldn’t ask for more!

See all of you next time.

Tags: LD17, postmortem

Capslock Adventure - It lives!

So you know my fake entry for PoV’s test of the new layout?

Well, it’s no so fake anymore.  It includes kinda-authentic disk loading sounds!  Once I am done and it’s playable, I will post a link to it for those who dare challenge the dreaded wizard lowercase!

I’m having lots of fun putting together this little warm-up game for Ludum Dare #18.

This will be my second Ludum Dare, and this time I hope to have a playable game at the end of it.  In #17, I spent far too much time tweaking the visuals on my last entry.  It might have looked nice, but it wasn’t very playable, and for that I apologize.  I will try to pace myself this time.

I will likely be using my standard platform for quickie games, which is Flash.  For tools, it’s the usual suspects: FlashDevelop and the spiffy and lightweight 2D app library Flixel.  And for content?  Photoshop, Musagi, sfxr, the usual trio.

As I’ve mentioned, I will be using Flash plus Flixel 2.35 stable for my LudumDare #18 entry.  But, I’ve modified my 2.35 version slightly, and so I am making a diff patch of my changes available here:  ChainedLupine’s diff-patch of Flixel 2.35

It’s not a whole lot.  Mostly it’s just small convenience patches, plus I integrated Photon Storm’s FlxBitmapFont class.

For my IDE, I will be using FlashDevelop along with rnelson’s FlexDbg plugin.

Oh, and here is my work station:

Kinda messy.

I’d really go for that theme.  (It’s been suggested that it be called anachronism, which I support.)

In fact, I should publish my FlavorC64 library just for this.  It’s not true emulation, unless you consider emulating slow, grinding disk access and flickering scan-line effects as emulation.

Oh, and it uses HiRes mode unrealistically, too, pretending that it’s just a straight 4-bit bitmap instead of using 8×8 cell attributes.

FlavorC64 is done.  Clicky the above screenshot in order to try it out.

What is it?  It’s a short bit of code I wrote to make C64-like visual displays in Actionscript 3.  It is not an emulator!

Here is the library itself.

And this is the source to the above FlavorC64 test app.

And finally, this is the required patch for Flixel which is necessary to make this work.

Note:  Apply this rev5 patch first.

It’s all very ugly and undocumented code, of course.

PS: Big thanks to Nossat, who provided the disk loading sound.  It’s not a real 1451 drive, but an Amiga 3000 floppy drive that I munged a bit to try to sound similar.

Impressive, is it not?

Well, I’m about to call it a night.  I’ve made a lot of progress with my game, and I hope I can finish up the basics of gameplay, tomorrow.

Here’s a screenshot:

Update:  You can play what I’ve got so far, just by clicking this link.  Try to lead the green guy to the red guy!

Well, I’ve only just started to get into the groove of stuff after my first day, but there are more updates to my game.

Red enemies will attack blue, and vice versa.  (Currently, the unarmed guards won’t punch other guards, but will in the future.)

See if you can get all the red guards to kill blue, or vice versa.

(Press R to restart the level, in case you die.)

Click image to play!

Whoops!  I noticed I forgot to enclose the whole thing in a frame.  It looks pretty silly.  I just fixed that.

I’m happy!  Ahead of the game here…  17 hours left in order to get a nap then work on some levels.  Woo!

Sorry, no playable snapshot at the moment.  But here are some screenshots:

An idea of what is going on:  You are an infiltrator into a military base which has been occupied by two armies.  Resources are low, so you have no weapons, but your mission is kill everybody in the base while making your way to the next area.  Enemies can be made to respond by your approach.  From there, you can either use in-world hazards or other enemies to dispatch them.

I want to thank everybody who tried out my Ludum Dare #18 entry, Infiltrator. In particular, special thanks to those who took the time to comment and vote on my entry. You can still play/vote for my game right now, just click on the banner!

This was my second Ludum Dare, and despite the warnings from senior Darers plus my own analysis of my previous performance, I ended up making a few old mistakes and plenty of new ones. I’ll cover that in…

ChainedLupine’s post-mortem for Ludum Dare #18: Infiltrator.

First 12 hours – Friday night to early Saturday morning

Friday was relatively uneventful. When the theme was announced, I knew that a majority of the games were going to try to use enemies literally was weapons. I wanted to try a more subtle approach, in that the player would not have a weapon of his own save his cunning and speed. The first thing that popped into my head was an infiltration game which relied upon stealth. The player would never directly pick up and use a gun, but instead would have to use his wits to survive.

I didn’t even need to do much idea sketching; My idea was a top-down game, using beams of shadow as a place to hide, plus a visible sight cone that would indicate where the enemies were looking. More ideas naturally came from this: Doors that needed enemies to be unlocked, holes that they could fall into, mines to step on, automated sentries that could be reprogrammed and utilized against enemies, etc. It wasn’t hard to fill my notebook with ideas.

The problem was choosing ideas that would be doable in 48 hours.

I decided that this criteria was important for my game:

• Working game-play. I didn’t want a repeat of my LD#17 entry, where the game was visually complete but not very fun due to running out of time to implement core game-play.
• Having more than just one or two levels, but a complete map that folks could explore.
• Completed and stable bumper code. I call bumper code all the pre- and post-functionality of a game. Title screen, level selection and transition, etc.
• Finish art/sound early in the development cycle.
• Have a series of building blocks that I use in a level editor in order to construct the aforementioned wide and expansive levels.

All of these I accomplished save the second. I ran out of time, due to the abundance of ideas and the complexity of implementing all of the last requirement. Building blocks are nice and open up possibility, but I learned the hard way that Infiltrator was at its core a puzzle game. And a puzzle game is very difficult to do in 48 hours unless it’s very simple.

I started to write the code for the game. This wasn’t difficult, as it was fairly simple. The primary difficulty would be in fine-tuning the game-play so that it was fair but flexible enough. Within an hour, I had a simple level displayed onscreen.

I spent some time making pixel art. Creating the over-head perspective man character was going to be simple; I intended to reuse that sprite extensively by re-coloring it programatically. After animating the sprite, I created some basic level tiles. I probably spent an hour tops on both of these tasks combined, and I am glad I did. I would later have very little time to spend on assets.

At the end of the first day, I had most of the game-play mechanics in place. You could run around in the level, attract guard’s attention, lead them to each other, and then get them to kill one another.

At this point, I decided to sleep, to prepare me for the largest phase: Finishing the bumper code and adding the rest of the game-play mechanics.

Next eighteen hours – Saturday noon to Sunday morning

This was the gritty time. I had to write all of the game-play features and finish the bumper code.

Once I had the core level parsing system in place, I decided to create a “How to Play” tutorial level. Perhaps this wasn’t all that wise, considering how I would end up running out time on Sunday, but I knew that the game’s objectives wouldn’t entirely obvious from the start, and it would be good to give the player a fairly calm level in which to test the game-play mechanics out.

The bumper code was easy to do. Tedious, but I had already thoroughly tested the system for switching levels during the creation of such system. I added a timed-score mode that eventually would not matter much. Unfortunately, the timed mode didn’t fit in with the radical change of level design that occurred on Sunday.

By the end of Saturday, I knew had a really solid and fun game. I was quite excited, and my brain was filled with ideas. It was then that I started to consider switching from a linear game to a more exploratory style level design.

In the final hours of Saturday, I spent a lot of time implementing tanks. I wanted there to be a heavily-armored enemy that could not be easily lured to death by the player. It would require a massed effort in order to take down a tank, via scripted level objectives. I ran out of time to put these script hooks into place, and in the end just used the tank like a nastier, meaner form of a soldier. By having mines destroy it instantly, it wasn’t quite as deadly as I intended.

Final ten hours – Sunday morning to Sunday evening

For designing levels and basic tile-map editing, I used a program called Flan.

Here is a screen shot of the first level I made for Infiltrator:

I wanted to keep the game as data-driven as possible. So all level control logic occurs from the level itself. Two tile-maps are loaded. The first is the displayed level itself. This contains all the necessary collision/shadow information for the entire level.

Next is a control level. Tiles are placed in this level to control how the level responds. “h” is a hole, the crate icon places a crate, the “s”/”sg” tiles place soldiers (or soldiers with guns, respectively). Surrounding the enemy tiles are toggle logic for the enemies, such as their initial facing direction and what team they belong to.

The idea being that once all of this was in place, all I had to do was spend the last ten hours or so making levels. Unfortunately, I only realized during that final ten hours, I had over-allotted the amount of content and under-allotted the time needed to complete levels based upon it.

In the end, level design was my downfall. I had a great series of building blocks, but not enough time to assemble them together!

It also didn’t help that I made a few last-minute design decisions which required me to swap out of level-editing mode and back into coding. For example, I had originally intended the game to be linear. You just progressed from level A to level B, until level n, when the game would end. But as I was making levels, I realized that a more open structure would fit the game better. So in the end, I didn’t actually use much of the time-trial code which I had put into place on Saturday. Only the secondary levels which can be accessed from the main base are timed.

The only purpose for those levels ended up just score-related, when in reality, I had wanted to include a story and a set of objectives. But, again, too much I wanted to do, and not enough time.

So, that was that. I finished up the final levels, packed it up, and posted it on the web page as an entry.

What went right

• Actually finished it.
• Feature-rich game for such a short time.
• Emergent game-play made it fun, according to those whom I had test.
• Finished most of my objectives concerning this Ludum Dare.

What went wrong

• Too broad of a scope for a LD48 competition.
• Not enough time allotted for level design.
• “Wouldn’t it be cool if…” interfered too much with core objectives.
• Spent too much time testing out components that would never be fully utilized.

Tags: LD18, post-mortem

Since there was such a good response to my LD#18 entry entitled Infiltrator, I’ve been working on-and-off on a post-compo edition. It’s nearly done.

A list of what I have done so far can be found by clicking “read more.” (For now, just a raw dump of my changelog summaries. I’ll put together a more complete list of what’s new once I am done.)

• Implemented running (use SHIFT)
• Implemented sound and oneway flags for triggers
• Added beeping sound effects for timer counter
• Reworked munitions dump level
• Added background tile layer
• Added transparent shadows
• Added smoother level transitions
• Added full level save-state recording (well, most)
• Clarified “neutral” enemies (which are now in same clan as player)
• Mines now leave scorchmarks
• Fixed player HUD being overlapped by game objects
• Redid level triggers so a desc can be given at same time
• Further fleshing out tutorial level (added explanation for continue pads)
• Added resume game function, which uses a Flash cookie to store all level states
• Added ability to save/continue game
• Added new large explosion for mines/rockets
• Soldiers now leave dead bodies (which can be thrown by large explosions)
• Soldier pathfinding fully in place
• Soldiers can now patrol along pre-defined routes
• Holes dynamically added/removed from Astar nodegraph
• Added Pathfind testing level
• Added ability for troops to return to original spawn point via pathfinding
• Implemented Astar pathfinding
• Added continue points in levels
• Redid door/sensor tiles
• HUGE performance increase in enemy rendering: Only re-generating sight-cones when changed
• Levels are now loaded from XML files and no longer hard-coded
• Added must-kill-enemy flag to doors
• Expanded intro level to teach about must-kill-enemy doors and mines
• Slightly improved the tile artwork

Winter-y greetings to everyone! I’m all excited for this festive Ludum Dare. I know it will be tons of fun.

This will be my third Ludum Dare. I’m not a veteran yet, but I think I’m starting to get the hang of things. I more-or-less follow Sol’s tricks and tips, plus or minus some of the more saner advice. *cough*

In fact, I enjoy it so much that I’ve had great success applying the Ludum Dare method to my projects. It’s great to get a prototype up and running in a mere 48 hours.

This Ludum Dare will be different for me! More on that later, when I figure exactly how it will be different. What I do know for sure is that I’ll be doing my Ludum challenge along with a friend. We haven’t decided yet if we’re going to team up for a Jam game or do our own separate projects. Either way, it should be fun.

I’ll post about my tools/libraries later, as I intend to release my Flixel code base with lots of improvements over last year.

Alright, now that I have some time to finish this up, I am declaring what I will be using, and sharing my basecode. Actually, baselibrary.

I’ll continue to develop in Actionscript3, using the Flex compiler. My IDE will remain FlashDevelop, as I am quite happy with it since I discovered the FlxDebug plugin. My graphics library will be Flixel.

Graphics will be drawn in Photoshop, or InkScape if I end up doing vector art.

Sound? I am not sure yet. SFXR is always there if I end up being lazy, but I might try something different this time.

Basecode? Some. It’s a hodge-podge of miscellaneous stuff, mostly for Flixel. For example, a simple class for drawing status bars, and another for creating scrolling text displays. The kind of crap I end up duplicating over and over, so I just stuck most of it into a separate library.

I’ve been working on a Tiled loader for Flixel. It’s pretty much feature complete*. The nice thing about Tiled levels is that they are more than just tilemaps, but can contain any amount of meta-data in so-called “object layers.” It’s decent if you’re into 2D tilemaps.

Anyway, here is the library as-is: gwslib Note that I use the fast SHA1 available here.

I wrote some Astar pathfinder stuff to go along with that, but it’s a bit broken at the moment. I will try to get it working before tomorrow afternoon.

*As long as you use the QT version of Tiled, and don’t use isometric tiles.

Tags: basecode, Flixel, LD19, Tiled