hey guys, i'm really gald you enjoy it!
thanks for playing.
after doing that long game dev session i had just to sleep for while, though, and relax a bit. that's why i couldn't to reply yet... that game exhausted me quite a bit, not only because it was laborious (but interesting) to make, also because it started to feel rather strange at some point... all was really improvised, nothing was planned out before, besides of the standard mechanics, so it just came out this way... as "incoherent", and odd somehow, as it started, mainly because of the lack of clear initial idea. polishing such an incoherent something wasn't that appealing to do, but it was still worth it, i think now, because it could work as ground for new stuff, later on... finishing things is simply something good!, i realized. that's what i always learn here, this time again. - TIGScompos are just pushing me in the right way... i'm really liking this place here!
after the very unfocused doodlings at the beginning, i started - mainly thanks to Jph's hint at the right moment - to explore gameplay mechanics, and let the other things come in afterwards, which was really key to the whole making. that's where the interesting secrets lie in the first place, it seems. assets, mood and perhaps even story are important, sure, but it's simply not right place to start (in my experience). i don't know why exactly... but working on the gameplay, suddenly gave me kind of a flexible skeleton for
many possible games, which can/could be fleshed out with assets then, but it's not a good idea to start with them, because things would be much too fixed that way. among other things (esp. technical stuff), that's the main insight i got while doing this game. - the gameplay, and all its defining elements (like mechanics, movements, enemies, items, other interactive parts of the levels...) should define the the assets, not the other way around...
in the actual game though, there are still lots of points i'm not content with. gameplay, style (incoherence, cold oddness) and also tech wise (physics/sound problems)... but, yea, i'm still happy with it. - it's really an experiment, maybe inspiring for others, also for me, for doing something better out of it. i never made a real 3d game before, so i'm really happy i got something done, which ended up even larger than i first intended.
but i'm aware of the many existing flaws in the actual "game design". that you have only 3 ships doesn't make sense in this kind of game, for example (will be fixed in the final), also there's something wrong with the structure of the majority of levels. you can often simply avoid all the battles there, and still get through to the exit, although they are laid out in a linear fashion.
also, talking about bugs:
yesterday, i encountered annoying problems again with the collision physics. tunneling through solid walls, mainly in the boss room, although i'm using "continuous collision detection". very annoying. 'Bullet Physics' simply didn't stand the test then...
@audio problems:
also to mentioned is that i used 'OpenAL' for the first time, before that i was using 'DirectSound'. doesn't seem to work as good as i expected... either i messed up the API calls somewhere, or the driver/hardware installation is corruped. ...hmm... don't know, really. i can just say, that the background music is stereo, thus 'OpenAL' automatically disables the 3d sound features for those samples... so, it seems to be something with 3d sounds then. hmm. i've uploaded a test build which prints out a log file.
errors with OpenAL should be marked as "ERROR: OpenAL: " <error_message>...
- it would be great if somebody with audio errors could point out where things break...
just start the game with "play.bat", play a level with audio bugs, quit. then, "log.txt" should hopefully tell us more about the problem...
okkuplektor_debug0.zipi know, that there exist much more solid better solutions, for 3d audio, as well as for physics. 'FMOD' and 'PhysX' would be my favorite candidates here, but they are not really free, and that's not acceptable, i decieded a while ago. still an unresolved issue...
btw, all the content was created with free tools for this game. 100%. 'Blender', 'Gimp', 'VisualStudio Express', and 'MinGW'/'Code::Blocks', for compatibility checks. also, only free libraries used (for jpeg, ogg, png, xml files).
@jph:
for the audio i'm using my own tool, called 'es' (executable sound). i did it some years back, when i was wanting to make some fartsy audio compositions (back in my aborted (and hated) numedia studies, ARGH!..). it's kind of a modular synth, where you can patch up everything you like in a quite open way. it's a bit tricky, still limited compared to similar commercial apps, and
very cpu hungry... but it does the job (and can even be used in realtime, like in my other compo games).
(that's how it looks like for the explosion sound, for example). - it's even necessary to have something like this in some way, because i never found good free solution to produce audio under windows, comparable to 'Gimp' in the graphics area. still, when doing "normal" music with my tool, it depends on an external midi sequencer, which keeps a pending problem... (any hints would be helpful..). i was using
'seq24' this time, but that one's really awkward to work with. but i had to, because i won't buy any new software, and never want to depend on cracked tools again, never!, especially when it comes to putting something out again. so, probably i'll do my own small midi seq, and publish it for free, when i find the time to do it, and find no better solution. very simple, similar to 'seq24', but slicker and more efficient to make longer tracks...
yeah, that's pretty geeky tech stuff, i know. but i think at some point will be kind of done... choosing the right tools, code a stable engine, and that's it. probably. - just because: i actually enjoy it more to handle the art_part of it... that comes later, i guess.
Community
