hunterz / hzmoria Goto Github PK

Working on a first cleanup pass of this file. It's huge!

Probably want to break it up or something.

Also, there are apparently some hacks/warts to look into:

• compact_monsters() has a note saying hack_monptr is a "horrible hack" to support being called from deep within creatures()
• place_win_monster() simply calls abort() if it can't do its job (basically an assert).
  • Wouldn't it be better to force deletion of another monster? Maybe weakest, or farthest away, or something? Or even give the player some flavor text saying it consumed another monster or something.

I prototyped sound support way back in the 1990s using a couple of WAV files extracted from Warcraft 1 or 2, and it was pretty fun.

Should revisit cross-platform sound support somehow... I think it would make the game more exciting to play, stream, etc.

One option would be just echoing in-game messages to a log file and having an external app monitor it - this is how Dwarf Fortress sound mods work.

A more sophisticated method would probably be to fire events to a separate thread that reacts by playing sounds.

The game keeps complaining about an incompatible scores file. Probably need to clean up the code around that. Maybe make it more aggressive about overwriting and/or institute backwards compatibility tolerance like it has for loading save files.

Also probably need to generate a new default scores file, or (better yet) make the game generate one on the fly when needed.

Curses libraries aren't a good path to a common user experience anymore, so port all the I/O code to BearLibTerminal.

II don't want to write a curses wrapper for BearLibTerminal, so this means replacing all of the curses calls. This is a good thing, because it will help eliminate more environment-specific code variations.

Curses, libtcod, or other frontend support can be (re)added later, but creating an I/O abstraction layer at this time would be overengineering things. Let's go to BearLibTerminal first, then see where that leaves us.

Looking at save.c turned up a lot of notes:

• update to 64-bit timestamps for Y2K38?
  • NOTE: this will break save compatibility
  • explicitly casting to 32-bits for now
• resolve externs.h include order concern
  • see legacy code comments
  • hopefully #2 / #5 will clear the way
• move MS-DOS configurable wall/floor symbol feature out of core code and into the I/O layer, then clean up save file handling of it (the fact that it leaked this deep is a code smell!)
• (DONE) define constants for settings flags (variable 'l') to help keep the save and load code in sync
• (WIP) get rid of save.c file globals
  • it's better to just pass stuff around than to share global state
  • bundle them in a struct if it's convenient for passing around
  • file_ptr and xor_byte fixed. from_savefile and start_time need more thought
• get rid of static function prototypes
  • define them in the order used for now?
  • see #3 for longer-term thoughts
• fix casting of data
  • signed versus unsigned int's, etc.
  • change vars to unsigned where possible?
  • implement proper signed read/write functions?
• document save file format somewhere?
  • at least add more comments to the code if nothing else
  • it's probably not documented in a text file to discourage cheating (also XORs data and such for this reason)
• (DONE) remove DEBUG macro?
• (WIP) I don't like the while() loop in save_char().
  • Seems like it could get caught forever if _save_char() goes awry
  • Not as bad now that player prompts are better
• (DONE) I don't like the logic in save_char() either
  • Especially the delete via unlink() seems problematic
  • People can just tab out and delete/chmod a file now
  • Maybe just give the player an option to pick a different name or exit?

Tried to clean up file management configuration a bit, but there's still a split between DOS and *nix that needs to be resolved.

Thoughts on how release files might ideally be handled for modern Windows/Mac/Linux ports:

• hours file should probably just go away, as it's probably a multi-user support feature for sysadmins
• Probably want to support portable installs on all OSes
  • In this case, the user would unpack all files into a folder tree that they control (write access etc.), and the game would just look for them in the binary's directory.
