About Jpfed
Jpfed's Trophies
Jpfed's Archive
Crashing
My energy levels are falling pretty rapidly. I got my ships to behave in a semi-realistic fashion, but I don’t know how much more I can do. I’m pretty much exhausted- the prednisone high has worn off and the liquid diet has not been enough to keep me going.
Still shooting to submit something by 9, even if it’s not much.
Waking up
Well, looking at what I have, I think I was right to hedge my bets. I’m feeling very pessimistic that I can complete the main game in time, and will instead focus on the combat minigame. While it should bring new things to the “two things running around and shooting each other” genre, islands don’t really enter the equation. *Sigh*
Maybe I’ll surprise myself, who knows.

Screencap
Menu operational
I finally got the watery effect I was looking for, and learned a thing or two about LOVE’s SpriteBatches. (I ended up dumping Java+Slick for what I know and LOVE.)

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.
No code yet?!?
Bizarrely, I haven’t written a line of code yet. I’ve been working on the concept and the art, but no code. Jpfed from LDs of yesteryear would be FREAKING OUT but I am bizarrely calm for the proximity of the deadline and the amount of caffeine in my system.
This isn’t gameplay, but a mockup that should resemble it fairly closely (minus menus and minimap)

Mockup!
Research complete (?)
I just spent 5 working hours brainstorming and doing research. I now have a set of ships (with various tonnages, cannon, speeds, and costs) that I *think* will be fairly realistic and balanced in terms of gameplay.
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.
“Food” photo
I was too excited to follow through on my “sleep normally” plan. Because I’m down with the sickness, there will be no solid food for me.

Nectar of the gods!
Piratey Tycoony thingy
I’m shooting for an inter-island trading sort of game, with occasional pirate attacks and random events to perturb the world economy. I want to approach this LD differently from last time(s); just staying calm and trying to work more assuredly, getting sleep and stuff like that. This game is a little ambitious, but I’ve got backup plans in case the original idea is too complex.
Throwing my hat into the LD17 ring
I normally use LOVE, but think I’m going to switch it up and use Java, Slick, and TilED. Should be interesting- I haven’t used Java in 3 years or so. But I’m hoping to make something that people can just run in their browsers instead of downloading untold megs of LOVEly .dlls.
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!
Adrift: Post-compo version
I haven’t fixed the help yet, but I have added another control scheme, improved the ship-to-ship combat, and (in my opinion) improved the graphics.
Windows zipped folder with .exe and all required .dlls here: http://jerryfederspiel.org/exes/PostCompoAdrift.zip
To clarify
It’s important to note that my entry was not done in four hours. This weekend ended up very different from what I thought it was going to be, but I was so far behind my schedule that I didn’t feel I had time to make a journal entry to clarify this. I worked through the night instead of going to sleep prior to my first prior engagement, so that was an extra 8 working hours. The other of my prior engagements fell through, supplying me with an extra 6 working hours or so. So in reality, I had about 18 hours to work on it.
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.
Menu up and running
Got the menu system going. Spent too long making it “pretty” (or at least, stylistically consistent with what I imagine the game will be). Got to keep moving- on to level generation/rendering.

This is going to be CRAZY
I’ve got to work on focusing my efforts on making a fun game. Last time, I spent too much time diddling around with graphics and sound, and while the game was pretty it wasn’t really any fun. This time, there’s no time to spare- I have to submit tonight, before I go to bed, because the rest of my weekend is full. I’m guessing that’s going to be about 4 hours.
One minute before the competition begins…
Throwing down a very small gauntlet
This compo will be very abbreviated for me: prior commitments reduce my available time to about 4 hours. But I’m still going to waste a few judges’ time with whatever I can throw together in that interval!
Tools: LOVE2d, Photoshop, Goldwave, and adrenaline.
Crush – final
Sorry for the ginormous download (11MB!). You can find it here: http://jerryfederspiel.org/exes/Jpfed_LD14_Crush.zip . The .zip contains a Windows .exe and all required .dlls. It also contains a .love file, which is just a renamed .zip of the game source and all of the graphics and sound files. Anyone with LOVE installed can run the .love file, regardless of their host OS.
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)
Crusher moving inexorably forward
So it’s animated and playable. I’m not sure how well the concept actually works as a game, for a few reasons. The whole idea of “everyone declares their attacks and then they are executed simultaneously” is interesting, but it doesn’t fit into any preexisting molds in my brain.
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.
The idea so far
I’m hoping to make a kind-of board game in which you must eliminate all of the pieces exclusively owned by your opponent. A few possible twists:
A. After every few moves/captures, one of the sides of the board crushes inward, effectively shrinking the board as you play. This one is pretty certain to be the case, for compliance with the theme and to make the endgame work.
B. it is likely that any given player will have up to 1 minute to input their play for this turn, after which point the moves take effect. If you haven’t specified a move this minute, tough cookies for you; the other player will move anyway. Perhaps both players specify their moves during this minute, and the moves actually take effect simultaneously.
C. Perhaps the board contains some pieces that both you and your opponent control (?). Mutually exclusive with the simultaneous-action variant of B.
First attempt
Hello! This will be my first LD entry. Tools:
lua with LOVE (naturally includes SDL, OpenGL, Box2d…)
Photoshop CS2
FL Studio 7 (semi-expensive software sequencer and synthesizer)
Goldwave (shareware audio editor)
Notepad++

















