jarcane/handhrl

A simple roguelike based on the Hulks and Horrors tabletop RPG written with Python 2.7 and libtcod

handhrl's Issues

Add Linux binaries

I'd like to add Linux binaries at some point in the future. This will mean learning cx_freeze and adding the Linux libraries to the repo, but hopefully the experience won't be too painful.

Food

The hunt for comestibles to survive is an important part of the classic Roguelike experience, and one I feel is appropriate to H&H as well, especially considering the play scenario of handhRL.

+1/+2 etc. bonused gear

The current item list is pretty limited, and I don't want to really add much onto it at this point until we've got the systems rebuilt in 0.3.

However, I think we can implement a simple change to the current weapon/armor/shield options by generating a quick random bonus for the item. We can weight this a bit, either using the random_choice functions or just setting up the die roll properly, but some +1 or +2 gear might come in handy and should be an easy add to the current code.

Traps

Let's make traps!

These will be placeable objects I think, but rather than being usable, they should be hidden, and trigger automatically when stepped on.

Hiding them should be a simple matter of defaulting their character to ' ' until discovered, but actually triggering them will probably require some kind of object check when the player moves.

Treasure/credits?

This is a decision that needs to be made.

I have left out valuables and non-usable artifacts from the loot lists so far because it felt out of keeping with the scenario we've been presenting (a nameless Ensign lost on a hostile world).

However, in the books, treasure is extremely important as the recovery of cash value is a major source of XP (probably the biggest).

We could easily make them just as auto-use items that add to XP and possibly score, it's just a question of whether that fits the direction I want to go with it.

More terminal text

Right now there's just a couple placeholder messages, but we can expand this to even more.

It might be worth considering moving this data to a plaintext file or external database because it could become quite large.

Help screen needed

I would like to add a help screen, to provide some in-game documentation. A simple list of the keys available for use called through show_text_log should be sufficient for now, though if we start getting more complicated a new screen may be needed.

The character status screen is terrible

At the moment, the character status box is a single line of concatenated gobbledygook that is so long that Python starts complaining if I add anything to it.

It needs to be its own function, and it would be nice if it included more information like base vs. current stats, and bonus from equipment.

Light items and variable FOV

It would be cool if, rather than the current system, FOV was variable based on an equipped light-source.

we could then have items that added a bonus to FOV range, stuff like torches, lamps, etc.

Experienced a crash with the Tesla Arc Device.

Will need further testing to replicate, but I ran into a complete crash while using the Tesla device during a recent game.

Should look into fixing this ASAP.

More monsters!

I would like to expand the monster list at least far enough to include one new monster from each level on the H&H underground encounter tables.

The rule of thumb I'm going by is to treat the H&H table as linked to dungeon_level / 2, rounded down. felixes and nagahides should be the lvls 1 and 2 options, but this leaves 3-6 open.

High Score system

I'd like to have some kind of score table. This is something that I've always loved seeing in Roguelikes, and I think it shouldn't be too hard to accomplish here.

I'm thinking a basic formula that factors kills, XP or level gained, and dungeon level gained. We can then report the score on player death (or win), and keep that score in a scorefile of some kind.

An additional menu option to display the scores wouldn't go amiss either.

Identifying items.

This might be tricky to implement, but it might be interesting to require at least the exotic weapons and devices to be identified somehow, possibly with a future science device.

Basic H&H combat stats

Eventually, I will want to implement a fuller version of the H&H rules, but for now, I think a basic subset of To-Hit, Str bonus, and random damage should be sufficient.

For now, we'll also assume a Soldier player, as I think the progression will be easiest to implement.

The <armor> cannot be used.

Noticing an odd behavior with armor equipment.

The message log spits out a 'The (armor.name) cannot be used' when equipping or dequipping it.

It goes through normally, but still throws the error. Something to do with the object properties not being created right maybe?

Monster AI bug

The current BasicMonster AI is pretty basic. Not only do they have no minds of their own until their within FOV, but they have this peculiar tendency to get stuck on corners.

