Well, didn’t really have time for LD, but I scribbled together a minimalist text adventure in 2 or 3 hours

It requires pygame and pyopengl to run if you still want to look at it..

final entry zip (.py files, had no time for py2exe)

Ok, it's 2008 since some time, but the first time I feel like posting. In the meantime, there was another LD48 I took part in, sometime last December. Results are here, and while not doing good in general, I made second place in the graphics category. Need to figure out how I can get one of those pelly graphics to display here, I always wanted one, and now finally, rather unexpectedly, I got one :) Maybe not totally unexpected, as I did take some time making shiny animations in Blender. On the other hand, I chose to make a puzzle game and ran out of time to create levels during the compo. When will I ever learn. Also have yet to add the game to the site here.

A post-compo version of my entry is here.

Changes are:

• Different algorithm to create dynamic holes (without any texture upload), and compiled with optimization on (so no more slowdowns)
• Gameplay change: Can now walk even during explosions (which allows new timed puzzles)
• Gameplay change: Added movable bombs (allows Sokoban style puzzles)
• 4 new levels (13, 14, 15, 16 are new - still not very good, but a lot better than the ones in LD)
• Allow to choose your starting level (once reached)
• Some graphical changes, like flags to mark indestructible fields
• Fixed several bugs (most of which could not occur in the LD levels)
• Includes a crude linux makefile now besides the mingw makefile and the .exe
• There’s still a bug with 16-bit desktops under Windows
• Another bug which caused unexplained failures to upload textures is fixed with the fixed exe in the comments (so if it doesn’t start up, you can get that .exe - maybe I’ll also re-upload a new version with this later)

Was experimenting with this, gtk-recordMyDesktop made it trivial to capture a window and even sound, shows me again how little gameplay there is, oh well:

(Hm, got bored at work, so an extremely lengthy post-mortem following..)

Post-Mortem

LudumDare 10 entry “Lunte” by Allefant

Introduction

I have yet to analyze the over 3GB worth of automatic screen caps, but I think I spent about a third of time each in IRC, coding, or working in Blender. Rather minor amounts of time were devoted to idea research, making sounds in SFXR and making music in LMMS.

Audio

In fact, my music is somewhat of cheating, as I used an existing melody, and further, an existing .mid file including 2 additional scores to the melody, cords (or whatever, I’m no musician) and percussion. What I did is just fiddle in LMMS to create and assign instruments.. I gave a high pitched square wave to the main melody, a piano to the cords, and since LMMS decided to simply lump the midi percussion notes into one channel, ignoring the MIDI assignment, some wooden sounding neutral percussion to that. As for in-game sounds, I used SFXR by DrPetter, which simply is incredible - in last LDs I was running an old SimSynth through Wine to get some poor sounds, now (also thanks to mjau) I have a native app with all those randomization features making sound generation much quicker.

Video

Since sound is covered, next to graphics. My tools were Gimp and Blender. But most of the visible graphics are Blender renderings. I do know by now how to set up a simple “armature” to get stuff animated. I still have no idea what the difference between the three windows IPO/Action/NLA is and why some of them are empty some times and sometimes not. And very likely connected to that, I can’t figure out how to give separate animations to separate things (like, doing the feet animation independent of the head animation, in the same armature). With everything downscaled to 640×480 pixels, not many details were necessary anyway though.

One thing which proved somewhat challenging were shadows. I decided I want to have them separate - since two tree sprites next to each other looked somewhat odd otherwise. Suffice to say, I had to resort to Blender’s Python-scripting capabilities to have a script which fiddles with material parameters - for the non-shadow version, disabling the shadow, for the shadow version, setting all materials to “cast-only” and a special “shadow plane” to “only-shadow”. The result is, each of my graphics has two versions, the shadow and the rest.

The biggest challenge however was the explosions. I learned some about particles, soft-body and the deflection setting in Blender. One thing I wasted time on was when I tried to get the explosion to cast a shadow - Blender simply can’t to that (yet?) - particles can receive shadow, but not cast it.

Code

Now, finally, to the code. I ended up not using pygame but my C-disguised-as-Python language and my custom library. Which for someone who wants to compile means, the following dependencies are required:

• allegro window, input, timers
• allegroglopengl context in above window
• DUMBmod player, actually not used, but i found no time to edit it out of everything
• OpenGL, FreeType, png, z, jpeg, ogg, vorbis, vorbisfile

After that, it should be a matter of compiling all .c files in the “generated” folder and linking to those library. I provided the Makefile I used for cross-compiling the .exe.

The actual code I have written is all in the src directory, little more than 800 lines. I love the Python syntax for that, even though the code is rather hackish and there’s no comments, the forced indentation makes it still easy to follow. There’s nothing really special regarding the gameplay, it’s a rather simple puzzle game, done a 100 times. I made one huge list of all objects (santa, trees, bombs, wood), then pass it to the C qsort function to sort by layer and by y position, then draw it.

