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!!!
Hello folks! Just want to drop another update on how the polishing phase is going!
Even about a year ago, I didn’t think the polishing phase would have taken this long (or this much work) because from an art standpoint, I already knew what had to be done to optimize things, what to spruce up and exactly how to do it. To a lesser extent I knew what was left in terms of the programming side (I did have a TODO list afterall), but what I didn’t count on was how much I actually missed in terms of features that people wanted to see.
I start to think about it and realize that much of it is basic stuff too; things I had in the mod but for one reason or another didn’t include in this version! I’ll break down.
1: Different stages of damage for monsters
In the 2009 mod version when you shot a zombie, the clothing and face would get bloody. I’ve included it again and if you shoot a zombie in the face, the material changes to a bloody (or at least, bloodier) version and repeated hits will damaged the head model itself (parts of its skull will fly off)
2: Brains and maggots
In the mod version, a headshot resulted in a geyser of blood and brains and writhing maggots! I didn’t add it on purpose in this version because I thought people wanted the gore tamped down and I didn’t include the maggots because I never heard any remarks about it before, so I thought people just didn’t notice it. However, it turns out people did notice it and wondered where it was and they also wanted the bloody headshots back! So now, each headshot will yield at least a 5 pound bag of brain matter, skull fragments and writhing maggots!
3: Unequip animations
I didn’t include these initially because I thought it got in the way of the pace of the game (I wanted to opt for a more quick switch method for the weapons) but then I realized that the pace of this game is deliberately slow…so why on earth would I rush the weapon switching animations? *forehead smack* So I decided to put them back in.
4: Sprinting animations
I left this out because I’m just a lazy bum. I’ve added motion to the weapons for sprinting now.
5: Reloading mechanics
This was one where if it weren’t for some members of the Discord channel pointing it out to me, I never would have known! My experience with real-life firearms is very limited. I’ve held a hunting rifle, an over-under shotgun and a handgun in my chubby little hands before. The only thing I know about firearms now is that they are waaaaayyy heavier than they are made out to be in the movies! XD
So imagine my surprise when I find out that some of my gun animations were inaccurate! (this is what I get for watching other videogame reload animations for reference hehe!) I was able to correct them, but as a result had to program some more things to accomodate the new functionalities. You can see it in the video at the end of the post.
6: Ironsights/Aiming down the sights (ADS)
I will say this right off the bat; I absolute DESPISE ADS in first-person games! I found that it always got in the way and resulted in me getting my ass kicked in multiplayer games so I never intended to include it in Out Of Hell.
But lately as I was going through my old code, I came across it tucked away in my base weapon class. I had added it as part of a tutorial video I watched years ago, but never “connected it” in Blueprints, so it was just kept as reference and nothing more. I decided to hook it in and try it, just so I could prove to myself again that ADS is a stupid, terrible thing to have in games.
To my surprise, I found that it made the game so much more intense! The first boss fight is just a basic encounter and easily breezed through, but as soon as I had to rely on ADS, this simple encounter turned out to be really freaky! Anything that adds to the unnerving atmosphere of the game is good in my books!
As shown in the video, you can fire without ADS but it will be much more innaccurate than if you do. This makes the game more challenging in a fair way, as opposed to framerates of about 9 per second making the game artificially harder!! **wink wink**
7: Walking attacks for zombies
This one took a lot of effort and messing around but I got it to work! This was on my TODO list for years, but I never succeeded until now. For the longest time, whenever a monster attacked, it would have to stand still and then perform its melee attack. This is easily exploitable as you could simply step in, smack it, step back, step in, smack it and rinse and repeat. It was also exploitable when monsters chased you but had to stop in order to attack, and all the while you could literally keep walking backwards and they would never be able to catch or hurt you (unless you backed yourself into a corner)
Now, most zombie types will be able to attack as they are moving and this makes for some incredibly dangerous encounters! It is programmed to be a random occurence to give the player some breathing room, otherwise you’d be dead in less than 30 seconds against a fast-moving zombie.
There are a few other things I’ve fixed and added, but those will still be kept under wraps as not to spoil too much.
I want to thank everyone for their suggestions and feedback over this past while! Keep the feedback coming and if it’s useful, I’ll see what I can do! Of course, it takes more time to implement these things, but in the end it only improves the game and makes it a more polished experience.
Hello Hello!
Polishing and optimizing is going fantastic and so I decided to record a small video of the GPD map in fully playable form just to keep you guys updated (Though it appears that the zombies are all the same, that’s only because of the random spawner that just happened to pick the same zombie type from a pool of many others. That’s RNG for you!)
When you spend your time someplace else for 10 hours a day (work, ugh), you have to make the most of every spare minute you have and so I’ve been working on this thing like an absolute madman.
I’ve had a list of bugs/issues/TODO’s that I’ve written into over the years and now I’m going down the checklist and completing it one by one. I’ve solved a crazy amount of bugs that have been plaguing this thing in a pretty short amount of time and it feels great! Many of the bugs I had to put on the backburner because I couldn’t fix them at the time and I truly dreaded the day that I would have to face them again (which is now) but surprisingly, it’s been much more simple to do these days!
I hope that you could see this starting to come together now. I built each piece seperately and now I’m locking them into place so that you could see the entirety of this beast!
Hello! I just wanted to update everyone on a couple new things! First, I got a new job as a Graphic Artist…again! It’s funny, in the past I worked as a cook, which I eventually left and became a Graphic Artist, then after years of that, I left to become a cook once again and stuck with the same place since 2013 and now I’ve left that post to work as a…..Graphic Artist.
I didn’t leave because my passion lies in designing logos and making banners for people or anything. The old place became tiresome in many, many ways and the Universe presented me with an opportunity at the perfect time with better pay. The people that I was loyal to that would have been a factor in me staying had left a long time ago, so I said fuck it, why not? What’s holding me here? Although by now I realize that this new place is just another job and in time, the same thing may happen again. My passion is my game projects and that’s where I derive my happiness from, not my job.
This new job slowed down the OoH work just a little bit. I was supposed to have completed the new demo for the testers a couple of weeks ago, but I’ve been focusing on learning the ins and outs of the new job (they want me to learn a bunch of new machinery and software) I was sidetracked just a little bit, but I’m back to working on OoH when I get home and on the weekends once again!
Just wanted to give you all a heads up about this development and to show you that these guys are patiently waiting to reveal themselves! 😉
LONG NGUYEN | Digital Artist & Game Designer 