The Kiwi Farms was targeted with a historic DDoS attack last week. Confirmed reports of 2.8Tbps on an individual provider, topping 4.8Tbps when known volumes are added together, and possibly up to 8Tbps if the attacker is believed. This is the third of fourth largest recorded.
Want to keep track of this thread?
Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading. Create account
I am aware of Twine, its limitations, and basic operation. I have actually considered taking on very much a similar project as yours for my own personal use, but I honestly think web technologies are retard shit, so I lost interest.
That being said I don't see your purpose as being any less troony, lol. Are you aware of Tweego? If your intention is to use a vcs and any old code editor, it may very well suit your purpose.
The greatest text adventure is (being) written in a language for text adventures designed by a man who thought web technologies were the future.
Women use Windows and aren't going to install some random software you say is a game you developed, and I don't want to teach them that it's ok to take executables (or minecraft extensions) from strangers. Browsers are relatively safe.
My intention is to also have human-readable syntax. Twee governs passage headers, the content still has to be written in one of Twine's formats with macro cruft and javascript for all the missing features. At best it'd be a flat list of nodes that's very hard to visualize.
(inb4 y not visualize in Twine: because variables.)
Ink and Yarnspinner use tree structures (good) and have less readable code at the cost of not having to put quotation marks around string constants (gay), and both have two syntax variants just to really fuck shit up (gay).
The Sugarcube Twine variant now, by the creator of Tweego:
Code:
→ Using <<capture>> to localize a temporary loop variable for use within a <<linkappend>>
<<set _what to [
"a crab rangoon",
"a gaggle of geese",
"an aardvark",
"the world's smallest violin"
]>>
<<for _i to 0; _i lt _what.length; _i++>>
<<capture _i>>
I spy with my little <<linkappend "eye" t8n>>, _what[_i]<</linkappend>>.
<</capture>>
<</for>>
→ Capturing several variables at once
<<capture $aStoryVar, $anotherStoryVar, _aTempVar>> … <</capture>>
^ "Whoa, this code is so clean, I can read it to my baby as a bedtime story" -- no woman ever.
So you basically want something that will convert choose-your-own-adventure books (in the exact way they are written, with all the go-to-page-xyz-if-you-etc stuff) to an HTML slideshow with buttons. Might as well just write your own, sounds like maybe a weekend's worth of work to me. Just use words instead of symbols for syntax elements like BASIC.
The best and worst thing about web dev is that it is accessible. You can start mucking around with stuff in the dev tools pretty much immediately. However building anything actually reliable and/or dare I say decent, requires a huge amount of experience.
My tinfoil theory is that the professors who are doing research in AI/VR are struggling to find participants because I've seen them come into group chats with students, advertise on campus, etc that they need people for some related experiment they're doing. What better way to get guinea pigs than to force AI slop in our intro courses.
That's true to a point. The bigger problem is that it causes a legibility issue becasue a lot of these grants relate to using AI in a data processing or research context, but reserachers also use it to bait student participants using AI as a buzzword since it allows them to then put "worked with AI" in some context on their resumes. It makes it so you have to sift through papers with a fine toothed comb to see where and how AI was used exactly. I recently read an eye tracking paper from my uni that was framed as "AI focused", but really all it did was use AI to determine where little dots appear on a screen to test response time. Technically it uses AI, but it could have just as easily have been done with a ready-made toolkit or 10 lines of $YOUR_FAVORITE_LANG. A lot of people just find ways to shunt AI into their research to get grant money, which I can't really fault them for.
a parser game needs a lot of extra effort to be decent
I don't want to spend time on filler content or on making some of it meaningful
it's good for a particular type of games and puzzles, mostly fucking around in [broadly speaking] uninhabited dungeons
it's nor good for dynamic stories where "not fucking around" is part of the characterization, talking to NPCs, and for games with a defined protagonist
in a plot-driven game that's mostly on rails a parser invites the player to consider a vast spectrum of choices, each of which must be implemented or cockblocked
you can't win this: trannyfucker Emily Short sold her soul to clankers, and players of her GenAI games still say there are not enough options WHEN THEY ARE PROMISED THEY CAN DO WHATEVER, duh!
I tried to find an article on "how to allow the player to tell the videogame he solved the puzzle" but all I get is gay discussions on tabletop "metagaming"*
parser games are short. Spider and Web is considered "long" for a modern game and it's just one puzzle, two fucking-around scenes, and a fairly obvious timed action sequence. To my best knowledge, no one has made a parser game with as much content as what's expected of an RPG.
I am not any good at coming up with parser puzzles or even Smash puzzles, I like talking to NPCs in classic RPGs.
parsers are good for hidden options but even paper choose-your-own-adventure books have come up with ways to implement [most of] them
Spider and Web's puzzle can't be implemented without a parser but it has already been implemented, I don't need to plagiarize it
*On metagaming: a lot of interpersonal stuff in stories women are interested in has simple solutions that neither you the player nor the protagonist don't initially know, and drama and various reversals of fortune result from that lack of knowledge. But once everything is revealed, if the player/character is completely free to act, the ultimate golden solution is that in the very beginning of the game, the player says the necessary thing and everyone hugs and sings kumbayah. Parser games incentivize this. Hadean Lands just plain makes player knowledge persistent between resets (and requires at least one reset to win IIRC). At least one (maybe more) installment of Myst (which a lot of parser IF devs love) has a final puzzle that is accessible from the beginning and you can just input the solution if you already know it from elsewhere. The cuck simulator Rematch you either solve in a single line or die. I don't want that, I want the player to be limited to what the player character might reasonably do, and the most natural UI for it is a fixed choice prompt.
So you basically want something that will convert choose-your-own-adventure books (in the exact way they are written, with all the go-to-page-xyz-if-you-etc stuff) to an HTML slideshow with buttons. Might as well just write your own, sounds like maybe a weekend's worth of work to me. Just use words instead of symbols for syntax elements like BASIC.
Output, mostly yes (a column of scrolling dialogue/narration sections with occasional clearscreens -- think fin de siècle Black Isle or Bioware games, Disco Elysium), and I also want it to be easier to write, with "dynamic" text in each paragraph (conditionals and interpolation in both body and choices), inlines, and callables instead of goto for better control flow.
Of course every text adventure game CAN be expressed as a physical book with paragraphs of static text, choices and keywords (you'd have to have some blank nodes with choices and/or conditionals only), just like every program is a series of nands and braces, and maybe even some optimized "normal form" exists where no sentence is repeated, but it'd be a pain to write and maintain.
Anyway, reading Crafting Interpreters (I'm too dumb for Game Programming Patterns).
That's true to a point. The bigger problem is that it causes a legibility issue becasue a lot of these grants relate to using AI in a data processing or research context, but reserachers also use it to bait student participants using AI as a buzzword since it allows them to then put "worked with AI" in some context on their resumes. It makes it so you have to sift through papers with a fine toothed comb to see where and how AI was used exactly. I recently read an eye tracking paper from my uni that was framed as "AI focused", but really all it did was use AI to determine where little dots appear on a screen to test response time. Technically it uses AI, but it could have just as easily have been done with a ready-made toolkit or 10 lines of $YOUR_FAVORITE_LANG. A lot of people just find ways to shunt AI into their research to get grant money, which I can't really fault them for.
That's a good point I still didn't consider; thank you for quelling my autistic anti-AI rage, lol. I should make the effort to sit down and actually read through the research, but I'm so tired of hearing anything AI that I just immediately send it to trash or dismiss it. I may be a bit salty that my department focuses almost solely on SWE and AI/ML instead of low level languages and hardware. But that's my fault for not going into EE. I think.
I also want it to be easier to write, with "dynamic" text in each paragraph (conditionals and interpolation in both body and choices), inlines, and callables instead of goto for better control flow.
You want this to be accessible to non-programmers, but you also want features like inlines and callables? How are you going to explain those features (especially callables) to non-programmers without just teaching them basic programming?
Variables and conditionals are easy enough for a non-programmer to understand. Functions (and, along with it, scoping, arguments, DRY, maybe even recursion, etc.) are a bit more difficult. Callable implies first-class functions-as-variables or even closures from my understanding which would be rather complex for non-programmers (and low IQ programmers).
Callable implies first-class functions-as-variables or even closures from my understanding which would be rather complex for non-programmers (and low IQ programmers).
No functions-as-variables, just reusable sections of code, no arguments, maybe returns. No classes, no scopes, one global namespace, strong typing, all variables declared in the header. The hardest part to explain is the call stack, but it's better than managing gotos. Recursion as something to avoid.
By inlines I mean inlines with respect to Printed Gamebook Language. Gamebooks consist of paragraphs. A paragraph includes a body with static text, imperatives, and conditions, and then choices afterward (which can be conditionally available). Sometimes there's a need for small paragraphs that have a small spoilery effect, then redirect back. I want to avoid this:
Code:
10:
You're at the magic item store. There are magic items for sale:
- potions of healing (unlimited, 1 gp each)
- a Cloak of Invisibility (5 gp)
- a Jewel of Ice (10 gp)
- a magic flute (3 gp)
The proprietor eyes your purse greedily.
* Buy potions of healing (355)
* Buy the Cloak of Invisibility (208)
* Buy the Jewel of Ice (117)
* Buy the flute (87)
* Leave the store (203)
87:
The proprietor insists the flute is magic but doesn't know what exactly it does.
Add MAGIC FLUTE to your inventory, then turn to 10.
117:
You've been had! The Jewel of Ice is just a nonmagical chunk of ice.
It will melt and ruin some ot your hardtack (subtract 1 RATION). Turn to 10.
208:
The Cloak of Invisibility will allow you to automatically win any battle without taking damage.
However, the magic of the cloak is limited, and after 3 uses, it will dissipate into wisps of spiderweb.
Add CLOAK (3 charges) to your inventory, then turn to 10.
355:
You can buy as many POTIONs as you want.
Subtract the required amount of gold, then turn to 10.
Code:
55:
You walk across the desert, heading west. It is very hot.
Subtract 2 WATER and 1 STAMINA. If you have no WATER, subtract 4 STAMINA.
If you have the code word TITAN, go to 250.
You see some ruins in the distance.
* Continue west (304)
* Go toward the ruins (172)
* If you have the MAP, you can use it by turning to (332)
250:
The Fairy Queen appears and sprinkes you with fairy dust.
Restore your Stamina to its initial value, then turn to 55.
These small bits of code should just be written into the first paragraph.
Note that if taken completely literally, in the first example you might be able to buy several CLOAKs and FLUTEs (depending on how the game handles variables) and definitely several popsicles, and the second example is an infinite loop where you go between 55 and 250 forever, and the water situation is probably intended as an if-else but will not play out like that.
Why no functions as variables: it should be easy to see what calls what.
Code:
if time == 0:
call work
elseif time == 2 and day == 5:
call bar
elseif time == 2:
call store
else:
call home
Why no scopes: because in a script, (almost) every variable corresponds to some fact in the story, such as current time (in the world), your waifu's affection points, or the number of fusilliers in your army.
The goal is not to design something accessible to utter retards, I am not interested in retard writing. The goal is to make a high-readability source format for interactive stories and export them to playable html pages.
I don't have a strong opinion on whether to export pseudocode to Javascript code or make a parser in Javascript and put the script into it as one huge string constant the way Choicescript does; for security, game preservation, and community health purposes I'd prefer the latter but tech-illiterate users might balk at the prospect of easy plagiarism or "spoilers".
security: no need for the author to install a compiler that has access to local files
game preservation: files distributed among players contain the source code
community health: prevent authors from abusing players and calling it "game difficulty"
Really? At mine CE/EE has to learn C/C++, learn the basics of Linux utilities, depending on your track you'll have to learn Verilog and/or Python, and assembly. If I could go back in time and warn my autistic self, I would've done that instead of choosing a degreepath filled with soyware engineers who would've been business majors if AI didn't save them.
Really? At mine CE/EE has to learn C/C++, learn the basics of Linux utilities, depending on your track you'll have to learn Verilog and/or Python, and assembly. If I could go back in time and warn my autistic self, I would've done that instead of choosing a degreepath filled with soyware engineers who would've been business majors if AI didn't save them.
idk in my college we started off first semestre with some python then we had mfing MATLAB!!!! and only then we had c/c++ and after that we had verilog and embedded c
but it definitely focuses much much more on actual electronics than programming
the college is somewhat competent though so the compsci degree is actual compsci and not "prompting 101" or "making diy hrt" thats why im tryna switch from EE to compsci (i dropped out after failing mathematical analysis ) in other news i am making an emulator and the whole state of the cpu/computer/whatever is a single 140+KB struct and im allocating it on the stack, good idea or bad idea?
in other news i am making an emulator and the whole state of the cpu/computer/whatever is a single 140+KB struct and im allocating it on the stack, good idea or bad idea?
The stack isn't magically faster than the heap, it just doesn't have the bookkeeping overhead from malloc() et al and tends to be in cache since it's reused so often. If the state lives throughout the entire program and is constantly accessed (which I'd expect in an emulator), you gain nothing by putting it on the stack. 140KB is also larger than the default stack size on some systems.
The stack isn't magically faster than the heap, it just doesn't have the bookkeeping overhead from malloc() et al and tends to be in cache since it's reused so often. If the state lives throughout the entire program and is constantly accessed (which I'd expect in an emulator), you gain nothing by putting it on the stack. 140KB is also larger than the default stack size on some systems.
In my adolescence, I hung out in web spaces with a lot of electrical engineers. Ones with a bent towards digital signal processing and whatnot almost always have substantial programming training. Your average coding EE, in my experience, produced better code than most average "software engineers".
You could try working through early chapters of Stroustrup's "Principles and Practice Using C++", which teaches concepts by taking you piece-by-piece through building and modifying a recursive descent parser.
In my adolescence, I hung out in web spaces with a lot of electrical engineers. Ones with a bent towards digital signal processing and whatnot almost always have substantial programming training. Your average coding EE, in my experience, produced better code than most average "software engineers".
one of my college friends, total ee GOD (would pick electronics out of trash and repair them and such), had ABYSMAL coding practices
i cant really remember much but he definitely was the type to learned just enough that allowed him to make shit work