For instance, a monster will only chase you out of a room if it is standing in a direct horizontal or vertical path to the exit tile. Otherwise they'll simply get stuck on either side of the door and stay there. (not necessarily a tactically poor decision, but also kinda counter to some behavior types, or to usual roguelike expectations.) It's also why they tend to attack you from a diagonal instead of head on.

libtcod has some built in pathfinding routines. It's possible we may be able to use these to readily come up with a more intelligent routine.

Redesign object generation

The existing monster/item generation system is terrible.

It seems elegant, at first, until you realize what it's actually doing, and that's when you notice it's actually terrible.
All it's actually doing is creating a single table, with flat percentages, and just locking access to entries based on dungeon level. This means that the entire game's monster or item list still has to add up to 100% chance, not just the table for any given level.

If an entry is locked, it just returns None, which short circuits the num_monsters/num_items tables too, because regardless of how many monsters are supposed to be there, if the table entry rolled isn't available at this level, it just doesn't show up. You can see this effect already quite clearly with the items list, and it's only going to get worse from here.

We need a more sensible system, ideally one more clearly patterned after the H&H rules. Something that can still take dungeon level as an argument, but then spit out a monster/item based on our (dungon_level / 2 = encounter_level) rule of thumb. If we do it right, we can probably just use the table right out of the book for the chances.

Create die roller function

In order to begin adapting the rules from the game into handhRL, we're going to need a function to handle die rolls.

libtcod has a built in randomizer, and it apparently greatly prefers you use that randomizer over python random for any calls to the function.

Function needs to take two arguments, and an optional third, for the H&H form: x_D_y_H_z.

Find alternative to Shelve

Shelve seems like a very nice way to handle our saves and scorefiles, and, for the moment, it is.

However, cx_Freeze hates Shelve, because if the weird way Shelve handles the dbm dependencies. It hates it so much.

This is a problem, because cx_freeze is the only way to make a packaged binary on Linux. It also makes much faster Windows executables than py2exe. Shelve files also aren't guaranteed to be compatible across platforms.

So, if we want to switch to cx_freeze, shelve has to go, and has to be replaced with something that will play nice with the cx_freeze.

New item table system

It's about time we broke up the items by category from here. There is a lot of possible loot in H&H's rules, and better results will probably be had by breaking things up into sub.functions for different item types like weapons, armor, etc.

Corpse file

Once the player names are in place, I would love to have a corpse file, and a subsequent feature in the place_objects routine that places the occasional former player corpse on the game map. It's one of my favorite little nods of persistence in old school roguelikes.

New monster table system

The monster table is officially past unwieldy. A new solution really needs to be found here because as it is it's just unworkable to continue adding more monsters to the lists.

Player name.

Currently, the player is initialized with a default name of 'player'.

Now that we have a high score list that takes a name, it would be nice if players could actually create their name.

Fixed-with score string

The bulk of the current score entry string is probably unavoidably even, but as there's a practical ceiling to score, it might be nice if at least that section of the entry lined up more neatly.

The simplest way to do this would seem to just be padding out the score string to a set width. The current score calculation should max out around 7 digits given expected available XP values, but 8 is probably wise for safety's sake.

Use hit dice derivations for monster stats?

In the H&H tabletop game, monster stats are mostly derived through a series of formulas and tables directly from the monster's hit dice, both number and type.

Some of the monsters do deviate from it slightly, but on the whole they largely obey it, and the discrepancies could potentially be ignored for the sake of streamlining the code. Monsters could thus be generated from merely two values, the number and type of dice.

Look under player automatically?

It's been requested that I look into seeing if we can simply display the name of any objects under the player (on the same tile) automatically rather than relying on the mouseover.

This is a good idea, and I think I should do it.

Slow down the inventory screen

At the moment, when hitting the inventory screen it is very easy to accidentally close it again.

It seems to be that the key repeat delay is fast enough that if you hold the 'i' key for just a smidge too long it just sends an 'i' choice to menu() right off and closes it again, possibly even using the item in slot 'i' whether the player wanted to or not!

