A multi-player roguelike on the Commodore 64
Leif Bloomquist (@schemafactor on Twitter) demonstrated using the Commodore 64 as a client for a multi-player, real-time roguelike dungeon crawler. (What makes it a roguelike? He touched on this in the talk, and admitted it was a little more like a MUD.)
You don't need a C64 to play! There is a Javascript client as well; the game can be found at http://rogue.jammingsignal.com/rogue/.
Why the Commodore 64? Well, it's a great computer for games, and sold 17 million units, making it the most popular computer in history. (The Raspberry Pi is catching up.) There is an active community programming it either on old hardware or in simulation.
The game uses an expansion card designed in 2002 to add an Ethernet board to the Commodore 64. Variations of this design are now available for enthusiasts to build or buy.
As an RPG, the game has some unique features. You can only carry two items, one in each hands, which means you need a friend to carry your loot. :)
The game, running at the conference:
Unfortunately my photo didn't get the display very well. You can see the Raspberry Pi that's running the server for the game on the table, too.
Roguelike Puzzles
Colin Liotta (@vyrin on Twitter) is the creator of Rogue Puzzles, which is now available as an IOS app. It's a set of puzzles games with a Rogue-like visual style and Rouge-like mechanics: moving with WASD keys, dodging monsters, pushing things around.
The inspiration for creating Rogue Puzzles was to form part of the MIT Mystery Hunt, an annual competition. Colin's team prided itself on always coming in second--- until one year they goofed and game in first. The first-place team has to make the puzzles for next year. An earlier year had a puzzles named Walk Across Some Dungeons (i.e., "WASD"), and the using an idea somebody had previously had is totally OK. Colin's follow-up can be found here: http://www.mit.edu/~puzzle/2018/full/puzzle/walk_across_some_dungeons_2.html
The original WASD had a scalability problem. It did everything on a server, which works fine at small scale but might run into problems when 200 teams start pounding on it. Colin's solution to this was to implement all the puzzle logic and interaction on the client. But how to make teams actually solve the puzzles? (Looking at the source code and "cheating" is perfectly OK in the Mystery Hunt, and sometimes even necessary!)
The sequence of keypresses that the client uses to solve the problem is sent to the server, which can validate the solution (a lot more efficiently than doing so one keypress at a time.) A different URL is used for each team. Colin started out using the ROT.js roguelike library, but he made substantial modifications.
Launching the puzzle in public form first let him gather information on which puzzles people found hardest. Getting feedback was really, really helpful. Simultaneously he was working on even harder puzzles for the Mystery Contest, incorporating elements like moving two characters at once. This mechanic is seen in many puzzles games, but not often in roguelikes:
A final set of playtesting was done on PUZZLETRON, a dedicated platform for testing MIT Mystery Puzzles. One thing that came out of this testing was that it was really necessary to have an undo function to turn the puzzles from "impossibly annoying" to merely "fiendishly difficult." In the real competition, teams that solved this puzzle took about two hours to do so, which matched Colin's goal for the difficulty level.