Run the Daycare - A Twine/choose-your-own-adventure game (Recent6284)

[Recent6284]

Hey all.

My last attempt at a Twine game fell prey to the typical problems: the scope grew, and because it was so big (and there was so much to write), it was easy to lose motivation.

I’m trying again with a smaller, more focused project, that allows for parcels of story to be written all at once. In theory this is a pretty modular system, with new story events to be dropped in without anything complicated once they’re done.

PLAY THE GAME HERE

• Current status: Nowhere near done, lots of placeholder text
• Last update: 2025-10-01
• Source code can be found here

( This is a static image for the purposes of illustration, not an actual “what the game will look like” - this is gonna be mostly a text adventure with maybe some static PNGs or other HTML elements)

The Game

You are a down-on-their-luck Zoomer/Milennial who just found our their grandma died (my condolences). Your grandma was a hugboxer and regularly donated to [Insert Custom Here] Daycare - if you can manage the daycare for [TBD] weeks, you can get her inheritance.

1. Every Sunday, you will receive one new guest to the daycare.
2. Monday through Friday, you will deal with one event per day: a Major event, or a Minor one.
3. Each Fluffy guest has their own storyline (the Major events).
4. Each Fluffy guest has their own Health (HEL) and Happiness (HAP) stat.
5. The choices you make in all events will influence their HEL and HAP. If you make the right choices, you’ll advance their storyline.
6. On Sunday, the owner will come pick the guest up. If the Fluffy is alive, you’ll get rewarded with Business Resources (BIZ).

Da Rules

• If your BIZ runs out, you lose.
• If your Fluffy dies (their HEL runs out), you lose.
• Your Fluffy may have different ending text depending on whether it hits minimum HAP and HEL values.

I’m currently debating whether if I want to have a shop with buyable upgrades to the daycare - I know I want to have weekly “here’s your business expenses” rather than forcing people to buy kibble individually and other boring stuff.

I want to have this system (ie, buy a Sorry Stick, get options to use it) but that considerably bloats the text because of the new options present. This would be a “once the main events are done” kind of thing.

I would also need to develop prices and make sure it balances with your intial money and the cost of your expenses. Losing all your money is one of the hard “game overs”, so messing with that balance can either remove it as a threat entirely or make it too punishing.

The To-Do List

I want to have 8 multi-part Major events.

• The events can either be 2 or 3 parts.
• Each part can have 1-3 “screens” worth of text and choices, mostly because I don’t want one long page.
• These events deal with a single Fluffy.
• These events will raise or lower their HAP or HEL depending on your choices.
• These events create branches in other parts depending on your choices. Doing something in Day 1 may change Day 2, or completely break the event chain.
• You may be able to spend Business Resouces (BIZ) to solve problems. This represents everything from rent, repairs, time spent, or buying things for the daycare.
• The player would not see all events in a typical playthrough.

I want to have 16 one-and-done Minor events.

• The events should be one part, or 1-2 “screens.”
• The events should deal with your current Fluffy.
• The events can have changing text depending on the Fluffy’s race, gender, or number of legs.
• Depending on your current Fluffy’s stats (gender, race, number of legs) events can be removed from the available pool. There can also be arbitrary flags (for example, if your Fluffy gets traumatized, I could flag a “isTraumatized” variable) but I feel like getting too into the weeds with that jeopardizes the project.
• The events will raise or lower their HAP or HEL depending on your choices.
• You may be able to spend Business Resouces (BIZ) to solve problems.
• The player would not see all events in a typical playthrough.

[Recent6284]

Current list of events:

I am very open to suggestions for events, and collaborations (if you want to write or volunteer art for one, have at it - I would just be editing it to make sure it fits into style for the game). When events have been completed, they’ll be marked below - at the moment, most are placeholders.

Major Events

• A Fluffy-Abused Alicorn
• Babbeh Crazy (Good)
• Babbeh Crazy (Bad)
• A Fat Fluffy
• A Former Feral
• A “captured” Alicorn, boarded for later
• A Fluffy with separation anxiety
• A morbidly thin Fluffy
• A Fluffy who wants a Special Friend (ie, “growing up too fast”)

Minor Events

