[Development Halted] Rogue: The Doomlike

[Hetdegon]

Yes, gold please!
And excuse the long verbose post, but just for the sake of argument about food...

I did a few coding and design things for TOME4 until before it was Greenlighted, and we kind of decided against food after a long debate. I can't recall the whole argument because it was a few years ago, but given the state of the engine at the time, the final decision was that it was kinda redundant even if being a long-time staple of the genre.
In a roguelike food is a mere timer, not unlike (for those old enough to know about the franchise) the original Gauntlet games. Rogue's original maps are very primitive and limited in length (you can see the whole thing in a standard 80x23 screen), therefore getting lost in them is very difficult and you only starve if you go too slow or you just had horrible loot luck. However, Doom's maps range from little linear trips to mazes that can take 30 minutes to go from start to finish, more if you explore or take your time. You just can't define a proper amount of food that isn't either plentiful enough to make the mechanic pointless, or scarce to the point of being unfair.

As much as I like the food mechanic (which I am actually have in my upcoming TC, so I hope this doesn't sound hypocritical on the long run, but hear me out), I'd either make it an option or multiplier (perhaps settable from a cvar or MENUDEF menu) or disregard it in this specific mod, unless you decide to add the random map generator where you have a proper measure of the level's size and content. In that case, I'd LOVE it there.
In case you want to implement it, the way I have it is just keeping it all in ACS, and have an ACS loop update the vital stats every minute of real time, it's really simple, so there's not much to explain. The difficulty is tweaking it to get valid durations for how long a full stomach should last and availability of food, which I do with the old school approach of testing it a lot of times. You can perhaps keep it all inside DECORATE with "inventory variables", consumed in idle and/or attack states.

Anyway I digress, I think you could balance by having your director...er, Dungeon Keeper, spam enemies past SUCK times, or try to account for number of things in the level to adjust the spawn speed. It's a bit of a hit-or-miss strategy, but maybe you can find a good balance.

Actually......OBLIGE embeds very easy-to-learn Lua as scripting language, perhaps instead of writing a generator from scratch, it'd be a fun thing to make a generator module with this mod in mind. It's certainly not the same, and it'd require forfeiting the extra control from UDMF, but it'd be considerably easier and since it was likely going to be an external tool anyway, it should save you a lot of time, and it should be able to carry most of the texturing and enemy placement logic by default, and give you control over a map's contents. You could perhaps add a bit of extra scripting to pack something like a custom ZMAPINFO** and textures into a final pk3 ready to be used from a shell script. Just an idea, of course. Do as you please.

**If you have control over map design, you can turn all levels into a hub for extra classic Roguey feel. And could enable stuff like pits and such that teleport you to the next level, allowing to go back to the previous level which would be preserved by zdoom.

[HexaDoken]

Maybe you could balance food out a bit by making it a monster drop. Larger maps have more monsters, so it should work. Slaughterfests will have infinite food but they are silly by design to begin with, and as for exploration-oriented mappacks like Phocas we could just say that "this does not work with exploration-oriented mappacks like Phocas".

Maybe make it a bit more than a timer(though not sure how far that would be deviating from Rogue) - dungeon crawl has varying food costs attached to various actions. Mostly innoticeable with fighters, but very noticeable with spellcasters - while casting nuke spells is infinitely more mana effecient, players may want to avoid doing that in all but extreme situations because doing so will quickly burn through your food supplies like it's not even there.

Made worse by the fact that rations tend to weigh a lot and casters are usually low on STR and thus can't carry much weight.

Perhaps you could think something in those lines, or not bother and say that people have Amulet of Infinite Food as a part of standard equipment.

[Josh771]

Well, on the matter of getting the duration right: I've been using a multiplier to convert Rogue turns into ZDoom tics. I reckon every turn as 18 tics, and the last release even "paralyzes" you for 18 tics whenever you use an item. The Dungeon Keeper (yes, an AI Director) places monsters every 1440 tics (80 turns), which is from the original Rogue. If I do add food, a full stomach will last you about 13 minutes in Rogue's reckoning.

The reason I hesitate to add food at all is precisely what Hetdegon was getting at regarding level variety. However, if I generate my own maps, I will definitely add food. So, for now, I think I'll let the feature slide.

Of course, I could always make monster corpses edible, and even have some produce certain effects when you eat them. Heck, I should probably just go ahead and start making NetHack DooM, right? Actually sort of a tempting idea...

EDIT: I should probably let you all know that I'll be gone for about a week starting Tuesday. Going on a road trip of sorts; I'll probably be quite healthily disconnected from the web until I return.

[Josh771]

So, this is probably going to be my last release for a week or so. Go check the OP; I've added gold and hunger. Currently the hunger system is optional and can be tweaked from the options menu. It defaults to "Off," but in addition to just turning it "On" you can set it for a slow or fast metabolism. Set it to slow metabolism if you want hunger but think you'll be exploring for 30+ minutes per map. Set it to fast metabolism for increased nutritional emergencies.

Oh, and I believe Heretic support should be rather nice now. Feel free to try it out and let me know if it's a little off somehow.

Have fun.

[Josh771]

I'm back from my trip!! And, quite honestly, I'm glad to be back home. Work on Rogue DL should resume nicely, and I've made a release of... well, whatever it is I did before I left. Among the newest additions is an implemented "Create Light" scroll -- but the scroll has no functionality in the software renderer but to create a floating bright orb. To be honest, it's not super-useful even in GZDoom, considering it is a stationary light source (a potion of infravision will serve you much better). Still, I lovingly crafted the light and its GLDEFS so that it would flicker out nicely in OpenGL (sorry, ZDoom purists and other software users!)

I'm considering a simple optional .wad/.pk3 that would make the Create Light scroll change the current sector to full brightness or something. Haven't investigated it.

My next target may very well be enchantments. I'm not entirely certain how I should approach it; I am open to suggestions.

[Hetdegon]

Hey, welcome back :D
Ah, light comes in handy, specially in PSX-styled very dark maps, never a bad thing to have in my opinion.

[Josh771]

I must admit that I just finished a quick test run in which the Create Light scroll was fairly handy -- twice.

So, I wrote a bit of music today. I'm considering making replacement tracks gradually alongside the project; I currently have something that sounds kinda Heretic-ish that replaces the music for Doom 2 Map01 (D_RUNNIN). If you're curious to see what kind of stuff I'm writing, I made this primitive pk3 that will demonstrate if you fire up RogueDL in Doom 2 and start a new game.

I don't expect to overwork myself doing that, since music is a hobby of mine anyway. I'll just divert it into RogueDL if mostly everyone is okay with it (or actually likes the music).

Oh, and I did notice some more changes of mine that I need to update the OP with. So I'll just fix up that changelog and get back to work.

[Hetdegon]

Gave it a little try. It sure sounds Heretic-ish. And my god I was so tired of D_RUNNIN, so thanks kindly.
Everything is going pretty sweet so far, keep up the great work :D

[Josh771]

Alright, I need some brainstorming here. I'm considering moving the inventory entirely to ACS (so I know what item is currently selected, etc) and trying to think of a good way to make enchantments "follow" items. My hope is that I can successfully add the following features:

• Player carries weapons in standard inventory; must wield them manually.
• Player carries armor and can wear/remove it freely.
• Player can see identified properties on a weapon (e.g. "Mace +1, +1") or armor.
• Player can see potions clearly identified in their inventory, no need to look them up.
• Same would go for scrolls, wands, staves, and rings, obviously.
• System would allow for overall inventory capacity with item weights.

So here's my big question: Can args[] or user variables be accessed reliably with scripting? And, if so, can they be applied to CustomInventory drops with a custom drop button? I'm currently researching ACS and DECORATE functions related to the task.

Oh, and if this works, of course, enchanted rings would follow rather quickly.

I understand this is a big task, but I'm a confident programmer. It may take blood, sweat, and tears, but I'd like to tackle it as long as it's actually possible (and I don't count having 40+ actors per weapon as "possible").

