About Olofson


Ludum Dare 22

Olofson's Trophies

Olofson's Archive

The Grumpy Pinball Ball – Postmortem

Posted by
Tuesday, December 20th, 2011 8:16 pm

Well, if you spent the last few years being slapped around a table all day, you’d be grumpy too! This ball just wants to be alone on his blocky islands.

Entry is here.

(And yes, the .eel files are plain text source files, so that’s the full, hackable game source right there. The language is a bit like Lua with a C-like syntax.)

Well, the other balls don’t really do anything, as I didn’t get around to implement any AI. And I didn’t get around to do any music either. And, it might have been a good idea to “tilt” the terrain of the higher level maps towards the viewer, or just select a few good areas from the Perlin terrain, as it gets a bit tricky when you can’t see what you’re doing. :-)

What went wrong

Decided to go for isometric 3D, so I had to code the engine for that, along with some physics. Not strictly a bad idea, but it was actually my first attempt at that particular kind of engine, so getting it to work correctly while not melting the CPU might have cost a few hours extra. And, I still got the depth sorting wrong in some cases…

Also got this crazy idea of coding a tiny MIDI sequencer, instead of just typing music in as ChipSound script, but the net result of that was just a wasted hour or so, as I didn’t have enough time to do any music anyway.

The biggest problem, however, was that I just caught a cold with fever, and couldn’t cope with the kind of tempo and short naps I planned for. All in all, I put in 27 hours of effective work time. Could have used 5-10 more hours – and they would have been there, even in the 48 h compo, had I been in proper shape.

What went right

Initially, all I had was this vague idea that the game would be about someone or something that wanted to be left alone. I decided right away that I’d go for isometric 3D and focus on low level game mechanics, so I drew a block in GIMP and coded away.

I realized I wouldn’t have time to do a proper character with walk cycles and stuff with the tools and (lack of) skill at hand, so I considered giving the rubber pig starring in my Fixed Rate Pig SDL example a call – but then remembered I need to work alone, and drew a shiny steel ball in GIMP instead.

Going with a steel ball actually turned out to be a brilliant move, as it became instantly obvious that the game mechanics would focus on bouncy physics, which can be a fair bit of fun in it’s own right, without any “artificial” game rules. In fact, there’s only one rule: A ball that touches the lava dies.

And of course, I did finish in time to submit for the Jam, so failing the main event wasn’t a complete disaster. (Actually did try to submit in time, but it just wouldn’t work – and probably for the better, as that version was pretty useless anyway.)

Lessons learned

No real surprises here, but well worth pointing out:

  1. Coding a custom engine for a time limited event like this is a gamble, unless you really know what you’re doing. Each kind of engine has it’s own set of problems, and unless you’ve written one of that particular kind before, a few hours will likely be lost understanding and solving problems that are brand new to you. That can be fun and challenging, but the gamble is real: If you fail, you’ll still be struggling with the engine by the time of the submission deadline.
  2. Make sure you have a functional, complete and efficient toolchain that you’re up to speed with, for anything you want to use in the game! I could have leveraged ZeeSpace and ChipSound better, but I don’t yet have a functional authoring tool for the former, and I don’t have a proper music setup. I’ve been having the same problem with Kobo II, and the LD #22 just made it more obvious that I need to fix this ASAP.


One would think that after a full weekend of being ill while working frantically, especially after previously having worked for weeks in a similar manner to get the Kobo II tech preview out, one would just want a long vacation – but I’m more excited than ever to get back to work! I’ll probably start by adding some more gameplay elements to Kobo II for a Christmas Special Tech Preview 2, and then I actually will take a break – by hacking a sequencer/editor for ChipSound…! πŸ˜€

UPDATE: Timelapse video uploaded!


Submission failed

Posted by
Sunday, December 18th, 2011 9:36 pm

Dunno what happened, but submission just wouldn’t work for some reason. No response, and apparently nothing entered.

