I also released the code for the game engine. Available here: https://github.com/mmulet/code-relay/tree/main/markdown/Tuto...
I ran into the same problems you did, any variable leads to an exponentially large state. Other than, "scoping" as you put (or branch merging as I put it), the most space-efficient way I found to keep state was to ask the player to remember a passcode. So the player can keep track of the state, but I don't have to (ie. exponential space savings!). Even when entering the password, you can keep the space small (n*2 rather than 2^n) see . Players used to retro PC games will remember entering passwords found in their instruction manual, so it's an added nostalgic appeal.
Let me know when your error dialogs game is done. If you want to collaborate on some games, hit me up, I too love games where they shouldn't be.
In the end, because it's a book and not a computer game, we could just ask the user: "If you have a key, turn to page 43..." and it just depends on the user being honest (or as honest as any reader of a CYOA book is, with nine fingers stuck between pages).
I assume there were similar books in the past that used the same mechanic -- maybe the Fighting Fantasy books? I forget.
Or if you wanted to make them work a little harder and maybe teach a little math, "17 times the number mod 47".
Of course they can still be dishonest, but it gives them an opportunity to have solved a simple puzzle. They get to the correct page because they "won".
The other thing we did, slightly simpler, was introduce a plethora of choices where only prior knowledge would get you (easily) to the page.
E.g. You can land on page A a number of different ways, but only from one path do you find out the suspect is in a certain city. Then from page A you're asked if you want to go to B, C, D, E or F. Without the prior knowledge there are too many choices.
Overall, awesome stuff :D Ever since I read , I knew you could do some funky stuff with ligatures, but I never imagined you could take it this far :D
You have to keep going past the ending (GameOver) keep typing. You'll revive and beat the boss.
Amazing project BTW, had a lot of fun!
This is years beyond the statute of limitations so I can finally talk about it - in my youth I broke into one of LANL's servers for kicks; some Lotus/IBM Domino machine, saw nothing of interest except for a project directory which even the admin didn't have access to... I didn't want to escalate privileges any further because it'd require permanent changes and would probably trip a flag - but then I found a bizarre folder.
Someone coded a series of directories within Domino and made a maze game, maybe a Zork 'lite'. I spent a few minutes exploring and got bored.
Plenty of similar stories about other better known orgs/corps but this isn't the venue for those :)
This week I stumbled upon John Robertson for the first time. He made an choice based Adventure game called The Dark Room, which (in its first iteration) was realized with YouTube Annotations, then performed live, and now he streams it on Twitch. It's an interesting combination of preparation and improvisation
For example, it's possible to go back to the beginning of the input box and edit your character selection while keeping the rest of your gameplay in place.
Seems like this could have a lot of potential as a puzzle game mechanic.
"If you want to make a game, make a game. If you want to make a game engine, make a game engine. But never, ever, make a game engine to make your game!"
I spent a good five+ years working on my own game engine to make my own games with it. Never finished a single game, or the engine-- but it was a fun learning experience so there's that.
If you work in games or want to work in games, writing a game engine is a very valuable experience. Probably the best thing you can work on for personal growth.
That said, I think you get substantially more value out of the experience if you've already gotten your feet wet making games with a commercial engine.
Now obviously QJ2D is not going to replace Godot or even LÖVE2D or TIC-80. It's a couple of days' worth of work, less than 200 lines of code; anyone could have done it. And nobody else is going to use it unless they have Greek letters on their keyboard. But not only did I learn a lot, it's also a substantial improvement for this kind of thing over the raw browser. I think I'll probably rewrite it differently for the next project, though...
I don't want to "work in games", but of course I enjoy writing games. I mean that's all computers are good for, really!
† not really games
Not only is this a brilliantly hilarious piece of tech, the humour in the game ain't bad either.
(And you are making the rounds on gaming sites )
just van rossum’s rubik’s cube is another recent example of font layout gone too far: https://twitter.com/justvanrossum/status/1340960087750402048...
Sorry, waaay off-topic, but I've never seen such incredible D&D dice!
Have you tried other shapes? Dividing the square by the diagonal should not have this problem, and you're even drawing a simpler shape (triangle vs rectangle).
[Edit]: Yes, it seems. Very cool!
If we can get 10% of programmers to devote 5 minutes to open source a day, we can help a lot of people (maintainers and the open source community as a whole).
Obviously, not everything can be broken down into 5 minute tasks. But, I believe there are enough things that can be broken down. That Code Relay is worth pursuing.
Maybe, it will only work for functional programming languages where there is a strict way to divide code into smaller and smaller functions.
Or maybe it will only work for crowdsourcing documentation. Most projects need better documentation, badly. So, this would be a worthwhile goal in and of itself.
The approach I'm taking now is to try everything and see what sticks.
This seems interesting and compelling, but I think encoding "this specific time at this specific timezone" into the foundation of the system will exclude a potentially significant number of people that may otherwise contribute to its success.
First of all, let's see how far away I am from PST... okay, 7AM PST is 1AM the next morning in AEST (in Australia). Imposing a globally-fixed time across the world, irrespective of timezone, falls on the suboptimal side of exclusive for a lot of people, since there are always going to be more people outside of any given timezone than within.
Secondly, I look at 7AM a bit deer-in-headlights: I'm incidentally temporarily using an offset sleep schedule at the moment while I rectify some environmental issues, so that time happens to be just about the mathematically least optimal moment in the day for me to approach a conveyor belt of unexpectedness with anything resembling interest. Most likely I would instead demonstrate the fastest possible method ever seen of permanently disassembling the conveyor belt, then go back to sleep :)
The above two points are my reasons why this approach would not be ideal for me. I suspect that a lot of other people would probably present unique anecdotes of their own with vaguely similar sentiment.
I would recommend a call waiting-like architecture instead. Have a giant queue of things on the server. Offer some small percentage of available tasks to a given user*, then hide those from everyone else. When the first user picks the thing(s) they want**, re-mark the unselected things as available. Do this for everyone at once.
* It will both be technically easier and socially more interesting for users to list their experience then get delivered a precomputed list of tasks, than simply go "ok here's _everything_". The 'everything' approach has terrible UX, with tasks disappearing as others "steal" them, but the precomputed ideology of "this list was calculated before you arrived" feels more like TV - the list of things the user can see is all there is. This architecture should age very well, too, allowing you to do all kinds of optimizations over time in terms of figuring out who visits and when and what tech they like and whatnot, then precalculate optimized views for each user before they arrive. You'd need a few hundred people before you'd be able to build that correctly though.
** Definitely let users pick more than one thing to add to their local queue. That way they can headscratch about (or get their brain into the zone for) complicated thing #2 while breezing through trivial thing #1. If someone queues a task they decide is actually too hard, make it feel like it's not at all the end of the world for the user to release the task back into the queue. This covers queuing up multiple things as well.
Also, make it possible for users to see all tasks they ever selected, including what they didn't complete or immediately released without starting - the user might have fat-fingered their mouse (or brain) and might want to go manually complete (or help completing) the task outside of the website. (Completely +1 avoiding the rabbithole of "wait, no, I actually wanted that task, yank it off of whoever is doing it")
In practice (from an architecture-design perspective) I reckon about 50 things and 3 or so users would probably look pretty similar to 1000 users and 150 things and 5000 users and 500 things.
In closing, even with the queue approach described here, I see the fundamental idea as very distinctly different from the asynchronicity and absolutely-unbounded-complexity of Stack Overflow. Here are 5 things. Which can you do **right now** in 15 minutes? That does not exist. It sounds awesome.
Also, SO's success, _despite_ the unboundedness issues, absolutely proves that there are people out there who will literally spend hours and hours figuring out other people's problems for free. The idea of making this process ADHD/anxiety-friendly, unintentionally or not, is why I initially said this was compelling. May you scale well :P
NB. Have you thought about supporting collaboration? That would be the next logical step for something like this - and it's so logical, it's unfortunately what everyone using the platform would likely clamor for. I recognize that it's extremely hard to even just collaboratively edit documentation etc, let alone work on solving open-ended problems with arbitrary tooling. Precisely figuring out and publishing your stance on this - eg, "nope, not interested", "sounds interesting, patches welcome", "sounds interesting, patches welcome if maintenance on offer", etc - from the start might be a good idea. (FWIW "patches welcome" can often come across as very unempathetic and ivory-towered, if you will, especially when it sticks around for a long time and gives the impression progress isn't happening. Articulation is hard, etc...)
Call me crazy, but you would write a Z-Machine on that.
For me, the tl;dr from the technical explanation was this:
> Now, everything in fontemon is baked
Just reading that made me laugh out loud. It's so simple and so ridiculous, i love it.
I recommend reading the entire blog post btw, it's very thoroughly explained and it assumes no knowledge of either fonts or gamedev.
(seriously, very fun!)
Now I gotta try shoving it into various programs to see if it works.
(However, I haven't figured out exactly what to do after that!)
Edit: Figured it out