Hell-Forged - Episode 2 (Restarting Eventually)

[Amuscaria]

Out of curiosity is there a easily built in way to do the following? Or it is just basically the same thing as Hexen?

You have a central hub level that where there are 3 exits, each exit sends you to the a map where the game plays normally in a linear fashion with a series of maps, one after another, but after a final level in each path, you are sent back to the first original hub level where all of your progress in the hub is not undone, and you can choose to go to another path, and so on. When all three paths are done, a 4th path is unlocked which ends the game when completed.

In know this is similar to how Hexen works, but Hexen lets you go back and forth between any of the maps and progress is saved in all of them. Where as I just need the central hub progress to save. Whether the progress in the branch paths are saved or not doesn't matter since you don't return to them. Not sure if there is some sort of memory consideration I need to consider using the Hexen system, especially with large maps with many hundreds-thousands of monsters, or is that completely irrelevant for modern computers.

The reason I'm asking is I'm thinking using the original idea that was meant for Episode 3, where you have a central hub that branched off into what was then of the themed paths, collect a special key, and returning to the central hub where you then have access to last final stages. HF-Ep2 only has 3 enemy themes, so I could only need 3 paths, but I'll have multiple maps in for each of the Blood, Poison, and Undeath themes. This makes more thematic sense. The idea that is that the branch you choose first will always be easier, but the other 2 paths get harder when you complete a path, with the third path being the hardest regardless of which path you choose initially - similar to how HF-Ep1 map7 works.

[TiberiumSoul]

im no expert but have you looked at Chubzdoomer's stuff? he might have what you're after

[Doominer441]

Wouldn't all you need to do is ensure the player can't return to the previous levels, and that the entrance to that level sequence on the hub closes itself? Like let's say you have a hub with several portals/doors to different sequences of levels. They could all be part of the same cluster/hub, but once you enter a sequence you can't return to the hub until its finished, and you can't backtrack to a previous level in the sequence, and once you finish the sequence the door/portal to it in the hub closes off.

[Gez]

Out of curiosity is there a easily built in way to do the following? Or it is just basically the same thing as Hexen?

You have a central hub level that where there are 3 exits, each exit sends you to the a map where the game plays normally in a linear fashion with a series of maps, one after another, but after a final level in each path, you are sent back to the first original hub level where all of your progress in the hub is not undone, and you can choose to go to another path, and so on. When all three paths are done, a 4th path is unlocked which ends the game when completed.

In know this is similar to how Hexen works, but Hexen lets you go back and forth between any of the maps and progress is saved in all of them. Where as I just need the central hub progress to save. Whether the progress in the branch paths are saved or not doesn't matter since you don't return to them. Not sure if there is some sort of memory consideration I need to consider using the Hexen system, especially with large maps with many hundreds-thousands of monsters, or is that completely irrelevant for modern computers.

This is very similar to Stronghold On the Edge of Chaos. AFAIK, unless it has been implemented while I wasn't paying attention (as people may have noticed, I am much less active nowadays than I was a few years ago), there is no way to have a "hub" level while the other levels are not saved. SOTEOC did that by simply keeping track of the state of the hub level with a few script variables and let everything be reset -- if you play it, you'll notice your automap gets cleared each time you return from a mission. It's also a level with very little dynamic gameplay -- no enemies to fight, and very few pickups to get. So the approach taken in SOTEOC may not be viable for what you have planned, if the hub is a "real level" for lack of a better term. If your hub is kind of like Quake's start map then it should be perfectly sufficient.

Otherwise, you can have all levels be in a hub. Yes it means that all the other levels will be saved too. This shouldn't be too much of a problem though; computers today can handle a little bit of save bloat; just look at the explosion of the "open world" genre...

[ActionAlligator]

Hey, I have zero experience with this stuff, so keep that in mind. I couldn't find anything besides Hexen's hub cluster stuff. So, if you decide to go that route, this is what I found that may be relevant to what you're after:

1) Hub clusters normally skip intermission stats screen, but if you don't want that, it sounds like you can force it on a per map basis with this: https://zdoom.org/wiki/MAPINFO/Map_defi ... termission
2) All of the maps progress will also normally be saved, but seems you can force, again on a per map basis, to forget its state so it doesn't clog save game (not that it rlly matters these days, but it's cleaner so w/e): https://zdoom.org/wiki/MAPINFO/Map_defi ... orgetState
3) Regarding changing map variables depending on the path the player takes (increasing difficulty), I think you would use world/global scope which can allow things in one map to affect things in others: https://zdoom.org/wiki/Scope