OTOH, no big deal, as there isn’t much of a game anyway. It’s “playable”, but the physics is half finished and enemies don’t actually do anything. I’m considering entering the Jam instead, although have a cold and for some strange reason, I’m rather tired. πŸ˜‰ Also, should get back to work on Kobo II ASAP. But well… Some 20 hours more or less.

Anyway, here’s what I tried to submit:

Direct download.

EEL scripting engine with full source, Win32 build and the support scripts I started out with can be found here, as announced earlier.


8:30 effective work time so far

Posted by
Saturday, December 17th, 2011 6:37 pm

Just did a 2 stint for a total of 8h 30 min, according to my screen captures. (I only capture while I actually work.) Need to improve on that for the second 24 hours that are about to start. However, considering cold + fever and being sleep deprived before I started, that might not be too bad anyway.

Of course, screenshot:

Might not look all that different, but what’s happened is that the “bobbins” and stuff like that are now “entities” that can be moved around arbitrarily. They’re still linked to the map for proper z order when rendered.

Oh, and there’s the main character half hiding behind that block: A grumpy old pinball ball…! πŸ˜€ (Oh, you’d be grumpy too if you’d been slapped around a table for hours on end on a regular basis the last few years.)

Ok; so that didn’t take many minutes to draw, and doesn’t really need any actual animation. I’ve been in better shape, and I’m essentially coding the engine as part of the game, so I need to focus on gameplay first.

More weird stuff

Posted by
Saturday, December 17th, 2011 11:01 am

Screenshot after I’ve abused GIMP for a while. Added a detail layer to the engine in order to handle these, as they have to be “ignored” when optimizing the map, due to them not fully occluding the background.

Probably going to link characters and items into the engine in a similar way… Nice, simple and effective – or so it would seem at least. Can’t use OpenGL Z buffering here, as everything is alpha blended, so what happens is back->front rendering of everything that’s potentially visible.

Wut? Yeah, I know; hurts my eyes too. It’s just a debug feature, FFS…! πŸ˜€ I’ll have the terrain generator paint the map in some interesting way, or something like that.


I’m thinking about putting some water out there. And maybe in some areas of the actual map too… But, later, if there’s time. I don’t think it would be of much importance to the gameplay anyway, the way I imagine it now.

On the edge

Posted by
Saturday, December 17th, 2011 8:21 am

Invisible guy walking close to the edge of the world in which he is apparently all alone…?

Just woke up after a few hour “nap”, got some coffee and mooshroom pie, and figured I’d drop a note before I move on.

I’ve optimized a little; now carving out sub-surface tiles and culling off-screen blocks. Not the most efficient implementation, but it’ll do for now. A you can see, I’m rendering only a fraction of the 8k+ blocks now – and this is on a 128×128 map, so this scales reasonably.

In other news, the cold I caught is apparently trying to kill me, but is having limited success so far, so work continues!

Oh, and I made some proper “buttons” for the main menu too:

First screenshot

Posted by
Saturday, December 17th, 2011 1:06 am

Engine! Sort of… πŸ˜€

I was a bit worried that I’d run into performance problems with an isometric engine, due to the fact that I don’t have one in this code base, so I have to script it from scratch. Doesn’t seem like that will be much of a problem, though. The screenshot shows 172 fps with plain brute force, the whole map (which is solid; blocks stacked up to height) rendered without culling. That’s 8951 blocks, every frame – some 10-20 times the number of blocks that actually fit on the screen.

(Core 2 Quad @ 2.4 GHz, single threaded, GF8800 SLI, 64 bit Linux.)

Getting started

Posted by
Friday, December 16th, 2011 10:36 pm

Lately, I’ve been thinking about some kind of synthetic looking isometric 3D world, and I might go with that; not sure yet. Played around a bit in GIMP and came up with this:

I imagined a bit more neon glow, actually; a bit like the “overbright” glow on an old CRT, or something like that. Oh well, that will work for now! (And yes, the block is of course actually a monochrome texture, so I can modulate those to whatever color. That might be fun!)

Now, coffee, and then code and engine and figure out what to actually do in there! πŸ˜€

