(Part 2) Top products from r/roguelikedev

Jump to the top 20

We found 10 product mentions on r/roguelikedev. We ranked the 30 resulting products by number of redditors who mentioned them. Here are the products ranked 21-40. You can also go back to the previous section.

Next page

Top comments that mention products on r/roguelikedev:

u/noeda · 9 pointsr/roguelikedev

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.
u/izdwuut · 5 pointsr/roguelikedev

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.
u/FerretDev · 2 pointsr/roguelikedev

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.

u/blindluke · 4 pointsr/roguelikedev

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.

u/Bozar42 · 9 pointsr/roguelikedev

Fungus Cave

Github repository, screenshot.

I'd like to share two things this week. First, I want to expand my C# toolkit, so I searched and purchased two books:

  • C# 7.0 in a Nutshell
  • Programming WPF

    I haven't read WPF yet. As for Nutshell, both the price and content is amazing.

    Second, I designed and implemented a field of view algorithm. It has following features:

  • It is not so complicated as recursive shadow casting.
  • Walls do not block LOS, but they make grids which are farther away from the observer darker.
  • You can easily add more obstacles in addition to walls and light sources.

    FOV is processed by three classes:

  • FieldOfView creates a 2D array. Each grid in the array can be of one of three status: Unknown, Visited and InSight. When drawing FOV, the first step is turning all InSight grids to Visited.
  • RenderSprite is the last step in drawing FOV. Every sprite checks its position in the observer's FOV status array and changes color accordingly: white for InSight, grey for Visited, and black for Unknown.
  • FOVRhombus reads observer's position as input and changes the FOV status array.

    distanceBoard:

    > 3 3 3 3 | 3 4 4 4

    > 2 2 2 3 | 2 2 # 4

    > 1 1 2 3 | 1 1 2 4

    > x 1 2 3 | x 1 2 3

    FOVRhombus creates another 2D array called distanceBoard. The algorithm changes FOV status in three steps:

  • Starting from observer's position, traverse the whole distanceBoard array and calculate the distance between observer and each grid. If the grid is a wall, push the position into a wallStack.
  • For each wall in the wallStack, check surrounding grids in a rhombus shape. If distance(grid, observer) is greater than distance(wall, observer), increases the grid's distance by 1 (or any positive number you like.)
  • For each grid in the distanceBoard, if the value is less than or equals to observer's max sight range, change the corresponding grid in FOV status array to InSight.

    Multiple walls cannot make the same grid even darker. If there are multiple obstacles that cast shadow, only the darkest shadow takes effect. If there are light sources, just reduce the distance.
u/FAHall · 8 pointsr/roguelikedev

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?
u/roguecastergames · 7 pointsr/roguelikedev

Divided Kingdoms

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

u/savagehill · 16 pointsr/roguelikedev

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!!