This was originally posted on cohost during a power outage.
i'm dreadfully bored here without power for at least a few more hours so i'm just going to ramble about the technical details of Project RyME.
the game was originally created as a silly little browser-based game so it runs on javascript, html and css. it's mostly vanilla js with a sprinkling of jquery manipulating dom elements. it's only the minigames (and even then, not all of them) that render to a canvas. it uses es6 classes and modules extensively.
to give a sense for how long i've been working on this, i had to use a polyfill to get dynamic module loading on firefox when i first started.
everything revolves around the system class, which manages windows, programs, remote computers, saving and loading, and some other stuff i can't think of off the top of my head. it's very monolithic and ideally i would probably break off parts into separate modules but it's good enough. there are a bunch of separate programs that system can run, like the file explorer, music player, doc viewer, etc. i think there are about 20 in total, each represented by a class that gets instantiated by system when calling runProgram. there are a few programs that should only ever run once, and there are some that need to load immediately. concourse for instance (the discord-like chat program) always needs to be running so it can handle events to populate the right messages and notifications.
speaking of events, the game is almost purely event-driven, as you might expect for a game that's basically all user interface. it uses a custom event system that's not dissimilar from javascript's default, but i needed a bit more broad control. you register a handler with system by giving the name of the event to listen for and a callback function that runs when that event is fired elsewhere.
the game is divided into parts called days. each day is represented by a module that establishes tons of event handler, strings, sequences, etc that make up most of the content for a particular day. in general, system and all of the programs are, for the most part, generic and are populated by whichever day is loaded. there are some programs that are exclusive to certain days though.
the minigames are mostly written using the phaser framework, but they're all wrapped up into regular program objects so they can interact with the rest of the system. in general each of the phaser minigames are completely separate from each other, with very little shared code, since they're all quite different. this really highlighted how bare bones phaser is compared to most full engines.
i think that's enough rambling for now. sounds like our backup generator is here so i need to go get that setup. feel free to send me any questions you might have about the game.
something else i forgot to mention is the internet browser. that one's a bit special because it's almost a real browser.
the main difference is it only looks for local files in a particular directory using the file:// protocol. it transforms the url you enter into a local file path and tries to load and render the appropriate page and in an iframe.
since pages are rendered separately from the rest of the game, it's not as straightforward for them to interact with everything outside. to simplify that, every page includes references to a js and a css file shared by all web pages. the js file includes a way to grab a reference to the system object from the parent window, which is usually enough to do whatever the page needs to do.
most of the webpage data is stored in a directory corresponding to the current day, so when you're on day 1 it checks the web directory for day 1. for later days, instead of having to duplicate everything for each day, it tries to fall back to the previous day if nothing was found for the current day. if you're on day 3 and search for a page, it checks day 3, then if nothing was found, day 2, then day 1. this way i can create updated versions of sites on different days and the most recent one will load while minimizing duplicated data.