• Daydreaming - Done 10/3
• Napping/Dreaming - Done 10/1
• A Fluffy Farts
• A Fluffy won’t stop humping things (male only)
• A Fluffy is caught lying
• A Fluffy won’t stop rubbing themselves (because they’re itchy) on things

[Toofy]

This is a good, simple setup with potential, best of luck finishing it

[Recent6284]

Thanks - I think keeping this simple and straightforward, and letting myself have “parcels” of writing to do, rather than endless variations depending on race/gender, will make this more likely to succeed. I’m also not letting myself get carried away with random generation and statistics like my previous project.

[SqueakyFriend]

Woo, I got the singular written event! (napping about sketties) I am counting that as beating the game.

It’s looking great so far! But I admit - I skipped reading at least half of the “these rooms are in the building” text. It was just too much text about stuff that really didn’t feel like it mattered yet, like when a game opens on a text dump tutorial for every ability in the game.

[Recent6284]

Yeah, that makes sense. When you skip the intro the next time (or in general), you get a link to the side that says “Daycare Description” that’ll take you to that page. I kind of felt that it was about worldbuilding, but maybe I can split it up to a “hub” where you click a link and are taken to each individual room’s description. That would break up the big wall of text and allow people to choose what they want to read about, or move on entirely.

[edit]: This has been implemented.

Thanks for beta testing - yes, you can be considered a winner for getting to the napping event, as that’s kind of the only one “done.” I wasn’t sure whether to put a “wake it up” just to give the option to be cruel or not - as it stands, having a nap raising its happiness makes sense, but I’m kind of torn whether to “offer a bunch of options to give the illusion of player choice, even when it doesn’t make sense to wake the fluffy up just to be an asshole” or to railroad the player into a specific tone.

[SqueakyFriend]

A wake-it-up option would be good! It may be illusion of choice, but it would also help from a gameplay perspective - for example, if someone wants to do a self-imposed challenge where every fluffy has minimum happiness at the end. It’d be annoying to lose that kind of run to an auto-happy event, right?

[Recent6284]

Agreed - I’m more just trying to focus on having something that’s completable rather than inflating the amount that I need to write (in order to accommodate all playstyles). Adding “abuser” options for every single event, then the consequences of doing so (so the next day wouldn’t be jarring) and then checks to keep track of it all, ends up inflating the text considerably.

I’m more approaching this from a neutralbox tone (you want your grandma’s money) and that the player knows the goal (to get the money, you can’t be a psychopath; if you lose all your money, you lose. If the fluffy dies, you lose). These provide specific guardrails rather than trying to accommodate every tonal option.

[SqueakyFriend]

Very true! Getting the big events done is way more important than making little sub-clauses for every single small event.

[Recent6284]

Yeah. Last time I tried this I got really caught up on doing so much technical work (stats, fancy back-end stuff) that by the time I got to writing it was hard to buckle down and do.

The way I see it, everything is set up the way it needs to be already. All I have to do is write plot now, and I want to challenge myself to do just a little every day until things are done. The way I’ve structured events, all I have to do is write one “screen” or “day” or “event” and just keep plugging along until it’s done, or at least the first batch of events are done.

After that, it’s polishing, and then if I want to, I can add new events on a case-by-case basis. The game is already set up so that any new events I add are automatically added to the pool of events the game will roll for.

Even things like the shop are ready to go in term of “what I have to code”, but it’s more about just implementing it properly.

To give people an idea, this is the template for a three-part, Major event.

:: Three-Part Template Name [init major]

<<set $majorTemplateName to {
        name: "Template Name",
        length: "3",
        intro: "TemplateName0",
        part1: "TemplateName1",
        part2: "TemplateName2",
        part3: "TemplateName3",
        partend: "TemplateNameEnd",
        seen: false,
        data: {
            name: "name",
            fluffname: "fluffname",
            gender: "gender",
            race: "race",
            legs: 4,
            color: {
                name: "color",
                css: "color"
            },
            mane: {
                name: "color",
                css: "color"
            },
            hel: 50,
            hap: 50
        }
}>>

:: TemplateName0

Intro text for TEMPLATE NAME EVENT.

<<button "Go to Next Day">><<getNextEvent>><</button>>

:: TemplateName1 

Event text 1 for TEMPLATE NAME EVENT.

