Top products from r/roguelikedev

Fungus Cave

Github repository, screenshot.

It has been over a month since I finished my last project, Cursed Souls. Now I am working on a new Unity game, Fungus Cave. There are not so many things to talk about the game itself yet, so I would like to share the books I have read about C#, data structure & algorithms, and Unity.

C# 7.1 and .NET Core 2.0 is my C# textbook. It explains everything step by step for beginners. Although you need a PhD in math to create Dwarf Fortress, to learn data structure & algorithms is not so demanding with the help of these books:

• A Common-Sense Guide to Data Structures and Algorithms
  
• Learning JavaScript Data Structures and Algorithms
  
  After that, I browse articles in RogueBasin to learn about: time system, dungeon generation, pathfinding, FoV and AI.
  
  There are tons of books on Unity. I cannot tell which one is the best, but two of them which I have bought are well worth the money:
  
  
• Unity 2018 By Example
  
• Mastering Unity 2D Game Development
  
  Save/load system and coroutines are two topics that I care about but still do not understand after reading these books. So I googled around a bit and found something in addition to Unity tutorials:
  
  
• How to Save and Load Your Players' Progress in Unity
  
• Coroutines in Unity3D
  
  That's all. It took me about three months to learn all these things. I hope this book list would be helpful to other developers. Happy coding!
  

People talk about prototyping games a lot. Like, you have an idea so you build out a simple example so you can play it and see if it's fun on a basic level.

But what they don't really talk about, is prototyping code. It's hard to figure out how things fit together in a meaningful way if you don't already know the coding conventions or patterns that can help you build them.

As a self taught programmer whose work includes a good deal of coding now, I've gotten a lot of use out of building out small 'hello world' type examples of more complicated code structures.

Imagine you're trying to build a skyscraper, you wouldn't just try and build it straight out of your head, you'd follow a kind of miniaturized version of it, a blueprint. So that's what you should do as a programmer, make blueprints. Don't just make blueprints for your whole game, make blueprints for even the smallest sections of it if you don't feel like you completely understand it.

My wife is a senior-level project manager for a really large construction firm and her projects typically cost somewhere in the range of $500 million. When she's on the job-site supervising a part of the build, she doesn't refer to the blueprint for the whole project, she uses the blueprint for that specific part of the job. So if you're having trouble figuring out how to properly break a python game out into modules, don't look at coding examples of full games because you'll just find it overwhelming. Look for simple examples of python imports and module structure. But more importantly, build small examples of how that works using those examples to make sure it works how you're expecting.

Think of the game you want to make, and form some basic ideas about how it should fit together. Read up on programming patterns, game engine architecture, or artificial intelligence for games and whatever other topics interest you about game design. Make small code projects prototyping concepts that are interesting. I have a project folder on my computer that is filled with small examples of programming patterns, complicated data structures, skeletal game structures, and anything else that can serve as a blueprint for building something else.

So if you're reading and come across Entity Component Systems (ECS), and you think that theoretically sounds like a good way to build your game, don't start by trying to build a game using ECS. Build a prototype of an ECS pattern. Something really simple and instructive of how you would do it for a larger project, a blueprint.

For example, this is the actual code I wrote when I was prototyping one of my favorite patterns, the Service Locator.

class Service:
_audio = None
_graphics = None

@staticmethod
def playermoved():
if Service._audio:
Service._audio.play_footsteps()
if Service._graphics:
Service._graphics.animate_player()

class Audio:
def play_footsteps(self):
print("Pitter Patter")

class Graphics:
def animate_player(self):
print("Look at the player move")

audio_system = Audio()
graphics_system = Graphics()

Service._audio = audio_system
Service._graphics = graphics_system

Service.playermoved()

And if you read the description, you'll see that this example doesn't really fully articulate the pattern as described. But that's okay, because the point of the code blueprint is to experiment with implementing concepts in a way that works for you.

The Baconist

(there's no bacon in this game despite the name: I originally was going to make a roguelike about stretching a really long bacon across the dungeon but it's going in a different direction now)

It can be played here: https://submarination.space/baconist132/index.html

Screenshot of one of the unfinished puzzles: https://submarination.space/baconist/puzzle.png

(move with vikeys or numpad or WASD or mouse)

