Losing is fun

This is a response to Christopher Walker's post Implicit vs. Explicit Failure for Educators and Game Designers. The post makes a distinction between two types of failure: explicit ("you have lost") and implicit ("you have not succeeded yet"), and argues that explicit failures are overused in games and education. I think that the post presents a very interesting point of view, and is well worth to read and think about.

However, roguelikes and similar games are based on a completely different philosophy. Losing is an integral part of the game. The unofficial motto of Dwarf Fortress is Losing is fun. This is based on the principle is that it is the journey that matters, not the destination (a similar thing was said by Gauss about mathematics) -- many players find roguelikes fun even if they have no hope of ever winning. Games such as Dwarf Fortress or Tetris do not even have a winning condition -- you will lose eventually. Other games do have winning conditions, and winning such a game after hundreds of failures is a great feeling.

HyperRogue mixes these two designs -- the winning conditions exist (or you can set ones for yourself), but on the other hand, you are allowed to continue the game after winning, but the game gets harder and harder, and you will have to lose eventually. HyperRogue has some puzzles which test your navigational skills in hyperbolic geometry (Princess Quest, Galápagos, Camelot, Yendor Quest). These do not need the component of losing the game explicitly -- however, they would not fit the rest of the game without it, so they also get harder and harder, and one can lose the game while doing them.

Recently, a peaceful mode has been added -- in this mode, the players can solve the failureless versions of these puzzles, or ignore all the challenges and just explore the world. This was intended to make the educational component in these puzzles more accessible to players who are less used to the brutal difficulty typical to roguelikes, and prefer puzzles that you can only win -- especially important in the case of live presentations. However, our experience from such live presentations shows that the standard game is generally much more exciting, especially for younger players.

I think that the dichotomy between explicit and implicit failures presented in the post is a bit exaggerated. In most games, you can try again after you lose; therefore, in a way, all failures are implicit. I think that, rather than avoiding losing conditions, we should teach that losing is not a failure, and minimize the psychological distress caused by it. According to a Go proverb, one should lose their first 50 games as quickly as possible; losing is not a failure, it is simply finding a way that does not work, and everyone needs to lose a lot before they master a subject. It is inevitable that one will "fail" in many situations during their life, that everyone fails, and I believe games to be a great opportunity to teach one not to be discouraged by this.

The post gives an example of a game about Greek mythology where you could lose, causing the chapter to restart, and the player to hear the 30 seconds of narration again and again. From this description, it appears to me that the main problem with the game was not the failure condition, but the fact that they forced the player to watch the story again when they lost. "Well, we need to have some kind of challenge. Otherwise it's not really a game, is it?" Well, maybe it is not really a game, but this does not matter -- not everything needs to be a game to be fun, and many games would benefit if the "challenge" was removed from them. Story and challenge do not mix. If the point of the game is to tell a story -- no challenge is necessary. A challenging game benefits from the story, but only as long as it does not get in the way. Well designed roguelikes usually keep their stories to minimum, or to pieces of lore that you can read if you want. They also rely on randomization, so that every new game will be different and interesting. This randomization sometimes causes the player to lose because of pure bad luck rather than bad decisions -- well designed roguelikes try to avoid this, however, from the "life lesson" perspective outlined in the previous paragraph, it is important to learn that losing is not always your fault.

The post also mentions the problems with stressful mathematical exams, where a single mistake with the execution of the solution makes the whole thing wrong (especially ones where the answer is a single number). Roguelikes also have this property, and there are also many real life situations where it happens -- real research in mathematics, working with computer security systems, etc. While mistakes are costly in all these situations, often there are actually parts of the work that remain valid (completing half of the game, proving useful facts on the way, code often becoming correct after fixing just a single character, etc.), and this should also be reflected in the way the exams are graded. As for games -- aren't they a great way to get one used to this, and reduce the stress?

Thus -- losing is not a failure. Losing is fun. It also makes winning even more fun. Have fun!

Programming language rant

Brian Bucklew, the developer of Caves of Qud (highest rated turn-based tactics game on Steam) and Sproggiwood (a casual roguelike very good both for beginners and for experts), has recently been involved in an external C++ project, and has tweeted a long series of rants about his hate of C++ from the point of view of a C# developer. Since Twitter is not a good medium for discussion, I am posting my thoughts on the subject here.