The challenging thing was the water/ice/snow layers. The straightforward idea was to first draw water, then where there is ice draw ice tiles, and finally snow tiles. It just would have meant, if there’s a snow tile at x/y, cut that tile out of the snow texture, and place to the screen. However, I wanted to use an alpha mask for the cutting out - but OpenGL 1.0 does not allow specifying a separate alpha channel. Which would have left me with some texture combine extension, or a fragment shader. I read up a bit on fragment shaders, but then finally went for a software solution, re-calculating the water animation with possibly ice and snow in front each time level geometry changes.

Game Design

One thing I totally neglected was level design. The game I cloned apparently lived from the clever level design, giving you hours of puzzles. In my version, there are no real levels, basically just 13 tutorial/test screens. I guess I could try and find a ROM of the original then rip out the levels. Or try to create some challenging levels myself. In any case, when doing a puzzle game in an LD48, time for level creation must be factored in. It’s hard enough doing platformer levels in short time, but for a puzzle game it’s crucial.

Conclusion

In a way, not having the least bit of originality haunted me throughout the competition. I wish now I had thought more about my initial chain-of-lights on xmas tree idea (all the xmas setting is a remnant of it), then could have spent the time creating explosions and break-able terrain on implementing that idea instead.

Ok, here a final screenshot:

Download (including source and windows .exe) is here: click to download

Not sure the .exe works, it’s cross-compiled from linux.

Right now I’m tired and should go to bed as I have to get up soon again, but some short thoughts. I’m quite satisfied I managed to finish. But I’m somewhat disappointed by how disinventive I was. This is just the original’s gameplay, with different artwork. Also from the technical side, I didn’t try anything new. Well, I blame the theme

Ok, slept about 7 hours then coded for about as long. Still far from finished. I spent some time looking into OpenGL shaders, then decided against using them and instead fiddled with some slow software solution.  Now there’s about 9 hours left, but I can’t stay up until 4am so it will be much less. Hopefully I can make some small levels so there will be about 10 levels.

to keep me alive during this LD.

Ok, I went the easy way and just added bombs with a chain reaction explosion. Took me hours to make those explosions in Blender. Oh, and for anyone who was wondering: Blender’s particles can not be made to cast shadows - no matter how hard you try.

Was playing around in Blender for hours.. and still have no idea about the game mechanics. Somehow, there needs to be a chain reaction of light bulbs Santa can somehow initiate or influence. Or maybe I’ll just add some bombs and have them chain react, worrying about what Santa has to do with it later..

Ok, still no fleshed out idea - but somehow, it goes like this: Santa wants to light up all trees for Christmas, so he has to do some electrical wiring in the forest to cause a chain reaction lighting up all trees. So far all I have is some mockup drawn in Blender:

I still have no idea. That is, already when Chain Reaction won in round 1of the voting I thought I’d just remake an old puzzle game where you place to bombs to set up a chain reaction of explosions. Problem is, I already remade that very game in SpeedHack once, so it would be like totally un-inventive, a re-remake.

Another idea I’m toying with is, a chain reaction of light bulbs. Like, you have to light a Christmas tree with electrical bulbs, and a chain reaction is involved. A level is won when you manage to light the tree. Still don’t have a complete plan how it should work though.

Just a bowl of soup for me - half an hour before announcement of the theme.

 Nothing much to see here - and interestingly to my cellphone everything but the monitor looks dark..

Since everyone is posting custom libraries, I assume that was required somewhere in the rules? I’ll likely just use pygame, but if not, I might use this library or parts of it. I put the code on SF a few years ago, it uses Allegro and OpenGL: logo is here and code is here. It’s written in C disguised as Python (I converted it all from plain C after being inspired by pyplus).

Recently Phil Hassey from #ludumdare directed my attention to Shedskin. Shedskin is a Python to C++ compiler - so it could solve the same thing I'm currently solving with my crude line-by-line .py -> .c converter. However, my experience with it was that it's not quite ready. It started with being hard to get running at all - I ended up copying the lib folder and the FLAGS file from the original distribution into my project. Also, it is all but obvious to me how to interface external libraries. I ended up manually keeping 3 files, a .py, a .cpp and a .hpp in sync, editing each one for each function to add. This is what stopped me from actually doing much at all with it, it's clearly too painful to be useful that way. Maybe a way could be found to directly let me use external code instead? I call libc.printf, and it puts a call to printf. At the most, there should be a single description file where I specify the necessary header stdio.h and the types (and maybe also the library?) Editing three files for each symbol is almost as bad as manually using the Python-C-API. Also, again packaging related, there needs to be sane way to incorporate shedskin into my projects, the generated makefile and FLAGS file won't cut it at all. Finally, one of the main reasons I prefer C over C++ is compile time. This was already noticeable with my shedskin test - gcc needed several seconds just to compile the code produced by shedskin for the short test program and library wrapper, likely because it's somehow pulling in lots of headers. My reference code doing the same only takes an instant from .py (reg-exped to .c) to the executable. Additionally, the Shedskin website says that it will need increasingly longer for the type inference with growing number of lines, so with a real program, that may add a lot more time even. Not compatible with my rapid testing way of coding. Finally, I don't think type inference is very important for me personally. With dynamic code, it is nice that I can just throw around objects of different types and let everything be sorted out where I want, even using techniques like duck typing. With static code, seeing what types are needed actually can be an advantage sometimes - else I manually would have to add comments about the types or do manual type inference. So, for now, shedskin is not for me.

