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!

NotEye 7.6

NotEye 7.6 is released!
This update is mostly for those who would like to use NotEye in their 7DRL 2014 entry. The seven day challenge starts in just a few days. Whether you want to use NotEye or not, good luck!

The 7DRL invitation caused lots of discussion about the licensing of NotEye. I am quite confident that GPL is (mostly) what I want; I have explained my motivations in the dev guide. I have also made the licensing clear in the package: improved the comments in the Lua scripts, license is displayed in the "about" screen, improved the "readme.txt" file and the sourcing of the audio/gfx files.

More changes:

• Added the DawnLike tileset (together with two new fonts) and some Lua scripts for it. Sample games now use this tileset.
• Added an "About NotEye" option to the NotEye menu. This simplified the NotEye main (pre-game) menu.
• Fixed the TPP mode (in 7.5 it worked correctly only in Hydra's hex mode).
• Fixed the "-N --ascii" command line option (which runs NotEye in the console).
• Added some new utilities for sounds, and for scheduling an action later.
• Added a noteye_halfdelayms(int i) command for more precise timing.
• Added more functions to JNI (thus Java can use more NotEye's functions).
• Fixed the Makefile (NotEye did not compile correctly on some Linux machines due to missing -lz -lcurses).

There have been some changes to Hydra Slayer, although it was not a focus of this release:

• Hydra Slayer has new sounds by Brett Cornwall. It is still a work in progress.
• You no longer get a double sword when growing your fingernails. (Also fixed the grammar slightly.)

See the NotEye website, or download directly!

Good luck hacking!

NotEye 7.5: TPP, samples, 7DRL invitation, and more!

After more than four months, a new version of NotEye is ready!

NotEye 7.5 has a new graphical mode (TPP). Since you can configure the camera angle, facing direction, and zoom, this is in fact several modes in one! Also, NotEye's fullscreen mode behaves in a more pleasant way (it keeps the current resolution, instead of changing it to the window resolution -- it can be configured to use the old behavior, too). Also, a new font was added (Wouter van Oortmerssen's Square font for roguelikes).

Moreover, NotEye is now friendly to developers using many different languages. Not only the support for C++ (namespaces) and C (NotEye header correctly compiles under a C comiler) has been improved, but also NotEye now includes samples in Free Pascal, Python, Java, and Lua. All of these examples (except Lua) show many basic features: PC, monsters, smooth animation, error handling (just reload the Lua files on Lua errors). All of the five sample games are very simple, but at least they are at least a bit different :)

Since the 7DRL challenge is coming, I invite the participants to use NotEye for their 7DRL this year. See here for more details.

Direct download link: NotEye 7.5+Hydra Slayer 15.5, Roguelike Bundle 1.3

Some more changes:

• Several options were added: Projectile speed, Backgrounds, Detail/violence levels (for disabling drawing of CPU-intensive details or blood). These options work for games which support them.
• Arrow keys can be used to change music/sound and detail/violence levels. Instant feedback when changing music/sound volume.
• All configs, recordings, screenshots etc. are now stored in the 'user' subdirectory; default config is included (in 'common') and copied there.
• 'copy error message to a file' in the crash menu.
• Auto-recording now can be selected from the menu (not only from the config file).
• Auto-logging. If you wanted to know how much time you spend playing roguelikes for some reason, now you can.
• Menus are now more colorful.
• Removed ADOM and PRIME from the menu - these games use NotEye, just download and run them.
• The NotEye Menu has been rearranged a bit. Fixed the message to 'press ENTER to resume playing' while in a game.
• Fixed the system terminal mode (it did not work in NotEye 7.3 due to changes).
• Gamescript files now provide their NotEye version (for backward compatibility in the future).
• In Hydra Slayer source, BFS is called bfs() instead of dfs().
• The palette display now works with all fonts (uses filled blocks instead of characters).
• Added some utility functions in the Lua scripts (sendvector, keyname).
• Renamed some functions in the NotEye header to make it clear that they belong to NotEye; also, for colors, the type 'noteyecolor' is used instead of 'int'. Added some new utility functions (noteye_lastkeyevent_* for examining the details of keypresses which do not resolve to characters, Lua-callable functions now can return nested arrays and Lua tables).
• Bounding boxes are calculated for tiles, which should make the pictures draw faster.
• A minor fix in backward compatibility.

Hydra challenge, new NotEye, HyperRogue music and exploits

It seems that a lot of things have happened during the last month...

In the previous two weeks, Hydra Slayer was featured in the Reddit Roguelike Weekly Challenge. Players were asked to play Hydra Slayer and reach as deep as possible. You can see the results here.

I had some fun, and I hope that the challengers had fun too. Congratulations to ionfrigate for winning! :)