This is a puzzle game where you need to solve puzzles. Right now that means you push boulders like in a sokoban because I haven't got around to implementing actual interesting mechanics yet.

Since past two weeks I've managed to lay down the most important technical foundations:

• Performance has been slightly improved (still crappy on browser but it's playable; the game can be compiled to native version that runs in a terminal and it's way better in there).
  
• Field of view now works more sensibly when you look through portals.
  
• Your character can still remember parts of a level that have been seen before (they are shaded darker)
  
• I now have a system that makes it fairly easy to design the entire dungeon (I essentially just have a giant text file that's interpreted and turned into world).
  
  My roguelike can also display animated things. I made my water look like all fancy and animated, a lot like in Brogue but I soon realized this is probably going to be a problem if I use water in puzzles and it has to stand out well from surroundings and look consistent. Sometimes boring-looking things are better. Overall my game has lots of flat colors.
  
  At this point my concerns are about designing the game mechanics themselves (as opposed to technical challenges).
  
  Pushing boulders gets boring quickly. I have some unfinished code that would add chain chomp -like enemies to the game and the puzzles would be about how to go around them or neutralize their threat. And I have a sketchbook where I threw in bunch of more ideas. My thinking is to implement wacky ideas and seeing what works. I also have a book on game design I'm going through, trying to educate myself what kind of (puzzle) game would be fun to play.
  
  I guess this is not really a roguelike. It's a puzzle game and the entire world right now is hand-crafted. There are no random elements to this game whatsoever. But I think that's fine.

Procedural generation is one of my favorite topics. From playing with early Life on my old BBC Micro to reading Short/Adams - Procedural Generation in Game Design, I find it fascinating how much you can make with guided randomness.

Nox Futura is all about procgen. It set out to be Dwarf Fortress in space, and has turned into its own thing. It does procgen on many levels of the design:

• When the world first generates, it starts with a Simplex noise heightmap of the world (and a second heightmap for humidity). It then divides up the world so a percentage is under water, calculates some tile types (forest, plain, marsh, hill, mountain, plateau) based on altitude/humidity/slope, and finally uses Marching Squares to denote coastal areas. This in turn is divided into regions via cell noise, and region biomes are derived from the most common terrain types within the biome area (along with latitude, altitude, humidity). The result is something like this and this.
  
• At that point, it randomly generates civilizations and places them on the map. Civs are generated from data files of available types, given random names, and some resources. They then basically play Civ with each other to develop the world.
  
• Once you pick a starting area, the game zooms into the original altitude noise and builds local terrain. It randomly places different rock types, soil types - and from that vegetation. The starting ship is then placed (not procedural). It gives a very Minecrafty looking world.
  
• Settlers themselves (your characters) are also procedurally generated. They get stats, a profession, 20-30 years of history. From that, game stats are derived. I quite like the result. How the settler appears is also generated: layers of voxel models are applied to one another to give an appearance that matches the generated data.
  
• If you land in settled areas, the world reflects what the civs have already built.
  
  After that, game play is player driven - so the procgen aspect is to support (or kill!) the player, rather than making new stuff (more with civs is the next step). So gravity, machines, fluid dynamics and so on. It's more physics simulation than procgen at this point.
  
  In One Knight in the Dungeon, I set out to make a more traditional roguelike. That meant procgen takes a slightly less all encompassing role, but it's still very important.
  
  
• I started out with a simple harness to test that procgen would work at all in Unreal.
  
• I quickly needed a way to turn REX Paint prefabs into map areas.
  
• I wound up needing a quick and dirty ASCII test bed for testing level designs. This shows an early attempt at making something like Nethack.
  
  Currently, I have several map design techniques in One Knight:
  
  

1. Prefab glue. This loads REX prefabs from a list, figures out where the exits are (they are marked in the map) and randomly arranges them into a big mess of pre-made level parts. It can add corridors, but the only thing procedural is how to arrange things. It will redo map chunks until the exit and entrance work, tries to have one major route through the dungeon (with side exits but minimal going back on yourself), and try to keep allocating until it has reached a target amount of XP for a level.
   
2. Nethack like, which pretty much implements the Nethack algorithm. It's not very smart otherwise.
   
3. Cellular Automota, which gives great organic-looking maps.

YARL (Yet Another RogueLike) GitHub | Scrum board | Website

This sprint goal was to create the website in Jekyll and put everything I've done so far in there (i.e. Daily scrum notes). It took me only one day to plan the sprint. I think it's good, this means more time for actual work. My estimates were rough but they were surprisingly accurate, if it weren't for tasks like "Write a Sharing Saturday post" or "Sprint planning". I didn't know beforehand how costly they are so I decided to just measure them and get some data first. That's why there is ~50% bump from 45 to 65 hrs. Initial estimates vs. time spent are very close, though. Initially I was going to commit to 3 hrs/day but it was more like 4 hrs/day, excluding Monday 19th and forth. It was hard at times, and my first days at uni were completely exhausting.

I was hoping to release HTML 5 version, but I didn't manage to. At first I had problems with adjusting Gradle version, then problems with GWT arisen. I forget to include dependencies in GWT config and add them to a Gradle config for HTML project. I somehow managed to build an example game shipped with installer, but building YARL was too hard for me. I was about to give up completely when I noticed that SquidLib installer has the GWT option as well. It looks promising, I will explore this possibility in the next sprint.

I was about to ditch the idea of uploading my Daily Scrum notes. I wanted to code my custom theme instead, but eventually I came to my senses and uploaded them. It was tough. I was going to modify the sprint goal and a part of me wishes I did. It would save me some psychical tension.

I suspect that writing Sharing Saturday posts takes me so much time because my English skills are not sufficient. I have borrowed a book, I might even open and read it. I'm thinking about tweeting, but I want to focus on other things in an upcoming sprint.

Below is a Sprint Retrospective. There are some things left from the previous sprint because they were not really applicable to this sprint.

Things I should start doing in an upcoming sprint:

• Estimate more time for refactoring.
  
• Look for a Java style guide.
  
• Read a Scrum Guide after every sprint to comprehend it a little more.
  
• Take tasks like "Write a Sharing Saturday post" and "Sprint planning" into consideration during Sprint Planning.
  
  Continue doing:
  
  
• Use Trello to measure time spent on writing Daily Scrum notes. I use it sometimes, but I need more consistency.

Pretty much any I could get my hands on. :) When I need a new demon, I usually go digging around based on what abilities I need it to have. (i.e.: If the game balance numbers call for a new Fire demon, I go looking for myths about creatures associated with fire), and I dig until I find one that sounds interesting to me. Since I'm searching based on design needs rather than by mythology, I end up with creatures from all sorts of sources. :D

