The Out Of Hell mod had been absolutely plagued with a terrible framerate issue, even on modern hardware since release in 2009. It was something that I tried to look into, but lacking any real knowledge, the best I could do was try to change a few settings here and there and release a patch.
Still, the problem persisted…until now. A User named ImmersiveSinner joined the Discord channel recently (who also happened to be a member way back in the old days on the forums. Remember those? :p) and told us about a fix they discovered!
Here is what they posted:
8:53 PM]immersiveSinner: What I found … recently when I played it last (last year sometime) was that it still kinda ran like shit lol unless you did one thing then it was smoooooooth as butter.
[8:53 PM]immersiveSinner: I have a 13th Gen i7 and an RTX 4070 TI… so I was still surprised when I had such horrible frame drops…
[8:54 PM]immersiveSinner: but if you just close the console printout window… Damn it’s like a whole new game.
[8:54 PM]immersiveSinner: No idea why.
[8:54 PM]immersiveSinner: like 500 fps constant no matter what’s going on.
[8:55 PM]Chicken+Ribs Combo: Hmm, I havent heard of that! Maybe we can repost that in the bug forum. Theres some folks that tried to get to the bottom of that frame drop
[8:55 PM]immersiveSinner: Yeah so when you switch to OOH in the mod menu in UT2k4… the console windows opens up right?
[8:55 PM]immersiveSinner: just alt-tab. close it. get back to the game… no issues.
So uhhh…there you have it. A framerate bug that’s been there for 15 years was caused by an open console window. I can only speculate as to why that would cause such a framedrop or consume so much resources, but that was the problem this entire time!
Now, do understand that the mod itself still has issues with optimization, so it probably won’t run completely smooth in all scenarios, but this is definitely better than the alternative!
Thanks @ImmersiveSinner!!!
What an absolute struggle it’s been since the first official beta test! There were a lot of bugs and issues uncovered (some game-breaking) and I thought it would only take a couple of weeks (at most) to fix. Well, that turned into 2 months! Not only that, the weeks leading up to launching the revised beta were just fraught with problems.
The biggest issues had to do with the save system which I had implemented so poorly. It was doing all sorts of unintentionally weird stuff so I had to basically rebuild another save system that was more efficient and easier to decipher (I even get confused by my own code much of the time!) I mean, just have a look and try following this in order to bug test! XD
Even though it took so much time to implement the changes, I got it done and we moved into Phase 1.1, where it was the initial beta with all of the fixes and improvements applied. That’s still ongoing as it launched yesterday, but the bugs found in this version so far are fairly minor (spelling/grammar mistakes, some collision issues, small coding stuff)
I’m going to fix these ones up as quick as I can and begin tying the other maps into the game which will make up the second phase! I don’t believe it would take as much time as the first phase, since this is where most of the coding and mechanics are fixed, so those won’t be an issue going forward. Any issue will be with the maps themselves and not the actual framework of the game.
After the second phase is complete, I will release a trailer before moving into Phase 3.0, which is the last stretch of the game. If that tests well, then I’ll release a public demo while the testing team does a final run through of the game as a whole.
This entire process has been frustrating, amazing, eye-opening and educational all at the same time. In hindsight, I am so glad I did this since releasing this to the masses without proper bug-testing (like the 2005 demo and the 2009 final) would have been hilariously disasterous!
You wouldn’t believe how much has happened with this game since the last post! It’s been a whirlwind of activity behind the scenes, which is expected at this phase in development. From getting this thing onto Steam and the approval process, the testing and feedback…it’s been hectic!
I’ve gotten my impressions from the testers and overall it has been good. The major areas most important to me (atmosphere, art direction, story elements and sound design) were all big a hit. Where the alpha stumbled most was in the areas of mechanics, quality-of-life stuff and bugs, bugs, BUGS!
Since the test ended (probably a little over a week ago) I’ve been able to fix all the game-breaking issues and implemented a few of my own changes as well as some of the good suggestions from the testers.
At it’s core, it is still a difficult game and that won’t change because that is what is intended, but hopefully it will be a little more enjoyable to play.
I was going to make this post a little longer in order to detail the challenges I’m faced with trying to balance this thing (not easy since I need to go through videos, bug lists and suggestions from 11 different people) but I think it’ll be better to explain it in the eventual development journal that I’ll write later down the road.
All in all, it’s been crazy, it’s been nuts, but most importantly it’s been productive!
If programming has taught me anything, it’s that I am an utter moron! I had a feeling the fix was going to be something stupid, because that’s how it always is. I’ll have some sort of impossible bug or issue, spend days if not weeks trying to figure it out and approaching it from the most complicated angles, only to discover in the end that the answer was stupidly simple the entire time.
So let me explain what happened here:
The way I have my save/load system set up is within the level blueprint itself and each time the player gets to the checkpoint, it takes the variables such as health/inventory/ammo etc. at that time and stores it. If you die and reload, then as soon as the map is loaded in, it checks for all those stored values and applies them to the player again.
So when it didn’t work in the shipping build, it was really confusing the hell out of me! Why was this working only in the development build?
I spent so long researching it online and spent days and days trying to implement the fixes that I found, but to no avail. I even looked for solutions while at work (when no one was looking) and printed out pages of forum posts with potential fixes to bring home. Nothing worked.
I was actually making more of a mess of things trying to apply the solutions from other people’s issues. It wasn’t until I got so frustrated that I just went through my own code again and tried to narrow it down myself.
I did checks and saw that the map that the player was on was getting saved. I then did checks and saw that the health was getting saved. So logically, it had to be something with the inventory code and not the save/load system itself, since it was saving and loading those other variables fine.
It wasn’t until by chance that I took notice of one little node that said “INVENTORY”. The reason this stuck out, was because it should have said “SAVED INVENTORY”.
What the code is essentially doing here is searching through the player’s inventory, checking if there is anything in it, and then adding it to the current player’s inventory. Except when I saw that, it dawned on me that the “INVENTORY” node was just the base default inventory, and NOT THE FUCKING INVENTORY WITH THE SAVED ITEMS!!!
I extended the correct node, connected it, compiled and like magic, it worked! So this entire time, after weeks of stress and anguish and wondering if I was going to have to rebuild the whole damn system, it all came down to this one.silly.little.oversight.
I can’t even blame the engine at all because it was doing exactly what I was telling it to do! It was loading everything from an empty inventory; which is nothing! And when I told it told load from the inventory with items; it loaded the items. Go figure! XD The reason it still worked in the development build is because I think, it was either pulling the variables from memory or somewhere else that isn’t included after the game is compiled. I’m not entirely sure, but I don’t even care now. I’m just glad it works.
I am elated and exhausted. It’s finally solved. I’ll let you guys know how the testing goes. 😀
The final stretch is always the toughest part. For the last couple of months (yes, months) I’ve been trying to get this thing to the testers and it has been an absolute nightmare of shit.
It all stems from the differences between the development version of the game and the shipped version of the game. I don’t know what the hell happens during the process of compiling, but the game works fine when it’s played through the editor. When it gets compiled as a standalone game, all kinds of shit starts to break.
The issue I’m having now is trying to get the save/load system to work properly. In the shipped build, either it’s not saving things or loading things (or both) and it’s difficult for me to tell because you can’t print error strings to screen or to a log file in a shipped build!
At this rate I might as well go back and rewrite the entire save/load system with all the time I’ve wasted debugging this thing! This is the biggest problem preventing me from being able to upload the game to the testers right now.
Anyway, just wanted to keep everyone updated with this rant. I’ll keep you guys posted on any breakthroughs.
A belated Happy New Year! I hope everyone had an enjoyable holiday season! Not much happened over on my side; it was fairly quiet and that’s just the way I like it!
I’ve still been chipping away at this giant mountain called Out Of Hell with a puny hammer and the absolute biggest problem in the entire development cycle has been overcome! This is actually really big news (to me anyway) since it was such a challenge and I am talking about the save/load system!
Being a smooth-brained non-programmer, I had absolutely no idea how I would ever tackle this and had been dreading it ever since the very beginning of development. I kept pushing it to the back of my mind and kept thinking that I’ll deal with it when the time came that I had to do it. Well, the time came a few weeks ago! I was/am in the process of compiling the alpha for the testing team so this had to be included.
I mean, the good news is that we’re at the point where I needed to include the save system so that the game can be properly tested, but the bad news is that it suuuuuucks to implement! XD
Sure, over the years I was able to snag some save system frameworks (they were free on the Epic Marketplace) but none of them worked properly for the project and I spent so much time trying to fix and debug all the issues that were coming up. This was made more difficult by the fact that I didn’t make the system and so I had no idea where to even start looking to fix things!!!
So rather than spending all my time and energy into trying to root out bugs and issues with someone else’s system, I decided to just make my own…from scratch…with no real coding skill.
This is what that idea felt like to me at the time:
It had to be done and there was no way around it. I opened up YPAPS-G and tried to see how I made the score saving system in that game then buckled down and worked my way through it one step at a time! Surprisingly, it didn’t take long to get the system up and running!
You can imagine the absolute high when I finally got the weapons, their ammo counts and all of the player stats to save and then load properly! I had somehow muddled my way to victory, but it was a short-lived one. The soul-crushing defeat came right after!
The only thing left was to take care of the items and supplies (food, health kits, bullets, smut magazines etc.) and this was such a pain in the ass to deal with. I spent nearly 8 days trying to solve this problem and it had to do with duplicate items in the player inventory.
For example, if I had 4 apples and 1 orange, the system would only save 1 apple and 1 orange! I eventually managed to get it to save 4 apples and 1 orange, but upon loading, I still only got 1 apple, 1 orange, and somehow 1 cinder block, 1 crowbar and 1 knife. I am not joking. XD
This had to be a flaw in the way the save system was built early on and it was creating these massive bugs now. And before anyone says anything like “Oh, just have a nested loop check the array for yadda yadda…”…don’t forget: Me smoothbrain, remember? 😉
Instead of wasting any more time, I brainstormed and came up with a fairly hacky way around it and surprisingly, it works fine!!! Not only that, there’s an unintentional benefit to me doing things this way, in that it actually puts a limit on the number of items that will ever be available at any one time, so it will make supplies truly, truly scarce! Hold onto that can of cola and medical kit…it may be the last ones you’ll ever find.
Now that the save system is complete, I will be spending the next week making the game over screens and working out how to get this thing onto Steam. FINALLY! 😀
Hello! I met a few personal milestones so I decided to post a quick update. I haven’t had an awful lot of time because of the day job, but in whatever spare time do I have I put into my true passion! I had quite a few features and overhauls planned and I’m happy to report I’ve met them (and they even turned out better than I hoped)
I did a complete overhaul of the melee system because I noticed during the last playtest (a while ago) that the testers were having trouble connecting their hits sometimes. This is because I originally came up with a convoluted method of enabling and disabling a damage collsion section of the weapon (the tip) so whenever the weapon reached a certain time in the animation, the collision would become “active” thus allowing damage to occur, and then quickly “deactivate” so that i doesn’t continue to do damage if the player wasn’t swinging it around. This worked fine, but there were problems with it that I discovered over time.
One of the problems was that if the framerate was low, the code (delay) wouldn’t fire off properly whiched cause a lot of those “misses”. In essence, the melee only worked properly if you had a consistent framerate so I ended up scrapping it and building another system using traces which turned out to be much more reliable.
Another is the gore system that you’ll notice in the video below. Since I was always a fan of melee-centric combat, I needed to make sure this one was as satisfying as possible and I think I accomplished it. When things get hairy, the shit really flies!!! This whole game is turning out to be everything I originally wanted the mod to be all those years ago.
I also implemented a “shove/push” system that can potentially help you get out of a sticky situation. The shove animations are different for every weapon and there are slight differences in what they do as well (if you don’t have anything equipped, you push with both hands and the enemy has a chance to move back further or if you’re using a firearm, you pistol whip for some damage etc.)
As you’ll see in the video though, if you’re not careful you can get mangled pretty quickly! The difficulty is entirely intentional since I want every monster to invoke a feeling anxiety. There should be no real difference whether you’re facing off against 2 zombies or 20, you should always feel as if everything can go south in just a few seconds.
There were actually a few more things that I did as well, but my mind is just blanking right now because there was so much of it. Anyway, I hope you enjoy the video!!!
LONG NGUYEN | Digital Artist & Game Designer 