There are a lot of them! No Rangers Allowed (D&D), SNEXploration Squad and the Book of Megadrive, Hinge Problems, and the actual selectbutton.net podcast are all part of them. I did a shortlived series on the Kingdom Hearts games call Labyrinth of Worlds.
There should be threads for most of these over in Output, or you can search them and find the relevant threads.
You could listen to SNEXploration squad and The Book of Megadrive, Conveniently located on the same feed here: http://shoutengine.com/SuperNintendoExplorationSquad/
Listen to 3-8 SBers discuss a random assortment of 16 bit video games. I recommend starting with Wizardry and Bonanza Bros respectively.
(Although the two most recent episodes are also very good)
Itâs a week later, but the Wild Arms remake on PS2 lets you opt out of battles before they start. You get a visual cue and have maybe 3 seconds to decide whether to fight the battle or spend a bar of meter to skip it. You get one bar back after a battle or picking up orbs (which donât respawn) on the dungeon floor. When your partyâs level is sufficiently greater than an encounterâs, you can skip the battle for free.
The system does a few things. It avoids battle intros and escape animations, it incentivizes completing dungeons on the first run, and it makes revisiting early areas painless.
the tabletop RPG Torchbearer has an interesting goal oriented combat system where you can drive enemies away rather than killing them, and depending on the enemy type this might be much easier or much harder than a fight to the death. This of course also applies to the player characters, enemies can choose to make routing or capturing the PCs a priority instead of just slaughter.
Web developers are notoriously bad at memory management. Going through the history of the Web:
First, everything was a static page so its memory cost on the userâs browser was pretty closely aligned to the size of the HTML file and the assets loaded by that page. It was a little rough in the early days of the WWW because you could easily go overboard with images and rudimentary GIFs, but generally you kept everything small anyway because connections were so slow.
Then pages became dynamic but generated on the server, so any additional memory cost would be taking place on your server which is presumably beefier than whatever computer your end user is visiting on. This could become a problem if your website needed to scale to a ton of concurrent page requests, but for most websites, the amount of thinking about memory you had to do was about the same as in the static days, so practically none.
The mid-2000s roll around and everyone wants to make their websites a little cooler. Libraries like jQuery or mooTools or whatever come around and make it easy for even non-developers to embellish their websites with animations and richer interactions, so everybody starts doing it. This is where Web developers (or in many instances, Web designers), which have traditionally never had to think about managing memory on their usersâ computers, start writing code that runs on their usersâ computers.
Inspired by richer applications like Google Maps and Gmail, the trend becomes to move towards âsingle-page appsâ (which Discourse is). The model moves away from the traditional page-to-page navigation model, and instead becomes about having one page loaded up front when you first access a site, and then every link and button you click is hijacked by the application to be handled locally on your computer. Page-to-page navigation is simulated via the browserâs history API. This is where Web developersâ lack of memory management knowledge becomes dangerous:
Many developers have trouble understanding that even though a language like JavaScript provides no explicit memory management (at least in a traditional browser environment), you still need to be conscious about how you keep references to objects so they arenât retained in memory indefinitely. If you put something in a global variable, itâs gonna stick around for as long as the page is up because the application canât know ahead of time if that variable will only become relevant 48 hours from now. This isnât a Web-only issue, but it is worse on the Web because of how little Web developers have had to think about memory as a whole.
Previously, the impact your page would have on a browserâs memory footprint was limited to the time your page was open on screen. If you hijack all of the internal links in the application to keep your page on screen the whole time, your average page view length goes up from maybe 600ms to several minutes or maybe even hours. Even if Web developers have been leaking memory everywhere on usersâ browsers since the Dark Ages, it was never really a tangible problem until single-page apps caused pages to be open for hours at a time.
Web development tends to rely heavily on external libraries, frameworks, and plugins for those libraries/frameworks, which nobody ever takes the time to vet. Since these are also mostly written by Web developers who have never had to care about memory, the code you write yourself may seem perfectly clean from a memory POV, but the things you are calling may be doing terrible things like hanging onto references to things forever or way beyond the point of relevance.
This is also why Electron apps are repulsive and bad beyond just the UI inconsistency but I need to go take the bus to go to work so hopefully this is a sufficient explanation