neon dollhouse 005
i'd like for this eventually to be one of those fun, showy game dev blogs but we're still in the early stages of things, so it's a lot of complex engine work and behind-the-scenes stuff most players will never notice
fun assets i can dangle like jingling keys in a baby's face
i finished the base design of the UI art - it needs a shading/details pass but as a concept i am VERY happy with it! it doesn't quite nail the PC-98 eroge interface vibe i want (it's a little too modern and too much of the screen space is the actual game) but i think it's more than acceptable.
i was sick of the room name/area flowing off the edge of the left-hand side so i turned that into a time display, and restored the original room/area header at the top of the text box.
i don't know if those stat bars on the right are gonna stay, and there's a huge swathe of blank space begging for use. in my head i imagine that'll be another "doll" just like Swan there on the left that shows whoever you're talking to or fighting, but that's probably a pie-in-the-sky idea for tomorrow's me
messed around with the doll sprite a bit:
don't mind that everything is burgundy, those are just the colors i use when drawing to map out contrast/detail
removed the dedicated "examine" / "journal" keys and added a proper main menu. right now it looks a little like this:
my initial concept for the title screen:
do i think i'll keep this? not 100% sure. i don't really think it shows what the game is about. i saw some screenshots from a game recently where you do maintenance on robot girls that was nothing short of breath-stealingly erotic and honestly it retroactively ruined this concept for me. i'd prefer the title screen to be sexier. since i planned for this image to be animated, i'll probably end up just reusing it for whenever Swan rides the tram from place to place on the campus i like showing my art in progress because 1) AI has turned the artistic world into a joyless hellscape and it's nice to actually prove a human made this stuff and 2) the glow-up when it's finished is always worth it.
boring engine stuff for technical dorks who like that kind of thing
okay so starting out, i didn't really think ahead re: what kind of states my game would be in, what kind of mechanisms would be present, or even like, what you do from moment to moment.
i knew you would:
move the player from place to place (rooms),
talk to/interact with NPCs and other elements (dialogue),
and get into "cutscene interactions" that necessitated moving the player to a special room and then back when they were done (encounters)
rooms/dialogues/encounters made up the entire ecosystem of the game. i gushed about making encounters work in a previous post, but if we're dividing ND's interactivity into a pie chart, it's really only one slice. not yet enough to make a game with
there is also one more major mechanism in place: choices. that's these guys right here:
initially choices were pretty simple objects. they derived their information from a metatable with some basic values i wanted, and were created through a function: create_choice():
i made some strange decisions when implementing these. for instance, each choice implicitly added itself to the room it belonged to, which meant invoking the choice was kind of ugly. in practice, every single room's choices were created like this:
this was a pain in the ass for a few reasons, namely 1) it was a bunch of typing i didn't really need to be doing, and 2) making choices belong to the room was kind of nonsensical. why do i need to invoke the room's name when adding choices to a room state (basically a room within a room)? why do i need to add "encounter" to every choice that belongs to the dedicated encounter room? i've been programming for a very long time; i can tell when i'm doing something the long, hard way, but i'd gotten so far in my progress i didn't want to change it.
at least, not until i had to.
i need a combat system. just like the room system pulls double duty as the encounter system, the combat system is also going to function as the engineering/hacking system, and the sex system for erotic encounters (people who have played Degrees of Lewdity will probably understand). if dialogues and encounters were half the pie, this system is the whole other half.
i realized that my system of creating and presenting choices to the player was entirely unusable for this. i was going to need a new choice type: i wanted "complex" choices, e.g. controls more involved than simply choosing the hotkey of the action you wanted to perform.
in fact, shit. i was going to need more advanced controls for other things: the wardrobe system won't work off of simple lists of choices, either. and what about when i implement the Space Station 13-style hacking?
pictured: me comprehensively rewriting 3-4 major core systems just so swan can take her top off
so i set out in choices.lua and wrote:
and that is how far i got before saying to myself "wait. my choice system is really clunky. what room am i going to assign these to? am i gonna make a 'combat' room? there has got to be a better way to do this."
from what i could see, choices had four major problems:
they implicitly belonged to rooms, meaning that the player could not be presented choices in dialogue or anything that wasn't coded as a room. for dialogue this was fine - i invented room states just to handle conversational trees and it works great - but if i was gonna add a whole new system this wasn't gonna cut it.
i was simply adding all these choices to the room's own internally-tracked "choices" table and then just... immediately moving them to the core game.choices table.
i was offloading actual choice processing: displaying icons, descriptions, finding and evaluating hotkeys, etc. to the functions that were supposed to just be displaying these things or running simple actions.
i coded choices in a really silly way so you HAD to use hotkeys to select them. going through the list with arrow keys or mouse control was basically impossible
step one was cleaning up the needless pass-along interaction between game.rooms[room].choices and game.choices. the former no longer exists; rooms simply dump their choices into the latter, game.choices.
the flow of code went from:
run choice processor -> figure out which room i want -> find the room's choice creation function -> dump all of the choices into the room's internal choice table -> discern which choices should be available and dump THOSE into game.choices
to:
run choice processor -> if the game's state is "room" just run the choice creation function of the player's current room (why would i ever need to run it for a room i'm not in) -> put them directly into game.choices
in lua you basically do everything with tables. i am intimately familiar with this design paradigm. i created two new companion tables: the job of game.choice_keys is to store every choice that passes the "can i do this" test and its associated hotkey:
just like that, with a few more tweaks, the controls were totally fixed. now the player can use up/down arrows to iterate through them. i haven't done mouse control yet but it should be pretty trivial
the second companion table is the most important. when the game displays the room to you, it does these things in this order:
run goto_room(room name)
if the new room has a pre_enter() function, do whatever code is in that
load the room's data, including processing the choices in that room
if the new room has a post_enter() function, do whatever code is in that
finally, get the prompt through get_prompt()
the prompt was doing an unnecessary amount of work: going through every available choice in game.choices, parsing its descriptions, setting values for time passing, determining whether or not to even display the choice to you based on stat checks, and more. i have no idea why i wanted to do things this way, other than that i was just starting out and planning ahead is not my strong suit
anyway, this is my new choice creation function:
the idea was: why not simply fully process the choice when it's created and then send it directly to game.choices?
finally, to piece it all together, the choices will then add their information to the second companion table: game.choice_rows
no need to post-process anything, no need to evaluate a shitload of variables in each choice as i'm building the prompt. just use the data that's already in there and don't worry about anything else.
after that was all done, and i'd tested to make sure the game wasn't reenacting 177013 every time i booted it up, it was time to do a very very scary thing: go through every single file where i'd used create_choice() and change it to its newer, sleeker sibling: choice{}. i've been programming in lua for 16 years and i had no idea you could just do function{} by the way. that still feels weird to me
anyway it worked great! it was a lot of work for something a player will never, ever notice, but god does it feel nice to have it done. it paved the way for way more complex systems down the road, and just like that, i'm a little closer to making this game the DoL/CoC/TiTS ripoff eroge fantasy i'm dreaming of
am i following my vision?
not 100%. i keep looking at those old mockup screens i posted a year or two ago and wishing i could be making that game. but i think i need to learn how to make games, period before i make that game. i don't want to half-ass it.
i wouldn't trade this for the world, though. i have very much always wanted to make a game like neon dollhouse (an eroge RPG with just as much effort put into mechanics/worldbuilding as smut), so it isn't like i'm compromising on my dreams, i think i'm just making myself eat my veggies and finish my plate before i get to have dessert
okay love u thanks for reading! ♥
join the Neon Dollhouse discord server at https://discord.gg/2fjBugSUnj or don't, i'm not ur boss














