a3qz / hag Goto Github PK

The up ladder from the starting room should not be useable - that is, it should not change which floor you are on when you use it.

Floor currently is 50, but we can play around with that.

Probably increase every time you trip

Based on turn numbers and floor, "incentivize" the player not to hang around too long.

Right now it is easy to get lost. I propose a few solutions:

1. A compass that tells you roughly where either the next ladder or the previous ladder is. This might be something you have to find, similar to the Legend of Zelda.
2. A breadcrumb system, where you can drop, a perhaps limited number of, breadcrumbs on the ground to see where you have already been.
3. A landmark system, where some rooms and such are marked with something to distinguish them.
4. A coordinate reference, even something like 20 paces east, 40 north from the starting ladder, would help.

Correct plurals should be used!

There are many pieces of dialog throughout the code that should be moved to the flavortext module. In addition to keeping things organized, it also makes potential translation easier if anyone eventually ever cares about that.

Right now you have no idea whether a potion is good or bad. This makes the game stressful.

I was thinking we could have a system that tells you, with some probability, whether something good or bad will happen if you drink the potion.

Right now all of the keys are defined inside main.c. It is probably better to have a separate header that defines each of the controls.

While doing so, the controls could be cleaned up a little. Namely, the debugging cheat key 'c' should probably be removed, as well as the 't' command that is commented out. Additionally, I'm not sure the fallthrough attribute is necessary with the current warning flags, nor what the best practice is surrounding this.

Because it doesn't if you malloc a string and call action_add on it, we will have a memory leak. If we do a global string then changing it after calling action_add will change it in both places.

Right now many of the elements of RNG are hardcoded. I suggest a new RNG module, perhaps
rng.c and rng.h.

There should be the following functions, at least:

int rng_rand(int max); //returns a random number in the range [0, max]
int rng_roll(int droprate); //returns 1 with probability 1/droprate, else 0

rng_rand should be sure to account for the limitations of rand in C. Namely, if the argument to rng_rand is greater than RAND_MAX but less than INT_MAX, it should piece together the result from multiple rand calls.

Further, rng_rand and rng_roll should both use rejection sampling to ensure that the randomness is uniform across their respective ranges. That is, rng_rand(max) should return every number in [0, max] with equal probability, and rng_roll(droprate) should always yield 1 with probability 1/droprate in the long run.

Finally, rng.h should define the constants for various probabilities.

Sometimes the player can enter a floor on something that is not a ladder. The cause of this is unknown.

Might be other things as well but couldnt test

Personally, I would like to see the code be GPLv3. Permission, @a3qz and @dontworrybhappy?

There is now a flavortext module that is meant to tell the story as you descend the floors of the dungeon. However, at the moment it is lame af. Anyone should feel free the give the game a better story.

tsk tsk

if you do not press one of the valid keys the program aborts

We are getting to the point that there are many source files all in the same directory. This looks daunting and a bit cluttered. Is there any sensible way to organize the source files into folders?

Something like 20 or 50 would make me happy - I just got set at 2, and the game is unplayable

I landed a critical blow of 0, this doesn't make sense and shouldn't happen.

A nice touch would be a demo system where players could choose to save a run of the game. This would be easy to produce as a binary file containing only the initial seed value as well as every keystroke made during the game. This file would be compact (limited to roughly 100KB because of the maximum floor tick count) and actually gives an easy way to save game progress.

I believe this is due to the enemy stack code - when I tried just using enemy_at for it it froze for me all the time.

Sometimes enemies will disappear if I move diagonally with them a few spaces away. Not sure if this is just on my end or not.

On my specific setup (using WSL and the Windows Console), the colors are changed after exiting the game (note the brighter green and white in the last image):

I can think of two possible solutions:

1. Saving the color values before calling init_color in colors.c, and restoring them on exit.
2. Not using init_color at all, instead leaving the colors up to the player's terminal settings.

Also, I noticed the rat in the middle image is white, even though it's set to COLORS_RED in the code:

I suspect the A_BOLD is somehow responsible (maybe causing it to use a different color value?).

I'd be more than happy to make a pull request implementing whichever solution is deemed more preferable. I'm partial to option 2, since it would probably fix the enemy color bug, while also allowing players to customize their colors if they find the current ones undesirable (e.g. due to color blindness).

Due to the nature of the genre, hag depends on RNG. This, however, makes testing hag difficult. It might be cool to be able to pass a flag for a seed for the RNG, either as a command line argument or possibly as an environmental variable. Even something simple like checking if a certain environmental variable is set, and if so, seed the RNG with a known value would be great for being able to write tests for the game.

As a downside, such a move might be controversial in the speed running community.

A minimap is a bit of a stretch for us here, but I think something like a button you could press to move around just the camera instead of the character would be nice (not impacting fov, but letting you see the layout of past rooms and hallways), now that we have breadcrumbs/exploration.

A sense of spacial awareness is somewhat missing in gameplay, and i think this might help.

Right now, it is not fun to get a floor with a bunch of long hallways with nothing going on in them - if we increased the clustering of the rooms, this would improve

Right now the potential luck debuff is a little too much - if you get it after floor 2 you are very likely to have your run ruined. Simple solutions are to just lower the scale at which luck debuffs. I'm worried, however, that that might take away the danger of potions, as no other debuff is nearly as bad late into a run.

My suggestion, then, is that luck potions always be spawned in pairs with equal and opposite effects. That is, we should remove luck potions from their current spawning mechanism, and then roll for a number of luck potion pairs to spawn, with each pair consisting of one potion of +x luck and the other having -x luck. This would keep the danger of drinking a luck debuff, as you will then need to find the luck buff potion to counteract it, while still making the run reasonably salvageable.

I'm not sure how #69 would play into this. Perhaps luck potions would always give no definitive answer?

Just started checking out hag, looks like a fun game. I've found myself referring to the README quite often to figure out the commands used for the game. I thought it might be a good idea to have an optional cmdline arg to show controls for newer players. I was originally thinking that a good place for this might be under the stats in the right side panel, but I think that might get too cluttered. Another option might be to not have the controls passed as an argument but to instead have maybe ESC bound to toggling a popup with the controls listed.

Lmk what you think, and if it's something you might want implemented, I'll take a stab at it.

Either we should introduce more randomness, such as hits/misses, variable attack damage, or nerf kobolds.

The "climb up the first floor" bug was actually just a trick to warp to the end of floor 1 - see this line.

Personally, at this point changing it would probably upset the speedrunners.

I question a lot of the design decisions here. Why is the enemy rulebook loaded in like it is? And why does enemy_add take in the list of attributes, rather than copying them from the rulebook, and then scaled according to the floor scaling rules? Also a lot of the logic seems scattered about - perhaps some wires should be tugged around.

The readme is missing how to drink potions, and it has a few typos. Also, we're not in undergrad anymore, so we can probably ditch the stuff about history, and maybe cheese up the backstory some more.