so, game development

i've kinda been picking at bits and pieces of what might become 'hell game 2' for probably several years now, not with a lot of intentional focus, and several things have come together. this is essentially a complete recode, and there are a few considerations, development-wise, why that is.

a big part of it is that the original hell game code is server-backed-- all the description and scene generation is done server-side and exposed via an API while running the game, mostly because at the time i really did not want to have to write all the extremely in-depth description-generation code in javascript. all the scenes in hell game are written in haskell and require the entire server to be recompiled to be updated, which is fine, but it does mean that it's basically impossible to have a downloaded version of the game. or to easily patch in stuff without doing a complete recompile. another thing with the game being server-backed is that theoretically i could be, like, logging everybody's body types and which encounters are their favorites. i mean, i'm not; i very intentionally left that out of the server's request logging code, but that that's even a thing i can do always stuck me as a bit invasive and weird. (it also means the game makes requests for each description change + event activation, which isn't really a huge concern but i imagine it makes playing the game obnoxious if you have a terrible connection.)

so the new version is currently all javascript all the time, with an initial load of, uh, all the game's content. this is not as bad as it sounds, since even a truly gigantic amount of text is nothing compared to streaming video or whatever. so, this would frontload all the loading concerns. it would also make it possible to have a downloadable version* once the game's more finished.

the current 'demo' version is still using canvas for rendering and is noticeably laggy at points; i've since taken the basic engine and recoded it in webgl (which can render at 60fps) for another project and presumably at some point i'll backport that to hell game 2, though it's unclear to me how important that actually will be, since it's not like this is a game where framerate matters all that much.

anyway so the new content format is gonna be this bespoke hybrid data specification language based mostly off of yarn, with some extra control flow features for all the body parametricity that's gonna need to happen. writing the parser itself hasn't been particularly tricky, but the thing that's currently tripping me up is deciding what syntax i even want to support. this is why you generally don't write your own custom data specification language. but given the sheer volume of stuff that's required to write all the scenes, uh, i'd like to make the 'data formatting' step as easy as possible for future me.

the other main issue for development is figuring out the plot. you may have noticed, if you looked at the demo files, but the setting has changed rather dramatically. imo it's a little too openly derivative of hellpoint and i'll probably want to change that around before i really dig in to writing large amounts of content. hell game had a very rough 'plot outline' but due to the nature of development i never really did much with it; i'd like for the game to have an actual, you know. plot. with story developments and everything. but translating that into something a player can play through in a way that seems natural and fun is a surprisingly challenging proposition. but sticking with the hell game approach of "write a sex scene for each encounter and worry about plot relevance later" probably will not work out so well.

mechanics are also a concern. i wrote that big weird 'combat system' for hell game, and i even recoded and wrote a revised version (still incomplete) for the demo, but frankly i don't really know if that's even a necessary part of the gameplay experience. who needs pseudo-rpg combat for a porn game anyway; i feel like maybe porn games have evolved past the CoC/Nimin mold by this point. but if i jettison that i'm not really sure what the main gameplay/content gating mechanic would even be. does it even need one? who can say. porn games as a whole have evolved a lot since i started working on the original hell game; the field has gotten incredibly commercialized and tbh it's kind of weird to just be making one based on w/e weird impulses i have to write content for, rather than doing what apparently everybody else is doing and aggressively focusing on a target demographic and effectively focus-testing all their content. that kind of thing is a little more prevalent in the het porn games scene than in the gay porn games scene, i guess.

(i mean the other thing is... uh i don't know to what degree any of you followed the slow miserable decline of carnal souls, but oh boy watching them attempt to keep working on gamedev to the bitter end, as they consistently failed to have the project management to translate any of their work into actual progress, while they produced more and more depressing bimonthly updates of medical issues and wheel-spinning, was particularly grim and definitely influenced my mood while i was also considering sticking with hell game development to the bitter end.)

anyway so all of that is why i still only have a hazy half-formed demo rather than something more polished. there are a bunch of unknowns in the design i have yet to really fill in, so insofar as i've been working on it recently i've just been picking a technical problem and sketching in parts of a solution.

* kind of. CORS restrictions on the file system means that in practice i'd have to give the 'download version' some kind of electron wrapper (bad) or tell people to disable security features of their browser to play it correctly (also bad). currently for filesystem game testing i've just been inlining all the content into javascript files with a deploy script, which is a different kind of bad but is at least maximally portable.