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.

Chronoweaver

Slow progress this week on my first-person Dungeon Crawler RPG since I was under the weather, but key decisions were made:

• I've officially decided to reduce the scope of the game and first ship it as a roguelike. It will remain a 3D first-person Dungeon Crawler with grid-based movement and turn-based combat, but I am designing it with permadeath in mind. I still haven't decided if anything will persist between deaths or if I want a progression metagame (e.g. the Academy in Dungeonmans).
  
• The full RPG game will become an expansion or sequel to the roguelike. I want to focus on creating a really compelling dungeon crawling experience in the first game without getting distracted with a full campaign setting, multiple cities & villages, NPCs, story arcs, quests and such. The scope was getting out of hand and focusing on a roguelike is the better answer for now.
  
• I finally have a name for my game! The "series" is now known as Chronoweaver. I even bought the domain for it. :D The first roguelike game will most likely include "Search for the Soulstone" as a subtitle.
  
• Why "Chrono"? Because I'm building the series around a special time-based magic mechanic. The goal of the roguelike will be to seek this special "soulstone" that is imbued with chronoweaving magic (i.e. time magic). In the RPG sequel, you will start the game with this soulstone (I'm not spoiling the specifics) which will explain how you are able to "respawn" after death. This was important to me to explain why the roguelike has permadeath and the RPG won't have it.
  
• Now that I have a name, I couldn't resist the urge to design a placeholder logo for Chronoweaver, and update my main menu screen. You can see an updated screenshot here.
  
• While Chronoweaver will remain a 3D first-person dungeon crawler on PC, console & mobile, I am sticking with my decision to ship a pure text-based version for chat clients (e.g. Skype, Facebook Messenger, etc.) and a voice-only version for Alexa / Cortana. I also started researching 2D libraries for C# since I'm toying with the idea of also shipping a top-down version with 2D tiles or even ASCII graphics (for the hardcore fans out there).
  
• The rest of my week has been spent in research since I was too tired & unwell at night to code. I'm not an expert on roguelikes so I need to ramp-up if I'm to build a good one. I watched about 9 talks from Roguelike Celebration, a couple more from GDC, played more Dungeonmans, dabbled with a few others, and I'm about a quarter through the book Dungeon Hacks by David Craddock. I really recommend that book if you haven't read it.
  
• See you on Discord in the roguelikedev channel!

I suggest C++ because once you master (novice) C++, you will be able to tackle any language with ease.

Once you have learned C++ & are comfortable with OOP, Try SFML GAME DEVELOPMENT if you feel you have made it to novice. It isnt for total newbies, but is still for novices.

It teaches almost everything, even multithreading & multiplayer. All in C++, using SFML. Has a Full project. Great engine by the end of it which you can use for a roguelike or anything.

Very thorough book. If that is too much, read it after an introduction to C++.

Helped me go from C++ Newbie to C++ Novice in a single day. Awesome to bookmark for later.

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.

Curse of Yendor

The Steam Greenlight has launched!

Thanks to some great feedback on the October 22nd "Feedback Friday" right here on RLD, I have managed to polish up Curse of Yendor and get it in front of the public. The steam public.

And the comments are great (for the most part, as anyone familiar with steam will understand).

Please take a minute to add your voice, and make this awesome Roguelike available on Steam.

Curse of Yendor is a classical roguelike with modern interface, focused on tactical combat, terrain deformation, and mini-quests.

It's available on itch.io , Google Play , and The Amazon App Store .

I now have a working Mac build, and Linux is next :D

Thanks for reading!

Bob

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

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

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_