The last time I participated in LD was around like LD4/5 or thereabouts. Back then I was still in college, and I used Python/pygame 😉 This time around…I’m in commercial gamedev now, as a designer. My first shipped title is a License: The Game, and I used some pitifully underdeveloped level editing and scripting technology to create gameplay for it. My view of commercial game design from this experience: your role model is MacGuyver, as you often have so little to work with.

But as for LD… as a hobby project I’ve been developing some technology for Flash 9 that uses both Flex mxmlc and haXe. It’s not quite as done as I would like…also I’ve had a mystery illness(first tiredness, diarrhea, vomiting – later, mild fever and dizziness) that I might not be recovered from….I left work early yesterday and when I got home I slept for about 12 hours.

Either way, I feel now that LD is not really about making a good game in the time period – rather it’s about going from no game to the beginnings of one. That makes it a good test-case for the tech I’ve been working on. Especially since the ultimate goal of this tech is: “A game per week, every week.” Once-per-week – at a good quality – will probably become possible only after I’ve done a few games with it, though, and I have some ready-made gameplay/menus/etc. to work off of.

For LD I’m only starting from my graphics work. Since I do not use the Flash IDE it is easier to generate pixel art — and I feel that it is also easier to make pixel art look good, if you keep the resolution low. Hence I’m using a 348×276 resolution with 12×12 tiles. I’ve already set up a pipeline for tiled maps using the program Tile Studio. And I have a pipeline for bitmapped fonts using Angelcode Bitmap Font Generator. The challenge will be in the actual gameplay.

Yeah, this may seem early, an hour-and-a-half in, but I was actually feeling my way around how the  toolchain I’ve been developing would actually work in an engine for a few hours beforehand, and decided that the whole concept needed a do-over. Feeling out those problems with was my real goal, and I’ve got tummy-aches from my illness(it is being mean and nasty and letting me only tolerate sugar water and maybe some milk), so I’m not gonna stress over it.

I just finished off 10 months of work on a Flash game and started it on the sponsorship process earlier this week. You can see the trailer here. This also means – more importantly – that I am free to participate in LD, which I haven’t done in years

Tools I’m using:

haXe/swfmill/SamHaXe – the haXe langage compiles to Flash and several other platforms; combined with swfmill and SamHaXe a full set of swf-building tools is available.

“Fireball” – an open source game engine/framework I’m working on for haXe and Flash. I didn’t get to really use it for my last project other than some experiments, so this is the first “real” test. The main feature is “live updates”, being able to download and use new assets as the game runs for fast iteration during development, and then being able to build solid swfs with preloaders without any additional work(just a different build script). The parts outside of loading assets are much less developed though. Until today the only things really working were basic timing, game startup, input events, FPS monitoring, and some scary unfinished sprite animation code. I banged out text rendering, various timing helpers, and some preliminary tilemap stuff today, and tomorrow I’m planning to put together the necessary asset pipeline to do a simple Roguelike/tile-based game with some sound. I think that’s all I can hope for for this LD48, anything more technically complex and I’d get stuck on collision bugs. You may view Fireball here but I don’t recommend trying it yet, since it’s unfinished and not really documented. Demo will come by Monday 😉

cosmigo Pro Motion – a great pixel art tool, possibly the best.

Acoustica Mixcraft – one of three music programs I may use, this one is my favorite for clip and loop-based composition. Since time is short, I may just bash out a loop-only track in an hour or two.

Renoise – another music program, this one is a tracker and good for creating new loops, sound design or intricate sequences.

Busker – a music program that is made for arrangement and transcription, rather than DAW/sequencing/mixing. If I use this, it’ll be to make a beautiful chord sequence and melody, rather than just “beats.”

In one sentence: “Island puzzles, like Lolo with more destructibility.”

Specific feature ideas:

• Cute PC character (somehow this has to fit into a 20×20 tile without animation)
• Turn-based, on-the-grid movement. High technology is to be avoided for LD.
• Bombs that can be picked up and thrown, but need an external trigger
• A projectile pickup(should it be a rock, a bow+arrow, or a pistol? hmm….) the player can choose when to fire
• Projectiles that, instead of instantly hitting, move at two tiles per turn
• Walls of various kinds, some of which are destructable – but part of the puzzle is to figure out which ones
• Cannons and cannonballs as an alternative to the projectile pickup
• Pirate enemies of various kinds that fire their own projectiles or swing swords when the player is in range! I’ll need to think about simple “AI” patterns that work into a puzzle design.
• Player goal: Make it from one end of the island to the other in each level (docks at either end)
• Stretch feature: Fire that spreads. Don’t know how this would work into a puzzle.

Schedule estimates:

• Basic player movement and collision – 1h
• Create and integrate a tileset in Pro Motion – 3h
• Level layout data files and keys to skip through levels, level exits – 1h
• Implement projectile pickups – 1h
• Implement cannons, bombs and destructability – 1h
• Pirate AI #1 – 1h
• Pirate AI #2 – 1h
• HUD and title screen – 2h
• Create and integrate sound – 5h
• Level design – 5h
• Sleep – ~10h(Running a small deficit is OK, but it’s not worth it to try to power through.)
• Breaks – 6h