I will start with mentioning that I have no experience with C#. I have experience with Java. I consider C# to be an evolution to Java. Since I was not satisfied with Java, I am not interested in trying C#, since I believe it to be based on the same general rules. One reason why I did not like Java was too much focus on object oriented programming. The widely held belief is that it is good to learn as many programming paradigms as possible, as then you are able to use the good things about these paradigms in whatever programming language you end up working with. I consider OOP to be one such concept: something that generally every programmer should learn (ideally on a fully OOP language such as Smalltalk) but not something that everything has to be written in. I consider OOP to be a very useful representation of polymorphism. For example, in Hydra Slayer, there are multiple kinds of objects: hydras, consumables, and weapons. I can list all the objects in sight of the player, and then e.g. list their names. It is useful to call a name() method that will work correctly for all kinds of objects despite their different inner representations. But not everything has to be an object. This was the only use of OOP in Hydra Slayer (not including NotEye which does use OOP quite significantly), and HyperRogue did not use polymorphism at all until recently.

Oh my fucking god I have to make two fucking separate files for every fucking object. How can anyone like this language. C++, two pluses because you have twice as many files as the precise same thing architected in any other language. I really think C++ programmers are blind to how many incredibly annoying things you waste your time doing in C++. Ugh. It's so damn wordy.

This actually looks very similar to the issue I had with Java. Having to create a file for every single object; not only that, also a tree structure is forced. Furthermore, because of the lack of conditional compilation, I could not create a single version of the HyperRogue Android source that would compile as one of three packages depending on the compiler options chosen, and I had to create three copies of this source (this was done with a script, but still); maybe an experienced Java programmer would do it in some better way. I do not know to what extent C# fixes this. It does have conditional compilation, at least.

I hate having two separate files (.c and .h) too. But contrary to Java, the language does not force you to actually do this. In my biggest project (HyperRogue) the main file hyper.cpp includes init.cpp, which includes all the other cpp files in turn, from the most fundamental ones. When I want to call some function which was not yet compiled, I simply copy the declaration to hyper.h which is included first. But this comes up very rarely and it is far from a problem that Brian makes it to be.

It takes 10 seconds to recompile HyperRogue. Not ideal, but not bad either. If header files are necessary, generating them automatically does not seem to be a difficult task.

Like C++ guys think they have the ultimate concise low level language, but you basically have to write everything in two representations.

I consider the Google Code Jam statistics to be a good benchmark of conciseness. Contestants have to implement solution to algorithmic problems as fast as possible. It has to run fast, which hurts Python, but not languages such as C# or Java. Most contestants decide to use C++. From contestants who have passed to Round 2 (thus, no newbies), ones using C++ are also more likely to advance to Round 3 than ones using Java or C#.

Want to setup a map<> for something? Make sure you keep track of everything and/or iterate it when erasing so you can delete everything.

I do not understand what Brian is referring to here. Deleting every pointer in a map is simply for(auto& p: m) delete p.second;. In most cases, you do not even need that! I usually do maps of ints, pairs, strings, vectors, non-polymorphic types, etc. which do not require anything; and contrary to garbage collection, RAII will take care of cases which are more general than simply clearing the memory. If polymorphism is required, smart pointers will handle deletion.

bahahaha I forgot you can do multiple inheritance in C++ . . . . what a bad idea

Maybe nobody uses it, maybe people use it to implement something like Java interfaces (which were designed later), maybe it is used in the implementation of C++ itself. I do not care. I never use this and I have no problems with this feature existing. I consider the diamond problem to be an inherent to (class-based) OOP, especially in roguelike programming, when the hierarchical subclass distinctions are often very blurry (attack monsters with a cockatrice corpse? uh, it was first a monster, then it was food, and now it is a weapon?).

omg I forgot C++ can't compile circular references; so a child can't simply refer to it's parent without some sort of hackery like void* (I've written several million lines production of C++ in my life, for those concerned I have no clue what's going on with C++)

Simply use forward declarations, I do not get how Brian did not remember this.

Wow, c++ got a little unhinged with copy/move semantics since I last visited it, hu? I'm trying to imagine people with like less than 20 years of C++ experience writing correct C++ programs nowadays..."

Yeah, the copy/move semantics sounds crazy. But... what happens when you compile an older program with C++11? It compiles and works faster, because move semantics work behind the scenes. One only needs to understand it and care about it when writing extremely efficient programs.

...also not having introspection/reflection sucks a fucking A+ hairy nutsack.