Switch to formatted strings

The current code makes heavy use of concatenation operations to build strings for various display routines.

This works, but has a couple issues:

1. codelines get really long, especially if we follow style (proper spacing and so forth)
2. said codelines can't as easily be broken up
3. the text of the strings can't really be changed except by rewriting the line or through very awkward manual insertion methods.

Python has a very powerful .format() method that can even inject arguments into strings. Switching to it in more places would clean up the code and also allow creation of routines to randomize the contents of the strings.

For instance, instead of combat messages being long concatenation statements, simply formatting them with {attacker} and {defender} arguments would mean we could easily write out all kinds of variant lines and select them randomly.

Needs an endgame

Currently, the game will simple generate new levels endlessly until the player dies (or just quits and gets bored).

Need to establish a target dungeon level, and then be able to call some kind of ending sequence to celebrate it.

Guns should be ranged

Weapons are now done, though we need to implement an additional class that allows for ranged attacks when equipped with a gun.

I think we can add an additional sub function or class to the Equipment class that will use get_target_under_mouse to aim at a thing and shoot it. We should also make sure this passes the turn so that the player can't just keep shooting until it's dead.

Possibly we could attach an ammo counter to this new class too, initialized with the item on generation.

Remove place-holder HP bonus

Stuck a massive starting HP bonus in the new player call so I could test some things, and completely forgot to fix it before the release.

Whoops.

Oh well, the current build was pretty damn tough without it, and this will let people see more of the new stuff.

True combat system

The current combat system is basically all flat damages assigned mostly by constant or pre-set values.

This will all need to be replaced with a proper attack roll + damage roll system in accordance with H&H rules.

Multi-tools

This could be a better way to replicate the Science powers from the book, as reusable, findable items with random spells inside.

We could probably also do some kind of 'psi-helmet' or other technobabble doodad for the psyker powers.

Redesign menu() to use show_text_log?

With such a cool screen available, it feels like actually using it more would be good, though maybe keeping menu() an overlay is more mechanically useful (the player stays aware of the scene while inspecting it).

Not certain yet. Leaving this unattached to milestone for now.

Room numbers don't remain passable

Seems to be an issue with the room "numbers" not staying blocks=False. Possibly a contradiction with the simplistic handling in player_move_or_attack().

Really like the room numbers aesthetically, so leaving it for now, hoping to sort it out in future commits.

Permanent usable map objects.

The game seems pretty survivable still, despite weak healing, partly due to the between level healing and the slight overpoweredness of the player.

I think allowing for some sort of camping might still be a good feature to add, however. Current idea is to avert usual roguelike practice of healing on skipped turns and instead have 'campsite' objects that can be used to heal the usual rest amount (1d6 + CON bonus in the tabletop rules).

Esc behavior still unsatisfactory.

At the moment, hitting Esc does three things:

1. automatically saves to 'savegame'
2. prints a msgbox telling you it has
3. quits game to main menu

I don't really like this behavior. It feels inelegant, obtuse, and a bit slow. Perhaps an actual prompt menu (save, or not) at least would improve things. This might also allow this new in-game menu to be detached in apparent function from the main startup menu, which due to the way the code is written as is, is probably an easier fix.

Alternately, we keep the main_menu as the only menu, remove #2 above, and clarify the function and/or behavior of main_menu to be a more traditional in-game menu.

Decisions decisions.

Begin refactoring and global cleanup

It's time to start breaking this thing up a bit before it gets any more unwieldy.

This will probably entail fixing a lot of global calls and revising arguments so that we can more safely pass code around from one chunk to the other, but some of the existing code can already be refactored as is.

Tentative organizational scheme to follow.

Display XP and player level on panel

As simple as that. It would be cool if there was an XP bar and a player level display on the main panel.

Monster zoos!

Think it could be a 'fun' and traditional surprise encounter to have rooms that spawn simply stuffed full of monsters.

These are always one of my favorite surprise challenges in a game, and really requires the player to pull out all their tactical tricks.