Primary weapon revealed: the Kobo II Executive

Posted by
Friday, December 16th, 2011 6:20 pm

The scripting engine with bindings, physics and the weird little sound engine, ChipSound, now available here; full sources that “should” build on Linux, Windows and probably various other platforms without too much tweaking:


Win32 build + support scripts (GUI toolkit, config file management and stuff like that) will be available in a moment.



Win32 build with the aforementioned support scripts. SDL and other DLLs included, so just unzip somewhere and start k2x.exe for… a not too interesting demo app/skeleton. Well, at least there’s a nice logo + jingle! πŸ˜‰

  • Win32 build here.
  • Scripts and stuff without the Win32 binaries. (You need to build ChipSound and EEL to run this.)

I’m *probably* in…

Posted by
Friday, December 9th, 2011 3:10 am

Still on the fence here, as I’ve been crunching for a few weeks, currently have a splitting headache, and could use a few days off instead. But…

OTOH, the Kobo II Tech Preview is now on-line, which means that I have a working Win32 executive, making deployment trivial. (There is no game code in kobo2.exe, only EEL with SDL, OpenGL, ChipSound, physics etc.) So, I should be able to pull this off without touching glorified assembly languages, or even running a native compiler. πŸ˜‰ (Well, I might rebuild the executive with a different icon. That should be safe. I think…)

So, if I do it, here are my weapons of choice:

Language: EEL (Runs on the Kobo II executive.)
Editor: KDE Kate
Libraries: Kobo II/EELBox executive (SDL, OpenGL, ZeeSpace, ChipSound, …)
Sounds: ChipSound
Music: ChipSound
Graphics: GIMP, ZeeSpace

Kobo II: October Challenge 2011 results

Posted by
Tuesday, November 1st, 2011 12:25 am

Well, I’m too tired, and there are too many remaining issues. Not much chance of wrapping anything reasonably solid up right now, so I’m writing this report before I go and get some sleep.

So the next goal is to release the alpha/tech demo and start taking pre-orders before Monday 7th.

Kobo II now has a Boomerang fighter with an “ElectroGun”, similar to the ones in Kobo Deluxe, that is, trying to circle around the player, firing some sort of electrically charged “bullets” at said player. Not much AI and no aim-ahead, but you need to respond actively to avoid pain.

There is also a massive drop ship that moves between random waypoints, teleporting enemies into the battlefield. When attacked, it will face the attacker and backpedal, while returning fire using a truckload of guns. Being in the wrong place hurts. A lot!

Current game mode is a Survival variant, where each stage N has N drop ships on it. You need to destroy all drop ships to clear the stage and move on. A score bonus of 10% extra per stage is awarded, and there is also an “adrenaline bonus” that multiplies the score when destroying lots of stuff in a hurry. Death, should you chose to continue playing on the current stage, is avoided by giving up 50% of your score in exchange for a new ship.

The drop ship doesn’t seem to like having screenshots taken of it when in action, but I managed to capture part of it anyway. (Placeholder graphics; constructed from various Kobo Deluxe tiles and sprites.)

Scratching the paintjob of the behemoth, moments before being violently desintegrated.

Playtesting is… not boring! This might work. :)


Kobo II: Micro-update

Posted by
Thursday, October 27th, 2011 6:38 am

Haven’t given up yet, and there are a few days left! πŸ˜€

However, SMART says my secondary harddrive might die any moment now. I do not need this now! :-( New drive ordered, and making extra backups to external drive, hoping that the old drive will last until the new one arrives.


Kobo II: Final week

Posted by
Tuesday, October 25th, 2011 6:45 pm

Well,Β I’m still alive and… hacking! :-) But time is running up, and I need to get back to work, so I’ll just link to the small blog post I just wrote over at Indie DB for now.


Kobo II: Second try!

Posted by
Thursday, October 6th, 2011 8:30 pm

Yep, Ludum Dare is running the October Challenge again – and I’m in, of course! :)