For introspection (as in, checking what is the exact type of a polymorphic object) dynamic_cast is fine. As for reflection -- this seems to cure a problem that I do not have because I rarely use OOP. There is OOP in NotEye, and debug/save/load functions are case-by-case listings of all fields -- this is a place where reflection could be used, but I do not believe it would help that much because (a) this was trivial to write, (b) it appears easier to handle special cases, such as when new fields are added / class hierarchy is redesigned and the load function has to be adapted without breaking older saves. (Anyway, I have managed to implement a method executing a given lambda function with parameters (auto field, string name) for all fields of a polymorphic object in seven lines of C++ plus two lines per class, and creating objects by class ID in about ten extra lines; despite having to write a list of fields and subclasses for each class, I like my solution for efficiency and type safety.)

Coming back to C++ after such a long layoff it's amusingly clear just how much Stockholm Syndrome you develop with its language design.

There were several tweets like this. I know some legitimate criticisms of C++, but all Brian's criticisms appear to be caused by some kind of bias -- problems already solved appear easy, new problems appear difficult, or maybe self-confirmation, or working on some very poorly designed external project. It is hard to see what could be achieved by using templates, macros, RAII, and smart pointers when being used to OOP and reflection. Rather than accusing people of "Stockholm Syndrome", I suppose that some people think in this way, and other people think in that way, and everyone chooses the language which is better aligned with their way of thinking.

Why am I not that excited about Jupiter Hell

The roguelike community was recently all over about Jupiter Hell — a roguelike with modern 3D graphics, which has recently run a very successful crowdfounding campaign. I am quite sure Jupiter Hell will be a great game — after all, Darren Grey and Kornel Kisielewicz are both working on its gameplay, and both are well known to create fantastic roguelikes. This post is a response to a post by Darren Grey, who believes that Jupiter Hell is a gateway for our beloved genre to get its deserved mainstream acceptance.

I tend to play mostly indie games: roguelikes, roguelites, some other games too. Occassionally I do try big mainstream hits, but I am rarely satisfied with them. For example, Witcher II. I have been playing mostly for the story. Most of the game was fighting, exploring, and collecting items. Fights were irrelevant (lack of permadeath!) and boring, and were an obstacle in the story, rather than the fun part. The game would be better without them. And without walking around and collecting items. One could say that it was still better than games that I could not play at all, but this does not change the point: I feel that it would be better if all the game — all the boring 20 hours — were removed, thus leaving just a nice two hour long movie. Diablo II is mostly a real-time roguelike, but I have found no point to try it with permadeath, as I have found it much more boring than roguelikes. I have similar feelings with other RPGs. First person shooters are not interesting at all. I have a relatively good chance to like mainstream strategy games, but I am often annoyed by too much micromanagement, or by animations which I have to watch again and again — when working on the animations in NotEye (for ADOM), I have taken care to have them so that they don't slow a fast player down, and it is great that JH goes the same route with its adaptative animation system.

On the other hand, a big part of the roguelike culture is its wonderful community. Barriers between creators and players are lowered. Players are encouraged to report bugs, provide their own ideas, and even learn programming and create their own variants or games in events such as the 7DRL challenge. This leads lone passionate developers working in their spare time to create awesome games (ADOM, Dungeon Crawl, Spelunky, DRL). Often playable for free — the motivation for creating these games was the fun of creating great games, games they would like to play themselves, rather than financial gains. These games won't have good graphics or polish,but are much better than the mainstream in my experience. I find the roguelikedev communities much more appealing than the general gamedev ones, which IME tend to concentrate on graphics and monetization too much.

So I would like more people to see that games with low production value / free / created by lone developers can be much better than the current mainstream games. Why people don't see this?

Maybe gamers in general believe that a game without high production value, or a free game, cannot be good? By a game with high production value I mean one which has, or appears to have, lots of money poured into its creation: complex graphics, cutscenes, professional voice acting, general polish, trailers, and so on. Will Jupiter Hell be really able to compete with popular AAA games on these grounds? And if it will, I do not see how would such players join our creative community, or try the relatives of Jupiter Hell — all the other great roguelikes — which do not have this production value.

Or maybe the contrary is true: popularity is actually not about 3D graphics? Angry Birds do not have 3D graphics, indies and roguelites neither, and they are quite popular too nowadays — not sure how good measure of popularity this, but by the number of Steam reviews, FTL is roughly on the level of popular strategy and RPG games. Ragnarok and JauntTrooper: Mission Thunderbolt were both awesome roguelikes, and they appeared to have features to appeal the mainstream — quite good graphics for their time, mouse control, permadeath only as an option. Still, they have failed. On the other hand, the insane success of Minecraft, despite being started by a lone developer inspired by ADOM and NetHack, and not having high production value, is a huge surprise. What was the cause of this? Marketing? Simply luck (what becomes popular and what not, actually depends largely on random factors, and Notch seems to agree)? Whatever the problem is, will Jupiter Hell avoid it?