Still, I think that the Hydra Slayer challenge did not show the game's full potential... I mean, it was not as fun for the players and myself as it could be. For players competing for scores, I think it would be better to count the wounds gained during the 50 levels, instead of going as deep as possible (I think that the game gets quite boring after level 50...). Also, all of the high-ranked players have been playing as daughters of Echidna, which is unfortunate IMO, as they are the least interesting race for me: it is easier to construct an efficient weapon set for Echidna than for other races; using this efficient weapon sets is a rather boring calculation; and they seem to be more powerful than the other races. They pose an unique challenge due to being completely different than other races, but if I was organizing a competition, I would probably ban them.

Still, weapon sets that have been used by different players have been a bit different (one of them used a pick axe, which was surprising for me).

The challenge led to some improvements in Hydra Slayer!
Hydra Slayer 15.2 features:

• The potion of knowledge is now usable only against a single enemy. This is actually more logical: when facing a bloody hydra and a vulture hydra, for example, you can choose whether to unblood the bloody hydra, or to analyze the vulture hydra.
• Also, the potion of knowledge is now less useful on shadow hydras: it now shows three single handed attacks. Before this change shadow hydras were extremely boring for Echidnas, since for any respectable Echidna three attacks are enough to kill a shadow hydra, and thus shadow hydras boiled down to drinking the potion and noting the numbers. Especially boring when there were lots of other Hydras in sight, and the game had to analyze each of them, which takes a lot of time for ambidextrous slayers...
• To nerf the Echidnas a bit, they are now slower to use items. Using items costs a turn, and throwing powder at hydras costs another turn (and the hydra attacks in the meantime while the powder is thrown!). I think that Echidnas need more nerfing, though, so please comment if you have any ideas for this.
• Some bugfixes: shadow hydras are no longer detected with a right-click. Keys such as 'm' and 'f' now actually work when a hydra is stunned (previously, the screen tended to disappear right away in this case... this bug appeared in UberHunter's videos and I could not find the reason for it, but it was apparently caused by the stun animation). The semi-transparent part of the screen sometimes appeared in the wrong place, this is fixed.

Also, NotEye got some improvements. Some players know these improvements from the closed prerelease of ADOM, or from the Roguelike Bundle draft. Both of these were called NotEye 7.1 (I think), so the official release gets number NotEye 7.2.
The changes are following:

• Minimap has modes: it can show the old typical minimap from colored boxes, but it can also show the original ASCII screen, or a graphical screen (in the Tile, Isometric, or FPP mode). So the player could play in ASCII mode and have a tiny FPP view in the corner, for example. Also the minimap is movable now, and the default placement is (supposedly) more intelligent.
• The Noteye window is resizable.
• A new 3x5 font added (especially useful for the ASCII minimap).
• Some keys caused NotEye menu to crash in some situations, this has been fixed.
• Added ChessRogue, Gruesome, Toby the Trapper, and Unstoppable to the NotEye menu.
• Music now stops when NotEye loses focus. Also better handling of mouse out of the window.
• Noteye looks for batch files in the 'batch' subdirectory, and can run games via these batch files.
• Scrollable map. Holding the mouse close to the edge of the map area will cause the map to scroll. Look at the menu (NotEye menu, or some game menu) to center back on the PC. This also means that when the PC is on the edge of the map, the tiles mode will detect this and move the PC off the center, so that more of the map is visible.
• Zoomable map. You can now zoom the map in the menu (by changing the tile size in the graphical mode submenu), or using Ctrl+Mousewheel.
• You can now specify the max frame rate, to conserve the CPU.
• Table streaming, to be used in integrated games, so that special events sent by ADOM will be streamed when creating a NotEye recording or playing via a NotEye server. The next prerelease of ADOM will display a nice, detailed animation when using the machines in the level with lots of guards and a huge shop! ;) (I was surprised when I saw that place first, so no details, go play ADOM yourself if you do not know what I mean)
• For some games it is good to restrict the map to the original map area, this is better supported now.
• An option to reserve space below the map appears in the menu now.
• Fixed some minor bugs with the cache used for zoomed images.
• Fixed some problems with FPP.
• noteye_getevent() now actually returns the event.
• "isosizes" now returns all the original parameters, too
• NotEye scripts have access to "getkeystate" (e.g. check if Ctrl is checked) and "getticks" (for timing)

You can download Hydra Slayer 15.2 and NotEye 7.2 here.

Last but not least, I am collaborating with NeonCorridor: he is creating great music for HyperRogue. The songs which are ready are available here; comments are welcome :) For a long time, I felt that HyperRogue was complete except that music was missing, and this is going to be fixed in a few weeks. Also, Adam Borowski has discovered some exploitful strategies in HyperRogue, which allowed one to achieve unlimited scores while remaining safe (or practically safe). These are also going to be fixed in HyperRogue 4.0. Stay tuned!