[XutaWoo]

Getting in contact with Nash is a good way to check on that. He's done several ACS inventory systems, most if not all of them allow per-individual information. He should be able to point you in the right direction real quick.

[Hetdegon]

Well, I am currently tackling that very exact scenario in my WIP TC, Vault City. This might not make much sense, I am kinda sleep-deprived at the moment and I got a bit of a brain mess dealing with the problem myself, and I am also in a hurry. Yeah, great timing.

I am currently in a massive changing-the-guts-of-it phase so the code won't build at the moment, but I can send you an earlier version of the TC and see how it's being done there, although this stuff is not totally implemented in there, but an earlier version of stuff like ammo swap is (for hitscans). I am slowly deprecating most of the normal inventory to move to my own.
Basically, every weapon is one of 4 slots. The animations, appearance, and behavior are determined by the DECORATE weapon as usual, but on equip every weapon sets its own data for primary/secondary ammo, damage bonus, etc, leaving the effects and visuals to the ammo itself. But the attack is called from ACS. Hitscans are trivial to do, just spawn one or X hitscans with the desired parameters. For missiles, you need a more elaborate trick, in my case I have a small jump loop defined in the weapon base class and have a chat with the player's (via TID) weapon data to retrieve speed and damage parameters as a bitflag that I set as user values for the projectile, then apply them (as a multiplier), in an INIT function.
However, this works only because weapons aren't pickups, you buy them at shops or receive them as rewards in quests (none so far, but that's the plan, I am only a couple of months into it), so a player can't reset weapon data by just dropping the weapon, everything is controlled.

