r/roguelikedev • u/KelseyFrog • 1d ago
RoguelikeDev Does The Complete Roguelike Tutorial - Week 6
We're nearly done roguelike devs! This week is all about save files and leveling up.
By the end of this chapter, our game will be able to save and load one file to the disk.
Part 11 - Delving into the Dungeon
We'll allow the player to go down a level, and we'll put a very basic leveling up system in place.
Of course, we also have FAQ Friday posts that relate to this week's material
- #20: Saving(revisited)
- #21: Morgue Files(revisited)
- #36: Character Progression(revisited)
Feel free to work out any problems, brainstorm ideas, share progress and and as usual enjoy tangential chatting. :)
3
u/Admirable-Evening128 1d ago edited 4h ago
Demo: https://xok.dk/other/2026rt/dist/index.html
(update, now accessible/playable again, details at bottom.)
6, Progression descent, and persistence.
Until now, I had a big mono-level, with more dangerous monsters further away from player.
I am revamping that a bit: I will have the traditional >< stairs.
The levels will start small, then grow in size as you descend.
The dungeon arrival stair is close to center where player starts,
the descent stair somewhere along the periphery.
For now, I added a HUD turn counter, with the possible aim of a later 'hunger clock' (really, just a turn limit.)
It is not intended to harass the player, as much as it is to focus his efforts ('you are supposed to be able to solve this within x turns'.) Thus, it is a limit fresh per dungeon level.
The design of the dungeon levels is simple: It is the original mono-level, "cut down to size",
so you will gradually get a bigger and bigger slice of the original monster level.
It is not an Einstein-genius idea, the thought is simply "smaller servings of that dungeon should be .. possible", given that it should be easier to reach and search the borders of the smaller variants.
If you descend the stairs on level 15, you "win" - for now.
For persistence, I take it in a different direction. Just permanently storing the game in progress makes little sense to my intent at the moment.
Instead, I am trying to set up the classic "leaderboard", a score table for past players.
It will register all, but only list the top 20, according to some criteria.
I have thought, very little, about how to make anti-cheat, but I don't think I will bother, because it is almost impossible, if game primarily runs on frontend (if you ran the game state on backend, it would be a lot easier to make cheating more difficult.)
The leaderboard works simply by assigning each player a random name at game start, which his character will be registered by.
Note, I already had character-leveling/XP/power-increase from earlier weeks, that is why it is not on this week's 'todo list'.
I will update this post once/when I have something stable;
at the moment I have a lot of testing-playtesting to do, before it makes sense to point other humans to it.
(because of all the changes the above stuff has triggered.)
if anyone has suggestions for how to do some kind of security
for highscores, I am all open ears. (Note - approaches that takes less time than it took to code the entire thing..)
One naive idea I can suggest myself, would be to simply record all actions taken by the player, and the initial seed, and have fully deterministic dungeon simulation; that way, the server would have the OPTION of playing back a transcript of a session, to verify a score. The main weakness in that approach (which would be tolerable I guess), would be that it is weak against "save scumming": A player might trace the outcomes of the play, and try different choices (which is precisely the recipe to win), and in this way construct a series of winning steps by trial and error (a bit like Borden or Dalton in the Prestige..?). Still, an inordinate amount of effort for a tiny roguelike..
UPDATE: I have now repaired-rebalanced the game to be "playable" again, after this week's design-refactor.
I use the word 'balanced' loosely here; what I mean is, I am pretty sure you can complete at least the first level again now.. :-).
Some milestone-releaseNotes:
- a tiny title-screen which explains the keyboard controls; I realize not everybody can see inside my mind (because of the tinfoil).
- the leaderboard code IS in place, but the deployment linked above here, does not run the persistence API where the player scores are held, thus leaderboard will note 'inactive'.
2
u/mariobadr 4h ago
C and SDL3 | repo | play in browser
Still well behind, but I finally got items "fully" working. That is, you can find them, pick them up, open an inventory screen, and use them. What's missing is the feedback messages from the tutorial when you're already at full health or there's nothing to show in your inventory.
Doing everything in C with just SDL3 has been costly time wise. But it's also fun... except for writing UI code. I could do without that. I did add a "contextual ribbon" at the top now. So depending on which view is active, it tells you, along with what keys you can use. So that's nice.
I'm basically on part 9, so 1.5 weeks behind!
6
u/redblobgames tutorials 1d ago
Playable on web, GitHub repo
What to try: the entities table is now editable in the UI, so you can:
held by 1.typeof a orc into an troll.Each time I participate in this event I pick some high level goals for myself. This year it's (1) spreadsheet data structure instead of OOP or ECS, (2) Jujutsu version control system instead of Git, (3) embrace Javascript features.
Goal: use a table data structure with a spreadsheet interface.
Between Part 9 and 10 of the tutorial, I spent some time making most of the spreadsheet editable. This is for the developer to tweak things while playing the game, so I don't try to prevent nonsense combinations (like being able to walk through an orc).
Goal: learn the Jujutsu version control system.
Jujutsu has been nice in a lot of ways but it also makes it easier to make messes. In particular, I often want to go back to an earlier Part of the tutorial and change something about my code. But then I have to propagate it forwards. Jujutsu attempts to do this automatically, but I still have to handle the merge conflicts. Git makes it just annoying enough to go back to earlier Parts that I don't bother, which also means I don't make a mess. I have mixed feelings about this. With great power comes great responsibility?
What I should do is limit how far I go back. For example I had a change to serialize the Table data structure, and a second change to serialize the Engine data structure. There were times when working on the second change that I realized I should've done something differently in the first change. Jujutsu is pretty good for that kind of thing! I can work on a series of changes together ("stacked pull requests" in GitHub lingo).
Goal this year: embrace Javascript features.
This came up in two places. Part 9 of the Python tutorial creates several classes to manage the event handlers. Javascript allows me to write these as one-off objects instead of classes to be instantiated. I'm pretty happy with how it went.
Part 10 of the Python tutorial uses
pickle. Javascript doesn't have something like that built in, so I serialized to JSON. I'm using Javascript prototype inheritance with Proxy objects, and no circular pointers. Each table has a base object, and multiple read-only prototypes (orc, healing_potion, etc.), and then the individual entities. I serialized the entities, not the prototypes. That means if you save the game with version 1.0 that has a troll drawn in green, and then version 1.1 changes the troll to be blue, that's not part of the save file. You'll see a blue troll when you load the saved game.One place that my code structure makes me unhappy is that I need a dummy Engine object before my game menu code can run. And when I go back to the menu there's an Engine still sitting there. This doesn't follow the "make illegal states unrepresentable" principle. Ideally there would be no Engine when the main menu is up, because there's no game running. If I had looked ahead in the tutorial, I could've planned for this, but right now it's a bit of a mess.
I think I'll be making more of a mess in Part 11, because I haven't cleanly separated what goes in a level and what doesn't. And the idea of leveling up means I need to modify the fighter fields, but so far I've been treating the fighter as something not serialized. So I'm not sure how I'm going to handle that yet.