Week 1 post

I’ve silently participated in the Reddit (RIP) does the roguelikedev tutorial over the past few years (and have never extended it beyond the basic tutorial - school-related things always seem to come up). This year I wanted to try something different and we’ll see how it goes. No guarantees I’ll finish this or that even I’ll make something releasable, but I wanted to have some fun and see where I can get.

I’ve always had a soft spot for grindy MMOs (for example, Ragnarok Online, FlyFF) and fell hard for Realm of the Mad God (RotMG) several years ago. Oddly enough, one of the early contributors who did the maps for RotMG - Red Blob Games - also participates in this challenge!

RotMG

Anyway, that’s where my mind wandered this year. This proof of concept will probably fall outside of the typical Berlin interpretation of a roguelike, and dare I say, may even become a roguelite.

Here is the core concept:

Roguelike mechanics (bump to attack, tile-based movement, permadeath, etc.) in a multiplayer, instanced environment

The fact that multiple players will be participating is not new, however is a tricky thing to address for the typical roguelike given that time moves only when players move. My design decision here is that time will forever be moving forward (meaning that the game state will update periodically), however players can “remove” themselves from the flow of time if they need to stop and think (or take a break).

Or, worst case they can bail on the instance as in RotMG if things don’t work out.

This will be the meditate mechanic - players will enter a meditative state where they still exist but are on another plane of existence. A mechanic which is ripe for abuse and therefore probably will receive a cooldown timer of sorts.

One of my caveats is that, while I will do my best, this will not be a “secure” environment in which I can guarantee that players can’t abuse the client/server mechanic. If you’re familiar with RotMG (or any multiplayer game really) there was a serious issue with item duplication that went on for some time. I’m going to handwave that bit and assume I’ll hire a security expert at some point that can fix things.

Anyway, here are my overall goals for the follow-along tutorial series:

  • Client/server architecture where all logic occurs server-side

  • “Standard” tutorial concepts implemented (e.g., multiple dungeon levels, enemies, items, etc.)

  • Different procedural content generation (PCG) methods for the map (BSP, cellular automata, etc.)

  • Camera system to allow large-scale maps to let the PCG shine

  • Ability for players to interact with each other (i.e., via a text chat)

And some initial architectural/design decisions in no particular order:

  • Server will be in Python to enable me to use tcod if necessary

  • Client will be in JavaScript/HTML5 and be responsible for rendering/handling player input

  • All code will be open source to enable others to spin up their own instances

And lastly some stretch goals:

  • Player can select tiles or ASCII

  • Players can trade with each other

  • Fog of war for individual players

  • Database implementation will allow persistence (redis or SQLite)

I don’t plan to checkpoint this at all as I go so the eventual repository will be one single main tree, but I’ll try to highlight things that are “interesting” for others in these posts.

Prior to the Week 1 drop I wanted to get a prototype up and running just to see if I could get Flask to play nicely with web sockets and a JavaScript frontend. Here is a sample - hot pink is you, green are other players, E are enemies that will either randomly move or follow the closest player. When a player goes dark they are meditating and still exist but aren’t a part of the game until they resume motion.

Sample interactions

Next post