• Might also be nice to support "proper" installs as well though:
  • Common:
    • Save and scores files should probably go in a user folder, except maybe in a portable install?
    • Support user folder override of MORIA.CNF config file?
  • Windows:
    • Default MORIA.CNF, .hlp/news/license/docs, etc. could probably go in the install directory, next to the game binary.
    • Provide a proper installer (NSIS/InnoSetup/WiX)?
  • Mac:
    • Binary goes in an app bundle?
    • Default MORIA.CNF, .hlp/news files, etc. could maybe go the app bundle too?
    • License and docs are TBD/TODO (how to expose those to the user?).
  • Linux:
    • Binary would probably install to /usr/local/bin or similar?
    • Default MORIA.CNF, .hlp/news/license/docs, etc. would probably go in /usr/share/hzmoria and/or /usr/local/etc?

This sounds too complicated for an initial cut. Maybe just go with a portable install at first, and refactor to properly installable solutions later? Expecting the user to unpack to and run from a user folder containing all files is probably reasonable, but needs to be tested on all 3 OSes (especially Mac) for viability.

Player gender is an 8-bit value that is currently treated as a boolean. This is boring.

Looks like it only has the following effects:

• Non-male PCs start with 50 more gold.
• PC height/weight are random rolls over male/female ranges.
• Character sheet display.
• Winner title (king/queen).

Initial thought - add a nonbinary third option:

• Displayed as 'N'/"Nonbinary".
• Roll over the widest ranges possible for height/weight, or at least randomly choose which table or table pair to use.
• Winner title is "Sovereign" or "Monarch".
• Remove the non-male gold bonus, because there's already a charisma bonus.
• Modify all usages as needed to ensure everything is properly supported / nothing breaks.

Another option would be to prompt the character for gender and winner title, but I'm not sure how to handle height/weight for this design.

Lots of strcpy() going on... May be worth making a wrapper for strncpy() that puts a null terminator at the end, and then calling that from everywhere - preferably using constants that control/document/standardize destination (and possibly source?) buffer sizes to the extent practical.

This may be somewhat OBE if/when going to C++, except that limits might still need to be imposed for screen/file I/O.

UMoria has a number of features that probably aren't relevant to HZMoria, which targets modern desktop computer environments. These should probably be removed to help keep the codebase as small and clean as possible:

• No need for system-level scores file
• Hours file concept is probably obsolete
• Any file locking/versioning type stuff can probably go away, especially if it's environment specific
• File/user permissions (setuid/getuid/username/chmod/etc.) stuff should probably go away

The UMoria codebase is rather messy, with very few headers, source files mixing internal and external functions, code files named "miscXYZ.c" etc.

Should maybe consider breaking the codebase up into subdirectories, possibly even building those into separate static libraries that get linked together at the end. This might help get better code/design separation between various areas of functionality. Maybe have a main header and source file for each module, backed up by headers and/or source files that are internal to that module?

As for the "misc" stuff: See if there are any themes that it can be sorted into, because "misc" is incredibly nondescript, and encourages chaos.

There's a bunch of dead code in the codebase:

• Commented / #ifdef'd out stuff
• Porting hacks/variations for platforms I no longer want to support
• Unused macros/methods/variables?

Also need to get down to one common implementation that supports Windows, Mac, and Linux, with no/minimal macrobatics. This means leaning on BearLibTerminal for I/O as much as possible, and trying to stick to ANSI C as much as possible for everything else (file I/O etc.).

Some stuff in death.c that I need to remember to clean up:

• Implements a custom flock() for some reason, that doesn't get used by the MSDOS port. Try to make the POSIX one work, or just get rid of it? Does this fall under #5?
• display_scores() prints ALL scores, 20 at a time. Consider just maintaining a top 20?
• Duplicate character checking is currently unix-only, and save.c (see #6) support seems...odd. Remove?
• The whole scoring system seems like a funny holdover from the 1980s. Might be worth considering removing it altogether if/when serious gameplay changes are made, or at least thinking about how accurate a reflection it is of progress towards the endgame.

Added support for a proper bool type, but there's a lot of cleanup that should occur to take advantage of this:

• Convert local and global variables to bool as appropriate.
• Clean up the code to assign/compare true/false (if anything) instead of numerical values.
• Add a specific function to save.c for writing/reading bool types to/from save files, in order to avoid having to do a dance to ensure good data.