For the LD4 in 2004, we did a series of preparation compos. They were much shorter as a real LD, and as theme had the remake of an agreed upon classic game. One of them was Robotron (the others were Sapce Invaders, Frogger and Spy Hunter). In the Robotron one you had 4.8 hours for the game. My entry turned out to be a much better game than the one I actually wrote with 10 times as much time for the real LD. Oh well.

The game is rather simple. One directional input (cursor keys) controls the movement of the pink blob, another one (ASDW) controls the gun. Just like in the original.

There’s 30 partially random levels, and quite a lot of different enemies with unique behaviors.

Some of them, like the crab and the spider, were added in a post-compo version. Those are really hard (but fun, this is one of the few of my games I play through occasionally), as is the final boss. The crabs circle you, and the spider tries to aim ahead when shooting - back then I was still good at calculus, apparently The final boss doesn’t shoot you directly, but takes a lot of hits and spawns random enemies.

Photon was my entry to LD6. The theme was “Light and darkness”. I still remember all the time I fiddled with shadow calculations. In my game, each light source does exact shadow calculations with all the level geometry - and in order to still have it all run with < 1% CPU, this was quite some work. Now, there’s nothing special about this except, I wanted to do things in the most simple way possible, this being an LD. And I had to admit utter defeat when I later saw bluescrn’s entry. Instead of spending half of the 48 hours on it like me, he went for a dead simple approach - with the only difference that his was not 100% accurate. Which would have made no visual difference in my game whatsoever. In fact his shadow method would have worked a lot better in my game in just about every respect

I still managed to do quite well. Here’s some screenshots from back then:

The title screen.

The goal of the game is to send all the photons coming from the lamp to the prism, but the problem is, you only can see the areas of the map which are lit up by the moving photons.

To control the photons, you can place mirrors - to light up more areas of a level, and once you have found the prism, send them all to it.

Seems the original submission is still up: original zip at original site

Swarm was my entry to LD8. The theme of was, well… “swarm”. I know, I know, I’m no good with coming up with names for my entries. Anyway, for this game, I coded an entire 3D engine (octree based) from scratch. So, I spent most of the 48 hours debugging octree code, and crammed in some gameplay towards the end. Since I never spend more time on gameplay - it still should be as fun to play as most of my games

This is an in-development screenshot, showing some octree debugging going on.

That’s how the game looks like. Shoot down all the pink, eyed balls to encounter the uber-cool-final-boss-with-superior-AI. (I got feedback suggesting that at least one person actually played long enough to encounter the boss - so I consider the gameplay aspect successful.)

Here’s a mirror of the original submission: Swarm

Hydra was my entry to LD7. The theme was “growth”. It’s a top-down shooter, where you play a growing hydra.

At the start, the hydra is merely a small worm - and even a single knight who has set out to kill you is a dangerous foe.

Some levels later and after eating lots of knights, the Hydra has reached quite some size. But, there’s now also more knights, and they also got bigger and stronger.

The final form when you win the game - I doubt anyone ever has encountered this without using cheat codes.

Download: original LD7 submission (no idea if it still works on modern systems)

Battery was my entry to LD9. The theme was “Build the level you play”. Initially, the open voting hinted at a clear winner of the theme “battery”, for which Hamumu found the best explanation: Battery is a place where bats are hatched. Now, when I woke up the morning of the LD, first thing was I checked the theme, and it mysteriously had shifted. So, I decided to make an RTS where you start with nothing, then have to build up the battery you play.

The title screen.

An in-game shot. Basically, you can order bats to dig (build the level you play), and in the new cave room build different structures for hatching worker and soldier bats and providing food to them. At fixed intervals, a wave of most horrific enemies will attack the battery - so you better have enough soldiers by then.

Insanity was my entry to LD4. The topic was “infection”. My idea was somewhat far-fetched and only in the story - the home town of Ian the janitor is befallen by an infection of insanity - so he has to beat up all the scientists at his workplace to find the cause of the infection and a cure.

Since I messed up the base engine (tried to somehow stuff the 3D into 2D), I wasn’t able to finish. There’s just one level with place holder graphics, but the level can’t be won and so the story never reaches its conclusion.

Gnome Guard was my entry to LD1 - theme guardian. In the game, you are confronted with a horde of small gnome children, and have to safely guard them home after school.

The title screen

The gnomes will run towards the green pillar, and avoid the red pillar.

But only if they feel like it.

The original download is mirrored here - no idea if the game itself still works: download link