Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

Olofson Arcade

28
Posts
68
Followers
49
Following
A member registered Oct 22, 2016 · View creator page →

Creator of

Recent community posts

Thank you! :-)
There is a TODO and design document for the game now, actually. I hope to get back to it eventually.

Thank you!

I do see your point, and it does definitely change the feel, which at least takes some getting used to.

Part of the reason for the change is that the zero inertia "physics" of Deluxe/XKobo causes various technical and aesthetic problems, and can be rather tiring on the eyes, no matter how you try to deal with it. The main reason, however, is that most players are used to smoother, more physics-like movement, and find the old games rather weird. (Some even believe they're grid based, which is not the case!)

For the Kobo II prototype, I went all modern twin stick shooter (after some failed attempts at single stick controls), but that's a different style entirely, and it's virtually unplayable without an actual twin stick gamepad. (Well, it does support mouse + keys, but at least for me, that's just too slow and confusing when the game gets intense.) Different game, for different players.

Redux is an attempt at applying some of the "modern" feel to the single stick control style, rather than turning it into an entirely different game. So, essentially, what I tried and failed to do with Kobo II.

That said, the parameters can certainly be tweaked, and I might experiment further with that - possibly even offer a selection of different player ships. What's there right now is pretty much just what felt comfortable to me, after playing mostly FPS games these last few years.

Yes, those are the only ones at this point.

And on that note, it's perfectly fine to make third party skins, even commercially. Legally, it's basically the same thing as forking the code and building a new game, which is, of course, also fine.

As for my "share," I'm going to have to recreate the enemy definitions and levels, as those are also part of the GPL XKobo code (and don't really fit the new physics all that well anyway) and I might put that data in the proprietary data. However, I still intend to package the FOSS source tree as a fully playable game, so in that case, it would just have a conversion of the XKobo/Deluxe levels or something - so essentially what is there right now.

Thank you! :-)

That's awesome! More than fine by me, as this was the idea behind this model.

(That said, the game logic is still based on the original GPL code, which actually requires this licensing model - but since that's incompatible with certain platforms, such as Steam, that code will be replaced eventually. However, this licensing model will remain!)

BTW, is the free installer using my (very crude) "Spectrum style" theme, or something more proper?

Thank you! Will do, eventually. There's been a bunch of updates to the underlying "tech" (EEL, Audiality 2 etc), so I'll at least port it to current versions, and re-release it on itch.io, for starters. I have some ideas I want to explore with that engine.

Thanks! Well, the bomb particles are active physics, and deal damage, so they can hurt the cat, and you can also use bombs to launch other bombs - but that's about all at this point. :-D I focused mainly on just learning the basics, and getting my usual "perfect pixels with native resolution positioning" going (the way I do it in Kobo Redux), because I wanted to make sure Godot can deliver the kind of smooth player experience I want. And, clearly, it can! There are some minor issues and messy areas, but overall, Godot has been a great experience so far. Might use it for non-game dev as well, as it's actually a lot smoother to use than traditional GUI toolkit solutions, especially if you need to go beyond the basic controls. I'm wondering what it would take to integrate it into VST plugins and the like...

Adorable animation, and exactly what I was looking for for my little OST Jam entry, Bombercat - and I see you just added wallgrab and wallclimb animations! I was planning on implementing that in the game originally, but didn't get around to it during the jam.

Nice and cute game, and the music fits well! Had a good time playing this.

(1 edit)

Well, I've seen a number of ATI/AMD specific issues through the years, and even did the occasional hack to get applications to work with them, so it's not all that far off to assume they're at fault yet again. ;-)

Not much I actually can do through the SDL API, as it wraps these details - but I wouldn't be surprised if there are workarounds in newer versions of the library. You might want to try replacing the SDL.DLL that comes with the game with the latest one (2.0.12, 32 bit) from here:

https://www.libsdl.org/download-2.0.php

On that note, I have some ideas for future versions, leveraging the rewind/replay system in a more interesting way. A bit radical, but it has been done before. :-)
https://github.com/olofson/koboredux/issues/560

Yes... Achievements have certainly been considered (at least for the Steam release - but one might as well implement local achievements for other builds, I suppose), and it would make sense to add some actual cost to the rewind thing, and/or some kind of reward for avoiding it, but I'm not sure how to go about it. Although it won't let you bypass anything, it's still kind of "free infinite retries" as it is.

