Release...I guess? The end? Maybe...?

OK, I supposedly released this.  Admittedly, this was because of a combination of getting tired of working on it and frustration with strange bugs that would appear when updating.  Its hard even to say what features and improvements have been made, due to several rounds of additions fallowed by reverting everything when a bug that I couldn't seem to fix any other way showed up.  So no detailed log of features added unfortunately.  Could more be added?  Well, its not impossible I guess -- it wouldn't be the first game to be chaotically developed and then receive major updates after being officially release.  Then, maybe not, and probably not in the immediate future.

Ultimately, this was not originally intended to be a big or long-running project.  It was picked mostly for two reasons: (1) I really wanted a game like this, and had ever since 2006 when I started playing Doom II with Oblige generated levels and my own logic and AI mod, at which point I started thinking how cool it would be for the level generator and game to be packaged together.  After Strafe stopped working for me, I wanted to make my own roguelike/retro=fps hybrid all the more as a replacement, but one leaning more toward the retro-FPS aspect and less toward the roguelike.  Not to mention I really liked the idea of being able to play my Doomlike Dungeons without Minecraft. (2) I wanted a relatively simple project to learn while Learning Unity, and decided that most of what you need for a retro-FPS, at least the hard parts, should be built into any modern engine, while the level generation was something I was already experienced with.

Well, I basically succeeded at the core goals: I created a legitimate retro-FPS game with procedural level, and created a game that is fun to play and that I can enjoy myself.

A Possibly Premature "Postmortem"