As some of you might remember, Kobo II begun life in last year’s October Challenge. The plan was to start really small, with little more than placeholder graphics and basic game logic, especially considering that I would use my own language EEL, which didn’t even have an OpenGL binding at the time.


Full story.

Last year: Scripting engine with no OpenGL binding.

Now: The below + physics, GUI, sound engine etc. Somewhat better chances of coming up with something playable, I guess… πŸ˜‰

Massive explosions


Project Spitfire results

Posted by
Monday, November 29th, 2010 9:29 am

Well, as it turned out, I didn’t get anywhere near 48 hours; more like 8… Even so, I now have a slightly updated retro sound fx engine (PC speaker emulator, originally), and the OpenGL based graphics engine can load and render tiles, maps and sprites. Not quite what I intended (a playable game), but still OK considering that I’m messing with old C code and only got a fraction of the time I planned for.

I’ll probably spend a few more hours on it now, getting the game logic in too, before I go back to working on Kobo II.

Still not quite sure where to go with Project Spitfire from then on. Stick with the 320×240 256 color retro style graphics, or upgrade to current standards? Or maybe make it even more retro…? Or something completely different, way out there? Keep the fast scrolling (60 pixels/second in the original 320×232), or step down to a more traditional scrolling speed? (This has massive impact on level design and attack waves, obviously – which is why I’m leaning towards the fast scrolling, rather than doing what “everybody else” has been doing for a few decades now.) More of the current 8-bit era fixed attack waves, or add smarter enemies?

Well, a few more hours, and I can start to actually try things out and see where I want to take it – which was the whole point of picking this up in the first place! So, although Real Life(TM) got in the way again, making the deadline impossible to meet, I still got another project off the ground, and in the process, I cleaned up some old code that might show up in other projects later. For example, the graphics engine uses some code from Kobo Deluxe and the OpenGL binding from Kobo II, and might replace the messy code (and glSDL) in Kobo Deluxe later on.

Thanks for the motivation and inspiration!


Project Spitfire status

Posted by
Sunday, November 28th, 2010 4:18 am

Well, I haven’t been able to spend all that many hours on it, and yesterday, I just couldn’t focus if my life depended on it! No idea what that was about… So, I’m still basically nowhere.

At this point, I’m not really expecting much, but nevertheless, I’ll spend the few remaining hours on it, and see if I can get something together. If nothing else, writing some code and actually taking a few steps in the right direction might take the edge of the intense frustration I’m feeling right now.

Bringing Project Spitfire back to life

Posted by
Friday, November 26th, 2010 6:58 am

First of all, I should make it clear that an elderly close relative of mine is in the final stages of cancer, so I’m not sure how much time I’ll be able to spend on this. Also, I’ve been working on Kobo II (a new sound engine, actually) rather than thinking about the MiniLD, and I pretty much decided what to work on while writing this.

First, I was thinking I’d “just” add sound and a level editor to Fixed Rate Pig, which may seem closer to a finished game at first sight – but thinking more carefully about it, it feels like Project Spitfire is practically as close, and more deserving of an update, as it’s practically dead in it’s current state: a windowed mode Win16 hack of a port with no sound.

Thing is, most of the engine code has actually been ported already; the core of the Kobo Deluxe sprite engine is actually a port of the one from Project Spitfire, and the “speaker” sound hack plays the original sounds from the DOS version. I’ll probably use OpenGL for smooth scrolling (it’s a pretty fast scroller, so it’ll look horrible at low frame rates…), and I might rip the map editor from my “smoothscroll” SDL example. Massive code reuse, that is! Hopefully… :-)

Not expecting to do any significant work on the actual game or anything during the weekend; just bringing it back to life, so I can play around with it and see if I get inspired or something. If nothing else, it could make another programming example for people to play around with – and perhaps a way for me to show that I can occasionally write a few lines of working C code. πŸ˜‰

Incredibly old site with info, screenshots and Win16 download can be found here:

Wow… Just realized the original DOS version is 15 years old now. Maybe it’s time to, like, finish it one of these years…? πŸ˜€

[cache: storing page]