3.6KB
title: Thots on RogueLike Design published: 2019-05-08
disclaimer: im writing this stream of consciousness
some people grow as a person over the years, others like to think theyve grown over the years, and then theres me.
still writing less than a hundred lines of a game and giving up, only to try again later (from scratch, no less).
nerd shite
roguelikes are pretty awesome, they're action packed, but slow. you can think about them, plan your move, eat your dinner, watch a show, whatever you wana do, and it'll just wait for you without complaining.
ive long wanted to create some kind of rpg, and like most people, have long wanted to make many kinds of rpgs.
therefore in creating some sort of roguelike engine, flexibility is the most important, for once we have the engine in place, we can strap on as many crappy spoilers as we want create multiple masterpieces from the same engine design.
language
doesnt matter, this isnt about that.
that being said, you should choose something really cool like haskell, or lisp, or hoon (if someone does this in hoon before i do then holy moly please be my friend).
why? easy. because these languages are objectively more fun than other languages, and therefore it'll be more fun for you to write if you do it in something awesome.
plus you get cool street cred and get known at your towns university as “that fuarking haskell guy"
legos
modular stuff is pretty awesome, makes it really easy for other people to use your stuff in ways you maybe didnt expect, and to that degree, id like to put something somewhat modular in mine.
perhaps something like this:
query engine // display engine // input engine
with each piece doing the following:
query engine
this is going to be the guts of our backend. it has a description of the complete state, and a list of keywords to edit that state, ie (move hero left) and it then does checks to see the legality, and if legal, updates the state.
this is pretty simple so far, but theres some nice chances to modularise this even further, for example we can seperate out the legality logic into its own part, this way we can easily write new definitions for types of objects and what they can and cant do (will go into more detail further down).
outside of that this simply updates our state, and returns it to us for use in the display side of things
display engine
heres some interesting use of modularity.
we simply have some agreed upon standard of asking for state from the query engine (ie, we could do an sql style lookup to get what we want) and then we write our display engines to read that standard. in lisp or haskell this could be as easy as a function call you implement.
we then decide how we want to display this data to the user. it could be easy as creating a small roguelike-esque scene out of ascii, or full 4d environments, as long as it can be done using only the state from the query engine.
we could go even further though, because making it easy for people to do things is a good thing.
imagine if we took a module that implemented a function accepting the state of the world, then serialized it, and then sent it out on a network. we could then create a second function that does this in reverse, and then bam, we can jam those two inbetween the query engine and the display engine and have playable over network games, or multiple types of display for the same game, at the same time.
if we set up this system of legos until we get to an “end point” then people have a lot of leeway for how they want to play the game, which is never a bad thing imo.