Maybe the roguelikes are not popular because is just hard to explain what they actually are? I think I have that problem with HyperRogue — its defining feature is that it takes part in the hyperbolic plane. Unless you are interested in mathematics, you won't know why would that be interesting — things like "a roguelike in the DOOM universe" or "a vampire roguelike" are easier to explain (assuming that you know what "roguelike" is), so people looking for new roguelikes would probably be more likely to try these. We call these games roguelikes precisely because they are so hard to explain — after all, other genres are named after their features, not after a notable game in that genre :) People are afraid of trying new things. I have updated the homepage of HyperRogue so that it explains the point of the game to new players, without scaring them off with difficult words such as "roguelike" or "hyperbolic geometry".

The Kickstarter page for Jupiter Hell explains that it is a "turn-based sci-fi roguelike/RPG". I think that categorizing roguelikes as a subgenre of RPG might contribute to the obscurity of roguelikes. The success of the Witcher series suggests that fans of RPGs do like games like this: nice story, gameplay not getting in the way. Maybe they do not get what they expect when trying roguelikes. Such people would be put off by permadeath, and the low focus on story typical to roguelikes. I have seen opinions that Diablo is not a RPG — and Diablo is quite similar to roguelikes, so I guess we would see such opinions on roguelikes too if they were more popular. On the other hand, a strategy fan would be much more likely to understand the point of procedural generation and permadeath (strategy games are often procedurally generated, and even if they don't usually feature permadeath, it is quite clear that this is the noble way to play). I am of a strong opinion that roguelikes are actually closer to strategy games than RPGs, they actually are turn-based tactics games. XCOM does have important RPG elements (story, character advancement, inventories) yet it is not seen as an RPG. Maybe we should rather market roguelikes as single-character turn-based tactical games, and emphasize the benefits of being single-character to players of XCOM and such (more action, more detailed characters, less micromanagement).

Or maybe we should try to find new players even further. Most people are not gamers, and I have a feeling that a popular opinion is that intelligent people do read books, or play games such as Chess, playing boardgames is cool, but playing computer games is a stupid thing to do. Such people would not care about graphics that much — everybody knows that a book is not to be judged by its cover, and Chess is the same game, whether you play it with beautiful pieces or not. Andrzej Sapkowski, the author of the series of books that the Witcher game is based on, said "I don't know many people who have played that game, because I tend to with intelligent people". I have watched Evelyn Lamb's talk Visualizing hyperbolic geometry. I think HyperRogue is a great tool for visualizing hyperbolic geometry, but it is only mentioned on the last slide (about minute 33): "I am too scared to do it, because I might like it, and then I won't ever do any work again". It appears that she had experiences with computer games similar to my experiences with Witcher, i.e., that they are a waste of time, and she was afraid that HyperRogue would be like this too. Whenever I see a game described as "addictive", I think it is not a good thing. Far too many games demand the player's time without giving anything in return. Skinner boxes, grinding, free games which allow you to use money to speed things up, unlocks which make the character stronger. Well designed roguelikes don't. In HyperRogue, even the Hyperstone Quest, which is considered very hard, can be done in just about two hours by a skilled player. Obviously getting that level of skill might take lots of time, but the game does not slow you down, only your own ability to learn new things. And learning is fun.

Maybe such non-gamers would be actually put off by the graphics of Jupiter Hell? I have read somewhere that all popular games fall in one of just three graphical styles. Jupiter Hell looks like a quite generic photorealistic violent game. Roguelikes are to a big extent a computer version of board games, and when watching the animations in the Jupiter Hell teasers, it has struck me that it does not look like a board game, thus confusing the potential players about the point of the game yet again. HyperRogue has recently received 3D graphics and adaptative animations too, but our design goals were different. Recently I have received a spam e-mail offering 3D models. I have looked at the (still 2D) screenshots of HyperRogue and decided that, even though the graphics in HyperRogue are nowhere as good as the art by M. C. Escher which inspired it, it is unique and thus looks much better than any generic 3D models. The new animations are consciously made to be not realistic — to emphasize that battles are to provide challenge for the player, as capturing the opponent's pieces in Chess, not meaningless violence for its own sake.

Obscurity of roguelikes is a big mystery for us roguelike fans, we could only guess the reasons. This post turned out very long, and yet it does not cover everything. Roguelikes have evolved in a completely different way than the mainstream games, and I think that we should be proud of that, instead of seeing it as an disadvantage. Please share your thoughts in the comments, or just play the most satisfying games in existence :)