I’ll be using LOVE and maybe vrld’s hump.

Still shooting to submit something by 9, even if it’s not much.

Maybe I’ll surprise myself, who knows.

Screencap

Menu screenshot for Ahoy!

A brief aside, if you will.  In the game “Oregon Trail”, you can manage your wagon-ride every which way, but in the end, everyone I know fondly remembers hunting as “the fun part”.  There was all this incidental stuff about fording rivers and getting typhoid fever and that was nice but everyone just wanted to hunt.

I had brainstormed out this big resource-trading mogul game, and thought that every once in a while there would be ship-to-ship combat.  Then I realized- combat is probably going to be Ahoy!’s “fun part”.  If you have trouble getting into the trading-resources-to-grow-an-empire sort of game, you should at least be able to immediately dip into some action.  Which is why there’s a “Combat Minigame” option right under “Main Game” on the menu.

This will also serve as a fallback in case I can’t finish the Main Game (and it’s complex enough that I might not)- I’ll still have an entry, because I’ll be finishing the combat part first.

This isn’t gameplay, but a mockup that should resemble it fairly closely (minus menus and minimap)

Mockup!

I haven’t written a single line of code, which is… atypical for me at this point in an LD.  But I did want to have more of this game designed up-front before I started, and it is almost completely designed at this point.

I’m glad I checked these things out beforehand with a wee warmup, because TilED QT 0.4.1 doesn’t notice my mouse clicks if the application already has focus! So I’m going to use the eye-burning Java version of TilED.

If it turns out that this change of coding scenery is killing my productivity, I may fall back on LOVE.  I would in that case also use LUPUS, a lua library which anyone is free to download and use.  (If you do use it, beware the Grid class; it’s not passing all its unit tests and I’m not sure why.)

Behold the almighty desk!

Windows zipped folder with .exe and all required .dlls here: http://jerryfederspiel.org/exes/PostCompoAdrift.zip

If it looks like it only took 4 hours, that’s because the majority of my time was spent fixing very early bugs rather than adding new content. So, sorry for the mostly-empty game :/

AND to clarify yet further: I didn’t design any levels for this game.  The levels are procedurally generated.  I tried two schemes for this: one based on recursively taking edges in a graph and complex-ifying them (which never worked to my satisfaction), and another (much simpler) one based on random attachment, with a few extra edges thrown in to allow cycles to form in the graph.  After generating the graph out of edges and vertices, I “rasterized” it into blocks to make collision detection easier.

One minute before the competition begins…

Tools: LOVE2d, Photoshop, Goldwave, and adrenaline.

Crush is a pseudo-board-game in which you try to outlive your opponent.  You do this in two ways: 1. Capturing your opponent’s pieces and 2. be better than you opponent at avoiding getting crushed by the wall.  In the style of RoboRally, everyone (you, your computer opponent, and the wall) simultaneously and in secret chooses how to act, and then your decisions are executed simultaneously.  Unlike RoboRally, you have a limited time in which to choose your action.

The game controls are mouse-driven and should be pretty easily discoverable, but there are a few undocumented keyboard shortcuts you might want to know:

• “r” reloads the game
• “q” or escape exits the program entirely
• spacebar ends the current decision-making period and enacts everyone’s current move choices (and if they haven’t made a choice yet, they don’t move at all for this turn)

My fiancee provided lunch- burritos:

I guess I should also make the game recognize when you’ve won or lost

In terms of how the game plays, there’s so much surface area between players that it feels limiting that you can only move one piece at a time.  Currently, the (dumb) AI opponent can deal with the situation and put up a reasonable fight, but if I make it so that people can input more than one move per turn it will complicate the user interface and I don’t think the “AI” could cope with the change.

I wrote music late last night, and while it works on its own as music it’s really not appropriate for the game.  I should do the sound effects first, then come back to the music with a fresh approach.

Everything’s too dark and drab.  I should make one of the tile types a little brighter for contrast.