I’ll do “gravy” sprites when I’m done with the basic thing.

Here’s a little sampler:

I guess it should be pretty obvious where I’m going with this…

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!)

Download over herely

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)

Some more project additions on my shiny new site. New design really makes adding stuff a lot more convenient compared to what I had before. Actually one of the updates is a project entry on that very system; SPCMS (the morbid can have fun looking through some source code on that one)

Mainly though, I finally got around to releasing Nitro Butts – an old game from 2005 that me and my brother made out of oldschool boredom. It’s actually quite a bit of fun and you can even do co-op if you have a gamepad and additional human around.

Considered doing something for the compo, but kept getting into other stuff (fun stuff, important stuff, interesting stuff) so time ended up running out. I decided to make a mockup screenshot instead, of something weird that could have been. Maybe. Anyway, behold:

Oh, I also happened to make an asteroids game during the compo… didn’t mean to do that, but technically I guess it could have been an entry. Not quite weird or unexpected perhaps, but at least it’s asteroids.  Windows-only.

http://www.cyd.liu.se/~tompe573/asteroids.zip

Now where’s the Inquisition game? Me want play!!!

Shrapnel!

Downloads (both have windows exe + source code and Linux makefile):

• Compo version
• Post-compo: Smaller zip, sound latency fix (no code or data changes) (new)

Uses SDL, SDL_mixer and SDL_image. I used kate for code/text, gimp for graphics, sfxr for sound effects (thanks DrPetter!), and pxtone to make music.

If the Linux version crashes when you run it on 32-bit x86, use this SDL library (contains a fix for a bug in SDL_SoftStretch)

Edit: Figured out the Windows sound latency issue! Seems the SDL.dll I used was buggy. Replacing it with one from libsdl.org fixes things.

This is it! Pretty darn complete. Download here: shortfuse.zip (1.1mb)

I tried making music, and that was a bad idea, so I didn’t put it in. Love those SFXr sounds, though!

Note: If it runs way too slow, or just if you prefer, you can use the command line argument “opengl” to run it in openGL instead of directX.

Lots of visual progress, a little bit of real progress.  All new pixely graphics all around, and a new HUD at the bottom.  The game automatically zooms the display in to cover the portion of the map that actually has stuff in it, so instead of scrolling, it just gives you a wider view on larger levels.  That’s good because you need ot know the whole layout to make your plans.  This zoom feature is currently very questionable, I seem to have to manually tweak exactly where it goes, depending on the level layout, so I’m missing something there, but it mainly worksish.

Currently, you can’t win or lose, but if you could be killed, boy would it be hard.  Thinking ahead is a must, and it all goes quite fast.  Each level has a percentage required to complete it, and you also need to stay alive, and the main gist is to get the best score you can, provided you blow up enough and avoid dying.

It’s got MOON, it’s got NO TEXT, and it’s got blocky pixels, chirpy audio and all the other essentials!

This was a strange “compo”, but several interesting games came out of it and I had a good time working on mine. The 24-hour time limit was rather severly busted, but that’s fine I suppose. DQ means surprisingly little around here, especially since this compo had no voting.

As usual for me, the main idea was a technical one and involved using a sphere-mapped rectangular playing area. As one theme was “moon”, this seemed easy enough to work in. The actual game concept was undetermined until rather late in the process. At first I was thinking that maybe you’d drive across the moon in some vehicle, collecting things… but that didn’t happen, so I changed it. The final game is pretty cool imho, where you drop/stack colored chips onto the moon to make them disappear.

This all sounds very lame and boringly puzzly in theory, but the main challenge is the hideous control scheme. You don’t control your position directly, or even your speed, OR the acceleration – but the next-higher derivative! Tap right and you’ll see very little happen at first, but after a few seconds the moon starts slowly rotating in the chosen direction, and then it goes faster and faster unless you compensate in the other direction. It’s very easy to overcompensate and end up in an oscillating back-and-forth motion where you have no real grasp of what the hell you’re doing, but play the game enough and you can enter into a sort of zen state where you can “feel it” and get along pretty well. This is really essential, since you need to position yourself very accurately over the chips to avoid missing (and thereby creating a new stack which needs to be completed and removed).

Unsurprisingly, most people that tried the game hated it. Once I realized where it was going I pretty much tried to make it as evil as possible, much like a lot of old C64 games which you find in some old dusty drawer without a manual and have no idea whatsoever what to do with. You’d start a game and almost instantly die, and the controls weren’t obvious at all or severely broken. Ah, the heritage.

I’m really happy with the music though, sets the mood nicely. Imho the game is worth playing a few minutes for that aspect alone if you’re a retro geek.

Scroll down to the bottom of this post to read some instructions (that you shouldn’t really get if you want the full frustrating experience).

Download: Windows version (575 kB)

-

-

-

Quick instructions: Arrow keys to move/rotate, Z to drop chips. Do not drop like-colored chips on top of each other.
There’s a small cheat which might make the controls a tad easier to grasp – type “showyou” at any point to bring up an acceleration graph in the top-right corner.

Ah, great compo this was. Tons of sweet games. Unfortunately that also meant fierce competition, and I only managed to snag a best position of 3rd in Fun (which is unusual for me, as I normally do better in the technical categories).

Base idea for the game was to have the level be “swarming”, for an unexpected approach. I figured there could be loose platforms drifting around in space and you’d try to jump around between them, doing… stuff. The gameplay part of it was sketchy at best.

I suppose the better part of the first day was spent getting the platform movement and interaction working, and then I think much of the second day I just sat and tweaked it, fixing bugs. The gameplay elements and final graphics/audio were added in the last two or three hours.

Windows download: 128 kB zip (exe, data, source)

Linux port: 16 kB tar/gz (needs above file for data)

Arcade build a’la Lerc.

Theme Growth. I did get a review on this game, here it is:

Ingame screenshot

My first LD entry, for the #7 compo in December 2005.

Story, according to readme.txt:

You’re kidding right? Uhm… Control
Jackie as she tries to escape from her
sugar-induced nightmare by climbing an
ever-growing flower. Flying pigs are
attacking and she needs to feed them
candy until they burst.

Collect delicious pig eggs for score,
and keep a look-out for hearts to boost
your health should you need it.

What more is there to say? You jump around, throw candy, collect eggs and try not to fall into the water as platforms appear and disappear from the randomly growing flower. The flower itself was the most advanced piece of code in this one, and the first thing I started working on. Generally I seem to go about LD compos that way – think of some cool technical concept, then implement it and try to turn it into a retro platformer somehow…

Download, WIN32 binary+src: jackiebs.zip (1.24 MB)

—

Just starting out, no platforms have grown out yet.

—

Flower has grown a fair bit and there are tons of platforms.

—

White pig has eaten too much candy, burst is imminent.