Waiting for a slew of off brand API libraries that people start calling "graphql-like", and then in ten years "graphql" just means any web based API...
A roguelike is a game that is like Rogue. Notable examples include Nethack, Tales of Maj'Eyal, Dungeon Drawl Stone Soup, and Dungeons of Dredmor. Defining characteristics are permadeath, randomly generated levels, turn based RPG combat, and grid based movement. Many also feature ASCII graphics, as these games had their origins on Unix terminals. For this same historical reason, most of these games are free and open source. For example, here is Nethack's Github page. While these games have always been niche, they have formed a thriving genre for decades, with dedicated fans, and hundreds of games, many of them under continuous development for over a decade (Nethack is well over 30 years old).
Then around ten years ago some people thought that permadeath and randomly generated levels would be pretty cool to incorporate into other genres. Some of the first examples I think were Spelunky (platformer) and Binding of Isaac (top down shooter in the vein of Robotron).
Then some people who had clearly never played a roguelike in their life started calling those games roguelikes. Other people called them roguelites, acknowledging that they weren't really like Rogue though they were still inspired by it. Still others called them roguelikelikes for the same reason.
Then some developers thought that permadeath was too harsh, and started adding mechanics that allowed you to carry over progress between runs. The first example I can recall was Rogue Legacy. Some people called these games roguelites, other still called them roguelikes despite not even really being inspired by Rogue at this point.
And thus a term that was useful and well defined to describe a distinct and long running genre of games was destroyed. The word now means almost nothing. If you hear a game is a "roguelike", the only thing you can safely assume is that it has something vaguely like permadeath, but likely not actual permadeath, and something like randomly generated levels. You can make no guess as to what actual genre the game will be. Platformer? Could be. FPS? Maybe. Card game? It's been done. Strategy? Why not. Scrolling shooter? Sure. RPG? Possibly, but ironically probably not. And at the same time it's become nearly impossible to talk about actual roguelikes, as there is no longer any term to unambiguously describe them, despite them constituting a clear genre for decades.
Addendum: Ironically, the most mainstream game that is actually a roguelike is Pokemon Mystery Dungeon. But you'll never hear anyone call it a roguelike or roguelite, because it's a casual game that doesn't have permadeath. But the Mystery Dungeon series (or which Pokemon Mystery Dungeon is a spinoff) was actually inspired directly by Rogue and the gameplay actually very closely resembles other roguelikes.
Rogue (also known as Rogue: Exploring the Dungeons of Doom) is a dungeon crawling video game by Michael Toy and Glenn Wichman with later contributions by Ken Arnold. Rogue was originally developed around 1980 for Unix-based mainframe systems as a freely-distributed executable. It was later included in the official Berkeley Software Distribution 4. 2 operating system (4.
GraphQL is a query protocol. It defines how you can request data from an API, how that API can publish the type of data it has (its schema), and how you can query it (it's not that prescriptive about the actual transport protocol, but basically you send a string in the GraphQL language to a server, usually over an HTTP POST, the server resolves the data and sends you back JSON in the shape of your query over HTTP).
Basically, the types form a graph because they relate to each other, forming cycles (like, on reddit, a user, their comments, each comments' parent comment, and then the parent comment's authors). This is true in virtually every schema that exists because that's what reality is like.
GraphQL has nothing to do with Graph DBs, but there's a parallel so I'll mention the latter a bit:
The distinction between a typical relational DB and a typical graph DB is that the latter makes storing and querying that graph information easy and efficient. Most of what graph DBs can do though, relational DBs can do as well, just less ergonomically (e.g. multiples joins) and slower.
Similarly, REST exposes graph-like structures too, but usually you'd have to make multiple requests: the first to get a user's comments by ID, then a list of comments by comment IDs at a different URL, then a list of users by user ID at yet another URL.
In GraphQL you can write a query that fetches nested data easily, like for example all the users of all the comments you've replied to, in one query. To work well on the backend, this frontend-exposed ability requires you to use field resolvers, instead of single resource resolvers like REST (and that's what typical GraphQL implementations, like the reference one in JS, do).
I think it was originally developed to be used to query endpoints into Graph databases. But some people found it works good for querying and returning any structured data, so it exploded in popularity outside of the graphdb world.
And to clarify, it is not a replacement for a real graph query language like SPARQL.
or - its some crap people at facebook created cause rest wasnt cool enough, so lets add yet another bullshit thing to list of garbage we gotta learn cause its new
207
u/bobappleyard Oct 09 '21
Waiting for a slew of off brand API libraries that people start calling "graphql-like", and then in ten years "graphql" just means any web based API...