I see! That makes (some) sense, as 3D accelerated windowed mode is notoriously problematic. I'm guess it is indeed one of those cases of the driver not synchronizing every frame, but I'm not quite sure what to do about it, as that's something that's supposed to Just Work(TM) with SDL. (I'm not using OpenGL/Direct3D directly in this game, so I don't have direct access to the full APIs.)

I'll see if I can make a build with the latest versions one of these days, so we can see if that has any effect on it.

Awesome! Your feedback is greatly appreciated - especially since I've never seen these particular issues before.

The audio engine relies on "flywheel sync" with the game logic in order to provide constant latency sub-sample accurate timing (as opposed to typical engines that just play sound effects as soon as they see the commands, "quantized" to buffer boundaries) - but this will fail miserably if proper timestamps are not available, similarly to the rendering and game logic.

If you set the skill level high enough (or play far enough into the game), you will probably end up in a situation where you have to keep retrying for a good while before you can progress. So, indeed; you'll never run out of lives, and could keep retrying forever, but you may well end up in a situation where you just can't progress, and have to start a new campaign instead.

Of course, there could be a limit of five rewinds in a campaign or something - but then you wouldn't have the option of coming back later, and see if you've honed your skills enough to continue that "impossible" campaign. :-)

That rings a bell... Have you tried with/without retrace sync? I've run into a few drivers/environments where frames are not synchronized under certain circumstances, which results in a buildup of enormous numbers of queued frames between the application and the driver. Naturally, that will completely foil any attempts at managing timing.

Anyway, yes, as it is, the game's 50 stages will repeat, with increasing difficulty, just like XKobo/Kobo Deluxe. Everything will be maxed out (constant bullet hell) somewhere around stage 400 (IIRC), but the 50 stages will keep repeating indefinitely.

However, in Redux, I've replaced the lives with a shield, and a time rewind/replay system, so while you only have one life, if your ship is destroyed, time is rewound, and the events leading to the time of destruction are replayed exactly as they happened. By pressing fire at any point during this replay, you can take over the controls, and resume the game from that point.

So, basically, I've made the game completely unforgiving in that the only way forward is to actually handle the situations your run into - but instead, you can rewind and try different strategies as many times as you need. My thinking behind the rewind/replay system is that it gives the player a fair chance at actually learning how to handle difficult situations, rather than just brute-forcing through them at the cost of previously gained ships, or even "restarting" the game with a full set of ships on the current level.

Hello, and thank you very much for your support! Not sure why the motion filter would do that, but then again, I'm not massively surprised, and was going to suggest trying to disable that, among other things. Glad you got it working! :-)

Meanwhile, 0.7.5.1 doesn't have THAT problem here, but instead, I can't seem to get any sound out of it! Not seeing any of these problems with my development branch (latest SDL2 + various fixes and updates), so I guess it's about time for an update... :-D

Awesome! Any audio related log output? It said 1.9.4 in the log, and I've pretty much only added documentation and build script fixes to Audiality since then, so it "should" work with master as well. Anyway, have fun! :-)

Looks like the build is fine, as far as I can tell from that, but the game can't find the data files. IIRC, it should work if you put all of them in the user .koboredux folder. (That is, gfx and sfx should be subfolders in there.) You can run kobord with the '-debug' switch to see where it's looking for these files.

Audiality 2 can be installed anywhere, and should be found by pkg-config if installed correctly.

Make sure you get the right version, though! (Specified in BUILDDEFS.) Normally, just building the latest master of the game + libs should work, but if you check out older versions, you may need the corresponding Audiality 2 version, as these are still development versions that break compatibility every now and then.

You can look at the install-libs script to see how things are supposed to be installed, which also covers checking out the correct versions of my libs.

(You can actually run the script to download, build, and install the dependencies, but it's really meant for virtualized build hosts, so it might install additional versions of libs you already have on the system, if they're not were the script expects them to be.)

Thank you! Well, I like how the controls and physics of Kobo II came out, and would like to build a proper game around that at some point. Deluxe was technically finished as soon as it was a working SDL port of XKobo, but it became a messy testbed for random ideas, and definitely needs some cleanup, and probably some sound and graphics updates.

Anyway, these three projects are physically related; Kobo Redux is (so far) based on the Deluxe code, the scripting language/engine of Kobo II is used in the Redux project, and Redux uses the same sound engine as Kobo II. Part of the plan here is to share more code between the projects, to somewhat remedy the mistake of using custom code for basically everything.

