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.

Conclusion

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!

David

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.

David

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.

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.

Oops…

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.

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:

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

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!

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:

http://eel.olofson.net/news.html

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

David

UPDATE:

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

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