So basically, you would have all the lvls in the episode connected as a "hub cluster" (since all 3 paths need to be connected to the same hub level), where the main hub level would use key world/global scope variables to register which "path" the player chooses 1st. Leaving the main hub lvl wouldn't show the intermission screen (unless you wanted it to), and then the sequential levels in that path would effectively play like normal Doom levels, where they only connect to the next sequential level. Each level would have scripts that look at world scope variable to check if this path was 1st, 2nd, or 3rd, and would adjust based on that. On level exit, they would show the completion stats with that "Intermission" map definition, and their progress would be wiped with "ForgetState". Upon completing the final level in the path, you'd return to the hub level as you left it, but the entrance to the 1st "path" would be closed off via script, and then again you have world/global scope variables waiting to be triggered by the "path" the player chooses 2nd. And so on, rinse & repeat.

Sorry if you already know all of this, but that's all I could find. You could ofc also just do it like Gez mentioned where hub cluster isn't used at all, which as he said should work fine if your hub level doesn't have anything worth tracking in it (monsters, items, secrets, etc.). I'd think you would just use global scope variables and script checks to determine "path" order difficulty and to close off "path" entrances (https://zdoom.org/wiki/MAPINFO/Map_defi ... emberState could try this too, not sure if it works for normal Doom style non-hub maps). Either way, hope it helps, good luck! This sounds very, very fun btw

EDIT: Seems I got a little confused and thought "cluster" and "hub" were the same thing. So, it sounds like "hubs" have to be "clusters", but "clusters" don't have to be "hubs". Defining as a hub basically changes default flags etc. as designed in Hexen. Instead, you can simply define as a cluster and change variables from there instead of worrying about new Hexen defaults. So, what you could do is define all the levels as a single cluster and use "RememberState" only on the central level. Then, it sounds like the rest of the levels should behave as normal Doom maps. Regardless, it sounds like all the map definitions still work either way (whether cluster hub or just cluster), so it kinda doesn't ultimately matter it seems. Not defining as a hub sounds like it would be slightly simpler.

[Amuscaria]

Ah, thank you all for the info. It's not vital that the branch levels save or not. I was just worried saving the state of a very large monster/item-filled level with a lot of moving sectors might cause memory and loading issues. But again, maybe that's irrelevant for modern computers. I do need the maps to go through the Doom1 type intermission screen, though. So if that's not possible with Hubs, then it's a issue.

IIRC, I can trigger scripts or use some sort of global variable that's not part of any map to keep track of some value right? All I need would be keep an int that goes from 0-2. When I finish 1 branch, iterate the value by 1, telling the next branch I visit to spawn more monster. And again, if its 2, to spawn even more.

[ActionAlligator]

Yeah, again being a huge noob, but that sounds right to me based on what I've read. I myself got confused between the whole "cluster" and "hub" terminology, ala my mess of a post up above, doh. I *think* if you just define all your maps in the episode as a cluster, described here https://zdoom.org/wiki/MAPINFO/Cluster_definition, and then just flag your main central level with "RememberState" https://zdoom.org/wiki/MAPINFO/Map_defi ... emberState, that should take care of everything you want. Could try making a few test maps to see if it works?

[Amuscaria]

i'll test with some maps. thx.

[brick]

I have seen something very similar to what you're describing in Refracted Reality. There is a "hub" map from which you can access all the others but it's not actually a hub in the GZDoom or Hexen sense (in fact I don't think the cluster is defined at all). The hub map just has a complex script that tracks which maps have been visited and which have been completed, each map gives the player an item (completely under the hood, the player is never aware of this) at the end and the hub map reads which items the player has and adjusts itself accordingly. I don't think the hub map state is even saved between maps, it's recreated every time based on the items (and therefore on which maps are completed). This will work perfectly if the hub map is just there to allow access to the others.

If you need the hub map itself to change, so there are new fights or new items and so on that appear with each revisit, and you want that progress to be saved in the hub map (but not in the others), you may have to get a bit creative. The Singularity Complex faked this way back on vanilla Doom, each return to the "hub map" was actually a completely new map. Maybe you can combine this with the script approach above depending on how you're designing the hub map and how much needs to change on each revisit.

It's not clear when you say hundreds-thousands, do you mean hundreds of thousands of monsters, or just hundreds to low thousands? With the latter, if you're developing this for the latest GZDoom then I think any computer than can run it will be fine. All of them in the same map is one thing, but if they're spread over all 4 maps then there should be no problem at all, since all except the ones in the current map will be in an inactive state and take very little computer resources.

[Hambourgeois]

Ah, thank you all for the info. It's not vital that the branch levels save or not. I was just worried saving the state of a very large monster/item-filled level with a lot of moving sectors might cause memory and loading issues. But again, maybe that's irrelevant for modern computers. I do need the maps to go through the Doom1 type intermission screen, though. So if that's not possible with Hubs, then it's a issue.

IIRC, I can trigger scripts or use some sort of global variable that's not part of any map to keep track of some value right? All I need would be keep an int that goes from 0-2. When I finish 1 branch, iterate the value by 1, telling the next branch I visit to spawn more monster. And again, if its 2, to spawn even more.

re: your second paragraph: You are thinking in the right way and it's likely that you have figured this out already, but given what I am reading in the cluster definition wiki page and the scope page, changing clusters looks like it's the only way to have a text intermission. You can have global scope variables that track even across clusters, which you would use to govern the hub map. A possible setup may look like this:

Hub- map01 cluster 0
B1M1 - map02 cluster 1
B1M2 - map03 cluster 1
B1M3 - map04 cluster 1
B2M1 - map05 cluster 2
...
B3M1 - map08 cluster 3
...

Define each cluster to have exittext (and/or entertext, if you want the text intermission at entry in addion/instead) that would play when you return to the Hub level, as it would change clusters to do so. The big concern with the hub map is I am pretty sure it would reset each time you enter it, regardless of if rememberstate or forgetstate is defined (think that only applies within cluster). You'd have to use the global variable state in conjunction with mapspots to spawn in any items/weapons/monsters you may want.

In terms of the logic to govern it, I'd probably set up a global variable for each branch (0 = incomplete, 1 = complete), to govern locking re-entry into each specific branch after it is finished, then check the sum of the variables to determine what the power level the branch levels should be (i.e. if it's 0 then do weak monsters, 1, add a few more, 2 it should be pretty hairy, and then at 3 it should be your final visit to the hub for what I am assuming will be the final showdown). You'd also have to have a pretty elaborate OPEN acs script on the hub map to check the gamestate and make any needed changes (opening up new areas, etc.) to the hub map for progression.

e: for clarity and precision

e the 2nd: I think I may have misinterpreted something. If you have no use for text intermissions and you just want the normal doom level end screen then you don't have to worry about the cluster stuff, but the variable stuff still applies

[Amuscaria]

@Hambourgeois: I actually don't need intermission text, just a episode intermission graphic with the arrow pointing to the location of the level, like doom 1, and in Hell-Forged E1. I know I can use the same intermission map for multiple clusters, because HF1 used separate clusters for Shark-level and the rest of the normal maps, while keeping the same intermission graphic.

I'm not sure how the Hexen hub system works, since I've never used it. Mapinfo has "exitpic" and "enterpic" properties that are defined for each map's intermission image, with their positions definable in a text file. I'm just not sure if maps connected via the hub system can use this, or does it transition straight from 1 map directly into the other bypassing the intermission map. I haven't had the the time to experience much yet.

As for the hub system, assuming the exit and enter pic properties work as intended between each map travel, I can just fake the linearity by preventing back-travel to previous maps until you get to the last map in each branch, which warps you back to the central hub. I was just worried with how big some of the maps are, if it would cause some memory issues. The last map in each "branch" would be around the same size as the largest maps in HF1. But maybe it isn't an issue, since while the maps are large, but the monster count is relatively small. It's certainly no Sunder. I don't intend to make slaughter maps, so maybe it would be fine.

[Gez]

I think RememberState mentioned by ActionAlligator is all that you need. No hub needed.

[Amuscaria]

oo nice

[Amuscaria]

In the context of Doom and its usual gameplay loop. Will a monster whose attacks stun you momentarily, either slowly down or freezing your movement for a fraction of a second (~0.1 seconds), making you vulnerable to more attacks, be game breaking?

Thinking of a monster that is a cross between an Archvile and Arachnotron. Attacks are repetitive and constant so long as LOS is maintained. Summons a small AOE under or around you that detonates after a small delay. Getting hit would stop you from moving, or slow you down a by 50% for a bit. If you're caught in multiple attacks it would potentially stun-lock you to death. Not sure if this would be unfair or be incredibly annoying in the context of Doom.

[Gez]

The grells used in ZDCMP2 do have a slowing attack. However, it's a classic projectile, easy to dodge; not a constant hitscan. The idea of getting stunlocked in Doom does sound very annoying; especially for a vile-style attack where the attack only ends when you move out of the line of sight but the attack itself makes it so that you cannot move so you get stunlocked.

If the attack merely slows you down a bit and isn't cumulative (they can't slow you down further if you're already slowed down), then that's not too much of a problem; just a hindrance but you can still get out of the way. If they can immobilize you, however, it's basically game over.