Ludum Dare 22
Ludum Dare 21
Ludum Dare 20
Ludum Dare 18
Ludum Dare 16
Ludum Dare 15
Seriously... EVERYONE uses SFXR
Awarded by PoV on December 15, 2010
Master of Distraction
Awarded by LunarCrisis on April 21, 2008
The "I'd rather do it in C" Prize
Awarded by philhassey on March 3, 2008
Glorious Particles Award
Awarded by Cthulhu32 on February 25, 2008
Awarded by philhassey on February 4, 2008
The Ãœber Awesome Sound Tool Award
Awarded by Endurion on December 19, 2007
Saturday was a write-off due to visitors, then I had a reasonable idea (similar to some others, I’ve learned). I started some basic code in Flash to render and subdivide hexagons, but then my mind drifted off to other things and I couldn’t bring myself to add gameplay components during Sunday. Was hoping for a jam entry, but after refining the concept on Monday I still didn’t really feel the spark needed to sit down and make it work. Too bad.
I think it might work out as a fun abstract game though, but probably needs a lot of reactionary tweaking after the initial playable builds start popping out, to adjust balance and add interesting challenges. Pacing might also be a problem, making it fast enough to be entertaining but not too fast for comfort. I imagined having mouse controls of a slightly unusual nature where you move to aim and are able to do limited backwards movement while still aiming and firing.
Feast on these conceptual mockups while I try to find the brain fuel for a post-compo implementation.
Congratulations to all the participants with far greater discipline than me! Getting a game completed and submitted isn’t a small thing at all. I look forward to browsing the results, as always. Next time I will have to do some warmups to iron out my gremlins before it gets serious.
I shouldn’t noodle with this anymore right now, better to get the rest of the game together and see if anyone can actually play it. It’s a pretty simple design, so hopefully I can have that done in a few hours tomorrow. I doubt it will be polished beyond these simplistic graphics, especially since I’m starting to like how they look already
I keep confusing myself regarding the flight direction and world orientation… adding landmarks for reference, but it might be hard to get this playable without dropping into chase cam. Maybe there’s a chance for some novel control switch-ups though. I’m thinking point-the-mouse steering rather than keys for roll and tilt of the vehicle. That would add a global sense of overview for the player, without keeping track of exactly how the plane is turned. Not sure it would be flexible enough for what I want though. I’ll try something else first. It’s not actually supposed to be an airplane, so screen-space directional input might work out as more intuitive, if the camera follows along to some degree.
Finally settling down to start coding the actual game. Did a bit of preparation work earlier today, but mostly distractions. I’ve had the whole design fleshed out in my head since I got out of bed though, and it has given me a sort of fake feeling of comfort all day. Like I don’t actually have to write the code… Well, good news is that it should be possible to create and test the basic mechanics/rules with very little code or content, then if it does end up working properly I can dress it up fancy tomorrow.
So right now I have a crude flight simulator where you guide this here airliner in 3D with the arrow keys. Works surprisingly well, and I’m enjoying it. Might get complicated and confusing once I introduce the restricted airspace I had in mind though, but we’ll see. That’s next.
kohina.com for soundtrack
Gameplay is done, and I now choose sleep instead of fancy redrawn graphics. Decided to do primarily game design this time around, rather than technical experimentation or flashy content. Kind of happy with how that turned out.
Download for those who want to play right now. Win32 exe, control with arrow keys. Let me know if it seems broken and I might rush to fix it before I go to bed.
Imagine a similar top-down island+water view as in my previous sketch. I’m too lazy to make another.
This game is more of a resource management affair, with few action elements. All the islands are fairly small and circular in shape. You start out on one of them with a small land vehicle which you can move around. From this vehicle, you can send a probing ray aimed at the mouse cursor, used to measure range. The intended purpose is for you to drive near the edge of the island and measure how far away the next coastline is, and if it would be viable to build a bridge over there. You have a supply of resources for this purpose, like fuel, metal, and wood. There could be different kinds of bridges to suit different situations of resource supply, like wood/metal/concrete bridges.
Anyhoo, if the range checks out, you would start bridge building, which would be automatic and animated in some fashion. When the bridge is complete, you can cross it to visit the other island and harvest its native resources. One alternative system for resource handling would be that you had a swarm of builder agents that would scurry between the bridge being built, and back to connected islands with resource supplies. They would gather material and bring it back to the build site. This way there would be no global material reserve, but it seems like it could turn out kind of complex and tedious to have build time and efficiency depend on the network of bridges, possibly having the drones move all across the map to get things done.
For deciding where you want to build the next bridge, you could detach a helicopter module from the main vehicle and fly over to other islands to survey their contents. Small icons and proportional numbers (like “5 Oil” and “3 Rock”) would pop up when you get near them, or when you land. The helicopter would consume fuel, and have a limited tank capacity. That could mean you end up stranded on an island, and you would have to build bridges to reach and salvage it before it can be used again.
I’m not really sure what the overall goal would be, and if the game should either be win/lose or just sandboxy. Sandbox would probably be the best option, with some tweaking to make it apparent that you’re doing well or not, depending on how you play. One idea that could shake things up (pun!) is to have islands randomly rumble and crash into the sea, taking connected bridges with them. This would mean that you’d have to build new and longer bridges to reach some areas in case a key island was lost.
It might be possible to layer a different and primary mechanic on top of all this, where you perhaps shuttle creatures or other artifacts between islands in some way, so there’s something to aim for and always something to do (they want to go from one island to another, then back again or move on somewhere else). In that case, bridge building would become secondary but still the main important task you perform while playing.
That’s all there is, and you can’t play it. I would probably have started prorotyping one or both of these if I hadn’t made the questionable decision to spend my weekend doing really boring Sculptris code. I didn’t feel like I could relax and start on something else before that was done though, and in hindsight I’m glad that I have the boring stuff taken care of so I won’t have to do it tomorrow.
As always, good luck to those of you making games, and I look forward to browsing the entry masses later. One perk of not participating is that there’s no pressure to vote, for once
I won’t be entering any code, but I had two interesting ideas that I considered making something of. Here’s a rough sketch of the first one.
The core mechanic has you driving a boat/car hybrid through a kind of archipelago landscape. There’s a jump button, and with each jump you transform between boat and car. It would probably be allowed to switch again in mid-air if you find that you will end up landing on the wrong kind of terrain. Landing inappropriately would lead to explosion and restart/respawn. The transformation would occur as an animated flip/roll along the length axis of the vehicle, so in theory it could actually be built as a car with a boat “on its back”.
Hopefully driving this contraption would pretty much be enough fun to entertain for a while. There would be some nice skidding physics, with the boat having less grip than the car. A bit like my old netboats game.
For added gameplay though, I figured maybe you could be fishing with a trailing line, gathering fish from schools/swarms that roam the waters and casually try to avoid you. You could add any number of fish to the line, but it would also add mass that would make it harder to control movement, and it would also attract sharks that want to eat the fish and/or you.
As an extra twist, to incorporate the land areas and encourage you to actually drive from time to time, I had a weird idea that you could get on land and drag the fish around as bait to lure tigers from the shrubbery, and catch those on the line as well. In the end, you would head back home to a meat market (X) where you score based on the catch/combo.
Not exactly sure how the various elements would play out in the end, but it seemed like it could be a bit of oldschool arcade fun. The playfield would be much larger than indicated on the sketch, with some areas of alternating land/water/land which would be tricky to navigate without losing a lot of speed or crashing. Perhaps seagulls could be chasing you as an incentive to keep moving quickly.
The end result isn’t too bad really, considering everything went horribly wrong all the time. I did not have fun
EDIT (after sleeping): Well, of course I had fun at one point, particularly while animating the character, but after that I started to mess up everything and got increasingly tired and hangry.
I learned some stuff though, and it would be interesting to attempt a similar 3D platformer thing with less rush and more polish. Maybe next LD. Remind me to start before half-time break.
I guess a download link is in order: Get it –here– or at the final entry post.
I mainly felt like goofing around this weekend, so I did. Had a vague idea for a game where you’d fly around in a cave-like world generated from audio data, but I “needed” implicit surface rendering for that, so I set out to experiment with the tech. I wasn’t too surprised to find that I didn’t have any desire to make game code after the rendering was working… I just played with different visual effects instead.
Here’s a collage of notable screenshots produced:
The first raw version ran at an abysmal 1 fps or so at 640×480, but after adding some biliearly filtered variable resolution rendering based on image-space local contrast and threading it to use dual cores, I managed to kick it up to some 20-25 fps for “friendly” scenes (meaning not too much visible edge detail).
Most of the screenshots are from “bruteforce” renders though, showing no optimization artifacts. The optimized version has a mild muddy/compressed look. Putting all of this in a shader would result in much simpler code and greater performance with no visual degradation… I might have to try it some day.
You can download the (messy) source and a few builds here: drpetter-minild-ds.zip
I also made a quick tune based on one of the drumloops given: destroyloop.mp3
Overall it was a fun weekend. Sorry for not producing a game…
On my own two feet here. Disregard the Eee, it’s just there to match all the other deskphotos. I’m not going to use it… The little black box beneath the keyboard is my high-tech entropy supervisor, which monitors heat flux in the immediate vicinity of particular computational elements. Calling it a common household thermometer would be a blatant lie!
Thanks for all the nice comments. My best time is 13.78, so those of you stuck around 17 seconds will have to put in some more effort
I’ve added some stuff to the game, mainly the option to generate random tracks (and save/load them). Also I added mouse controls for one player, in case keyboard sharing gets uncomfortable. Furthermore, there’s a fullscreen mode and slightly different track graphics.
The game still starts up with the same default track, and the gameplay code/simulation hasn’t changed.
Download here: soltcras.zip
Yay, I’m entering! Spent about three hours on this, although I went most of this day thinking about the idea (which was initially a lot more ambitious). It turned out kind of cute though, and I’m happy with it. You might be able to have a few minutes of fun if you’ve got an opponent available, or even just putting down a few solo laps.
Win32 package: drpetter_ld13_soltcras.zip
(might be portable, for those who feel like compiling… get portaudio and glfw)
(edited 28 minutes after deadline adding a simple framerate limiter to make it playable if vsync doesn’t work)
original, packaged before deadline: drpetter_ld13_soltcras_old.zip
Started at local midnight, two hours ago. I had grand plans of making a generic scriptable text adventure engine when the compo started, but couldn’t find the inspiration and energy needed to get on with it. Instead I stalled and waited for the very last moment to get something half-assed out the door. It ended up completely hard-coded and very simple, but at least I got to write a text adventure. Last one I did was probably in AmigaBASIC twelve years ago.
Download and poke around a bit. You might have a minute or two of frustration fun: drpetter_ld12.zip
Maybe this is what I should have been doing for the last LD… It took me two days to make and it’s based on the code of my LD11 entry (I didn’t even miss Felicity!)
Making “just a game” was kind of enlightening, since I didn’t have any real technical challenges to overcome and could just get on with content and putting in simple control logic to make it all come together. It’s pretty much an unthinkable project viewed in terms of what I’ve been doing the last few years, but since both development and result were enjoyable it’s a pretty clear hint that I should be doing it more often.
However, I ruin that immediately by having a natural impulse to make some kind of convenient editor/engine which would reduce the need to write copious amounts of replicated-but-slightly-modified code for instance when I want new enemy types etc. I have made these before, and each time I end up spending weeks or months working on it and then never really use it because I get increasingly unhappy with how it’s built. Still, I couldn’t possibly make a game of say 10x the complexity/scope of this one without using more structured code at the very least. And defining animations, scripted events, enemy patterns etc would quickly get tiresome and repetitive to do in code+Photoshop if you have more than one or two types to deal with. The grunt of this game (discounting image loading and input code) is a 1500-line C file, where almost all logic is directly in the main loop – wonderfully spontaneous way to work but of course breaks down with increased program size due to convoluted value/flow dependencies, loss of overview and the need to repeat code.
The fact that I did manage to create this in just two days though, and that I didn’t run into any major hickups along the way, probably says something about suitable code vs application complexity. If I had gone and made “a perfect design” with fancy classes and streamlined algorithms for everything, I would most likely not be done yet. More importantly, I probably wouldn’t even have started since such a small project doesn’t really justify that kind of work. Not without the prospect of a larger product coming out of it, and if there was one I would probably be too intimidated by the thought of that and keep trying to out-think myself in terms of what stuff I’d need to make that “great big thing” work eventually.
I think Derek Yu recently said something about coders being able to “doodle” games like artists sketch with pencil and paper, and that’s probably an important thing. A sketch is never meant to be used for anything substantial, it’s just playing around with the tools of your trade to make something spontaneous and fun. If it turns out nice then you could potentially do it again from scratch but “do it right” and expand on it if you wish – but you should definitely not be doing it the roundabout way to begin with since that would destroy the spontaneity and make it a laborious task instead of a free-minded sketch. When sketching you can only use whatever skills and processes that come natural to you, without considerable planning or conscious mental effort. Of course, with increased experience this set grows larger and some people could probably do advanced class hierarchies without thinking too much about it. All the more power to them.
Since I made this thing in such a short timespan, I have a pretty good overview of all the techniques I used and the bare-bones code needed to make them work. This could provide some extra value when designing larger game systems as I might be able to target my efforts more carefully, and not get overly general or implement pointless things. For trying out pure game ideas though, I still feel that it would be sensible for me to “sketch” in a more streamlined tool… a kind of game maker for sure, but definitely not Game Maker (for the simple reason that I’m incapable of using any tool that is close enough to what I could potentially build myself, which is a most unfortunate condition in terms of productivity… but creating a tool to fill some (possibly imagined) need of my own is just so very rewarding)
I put up an article on basic sound synthesis yesterday. It had been requested by some folks. Touches on fundamental aspects of sound in general as well as more specific details relevant to classic retro waveforms and the kind of stuff sfxr does.
Ok. Managed to scrape something up that might be considered a game. About as complex and innovative as my last few LD entries
I actually had fun this time around, but mostly with irc and blogs rather than actually making a game of my own. Maybe next time.Â Now sleep before getting on with all the games!
Giddit: marge.zip (windows executable, and a bunch of code that you probably don’t want to try compiling)