Estimate: 37h

I’ll set a tentative milestone for 8:00 on the 24th (PST) to have a one-level demo going.

Then the rest of the time can be spent on fit+finish.

Nothing to show, yet. I took some time to craft the basic structure of the game in a neatly componentized fashion, but I’m sitting right on the threshold of having a screenshottable game showing colored boxes, one of which will be able to move and collide. I just need to do some integration work to load the map file and propagate input. Once I have that, adding more actors and rules will be a snap, so I’ll have real gameplay in just a few more hours of work.

Now I will take a nice long break to eat dinner and see the Goonies, which is playing at midnight at the Del Mar. Whoo.

The project is codenamed “Pincer.” Short snappy codenames are always useful, much better than “the game” or “src” or “Lousy Off-the-Cuff Title.”

The blue square is the player. The grey one is the “dock” he came in on. The red is beach, and the green is grass. These colors are quite arbitrary palette picks, I didn’t align the way they were generated with the tiles using them. I ran into my first difficult bug getting the player to move – because I was doing a translation of linear to 2D coordinates on the map with the y value instead of the x, so he was actually spawning outside the map. Foolishly, I didn’t take a close look at this information before tearing into the collision code.

For dinner I went out to Jeffery’s, a diner just down the road from home, and had a burger, coffee, and coleslaw. Then I saw Goonies. Great ensemble movie, there are few films that feel so rowdy. It got me thinking about my coincidental choice of pirates in the theme too. I can include more in the way of traps – building them, setting bait with gold, etc. I might go that way instead of total destruction. We’ll see.

My sleep schedule happened to be screwed up coming into the start of LD, by the way – I woke up a few minutes after it started. So I’ll probably keep going until dawn breaks or something. I want to have at least a little gameplay before I go to sleep – some pickups and destructables, I guess.

I now have pickups, but it isn’t enough to show that I’d make a screenshot for it. And I took some time to refactor how I did actor-to-actor collision – not to the point of being wholly generic, but enough so that now I call player.checkActorCollision() at the end of each turn and it handles all the player interactions – so I just repeat that template for each actor needing its own collision events. This’ll let me control the order of collision events pretty finely, which is good in a coarse, turn-based sim like this.

It always feels kind of ugly to me to figure out which actor a collision event should occur on – since even though the events always involve two actors, only one of them has to initiate the tests. (even if you have a generic shape-testing system – or in my case, a Roguelike point-testing system, you still have to find a place to do all that “what type of actor, is it invincible, etc.” stuff…) Something I’ve got a few ideas swirling around for. Well, that’s enough writing for now.

I realized that my “tags” (integer identifiers on each actor) would benefit from being combined with their position data, rather than put off in a separate component.

After another brief bug hunt(this one caused by there being two sets of identifiers for the player and pickup, one in the old tag code and one in the tile code) this is now working and the rogue-like collision, which I’ve made part of Fireball’s libraries, is that little bit more useful.

Now, I should really stop dicking around with tech. I’ve got a game to write

I implemented a win condition(touch the “end dock”), 8 (test) levels, and a level skip key (/). The basic framework of the game is almost done – just needs a title and a win screen. Progress!

Now I have some shooting action going. The projectiles spawn, move, and despawn correctly. I probably still want to add the “two steps per turn” thing though. It just seems like it would make the puzzle aspects more engaging to have to calculate relative speeds like that.

Build is up. Arrows to move, space to pass a turn, / to skip levels, WASD to shoot.

New build showing projectiles that move faster than you. This is done by having the main loop call as a function pointer; when projectiles exist it temporarily changes to the code that forces you to watch a frame of the projectiles mid-flight. Somehow, I made this build exactly 30 minutes after the last one. As before, arrows, WASD, space, and /.

This is a “non-report” that I’m doing just because it’s becoming a habit to blog what I’m doing constantly. I took the last half hour or so to fix up some tutorialization issues in Deep Sea Descent pointed out by the kind people at Flash Game License – I just happened to catch the message minutes after it was sent. Nice, simple changes, and I think they made a big difference. So – if nothing else comes up on their end – they’ll have it approved for bids in a few hours, by the time I go to sleep. That would be nice

As far as Pincer goes, I guess I’ll try for limited ammo, a HUD, walls, and explosives by the time I go to bed. Still have more features I want to get to though – pirate AI and player death, gold, maybe some crates to push around….I’m approaching this game as “throw features at the wall and see which ones stick.” I can only do a few more before starting the polishing process though.

Another build, this one came almost an hour and a half after the last one. This one now shows the controls so I don’t have to go and write that here every time 😛 It also has limited ammo – you get one shot from the pickup.

Something cool I used for this is a bit of code I had lying there, not sure that it would come to use: Layout.

This is Layout:

package fireball.gfx.util;

import flash.display.DisplayObject;

