site banner

Friday Fun Thread for April 28, 2023

Be advised: this thread is not for serious in-depth discussion of weighty topics (we have a link for that), this thread is not for anything Culture War related. This thread is for Fun. You got jokes? Share 'em. You got silly questions? Ask 'em.

3
Jump in the discussion.

No email address required.

I am building a crypto version of Gwern's CYOA idea for a pretty big hackathon. Ideally (and IMO probably) we win a prize of at least $10k, then make some connections and turn it into a real thing. If anyone would like to join me (for prompt engineering, development, or marketing) please reach out and I'll provide more details. I am great at the crypto stuff and OK at everything else, so in particular someone with a basic understanding of AWS or nice front-end development would be useful.

Holy shit. That could be so good. Infinite MUD.

That's the goal!

I read through Gwern's CYOA idea and it seems very promising. The biggest hurdle is clearly consistency/memory. There could however be an ambitious way to improve it, implementing memory like they did in this https://arxiv.org/abs/2304.03442. It allows for consistency with minimal context window usage.

This is how I would implement it:

Store every location in a big node diagram. Every new Location creates a new node, with its features as sub nodes or roots. Any unaltered new node is saved globally in all branches, alterations to the nodes stay branch specific. So you could find an ominous Altar in the cellar on a hunt for cultists, but after this generation it could then turn up on unrelated branches, creating a more dynamic and consistent world.

There are a few flaws here, It would be very computationally expensive to refer to the node diagram on every generation and check when to alter it, then again the whole point of the CYOA gimmick is to generate that stuff once and then reuse. It could also taint branches with potentially unwanted things from other branches, turning this more into collaborative world building.

You could do a similar thing to characters, storing their details in notes that are called up when they are in a scene.

While I don't think you need a very exact or thorough implementation of this, something that's supposed to be used by many people and extend for quite some time does need some kind of long term data storage. Or you could bank everything on the massive 32 thousand token window for gpt-4 that's going to be rolled out.

Ignoring my rambling, I am really interested in learning more details about how you're deciding to go about implementing the project.

Yeah there's all sorts of absolutely fascinating decisions to make. I agree that memory is the biggest hurdle and in general it seems that the more that can be handled by regular code, the better. Ideally there are multiple layers of GPT interpretation of whatever information is presented to it. Maybe you have a context layer and a location layer, and one GPT plugin summarizes them for the next plugin, which combines the summary with the player's chosen action to determine what happens next.

I like the location idea but it does have some drawbacks--namely if a branch has an explosion or something that modifies a location, the Location system will guarantee that that explosion didn't happen. Perhaps you could have a location system and then a separate plugin with branch-specific modifications to that Location. Same with characters, quests, etc. I think you definitely would need this Location system to be interpreted by GPT though, because any other solution would necessitate a grid system or something along those lines which I think would stifle creativity a bit. You'd also want the system to be able to locate landmarks and mention them when they're within sight, which would be quite difficult to implement, but very worthwhile.

To be honest I have a busy job and only have a month to build it, so I will be happy if what comes out at the end works at all haha. Once this grind is over it will be fun to put a lot more time into optimizing everything though. This is the sort of thing that could just be improved upon forever. My understanding is that in certain respects (such as the context window) AI should be subject to Moore's Law so in a few years maybe we have enormous 200k context windows and all of this becomes very easy.

I'll follow up with more details when I have them written down, but tbh Gwern's writeup suffices for me for now.

The whole crypto aspect is mostly just to get funding, right now (crypto hackathons seem to have much less competition), at the VC stage (same), and if/when it actually becomes a real company. The basic idea is that you can buy an NFT of a branch in the story, and then you "own" that branch and earn royalties whenever anyone buys a branch downstream from yours. I am not much of a crypto person (despite working in the field) but I think people would genuinely enjoy owning stories on the blockchain. My hope is that it further incentivizes people to search for high-quality branches--they get paid if they choose the best branch after all. Then all the NFT purchases would go towards subsidizing the experience for your regular consumer who just wants to read a cool crowdsourced CYOA book.

Yeah, I agree with everything you wrote here (Although I already mentioned the branch specific modification to locations in my original comment). The crypto stuff actually seems a lot harder to implement than the rest of the program, imo. I might actually try to develop a location/character database/lookup in my ample free time myself, run it all locally on some 7b model. Will share the code on GitHub if I manage. Some interesting prompt engineering challenges there, I think.

Good luck on grabbing some of that crypto money!

Oops, must have missed your comment about branch-specific modification. I'd certainly be interested in seeing what you come up with. Part of the reason I'm excited to build this is because if it works at all then I will enjoy it, even if it never goes anywhere.