That really sucks, man. I think you're getting this much feedback because people think you have something worthwhile here. Sure, in my own words, "the game itself is barebones at the moment, and it could really use some balancing," but it's a demo, it's going to be like that. I don't know, from one dev to another, I really hope you reconsider.
After 18 months of work and showing that the project will keep going, I don't think a one time payment is unjustified, and you continue to get updates for free afterwards.
I not usually one for Dress-up games, but this one is solid. I love how you can talk to Honey. It brings so much more life to the experience than just a static character. Good work!
I appreciate the in-depth explanation, but it doesn't really solve the main issue. All of the values are set to 1 when the game boots, and are changed as the game is play. Cool, exactly what we want, but, those valves are wiped when the game is secured. Therefore you would have to read though... 20,000ish words to unlock the secret end... in one sitting, or leave a dubious webpage up until your next "reading" session. If the game had a save system, it would work perfectly, but as mentioned before, absolute pain to set up. Currently, this is the macros used to achieve the unlock:
(if:(history: where its name contains "=")'s length >= 1) +
(if:(history: where its name contains "/")'s length >= 1) +
(if:(history: where its name contains "#")'s length >= 1)
[text]
It basically does the same thing, just using history instead of values. That's why you can't hit the back key after finding them: it undoes the history of the game.
Like I said, thank you for the assist (I have it saved for later,) it'll all be moot in the next update.
That's for the feedback, bud! I fully understand what you mean, and honestly that's what I was gonna do from the start. Have a list of all the endings completed, make the hidden flavor text just that, make the door an actual keypad that the player would type the code into, etc., etc. Unfortunately, Harlowe kinda sucks, and the deeper I looked into the backflips just to get a save system going to facilitate a system like that was way more than than what it was worth. So I ended up settling on the current design (as annoying as it is.) ...and why on the next update, there will be a way to just bypass the door. It was always planned, but I guess it doesn't hurt saying.
Okay, so there *is* a way to bundle images with the Twine download. It seems fickle, but operational. Problem: there are currently 109 images already attached to the game with roughly another 200 images needing to be made, along with the next ending and audio support. I could break it down and rebuild it, but, quite frankly, I don't think the juice is worth the squeeze. If I do another Twine project, I would invest in that method from the beginning.
Sorry for the late reply. Based on my current understanding of Twine, in order for it to display images, the image has to hosted on a site so that the program can recall the image. There may be a way for Twine to call an image in a named, downloaded folder, but I would have to do a bit of research.
Thank you, bud. Like I said, it's far from over. I'll still be taking my notes with me and working on outlines and ideas, I just probably won't have the time to do any substantial work on it for the next few months.
That's kinda the cool thing about Twine though. You don't load the files to the game itself, it references the file on the internet. You just link it via an address and it pulls it from the web. (not trying to convince you, just for future projects).
Have you ever thought about adding images to the pages? You pretty already have something for each event in your portfolio. Then again, I understand that could be a tagging nightmare,
