Hello there, LD community and whoever else might read this!

I’m new around here, but not totally new to game development. Some might have heard of some Free game I’m messing around with every now and then, and maybe even seen some programming example of mine, involving a pig. 😉

Anyway, after spending way too much time figuring out what tools to use, working on my new site, Olofson Arcade, and various other things, I’ve finally decided what to do, and (roughly) how.

[…]
So, some time ago, I decided that I’ll just wrap Kobo Deluxe up and finish it according to the original design goals: “An enhanced version of Akira Higuchi’s game XKobo.” Nothing more, nothing less. It’s a small, retro styled game for hardcore arcade fanatics, and that’s the way it should stay, modulo some easier skill levels for the occasional joystick wizard wannabe. 😉

Now, what to do with all those ideas that had accumulated, all the unofficial experiments, all the neat graphics tricks that wouldn’t really work without OpenGL, and all that? But of course: A sequel!
[…]

Full story here.

David

Well, bad news first: Yesterday, I lost many hours to an old, nasty bug in my EEL scripting engine.

The good news: I cracked the bug! Turned out to be memory corruption due to the VM allocating one byte to few for a “stack” used for memory managing VM register variables. (EEL has an oddball automatic memory management solution, due to it being targeted at realtime applications. Reference counting with a few shortcuts, basically.) This had gone undetected as it only happens when you have a multiple of 16 register variables in a function.

Also, I now have an “Olofson Arcade presents” screen, a title screen with a nice, animated logo, and some nice code to play around with. So, now I can throw some game logic in the mix! I intend to take the Kobo Mk II for a first test flight some time today.

Not as much visible progress as I would have liked; there is one of those “thanks for playing” exit screens now, and yes, I did make that first test flight mentioned in my last post! Not very interesting at that point, but at least, I could experiment a little with Asteroids style control (rotate + thrust) vs the classic Kobo Deluxe style controls (aim and go in the direction indicated).

Right now, I have a control system that’s much like that of Kobo Deluxe, but the ship is actually driven by physics (ie mass, inertia, forces, acceleration etc), using a set of thrusters for power and control.

The advantage of using actual physics is that I get that nice, smooth, realistic feel, along with actual data to use for rendering the ship and thruster flames. Also, I can very easily have the ship respond sensibly to projectile impact, collisions and whatnot; just apply the forces and let the physics deal with it.

The downside is that “real” physics demands real control engineering! Typical naïve methods will only have the ship wobble uncontrollably, just as it would in real life. Fortunately, I’ve spent some 12 years doing control engineering for a living, so I can probably figure that part out. 😉

Oh, the ship has cannons too! 😀 Two sets even; one that’s much like the forward cannon from the old Kobo Mk I (the ship in Kobo Deluxe, that is), and one that spews out a massive, cool (er, I mean hot…) looking stream of… lava or something. The latter was just the result of my initial experiments, but it might show up somewhere, in some form.

I’m thinking of dropping the tail cannon of Kobo Mk I, and use two weapons instead; a primary nose cannon and secondary tail mounted device that drops a bunch of small bombs or similar. The latter would be mostly a defensive weapon, to get enemies off your tail. I’ll play around with it and see what works and what doesn’t – but first, I need some enemies…!

Just posted another update on Kobo II over at the Olofson Arcade:

Looks like I’m pulling in the old ZeeSpace after all. That is, structured/procedural/parametric graphics! You know, this sort of stuff:

I planned on just doing some placeholder graphics in GIMP for starters, but that’s just a big waste of time if it’s going to look anything but mediocre. With ZeeSpace terrain and models instead, I basically get instant nice looking graphics that is easy to scale and modify, and that can also be refined and polished to production quality later on. Also, as it’s structured graphics, there’s no need to worry about display resolutions; it’ll render razor sharp in any resolution – even on a 2560×1600 screen.[…]

Full story.

Well, first of all, I’ve been spending lots of time doing paperwork, and a few hours working on this: Olofson Consulting.

When it comes to actual game development, there have been some issues as well. Not exactly unexpected, but I’ve spent a little too much time trying to figure out how to actually use ZeeSpace for backgrounds. It is fast enough for realtime rendering, and at first, I intended to leverage that to do away with map size restrictions – that is, you’d be able to fly “forever” without wrapping or hitting some artificial limit. However, there are various problems with it, most importantly:

• You need to generate the background graphics incrementally, and unless you’re running rather low quality settings, this is expensive enough that distributing the work evenly enough across frames becomes tricky.
• To use the shadowcasting feature – which looks really nice, and is pretty much required to spot tall structures and mountain peaks – I need access to Z channel (ie height field) data way outside the area I’m actually rendering.

I have figured out various solutions, but obviously, this is pretty hairy stuff to get right, and certainly not something I can whip up in a day or two.

So, what I’m going to do for the alpha version is simply restricting the map size to some sensible size (slightly larger than the Kobo Deluxe maps, I think, as Kobo II won’t wrap) and simply pre-render the whole thing before starting the level! If you want native resolution backgrounds at 2560×1600, that’s almost a gigabyte of data – but if you can get by with 640×480, you “only” need 50 MB or so.

Obviously, there is a huge potential for compression here, for future releases. There is the obvious lowering the color depth and various graphics compression algorithms, but more interestingly, since all graphics is either generated (Perlin noise and the like) or structured (various primitives; surfaces, domes etc), there is a lot of potential for the compression algorithms taking hints from the structured data, rather than just looking at the raw pixels.

And, there is also the option of actually following the tile grid when placing map objects, to improve the chances of the compressor finding identical tiles. Chances of leveraging this can probably be improved if lighting data (shadows) is separated from the “raw” graphics, so that top-right corner of building 23 is always the same tile, regardless of whatever other tiles are casting shadows on it.

Given the nature of the graphics at this point (mostly monochrome surfaces with geometry + lighting doing most of the work), one might actually get away with trivially compressing many of the tiles to 8 bpp monochrome, with just a single RGB color per tile for “colorization”. One might even interpolate color across the surface of each tile, to support smooth chroma gradients with virtually no memory overhead.

Anyway, bed time…!

Obviously, with me in the process of starting business and stuff, things haven’t been progressing as planned with Kobo II with regard to The October Challenge. I’ve given up on the idea of starting the pre-purchase alpha period this month, as there isn’t enough to show yet – and besides, I risk getting in trouble if I actually sell anything at this point, so that’ll just have to wait.

Anyway, I can fly around in rather nice looking terrain and fire two different weapons at the mountain peaks in the area, but that’s about it so far. Next project is adding some sound effects, I think. I mean, no sound is really boring – and I’m a sound/music guy, perhaps more than anything…! That just won’t do.

As to the Challenge, I am going to try to release a small technology preview before the deadline! The watermark in the corner actually says “GAMEPLAY PREVIEW” right now, but that doesn’t seem appropriate just yet.

Now, as I said, I couldn’t safely start doing business at this point even if I did have a product ready for release – but I suppose I don’t have to refuse the occasional donation… And I suppose I could accidentally give away a final version license or two. You never know… 😉

As far as game design and visible progress goes, things have been moving slowly the last few days, but here’s another update – and an in-game screenshot!

I’ve been working a bit on the sound engine, but mostly cleaning things up and fixing some minor cleanup exit bugs. However, I figured it was time for a screenshot, so I threw in a screenshot feature.

Full story.

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:
http://olofson.net/spitfire/

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

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.

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!

David

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… 😉

David

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.

David

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.

David

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.

David

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

Tags: ChipSound, EEL, GIMP, Kobo II, linux, opengl, SDL, Windows, ZeeSpace

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

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

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:

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.

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.