This website is a good example of a source I use for such searches. It isn't 100% perfect, largely because it doesn't call out sources too well which makes it tougher than I'd like to verify how accurate it is, but I have books and other websites that can help with that.

I do also sometimes flip through those books (including my favorite, The Dictionary of Mythology ) just sort of scanning for interesting sounding myths: if I find some, I make note of them for later and consult that list when I need new demons to see if any fit what I'm looking for.

Procedural Generation in Game Design is really good. I would read chapter 26 after reading Chapter 1 through. The order of the chapter should have really been changed.

Artificial Intelligence for Games
https://www.amazon.co.uk/Artificial-Intelligence-Games-Ian-Millington/dp/0123747317
Easy python, easy to understand.

One other book that is really nice is Algorithms 4th edition if you know Java.

Not really programming books, however fighting fantasy books are really nice. Also, RPG books like D&D, Rolemaster and GURPs are good to study.

You've chosen wisely. King's book is excellent. Hunt down the accompanying study guide if you can, and you are set for life.

Although there is no need to study C from K&R, I still recommend you read it for pleasure at some point. The writing is crystal clear, and the examples are chosen wisely.

In terms of "tying it all together" I recommend this book - http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135

It covers game engines in a pretty general way, a light overview of every part and what role it plays in the whole. If you're having trouble figuring out architectural questions like what a game loop should look like, this book will help a lot imo, maybe faster than source diving in other roguelikes.


Outside of resources like that, I'd suggest just starting even simpler than a game loop. Draw a field of '.' to the console. Draw an @ on top of that. Make the @ move. One thing at a time, and your game loop will build itself.

> AI: "Artificial Intelligence for Games" by Ian Millington

My favorite is Behavioral Mathematics for Game AI, I will definitely check yours :)

I agree that books explicitly devoted to Roguelikes are rare, let alone for Roguelike Development. In fact, I only know of 3 related to either:

• Dungeon Hacks
  
• One Week Dungeons
  
• @Play: Exploring Roguelike Games
  
  That said, I imagine there are other books that are directly applicable to Rogulike Development, such as that PCG book I linked in the OP. Maybe there are some strong AI, Game Design, or even UI books that roguelike devs here have found applicable?

Divided Kingdoms

I've been very busy at work, so development time was limited this week:

• Added health bars above NPCs with their level
  
  
• Containers are now working; it is possible to add and remove items.
  
  
• More work on the item generation algorithm; items now have levels, prefixes and suffixes with stat modifiers working. I still have a ton of work ahead as I only have a few modifiers in my data files and they don't really make sense yet.
  
  
• Inventory list view now only displays categories that have at least one item
  
  
• Fixed blood particle animations after migrating to party system
  
  After reading a book on AI (Behavioral Mathematics for Game AI) and a book on emergence (Emergence in Games), I started reading Game Design Workshop; it's a great book so far. I want to read Designing Virtual Worlds next.
  
  See you next week!

Thanks! Glad they're helpful to some people, just trying to do stuff that would have been helpful to me starting off. As far as next talks:

Jason and I did chapters in this book, which came out recently: https://www.amazon.com/Procedural-Generation-Design-Tanya-Short/dp/1498799191

We also did a more academic style paper on the sultan history generation system:
http://dl.acm.org/citation.cfm?id=3110574

My next talk will probably be on map generation system in general, and maybe the sultan dungeon map generation subsystem in particular. I was thinking roguelike celebration, but it overlaps with my annunal vacation week this year. So maybe next year!

There is also a great chapter on his methods in the book Procedural Game Design.

https://www.amazon.com/Procedural-Generation-Design-Tanya-Short/dp/1498799191/ref=nodl_

I'd recommend this book, though if new to coding it may be a bit overwhelming https://www.amazon.com/Engine-Architecture-Second-Jason-Gregory/dp/1466560010/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8&psc=1&refRID=NC95XNX16602MDF2SG80

Uh... I only noticed now that you were looking at the first edition... I actually meant the second edition. But by comparing it I guess your comments on the chapters still apply, with only part of 6 being relevant.

If I had 40 bucks I would buy this right now
https://www.amazon.com/gp/aw/d/1138743313/ref=tmm_hrd_title_0?ie=UTF8&qid=&sr=

I prefer Uncle Bob's view:

> It is well known that I prefer code that has few comments. I code by the principle that good code does not require many comments. Indeed, I have often suggested that every comment represents a failure to make the code self explanatory. I have advised programmers to consider comments as a last resort.

Other times he puts it more bluntly:

>Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.

or

>"Every time you write a comment, you should grimace and feel the failure of your ability of expression."

I know it's not always practical, but I like Uncle Bob's extremely demanding perspective, because I feel it sets a really high bar and struggling to work toward it is something that stretches me.

If this is a wildly shocking view, I highly recommend picking up a copy of Uncle Bob's book Clean Code which I learned about from this IRDC talk. I saw that talk, bought the book, read it, and my views were changed. I now refactor a lot more and comment a lot less.

Uncle Bob's minimally commented code doesn't come cheap though, he spends a ton of cycles after the code works, retooling it specifically to make it readable.

Also, for the record, I ain't no Uncle Bob. Don't misunderstand me as saying I live up to his standards please!!

While 2d math is common in roguelikes, 3d math is much more rare. Chapters 1-5 on coordinate systems, and vectors apply, but chapters 7-17 do not. While familiar with matrix math, I don't find it applicable to roguelike development. The visibility systems described in chapter 16 is not as far as I can tell from the preview on amazon applicable to roguelikes. In fact I'd be more confused if I read that and then tried to use it in a roguelike.

> By any means I would say that geometry (at any level) wouldn't be enough even for a RL. But right now I plan to focus on geometry, since it seems to be the most fundamental subject and the one I lack the most.

If I had to put together a primer on roguelike math:

• Cartesian Coordinate System
  
• Euclidean Vectors
  
• Pythagorean Theorem
  
• And maybe sine cosine tangent
  
  I wouldn't start with wikipedia either. Instead https://www.khanacademy.org/math/geometry-home and https://www.khanacademy.org/math/trigonometry are a likely a decent means of starting.