another one IVAN fork (build: 2025, Apr 18)

Maybe one day I will have the time to port all of these great changes to vanilla. Maybe.

…or take k8I as new vanilla. it basically has almost everything vanilla has — the main difference is that i haven't added new materials to items (because i feel that it results in too many item variations without much sense). but materials themselves are there.

to make myself clear: new materials are great. but i feel that random items with too much random materials aren't adding much to gameplay. it is prolly better to add a way to tie some materials to game time and dungeons/levels. i.e. the deeper the player goes into, for example, imaginary dwarf fortress, the more items made of dwarven steel are there, but such items are very rare in other dungeons. i'm not sure how to implement it yet, though. i.e. i know how to code it (just recalc coefficients for weighted random), but i'm not sure yet how to specify it in scripts to make it manageable.

and if i'll ever finish the scripting part, k8I will get the ability to load various modules with new items and characters, and without recompiling the code. that is something i always wanted to do, to allow people to experiment with the game without messing with C++ compiler. this is my Ultimate Goal, because i believe that IVAN engine is really great, and it can be used to create many of different games. we have material system with many predefined materials, a lot of items to reuse, and with easy way to create new unique items and charcters the possibilities are virtually endless.

not that i am expecting a lot of people to come and create new content, but hey — we'll never know the number if we won't have the easy way to do it!

p.s.: btw, there is another change i forgot to mention — paperdoll panel now has hunger and stamina "indicator bars". because why not? we can feel how hungry or how tired we are, there is no reason to hide this info from the player. IVAN is a strategic game after all, and having that info with better granularity than we currently have will allow to better plan your actions.

and i will prolly turn health bars on by default in the next build. this is the easy way to tell how badly monster is hurt — which is something we can see most of the time IRL (well, more or less . and it helps to plan your actions too.

still here. got distracted by other things, though. do not worry, estimated hiatus time is only 4 years now.

tbh, i don't know. need to finish several unrelated things first. sadly, i cannot work 20 hours a day and switching tasks all the time, like i could in my teen years. i'd like to, but. anyway, do not adjust your sets. or at least not permanently.

I was just talking with someone yesterday about the N64 game Hybrid Heaven. It's incredibly slow and kind of boring and weird, but in our youth we had nothing better to do but spend hours plodding through this game. Ain't got the time for that anymore!

…but we have time to play 20+ y.o. game at least!

Not really, unfortunately.

I do! Then again, I mostly don't sleep lol

i decided to use LISP as the scripting language. of coruse, to keep the good old tradition, it will be fully undocumented, and incompatible with any other LISP out there. no, i am not joking here, i already created first implementation of it. internally it even compiles LISP code to VM bytecode. but don't expect it to be fast.

btw, 64-bit support is officially dropped from k8IVAN. i see 0 reasons to support it.

so, i created minimalistic Scheme implementation. it took ~5 days (i procrastinated a lot, it should've been done in 2 days or so). of course, it supports lexical closures, tail call optimisation and call/cc. now i have to invent some way to automate bindings creation — that's the real challenge. the engine uses bytecode compiler with closure optimisation, and it is quite fast. actually, much faster than i need it to be.

the idea is to create "scriptable entity" as a separate entity class, and then gradually convert other entities to scriptables. this way i won't need to convert the whole codebase in one go. the grand goal is to move all entities to Scheme, but this may take decades to complete. yet i need to start somewhere.

it is absolutely impossible to stop improving Scheme compiler once you made it work. somehow i feel that in a year i will have self-hosted Scheme system which compiles to optimised machine code. and, of course, 0 lines written for IVAN scripting.

wrote second version of Scheme. the third is coming. still 0 lines of IVAN code. i am starting to think that i made a mistake somewhere…

does this mean it will work on xp lol

why not? nothing special used in the code, and i am not using winapi directly. so if the compiler, sdl2 and other libs aren't doing something special too — it should work.

tbh, i don't even need sdl. the only thing i am using sdl for is to init OpenGL, and to have the unified event loop across platforms. i could easily switch to OpenAL+libopus for sound, so sdl2_mixer is not reqlly required too. for my Oberon/Ur system (which i am using to code my small 2d games) i did exactly that: wrote simple lib to init OpenGL on win32 and X11, and OpenAL wrapper. works like a charm.

i am simply too lazy to rip out sdl and rewrite my Oberon code to C++. i'd better waste my time rewriting IVAN to Scheme: it would be useless too, but way, way more fun. (no, i'm not going to do that. at least not right now.)

i just thought… should the death be as immediate as it is now?

what if we have the literal Grim Reaper to spawn, and the player is converted to an invincible ghost? initially the ghost is quite fast, so it is easy to outrun the Reaper, but as time passes, the gost becames slower and slower. the Reaper can go through walls too, of course. the idea is that the player can reach an altar of some diety he has good relations with, and pray for the new body. resurrection should have quite a huge cooldown, i think, but it might be fun.

of course, the players will immediately start dying just to explore the level in their new shiny etherial invincible form… which i see as a good advantage of this new mechanic.

outrunning Grim Reaper — what could be more silly than this? so i believe that it definitely fits into IVAN.

by the way, that's how the LISP code meant to look like:
SPOILER ALERT. Click here to see text.
nope, that's not Python. this is Scheme. not that intimidating anymore?

p.s.: edited to make the code even simplier-looking. it still works, yeah.