class Layout
{

public static inline function sTopbTop(ti : DisplayObject, px : Float) : Int
{
return Std.int(px);
}

public static inline function sTopbCenter(ti : DisplayObject, px : Float) : Int
{
return Std.int(px-ti.height*0.5);
}

public static inline function sTopbBottom(ti : DisplayObject, px : Float) : Int
{
return Std.int(px-ti.height);
}

public static inline function sCenterbTop(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.YRES*0.5+px);
}

public static inline function sCenterbCenterY(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.YRES*0.5+px-ti.height*0.5);
}

public static inline function sCenterbBottom(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.YRES*0.5+px-ti.height);
}

public static inline function sBottombTop(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.YRES-px);
}

public static inline function sBottombCenter(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.YRES-px-ti.height*0.5);
}

public static inline function sBottombBottom(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.YRES-px-ti.height);
}

public static inline function sLeftbLeft(ti : DisplayObject, px : Float) : Int
{
return Std.int(px);
}

public static inline function sLeftbCenter(ti : DisplayObject, px : Float) : Int
{
return Std.int(px-ti.width*0.5);
}

public static inline function sLeftbRight(ti : DisplayObject, px : Float) : Int
{
return Std.int(px-ti.width);
}

public static inline function sCenterbLeft(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.XRES*0.5+px);
}

public static inline function sCenterbCenterX(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.XRES*0.5+px-ti.width*0.5);
}

public static inline function sCenterbRight(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.XRES*0.5+px-ti.width);
}

public static inline function sRightbLeft(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.XRES-px);
}

public static inline function sRightbCenter(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.XRES-px-ti.width*0.5);
}

public static inline function sRightbRight(ti : DisplayObject, px : Float) : Int
{
return Std.int(Game.XRES-px-ti.width);
}

}

Very simple, but highly useful. On all the functions that take an x and y coordinate, I can pass in Layout functions to transform them.

However, I have a flaw in how I’m doing font rendering that is going to limit the utility of Layout for this game. The flaw is – Flash does not autosize TextFields at the moment of instantiation, as far as I can tell. Not only that, but I don’t use TextFields directly; I render them to bitmaps, because I want to cache that data. Hence to get around these flaws I’m oversizing the surfaces I draw the text to with a bad heuristic(32px height and width per character).

I think that in the future I may switch to a solution based on the Polygonal library’s font rendering solution. Although it’s a little bit cumbersome(compilation process vs. drop in a ttf), a little bit less Flash-friendly, this will give me good data to work from, and the basic render speed is faster too.

I added bombs. You can “disarm” them by running into them, or shoot them to cause an explosion(an effect which builds on the two-frame bullet firing code). Right now the explosion doesn’t do anything, but I will soon add player death and environment destruction to the mix. Then things will get interesting….

I’d run off another build but I’m getting sleepy at this point(~7pm to ~9am…that’s….5+9=14 hours awake) and would rather conserve some energy.

The newest build has, as I wanted, destruction, explosions, and player death. It restarts when you die.

I just noticed a bug in it though – didn’t make the ash passable. Oops.

This game has some basic combat going now.

First you have to cross along the line of fire of the pirates(who, at least in this incarnation, just shoot in cardinal directions) to get to the ammo.

Then you have the option of picking them off like a sharpshooter, weaving in and out of their fire line, or blowing up the bombs, which will conveniently chain their explosions. It’s awesome, albeit a bit hard to read with the colored blocks. I think I will go to bed in another hour or two, add a few additional forms of AI to vary things, and then do the level design and polish.

I figured my other AI could be a pathfinding one. Surely I could just reuse some pathfinding code for haXe? No, of course not. The library I found showed several signs of poor manufacture(particularly, using the extremely slow Enum construct to identify whether nodes are start/end/clear/blocked instead of, say, an integer value) and threw an exception in use.

Now I’m left torn between writing my own pathfinding code(done it several times before) and integrating it into the Roguelike collision system, or to go with dummy run-at-player AI. The latter would be a much safer bet, but I think that having a pathfinder mob, besides being useful library code, would add more dynamism to the game – with the water and bombs, there’s plenty of opportunities for the player to snipe at them or send them into traps, rather than it always being a head-on combat situation.

This is probably one I should sleep on, really. I’m at the end of my day.

Against my better judgement, I went ahead and implemented Dijkstra’s Algorithm. The time cost was large: 3 hours, most of it spent on a bug that I resolved by not being macho and using the 2D field class I had been using for every other 2D grid(tiles, collision) and really should have used for the nodes from the get-go.

But it works. I need to give the pirates a proper LOS check though. That can come tomorrow.

Just got up, showered, shaved, and now I should probably find something to eat.

But today’s the day where I make Pincer look and sound awesome, as well as hammer out all the level design. Wish me luck!

I would have taken pictures but I don’t have a good setup for that right now. Breakfast was bacon, turkey sausage patties, and a scrambled egg fried in the fat of the other two. Then a “Fiberful” fruit bar, and then my usual supplements(a multi, additional D, calcium, an Omega-3, and whey protein), followed by some green tea to wash it all down. This is food that makes me work well. Heavy carbs like beans+rice, potatoes or cereal just make me feel hazy, ill and unmotivated.