<<button "Go to Next Day">><<getNextEvent>><</button>>

:: TemplateName2 

Event text 2 for TEMPLATE NAME EVENT.

<<button "Go to Next Day">><<getNextEvent>><</button>>


:: TemplateName3

Event text 3 for TEMPLATE NAME EVENT.

<<button "Go to Next Day">><<getNextEvent>><</button>>


:: TemplateNameEnd

The saga-end text for TEMPLATE NAME EVENT.

<<button [[End the Week|Week Start]]>><<set $currentWeek++>><</button>>

The more important part is this:

<<set $majorTemplateName to {
        name: "Template Name",
        length: "3",
        intro: "TemplateName0",
        part1: "TemplateName1",
        part2: "TemplateName2",
        part3: "TemplateName3",
        partend: "TemplateNameEnd",
        seen: false,
        data: {
            name: "name",
            fluffname: "fluffname",
            gender: "gender",
            race: "race",
            legs: 4,
            color: {
                name: "color",
                css: "color"
            },
            mane: {
                name: "color",
                css: "color"
            },
            hel: 50,
            hap: 50
        }
}>>

This creates a variable that tells Twine what the name of the event is, the length (in parts, minus the intro and ending), the names of each part, and whether someone has seen it or not (this will be changed when the event is chosen).

So the variable $majorFatFluffy would have all that, but then a data section, which houses all the data for the main character of the storyline.

When the event is chosen, it ports over all this data to the $currentStory variable. This way, I can call $currentStory.part1 (for example) and it’ll print out what the passage name is for the first part of the story (in this case, TemplateName1).

However, it’ll take $majorFatFluffy.data and copy it over to $currentFluffy. This way, I can call $currentFluffy.name in order to get the Fluffy’s non-Fluffspeak name (ie “Blueberry”), or call $currentFluffy.fluffname to get its Fluffspeak name (ie “Bwuebewwy”).

So, moving on, I can run a check for an event that goes “if $currentFluffy.legs < 4, don’t add this event to the pool” or “show this event only if $currentFluffy.race is “alicorn””.

Perhaps the thing I like most is the color section, because calling $currentFluffy.color.name will give me, for instance, “Blue”, but I can set $currentFluffy.color.css to a specific hex code, to reference in things like coloring text. $currentFluffy.mane.name and $currentFluffy.mane.css are the equivalent for mane/tail colors.

This is all very much nerd shit, but it gives a peek behind how events are structured.

For Minor events, it’s a lot simpler:

:: Daydreaming - Data [init]
<<set $minorDayDreaming = 
    {
        name: "Daydreaming",
        passage: "Daydreaming Passage",
        gender: ["male", "female"],
        race: ["unicorn", "pegasus", "earthie", "alicorn"],
        legs: [1, 2, 3, 4],
    }>>


:: Daydreaming Passage
Passage text for Daydream Passage.

<<button "Go to Next Day">><<getNextEvent>><</button>>

I set the variable for a Minor event (ie, $minorDayDreaming) to an array that includes the name, passage (the link to the text in Twine) and then a set of conditions that will be checked when determining eligibility to add to the pool (the eligibility check happens every roll, not just once).

It compared the gender/race/legs to the $currentFluffy’s data, and if it matches, it’s added to the pool. There’s another check for whether the user has seen the passage or not, but it’s different than the seen attribute in Major events (I’ll likely make them consistent one day).

[Recent6284]

Was bored at work today and put together a little diagram to better illustrate the daycare better. This is an early version but the newest one will always be found here.

• Most doors are sliding doors, to avoid Fluffy-related crushing accidents
• Exterior door and Main Play Area door are double-gated to prevent escapes
• The wall line between the Double Door and the Double Gate is a half-height wall, allowing for observation from the reception area
• The thick lines on some walls (like the one on the wall between the Office, Double Gate and Main Play Area are windows.
• Litterbox is far from the food area (which is south of the Double Gate) to prevent contamination.
• Water bottle is wall-mounted and connected to water pipes. It’s basically a hamster-style dripper because I don’t think I’d trust Fluffies not to drown in a water bowl.
• I feel like I maybe have made the reception area too big, but making the chairs bigger throws off the whole scale of things. I might replace them with a desk or something to give the room some furniture.