A lot of things definitely went right, and most importantly the game is fun to play (at least if you're into this kind of game):

1. The level generation is pretty good.  I does produce levels that look good, even if a bit blocky-looking.  The levels also provide a variety of tactical situation, including big open rooms, narrow twisty passage, areas with environment hazards like lave and slick ice, flat battlefields and areas full of height variation where the player can engage in tactical platforming.  This should not be surprising as the core generator had already been tested for nine years in a mod that has received over 20 million downloads.
2. The weapon mechanics are good, even if not entirely original (all weapons have equivalents in either Doom, Minecraft, or D&D).
3. The somewhat more novel health and armor mechanics generally worked well, though the ability to die from shock damage and the generally high damages (in terms of shock) make the game pretty deadly.  These might work even better in something like an action RPG or survival game.  Not that it was completely original, the shock/wound system being loosely inspired by the TTRPG's Torg and Torg: Eternity (which also inspired the games premise/backstory here).
4. Generally, most of the mechanics played pretty well.
5. The control scheme, though not original, was pretty good, offering several ways to do cycle the inventory.
6. The unusual approach to "true first person" (by attaching the camera to the head of a complete third-person character) was made to work well, though I would probably not use it again since it created some limitations, such as not being able to two-hand items due to the other arm clipping into the camera.

Where Some Things Went Wrong

1. Code architecture problems: Some areas of the code are overly interdependent, adding some inflexibility that began to hinder further progress, as it became difficult to make changes without breaking things.  The worst example is the inventory system, where the player model, UI, and items are deeply link together; all items were given an OnMobUse() method, but can not actually be possessed by anything but the player character due to having a hard-coded link to the player's hotbar.
2. A lot of problems occurred because of starting the game as a complete Unity noob, with no knowledge of the capabilities or limitations of the engine or how Unity is designed to be used.  These are not engine bugs, but gotchas that would cause an experience Unity developer to do things differently.  These include quirks of the physics system, the way the navmeshes work, and a lot relating to the way Unity handles its own special base classes (MonoBehaviours and ScriptableObjects) versus generic C# classes.  (It didn't help that I was also learning C#, which is less like the Java I was used to the deeper you get into it.)
3. Actual engine bugs I did not expect: Some of these include that kinematic objects can be pushed by fast-moving projectile (I think it happens when a projectile is fast enough to be deep in a target before the collision is caught, leading the physics engine to push them apart in order to resolve the overlap).  Similarly, dynamic objects to be able to glitch though 90 degree corners if moved directly instead of physically).  The worst of these was having animate characters t-pose on death after changing unrelated setting or pieces of code, and then continue to do so even if the changes are reverted.
4. Even though the levels were good in terms of looks, exploration, and forcing tactical adaptation, there were some problems making them work properly with navmeshes.  Navmeshes could not be baked from the editor, of course, since the level geometry didn't exist before run time and change when the scene is reloaded between levels.  There is no simple or obvious way (available to a noob) of auto-generating off-mesh links, thus no way to use multiple surface types, such as give submerged floors a higher navigation cost).  Thus, to keep mobs from treating water and lava like any other floor required not allowing them to move up or down at all.  This effectively confined all mobs to the floor height they spawned on.  I also suspect this of being the cause of the rare mobs inside walls -- they spawn in valid locations that happen to not be on the navmesh (due to floor height changes) and get moved to the closest navmeshed area, which is sometimes in a wall.  A more experienced dev that is using procedural meshes in an RPG set in a laborynth noted he didn't have these problem because he didn't have height variable or jumping -- though these are need for the core concepts of the game.  Water, intended as a hazard for the player by slowing movement, became an easy way to "cheese" hordes of melee mobs.
5. Asset Addiction: I started this out with the plan that I would by no pre-made assets, but use this as a practice opportunity to get good a blender.  Then I had some struggles with rigging.  Then I struggled for a week on creating a triplanar shader (only learning the proper name for that toward the end) and finally broke down and bought one for $20 -- well worth it considering the amount of time and stress I had gone through with no end to failure in sight (those darn normal maps wouldn't work).  Then the idea was to go ahead and just buy models with animation on them, since that had been a frustration too.  Then buying code assets I didn't end up using because they sounded like an easy solution to a problem but then didn't fit my project anyway.  Then more monsters, since the big set I first bought didn't fit the game as well as I thought.  Then a AAA quality pack of humans, elves and half-orcs (as a "lightening deal" $149 for supposedly $1500+ in regularly priced assets) which were only used for the player character but greatly bloated size of my assets folder tremendously.  Then realizing that the couple monsters I had made no longer fit in because they appear too stylized next to everything else, so a creating a huge dependence on asset store art.  Not that I didn't over half of the wall / floor / ceiling material, and few other little things like ammo and some weapon parts (pistol grips, a magic energy blade, etc.) -- but I had none the less become dependent on paid assets for 3D models.  
6. The Price of Assets: All this led to suddenly being over-budget (originally set to whatever my royalties my mods got during development).  That, in turn, led to a  desire to make this a commercial game, in hope of selling enough to at least break even so I wouldn't feel stupid for blowing excess cash on assets.  This made the whole things stressful, and even made more bought assets tempting, since I had to have a commercially viable game.  This culminated in a probably unrealistic desired to put this on Steam, and certainty this would be my first commercial game.
7. Due to problems adapting to systems I hadn't anticipated, the rate of mob production dropped and came to standstill, leaving the game with a handful of goblin types, and imp, and weird beast.
8. It was intended that there would be cave like rooms with terrain-like floors and ceiling based on height maps, though I never got these to work.
9. Some aspect of room and level quality control were never made to work, though the use of A* to make sure a valid path from start to finish (with levels being discarded and re-planned in case of failure) does at least insure all levels are beatable in theory.
10. I failed to realize how long this could take to include every feature that had crept into my plan, or to start the project off with the plan to include such additions -- or how miserable it could become when frustration became a far more common outcome that progress, or that that might happen.
11. The bloating of files very quickly made saving the full project in on github impossible, and eventually ballooned to over 30 GB of disk space, take a good half hour just to copy a back-up to another hard drive.  The bloating by high-res assets also bloated the size of the game files, meaning its already pushing the limits of what Itch.io allows (possibly, depending on if you could the 500 MB zip file or the almost 1 GB unzipped size of all files).

It reality my first upload of a "prototype" was more like an alpha to my original plan, and was partially listed as a prototype because even then I wasn't sure if I wanted to continue it.  Most of the development time was before that, setting up the level generator (over half of the code base), character model, and creating the core weapons and those first handful of enemies it still has.

The Future?

I actually don't know if I'll add more to this, or if it really is done, though I will take a break for a while at the vary least.

For now, I have a book of OSR (Old-School Renaissance/Revival) or OSR-adjacent tabletop RPG rules I was half done writing last summer, so I may want to finish a draft of that to play test with my sister, as well as some other tabletop projects like a small, low-level, snadbox megadungeon targeted to small groups of OSR players new to old-school roleplaying. 

When and if I get around to working on videogames again its hard to say what my next project would be.  I might explore an old idea of mine for a society simulator -- basically a simplified life-simulator on grand scale that would certainly be called a "city builder."  This was my first adult attempt at making a videogame (where I got bogged down in trying to make a custom engine), the closest thing I game programming I have to a "passion project," and something I would not start with the expectation of finishing in a few month as I did with this.

As for this game, any further addition would probably be new monsters (there are current entries for monster level 1-4, with 1-10 existing in code, though 9 and 10 are strictly for hypothetical bosses).  Anything beyond that would be minor additions for presentation and quality-of-life, such as an intro-screen with the backstory, help screen, perhaps a simple options screen.  The first additions would involve recreating some progress lost after the last occurrence of the t-posing corpses bug, which include more ammo in later levels, better archer animation, and the addition of a skeleton.

Then there is the question -- should I actually try charging anything for this, small and simple as it is?  Or, if not, if I do just give it away, should I open source my scripts so that others can learn from what I figured out and where things went wrong?

(...and if you've actually read all this, I'm impressed -- thanks for paying that level of attention to this project.)