December 7th, 2012
I cannot believe that I was still working on this a year ago. But whatever, this project is finally reaching its culmination (by which I mean: alpha release) so it's time to start maintaining a log again, because I really need to get back into the habit of making significant daily updates. Pretend I had a prior habit of making significant daily updates.
I'm looking to officially "release" it come the 21st, since the end of the current long count is a pretty great milestone to do anything on. This gives me exactly two weeks to get it to the kind of game that I would consider "playable" and "fun", and then a little over a week after that to make it look fancy before the end of the year.
I'm not just going to paste my entire (huge) todo list into here, but the short version, in rough order of importance, is:
- There's no content. Like, there's a little, but it's really not much, and I'd like to debut with a reasonable amount of playable content. Not just four events and five rooms.
- the current event system is too complicated internally WHILE AT THE SAME TIME being not flexible enough to handle the kind of output I'd like to have, and this leads to events not running 'properly' and running in the wrong order and not persisting properly, all while being a huge pain to manage.
- While I have a gamey challenge system designed, I don't have a working javascript applet nor the backend code to handle things like "skills" and "experience" that I'll need to put it ingame.
- the transformation system — the entire body system — is a mess that I haven't touched in months. This is going to be a problem when I get around to... trying to add any TF stuff whatsoever. (That being said, I am entirely okay with putting this on the backburner until I fix the other things on this list)
- The layout is absolute garbage and while that's not technically important, it's pretty vitally important for what is called "game feel". Even for porn games.
So: I'm going to finish writing up the code for all my existing content — which is the introductory railroading part — and then I'm going to sketch out some loose frames for the more open-world stuff, and then I'm going to start revising all of that into a more streamlined format, once I actually know what content looks like in the data files.
December 8th, 2012
Mostly what I did today was finish up the prototype of the game toy. The interface is done, but I still have no clue what the mechanics are going to be like at all. Or rather, I have vague ideas but nothing that's at all concrete. Still: javascript is a mess, and now the applet is done and working in... most browsers? Let's go with most browsers.
December 13th, 2012
Yes, I can see this 'daily update' thing is going swimmingly. I've been messing with the code and it's coming along, although unfortunately very little of it has actually borne fruit yet. The mechanics toy has been coded up in... most respects, so that given a little more code it would be possible to actually start having challenges in the game, but haskell's excessive purity is thwarting me. The main game process is that of selecting events from a room, by checking against the player state, and then running events on a player. runEvents
used to have a type of Player → [Event] → (Player, [[Text]])
, which worked fine when 'events' were limited to things that, well, changed the player state and output text. However, part of the process of streamlining the room code was folding game choices into events1, and when that happened just a [[Text]]
output became restrictive. I first changed over to Yesod's Widget
type -- that being "any html" -- but then I realized that still wasn't enough: it's impossible to generate the html for a form using Yesod without being inside the Handler
monad, and that wasn't happening.
The solution to that, to make a long story short, is probably to just completely ignore Yesod and write up an, idk, EvaluatedEvent
type, that can carry enough information to make it possible to generate form data when it gets around to rendering stuff. Well, that or making the result type (Player, GHandler sub master (Widget))
, but, ugh.
Followup problem: the room event processing code is a huge mess that desperately needs to be cached before anything will be able to work properly. The concept is that rooms exist in potentiae as a 'base' room and a list of potential alterations, each with their own triggers (based on player state). When a player actually enters a room, the mods are evaluated and the room base is expanded into a concrete form where all events and actions are either 100% going to happen or discarded entirely. The problem is: maintaining that processed room is remarkably difficult. When choices -- the new kind that are events -- are nested inside of other choices, they don't persist in the room mod list -- because they aren't room mods themselves; they're inside the mods -- and that makes processing them a deeply involved process.
My original plan was to keep a cache of the room as part of the player state, kept in the database, but this was thwarted because Event
s defy serialization: they can contain partly-processed functions, which are basically impossible to instance as Show
or Read
, which is what Persistant requires for all its DB marshalling. This is unfortunate, since the only other real option -- the one that I'm basically going to have to take -- is to keep a copy of the entire player data type, and use that to generate a deterministic room cache. This is dumb, but not having a cache is increasingly breaking everything, because it's really important to be able to check precisely what state the room the player is in. Just cosmetically-speaking, there are currently all sorts of huge issues with triggering an event in a room, clicking on one of the menu links, and then returning to the game only to have completely different followup events happen. Caching: it's a good idea.
Anyway that's what I've been working on. Actual content: still regrettably thin on the ground.
1 previously there were Event
s and then there were Choice
s; I don't actually remember the original reason for the distinction aside from "they seem like different things", but as I went on coding up content I became aware that having them as separate types was just a big hassle. Most notably, since Choice
s themselves could only return a [Event]
when they were selected, it was impossible to nest choice prompts without a lot of finagling variables. This issue would only compound if I added a separate Challenge
type, since all the special cases for choices would have to be duplicated.
December 20th, 2012
Well this has been a debacle. Not, you know, necessarially in a bad way, just...
I've been working on the code between updates, and the major thing to note now is that challenges work. Well, 'work'; the player has actions and they're compared against a set of challenge actions and you can win or lose: mechanically most of the parts are in place. But the game is un-fun and confusing and the rewards you get don't mean anything. But since it works, mechanically, it's been moved down on the todo list: I'm focusin on bodies again. Oh god, bodies.
(I'm also writing content, which is all mostly minor open-world filler, but it's something which is better than nothing, and it's giving me a better grip on the structure of the world and the way I want to lay out the game content, which is an aspect of the game I frequently skimp on in favor of going on about code.)
The reason why there still aren't any sex scenes in the game is because I still haven't nailed down exactly how I want to handle sex scenes. It's a technical hurdle in two parts: when you have a sex scene, you have to figure out which of a hypothetical multitude of scenes you want. Maybe you have two dicks and there's a special variant of the scene for two dicks. Maybe you have three dicks, though, and so how do you pick which set of two? Maybe you have two dicks, but one is in the usual location and the other is at the tip of your weird scorpion tail, and just subbing that in makes the scene inaccurate to the layout of your actual body. Maybe the scene has a few extra paragraphs and lines interspersed all through it if you have breasts. Maybe there are a few separte descriptions in a few places that should differ if you have skin or fur or scales or feathers on various body parts. There needs to be some sort of way to resolve all that, take "the player character's whole mess of body parts and their configuration" and butcher it down into managable pieces that have all the information you need. I've turned this into a two-part solution: one part is isolating parts -- for a given scene, find a part that matches -- and the other is explicating about what traits a part has -- what variety of weird dick, how large the breasts, etc. I've kind of got the isolating parts part down; it's easy to just say, okay, we have [(Identifier, Body -> Maybe Part)] -> Maybe [(Identifier, Part)]
and we write some helper functions to help write those Body -> Maybe Part
functions. Easy. Actually using that part information is harder: Text events are for the most part text literals, using tokens inside the text stream to process variables -- %xe
, for example, gets replaced with he/she/it/they/etc etc etc depending on the player character's pronoun selection. This immediately brings up a problem: what if you want to use someone else's varying pronoun?
The short version of this issue is just, to get any kind of reasonable system you have to embrace some constraints. If I wanted total modularity I could just write scenes in code that were all Player -> Text
, but that would be a huge chore. To make the process simpler I have to make assumptions and stick with the constraints those assumptions require.