As for Deluxe, I've started a new repository for it (https://github.com/olofson/kobodeluxe), where I've pulled in fixes from Debian for starters, and I'm going to backport various bits from Redux, including the SDL2 rendering, since SDL 1.2 is obsolete. Not quite sure what to do after that, but at least, I think the "unbeatable base" issue should be fixed, and there should be a more strict campaign mode, but I don't know... Of course, Kobo  Deluxe is, and will remain, an entirely Free/Open Source game, so I guess people could join in, but C++ scares many potential contributors away, and even more so if the code is ancient and messy, so my expectations there are low. :-)

Thank you very much!

Indeed; the updated mechanics and physics call for everything to be rebalanced, and I also want to introduce some more "designed" maps, along with fixed seed campaigns, to enable competitive play, speedruns and the like. There are also some old issues, such as the maze generator sometimes creating more or less unbeatable bases. These are some of the reason why the refactor/rewrite is needed.

Well, the problem is, the remaining bits of code from Kobo Deluxe/XKobo need to be replaced for legal reasons, before a Steam release is possible. This is code that desperately needs to be refactored or rewritten anyway, so it's no major setback, but the legal situation prevents me from even entering Steam Early Access until this is sorted.

Meanwhile, I took a ~2 year break from "spare time" coding, and then, 2020 has been... interesting. However, over the last few months, I've been updating the sound engine and other related projects - and next up is a new graphics/game engine core, which is pretty much the blocker for Steam.

So, Steam Early Access in 2020 is a possibility. There will likely be a content update, including a new soundtrack, before, or in conjunction with that.

Thank you!

The 80's (or possibly early 90's) arcade feel is indeed what I'm going for, or rather, what might have happened if someone with a huge budget were to build a machine around that time. Multilayer parallax scrolling, hundreds of sprites, scaling/warping effects, lots of sound chips etc - expensive, but all technically possible with hardware available back then.

Correct - but the Makefiles (as generated by CMake) should take care of all that normally. I suppose you can't use my shell scripts out of the box, but CMake, GNU make etc should work fine on most platforms.

Thank you! I hope you'll enjoy the new developments.

The build scripts expect both SDL2 and A2 to be properly installed in the development environment, like any other libraries - so the typical procedure  is to build and install SDL2, then build and install A2, and finally, the game.

As I don't actually build the Windows version on Windows, I can only give some rough hints here, I'm afraid. Your best bet is probably to use MinGW, as that is essentially the native version of the toolchain I use for crosscompiling. You'll also need CMake to use the existing build scripts. Once you have that installed, you'll need SDL 2.0 and SDL_image 2.0 development libraries, and dependencies, and then you'll need to build and install Audiality 2.

As for the build process, there are some hints here, although aimed at Un*x systems and similar.

Thanks! A2 is a modular synth with realtime scripting (with A2S) - which at this point, is the only user interface. (Documentation in progress: https://github.com/olofson/audiality2/tree/master/doc ) The idea is to cover everything from virtual instruments through sound effects and streaming with a single architecture, in order to eliminate the traditional distinctions between these fields. A2S was never really intended as a "music language," but that's how all music for it so far has been authored. Dynamic/interactive music would seem like the obvious next step there.

Either way, I'm planning on building an interactive A2S editor with tracker capabilities, and possibly support for "instrument" GUIs for realtime tweaking. Wrapping A2 up as a VSTi for music authoring in traditional DAWs is also on the list. It has crossed my mind to do something more similar to the FMOD and Wwise authoring tools for A2, but that's a massive project, and I'm not sure I want to develop and support tools full time. But, you never know... :-)

Thank you very much! Then you should get two Steam keys when the time comes. :-)

There will be another 0.7.x release, but then I'm focusing on 0.8.0 and Steam, which means new levels and upgraded enemies. The game logic code needs major refactoring, and it has legal issues. Rewriting those parts takes care of both. I'll open up Steam Early Access as soon as 0.8.x is reasonably playable.

As to Kobo II (working title), I started running out of time and resources, and I realized I'd have to strip it down to something quite generic and uninteresting to be able to finish it at the time. So, I put it on hold, replaced the contract work with a job, and started working on a smaller project: Kobo Redux, which is also much more similar to XKobo/Kobo Deluxe in feel and gameplay.

However, I've kept working on Audiality 2 (sound engine, also used in Redux) and EEL (scripting language, used for some tools for Redux; may be used for GUI and high level logic in Redux 0.8.x), and I intend to update the Kobo II tech preview, and release it with full source code in the near future.

After finishing Kobo Redux, I'll look into reviving Kobo II - probably under a different name, as it's really a different subgenre, which doesn't appeal to all Kobo fans.