Hello Darers. This will be my first Ludum Dare and I’m greatly looking forward to it.
Sound effects and music: sfxr, GarageBand, Audacity
Art: Adobe Flash CS6, Photoshop, maybe Illustrator if the mood takes me.
Code: ActionScript 3 (with Flash)
Libraries: Box2DFlash if I can find an excuse to use physics.
And we’re off. Chuffed about the theme (10 Seconds). It was my favorite. Constraints are good for creativity, and 10 seconds is not a lot.
I like to know exactly what I’m doing before I do it. An ordered goal list can solve a world of problems later.
My goals for LD27, in order of priority:
Having awesome fun! After much brainstorming and a little experimentation, I’ve settled on a concept. Here’s some of the brainstorming that led to my decision.
Concept: Level Up!
An RPG that lasts just ten seconds. You play in three or four brief segments: 3s + 3s + 2s + 2s. In each segment you must act quickly to make a few key movements. These movements award you some number of experience points. The game then says “Level UP!” and pauses. You now spend a lot of time finely tuning your character to prepare for the next 2 or 3 second mad dash of play.
My concern here is that 10 seconds of total play may simply not be enough. It also implies a lot in the way of art and UI.
Concept: Ten Seconds of Roguelike
It’s a roguelike and so basically turn based. A great many turns may be enacted, but they all model a span of just 10 seconds. So these are either very detailed actions at “meter” scale, such as unstopping the cork on the potion bottle before casting the spell, and the spell would be cast by pronouncing each letter of the spell’s name over the course of several turns; or relatively coarse actions at the “centimeter” scale, such as the detailed manipulation of swords and shields in a 10-second sword fight. Focusing on magic might work even better.
Or actually, setting the game inside a computer would give this “time extension” effect ad infinitum. Thus:
Concept: Core Wars on a Bomb
It’s a programming battle, CoreWars, where you interactively write code that executes over the space of X (~100) clocks, where 100 clocks=10 seconds. (Now *that’s* a slow computer.)
This one continues to appeal. Just another CoreWars would be uninspired, but there’s range here for some real intrigue. If the “clocks” scale becomes a way to simply evade the theme, this is no good. But if the game could have the time-restricted feel that we expect from this theme, I like this concept for its simplicity, low art cost, and inate appeal. Needs to be single player though. So presumably the “circuitboard”/”memory field” is a puzzle of some kind, and you have to write a program (typing it in? dragging components?) that solves the puzzle i.e. breaks through the barriers. Possibly a bit like Core Wars but where each level provides a premade opponent program (but not necessarily symmetrical?).
Let’s focus on the time problem. Is this an evasion?
What about if the program you’re writing is trying to crack the code (in some sense) on a bomb, the timer of which is displayed prominently at the top. The timer runs in slow motion (from your perspective) but never stops. It has tenths and hundredths places so you get the effect of resolution. Possibly the tenths place is the clock marker: when it changes, the computer executes an instruction. So you have 100 instructions maximum to solve the code.
What do we mean by code? I like the idea of looking at bytes in memory, a field of green fuzzy digits perhaps. You upload your program into memory and you see it there as bytecode. The instruction pointer is marked. Changes to bytes are flashed. What’s the challenge?
If it’s really a code breaking thing…hmm. I’ll come back to that. In Core Wars an enemy program is executing and trying to force your program to crash. Maybe that’s your task: force the enemy program to crash and avoid being crashed yourself.
Alternative, the bytes might be largely inert: just data. You are processing the data in some way to identify the code word, which is hidden somewhere in it. Bit like Battleship maybe? But what does programming have to do with this? What’s the variety of challenge? Maybe there are “bomb” bytes that you can’t touch?
Each level needs to require a (more or less) unique program though.
What if the bytes can be occupied by ‘entities’ that are a bit more meta: a roving “code byte” for example. If you can read the location of that code byte, you win. The trouble is that the code byte moves constantly. In early levels its movement pattern is simple; later it becomes more complex. You have to corral the byte in cases by writing to bytes that block off its movement.
But no: again, this doesn’t sound like programming; just writing to x,y locations.
Yeah, no. I don’t think I can produce an interesting programming game in this amount of time. I could crib from Core Wars but I don’t wanna.
Concept: Targeting Computers
Yours and another space ship are closing for battle in 3… 2… 1…. You have to target your ship’s weapons in sequence and raise shields at the best times to deal the most damage. Targetting is in slow or pause mode so might take minutes, but the actually engagement takes 10 seconds each time. You play in waves, with a new, more difficult ship engaging each time.
This one seems pleasantly natural. It makes sense as a game. It has great potential for fun. There’s a familiarity about it (not too different from FTL). And it doesn’t seem too hard to implement. The risk factors are: (1) artwork, which would ideally require some pretty serious chops; and (2) fine tuning the game design to give it that chess-like, fencing-like, tactical quality. Plus, oh yeah, probably a fair amount of UI work. Mm. That cools me on it somewhat.
General Thematic Transformations
So I’m noticing some patterns.
I’m liking REDACTED best. 😉
…for planning some things out. Especially when it’s graph paper.
I’m doing this Dare in Flash, and that has me programming in ActionScript for the first time in three or four years. I forgot how much I enjoy the language. Things seem to move quickly for me in it. It has enough C++ like elements (like strong typing and “templated” vectors) to give it some crispness and power, but also has that soft, forgiving side that makes scripting languages quick for work like this.
That said, I’ve gotten rustier than I expected. I keep having to look up everything. What Math.random() returns. How to delete elements from Vectors and Arrays. How to format numbers into sensible-looking strings. The syntax for Vectors, to use that example again, is weird: Vector.<TypeName> is kinda like C++ only not.
I’ve at last implemented death in my LD27 entry, which officially makes it a game.
Before being smashed by asteroids:
After being smashed by asteroids:
It’s a game.
I’m seeing a lot of awesome stuff up here. Very inspiring!
I’ve got the essentials of gameplay for my time-travelling 10-second game completed. You can watch the game in action.
I’m just using one library for my time-travelling 10-second game: Box2D, the Actionscript version. I had not used Box2D before this weekend, and I must say I’m pleased and impressed. It’s not vastly dissimilar to Chipmunk, which I’m more familiar with. I prefer some things about Chipmunk, but on the whole I find the object oriented interface to Box2D more to my liking. If I were working in C++ I’d compare the two based primarily on performance, but with a Flash game performance is never a huge ambition. If it’s good enough, it’s good enough. So the interface, the ease of learning—these things start to matter a lot. And Box2D has served very well in that regard.
We’re all running out of time. This competition is about to live up to its theme.
Fortunately “Space-Time Adventure” has wrapped up nicely. Nothing left to do but to polish off the notes and package the source code.
Alas, I didn’t have time to get sound effects in. It’s only an hour or two of work, but it’s not going to happen. If I could turn back time…. Hindsight is 20/20. You get the drift (especially if you’ve played the game).
I think I made a pretty cool game.
It has physics. It has people getting killed by flying boulders. And it has time travel. What more could you ask for?
And this is not some sort of hokey half-working mocked-up pretend time travel. You can actually scrub back and forward through game time—dynamically—to change the world in the past, the present, and the future.
Please try it!
I’m developing my LD27 post mortem about Spacetime Adventure, my physics-based time-travelling game, on my website. You might be some of the few people in the world who actually think it’s interesting. Please check it out.
Of course it’s easy enough just to play my LD27 entry, but if you want to see how it plays, a gameplay video is now available.
The third and final entry in my Spacetime Adventure Post Mortem is now available.
You might find it interesting. For example:
I expected a pleasant weekend’s amusement, a chance to test my skills and, if they didn’t fail me, to show off a bit. I did not foresee how much I would learn, how delightful I would find the actual process, or how meaningful it would be to discover the often amazing, beautiful, clever, and entertaining games that others were creating.
See whatcha think.
My first Ludum Dare—27—was one of the highlights of my life as a programmer. I’m cranked for another exhilarating weekend churning out digital joy.
Code: C++
Engine: Fresh
Sound: CFXR, Garage Band
Art: Photoshop
Grrr… I’m pumped. It’s too early to do any real work, but I’ve been thinking about my flow of work in the last Ludum Dare and I’m mentally divvying up the weekend.
Four broad phases of development:
Ideation is about dreaming it up. Given the theme, what do I want to make, how can I make it, is it realistic? Lots of brainstorming, leading to lots of design.
Proof of Concept is implementing the idea to where it’s playable. It’ll be small, coarse, and clunky, but the question is: is it fun? If not, how to get it there?
Expansion is taking the Proof of Concept and making it a (more) polished, 10+ minute experience.
Stabilization is the concluding phase. Testing. Fixing bugs. Polishing. Making sure it’s downloadable and working.
How long should each phase take? Well my schedule is kind of crazy this weekend.
Friday 8–10pm: Ideation
10pm–early: Proof of Concept
Saturday 8am–late (with a break in the middle to attend my daughter’s Christmas piano recital): Expansion
Sunday lunchtime–5pm: Stabilization
Giving me a buffer of three hours. Last time I got done too early—like, by 3pm—and was twiddling my thumbs waiting for 8pm. I’m not sure that’s a problem I want to fix, but I’m not planning to get done that early this year. My new engine needs debugging on Emscripten, so I’ll have my hands full in the final hours.
Pumped.
In a few hours the theme will be announced on this site. This site, however, will be clogged, and you won’t be able to get in for ten painful minutes or more.
Where else should we watch for reliable echoes of the theme announcement?
Oops. Worked all last night on a concept that literally collapsed. (It was a physics game involving lots constraints, and I just couldn’t stabilize the simulation while keeping it performant.)
I awoke this morning with fresh inspiration. Will start again.
More than halfway through the time, and—I dunno—maybe I’m halfway through with implementation? My reboot is going nicely though. Screenshot:
All right I am officially no longer rating games with the snowman theme. It really seems like you must have started work before the real theme announcement on Friday, and I won’t touch that stuff.