In this case, things are very difficult because of the inherent limits of zdoom, such as "no more than one item/stack of each type".So, yes, moving the entire inventory to ACS is pretty much the only way. It's tricky because you can't send strings from DECORATE to ACS in any way I can think of, so you gotta name your items stuff like ITEM_CLASS_1 and generate the strings inside ACS using roots and indexes and stuff like that.
Basically, things can work out if you have items that register themselves in ACS when picked up, then you can handle them there. The how is a bit more complex, and dropping the item will essentially reset it all, unless perhaps you call ACS on spawn of dropped items, some sort of transient array of data that, if set, has the item set the args (then cleared immediately to avoid a random spawn giving itself those args), otherwise just abort ASAP. But I haven't tested this theory yet and it might not work at all.
Oh yeah, try to use user vars when possible instead of args[], args are more useful for map-editor-set attributes, and can conflict with some stuff. You also get a bit more clarity using user vars.
For weapons, you could dynamically give and take weapon entities when equipped, and use an ACS-based attack function to have them respond to their enchantments and settings. For armor you can probably do the same, have an armor pickup register itself on your ACS inventory at pickup state, equip to give a power (refreshed every once in a while) to give you specific defenses, and remove them when you swap armors to apply the new ones.
As far as displaying changes, I gave up, the only way seems to write a custom inventory screen. I am slowly phasing out every standard use item to use the new system, but I didn't write an inventory screen yet.

I hope any of that made sense, I tried to the full extend of my English capacity (I am not a native speaker), and I can't double check at the moment. If you wait about a week I can probably finish my inventory system and contribute with some code, otherwise the last-working backup could give you a few pointers. I'll PM if you think it can help. It's shitty and placeholder-ish until I am done with more internals, so don't laugh too much at it, though.

[Josh771]

@XutaWoo: I've seen the thread where he was working on a slot-based inventory system. I didn't read enough to know whether he'd seen much success there; I'll check with him and see what's what. No sense reinventing the wheel.

@Hetdegon: The stuff you're doing with weapons sounds more advanced than my needs; I'll basically be upping accuracy, damage, or both based on the present enchantments. You touched on that; I'm already using a little ACS to get that stuff aligned so it'll probably be easy enough for me to make the scripts play with more data. The biggest trouble ahead is tracking that new data -- enchantments (also blessings and curses), armor class (for damaged armor -- say plate mail with an AC of 4), and perhaps other things. At least my armor system is already using ACS-based effects; it'll just need to be rid of its INVBAR habitat.

The question here is dropping items: do you intend to write your system so that items (weapons, armor, etc.) can be unequipped and dropped? This is key to the project. I've already discarded a crazy notion of dropping invisible enchantment items that hook onto the immediately picked up item (so you drop your Leather Armor +3 and it actually drops a Leather Armor with 3 scripted "enchant next armor" items). Tell me if I shouldn't be so quick to discard the thought, but it seemed... hacky.

[Hetdegon]

Heh, yeah, I went for all the bells and whistles there. And some features got cut in design phase, so imagine.
Anyway, I just thought of something. I need a few couple of hours to finish IRL stuff, and then I'll see if I can quickly put a proof-of-concept into code before I pass out. I'll report back if I can get it to work.

[Hetdegon]

Alas, I don't think it's doable at all. But I am not sure if this is because of a bug, or just plain doesn't work.

I put together this hasty test inventory (it's crap done in 20 minutes, but for our purposes it works): https://dl.dropboxusercontent.com/u/95471203/TEST.PK3
Give yourself a "scrollofstuff" and bind some keys for the drop (or "pukename p_itemdrop") after changing the values ("pukename p_ival_shuffle" or bind a key).
I attempted a few methods. Using SetUserVariable with a tid (the method that remains in there) and other bruter approaches like having a shared variable storing the information and pick the two values as results from ACS scripts (after confirming there's data to be shared. So a whooping 3 decorate-acs calls, and not even that does the trick). None of the approaches worked, it'll always set zeroes like if nothing happened.
I really need to find my way around gzdoom in gdb and find where entities are stored to find if there's any change, because it seems there isn't one at all. I don't think A_Log or A_Print allow printing variables, which would make things easier...

At this point I am wondering if this is an actual bug, or if the custominventory class ignores any set user vars by design. If we can work this out, the example above will surely work.
(Excuse the lack of comments. I rushed through it just to get it done and I need to sleep........zzz)
EDIT: Oh, I didn't notice at first but the spawned pickup is a bit unreliable at times, I think I messed up somewhere in there. Try again if it doesn't make a plasmaball thingy appear. The intended function doesn't work anyway, but still thought I should note that out. Oh, and I am using a fixed TID instead of checking for a free one. I did that before, but made it a fixed integer just in case it wasn't working, and forgot to put that back into the code before uploading, whoops.

[HexaDoken]

Everything you said should be doable in ACS. It may be a code nightmare at this point or other, but eh.

This little piece of old test code I did for a certain never-to-be-released RPG mod long ago may be of particular interest for you. It gives weapons randomized damage bonuses(i.e. shotgun +1, shotgun +5, shotgun -1 etc.) which are consistent and kept no matter how much you juggle them around and drop them.

It also doesn't feature 9000 weapon variants per weapon, although I did have to make pickups technically be monsters rather than actual pickups.

The rest of inventory system is just a lot of ACS and arrays.