Fun little game, a bit on the easy side on normal, the melee zombies were never really a threat, really the only enemies that constantly hurt me was the zombies with guns because they look like everyone else so you don't expect em to shoot.That said it felt a bit weird that a zombie spin-off to a game where headshots kill has headshots that barely do more damage than bodyshots.
1. Indeed, pixelise shaders have always seen a bit odd to me as if you have an inbuilt scale function for the screen/framebuffer why bother?! (I suppose the answer is I'm lazy)
2. Each character mesh is split into each body part and has a mesh for each level of damage. The relevant damage version of a body part is simply shown/hidden as necessary. I originally wanted to implement this by swapping the mesh resource in the instance, but Godot doesn't allow for this.
Yeah, sounds could be quieter. I was going for the over-the-top distortion, low-fi arcade sound effects. As with all my games I experiment with things which leads to inconsistencies with various aspects.
Thanks for the answers! I have just one more, if I may - as I said this game contains all elements I love about a retro game, so I'm curious about the process :)
Are the levels assembled in TrenchBroom + Qodot or do you do lay down the geometry + texturing in Blender?
Each piece is modelled/textured in Blender. Import/export scripts attach collision and the correct materials based on name look-up tables. Levels are then put together in Godot. At runtime the individual pieces are merged into a single room mesh. The runtime merging preserves the collision nodes attached to each individual piece and parents them to the new combined mesh node. I can also choose to have the mesh combining script simply generate a trimesh instead of pre-defined box collision meshes.
Each component mesh can be easily put into a scene and instanced with others to save having to make the same rooms over and over.
Hope that answers your questions, always happy to answer as I love talking about this kinda stuff.
Very enjoyable, loved the artstyle and the little nods to House of The Dead and Resi, rest of this comment is going to be little things about the game I wish were different but I really want to emphasize that I enjoyed it a lot.
- The collision on steps is wrong, the camera bobs up and down while you're going up and down them.
The easiest way to fix this would be to make the collision for the entire flight of stairs a ramp instead of conforming to the geometry of the steps.
- No ambient noise / music
This is ok, making music is really hard and no music is definitely better than bad music. It's very easy to make some simple pink / white noise ambience in Audacity and it adds a lot to a game, (video below covers this well) try it out and see how much better it makes your games feel.
Here's the ambient noises in Resi 2 for inspo - No reason to play the game the "fun" way
You have a really cool dismemberment system for the zombies but no incentive to utilize it. It would be cool if the zombies did a lot more damage and you could gib zombies legs with one pistol shot so that it was more efficient to shoot them and leave them alive than it is to kill them outright
Good work though, looking forward to anything from you in the future
Fun game if you are in an early 90s mood! I donated some bucks after finishing the game. Because the dev is working on updates, I have a few more remarks:
In level 4 I could directly walk outside the level back through the front door (v1.1);
I could walk through a bathtub (v1.1);
Forward and backward default mapped as 'up' and 'down'. I would expect 'W' and 'S'. (v1.21);
Sound not working as superuser, but who would use that anyway :) (v1.21);
v1.1 works on Linux, but v1.2 crashes. What happened?
Unhandled Exception: System.DllNotFoundException: System.Native assembly:<unknown assembly> type:<unknown type> member:(null) at (wrapper managed-to-native) Interop+Sys.Stat(byte&,Interop/Sys/FileStatus&) at Interop+Sys.Stat (System.ReadOnlySpan`1[T] path, Interop+Sys+FileStatus& output) [0x00028] in <46e2faba55964e57bc4a72159b9574b8>:0 at System.IO.FileSystem.FileExists (System.ReadOnlySpan`1[T] fullPath, System.Int32 fileType, Interop+ErrorInfo& errorInfo) [0x00007] in <46e2faba55964e57bc4a72159b9574b8>:0 at System.IO.FileSystem.DirectoryExists (System.ReadOnlySpan`1[T] fullPath, Interop+ErrorInfo& errorInfo) [0x00000] in <46e2faba55964e57bc4a72159b9574b8>:0 at System.IO.FileSystem.DirectoryExists (System.ReadOnlySpan`1[T] fullPath) [0x00000] in <46e2faba55964e57bc4a72159b9574b8>:0 at System.IO.Directory.Exists (System.String path) [0x0001e] in <46e2faba55964e57bc4a72159b9574b8>:0 at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x000c1] in <46e2faba55964e57bc4a72159b9574b8>:0 at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share) [0x00000] in <46e2faba55964e57bc4a72159b9574b8>:0 at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) at Serialise.Binary[T] (T obj, System.String path) [0x00006] in <076b9e46999845aeb5b74b99a5b9aaa8>:0 at PlayerGamedata.save_gamedata () [0x000a4] in <076b9e46999845aeb5b74b99a5b9aaa8>:0 at PlayerGamedata.get_gamedata () [0x00019] in <076b9e46999845aeb5b74b99a5b9aaa8>:0 at PlayerGamedata._Ready () [0x00047] in <076b9e46999845aeb5b74b99a5b9aaa8>:0
Looks like an error due to the "Gamedata.sav". It seems like it happened on start up and was caused by not having write/read permissions for the folder.
I need to know, was it on startup of the game or during gameplay (end of a level/changing options)?
Did you copy your old (1.1) data file to the new version? If so, try simply deleting it.
It was on startup of a clean v1.2. I deleted the v1.1 directory and ~/.local/share/godot just to make sure. A startup of v1.2 as superuser shows some extra warnings:
pure virtual method called terminate called without an active exception
================================================================= Native Crash Reporting ================================================================= Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. =================================================================
================================================================= Native stacktrace: ================================================================= 0x9e9ca4 - ./AfflictionRescue1.2_linux.x86_64 : (null) 0x9ea01c - ./AfflictionRescue1.2_linux.x86_64 : (null) 0x9dcac8 - ./AfflictionRescue1.2_linux.x86_64 : (null) 0x9e92ff - ./AfflictionRescue1.2_linux.x86_64 : (null) 0x7f28ddb860f0 - /usr/lib/libpthread.so.0 : (null) 0x7f28dd88f615 - /usr/lib/libc.so.6 : gsignal 0x7f28dd878862 - /usr/lib/libc.so.6 : abort 0x90c6eb - ./AfflictionRescue1.2_linux.x86_64 : (null) 0x247ae76 - ./AfflictionRescue1.2_linux.x86_64 : _ZN10__cxxabiv111__terminateEPFvvE 0x247aeb1 - ./AfflictionRescue1.2_linux.x86_64 : (null) 0x247994f - ./AfflictionRescue1.2_linux.x86_64 : (null) 0x13063b5 - ./AfflictionRescue1.2_linux.x86_64 : _ZN16AudioDriverDummy11thread_funcEPv 0x1dcb300 - ./AfflictionRescue1.2_linux.x86_64 : _ZN11ThreadPosix15thread_callbackEPv 0x7f28ddb7b3e9 - /usr/lib/libpthread.so.0 : (null) 0x7f28dd952293 - /usr/lib/libc.so.6 : clone
================================================================= Telemetry Dumper: ================================================================= Thread 0x7f28d48c6640 may have been prematurely finalized* Assertion at mono-threads.c:650, condition `info' not met, function:mono_thread_info_current,
I've just uploaded a potential fix (at least in terms of crashing). If you could give it a run (1.21 experimental) and let me know if you get the same behaviour that'd be great. You should simply get a warning saying you cannot save progress rather than an out right crash. Running it with super user though has me worried that this isn't the issue.
Well that's progress :) Could you in a post me an output of an "ls -la" command in the game folder and another of it's parent folder. It is definitely a permissions issue. If you run the game with super user does it still show the "cannot save" popup?
edit reply: Well that's good. I'll investigate this further and try some things out. Permissions are messy and complicated but hopefully there will be a couple of ways I can avoid issues. Thank you for the bug report.
I really enjoyed playing this game. The secrets and movement reminded me so much of doom and the gameplay and graphics made me remember my childhood. Keep up the good work. Also the laser gun is FIYA!
I will try and get something implemented asap. Being a one man band and making these games in a month means I don't always get time to add certain features. I'll look to develop a means for me to easily port keybinding code between my games. Thanks for the feedback and I'll push an update when it's done.
What a great game ! This is the most sophisticated 3D Godot game i've eve played. I encountered no bug at all which is great. Everything feels right, the zombies being dismembered, the gun sounds..! The lights are great, I wished the level with the flashlight was more dark as I could see without it though. A good idea for your next game would be to make a loader with a progress bar when switching scenes. You can do this with godot's ResourceInteractiveLoader and if you're using a lot of shaders you might want to use a shader cache. Here is one of my projects where I implemented both : Circus Daddy Repo.
Thanks for the feedback and kind comments. Glad that bugs are a scarcity in this game :)
I certainly had an hunch that the flashlight level would be different on different screens. I need to add brightness calibration if I do any more games/levels with gameplay relying on dark/light. A loading screen is basically done for the next version. As for the shader cache, I was doing this in all my previous games but gave up here. It doesn't always work and it was just unbelievably irritating ( I don't even use anything other than the basic spatial material).
Ah yes gamma calibration seems the way to go. Well one thing to know about the shader cache is that it doesn't seem to work on particles. The godot spatial material is optimised (precompiled I belive) and should not cause freezes though.
Thanks for playing and for the feedback. Really happy you enjoyed playing :)
I'm getting some things together for a potential future update so I will be trying to add things such as fullscreen and interface improvements. Feedback such as this really helps me identify things I need to dedicate development time to.
Linux build not running for me for this one. I get the Godot window then hard crash. No problems previously running Office Point Rescue on my linux box. I can send you the log if you like. Here are the first errors logged:
Hey thanks for the report. This is gonna be a pain to work out. Out of interest what version and distribution are you using?
edit: replaced the linux download with a different build. Let me know if you have any success. Haven't yet been able to reproduce this but looking into it
I figured it out: it was crashing on startup because I was running the linux executable in a temp folder that held an existing options.cfg file (from some other Godot game). When I moved the executable to its own folder, it ran fine and created a fresh options.cfg file in there. I checked with the original build and that also worked once I extracted to its own folder. Sorry to give you a scare (well, it's almost Halloween, I suppose.) Interesting that Godot crashes when it reads an options.cfg file it wasn't expecting.
Ah man, yes you did give me a scare. So glad that you got it sorted though :) I know I should handle checking whether you can write to the folder/the file is valid etc. but I thought I'd wait to handle it until it was a problem ( i.e now). Thanks for the report and glad you find the games fun, makes it worthwhile!
← Return to game
Comments
Log in with itch.io to leave a comment.
Fun little game, a bit on the easy side on normal, the melee zombies were never really a threat, really the only enemies that constantly hurt me was the zombies with guns because they look like everyone else so you don't expect em to shoot.That said it felt a bit weird that a zombie spin-off to a game where headshots kill has headshots that barely do more damage than bodyshots.
Hey Liam, awesome game! It provided a fun playthrough for me. The game has all the elements that I love.
Technical Questions, if I may:
Things that could be better:
1. Some of the sound effects and also the hostages' voices are too loud/too distorted compared to the other sounds.
2. Actually just one :D
Thanks bud, means a lot :)
1. Indeed, pixelise shaders have always seen a bit odd to me as if you have an inbuilt scale function for the screen/framebuffer why bother?! (I suppose the answer is I'm lazy)
2. Each character mesh is split into each body part and has a mesh for each level of damage. The relevant damage version of a body part is simply shown/hidden as necessary. I originally wanted to implement this by swapping the mesh resource in the instance, but Godot doesn't allow for this.
Yeah, sounds could be quieter. I was going for the over-the-top distortion, low-fi arcade sound effects. As with all my games I experiment with things which leads to inconsistencies with various aspects.
Thanks for the answers! I have just one more, if I may - as I said this game contains all elements I love about a retro game, so I'm curious about the process :)
Are the levels assembled in TrenchBroom + Qodot or do you do lay down the geometry + texturing in Blender?
Each piece is modelled/textured in Blender. Import/export scripts attach collision and the correct materials based on name look-up tables. Levels are then put together in Godot. At runtime the individual pieces are merged into a single room mesh. The runtime merging preserves the collision nodes attached to each individual piece and parents them to the new combined mesh node. I can also choose to have the mesh combining script simply generate a trimesh instead of pre-defined box collision meshes.
Each component mesh can be easily put into a scene and instanced with others to save having to make the same rooms over and over.
Hope that answers your questions, always happy to answer as I love talking about this kinda stuff.
Thanks again for the answer. Quite an interesting process, very different from what I thought.
Due to what you explained, I researched a bit and found out about Godot's "-colonly" and other extensions to deal with collision objects. That helps the workflow a lot! https://docs.godotengine.org/en/stable/getting_started/workflow/assets/importing...
If and when it works ;)
Very enjoyable, loved the artstyle and the little nods to House of The Dead and Resi, rest of this comment is going to be little things about the game I wish were different but I really want to emphasize that I enjoyed it a lot.
- The collision on steps is wrong, the camera bobs up and down while you're going up and down them.
The easiest way to fix this would be to make the collision for the entire flight of stairs a ramp instead of conforming to the geometry of the steps.
- No ambient noise / music
This is ok, making music is really hard and no music is definitely better than bad music. It's very easy to make some simple pink / white noise ambience in Audacity and it adds a lot to a game, (video below covers this well) try it out and see how much better it makes your games feel.
Here's the ambient noises in Resi 2 for inspo- No reason to play the game the "fun" way
You have a really cool dismemberment system for the zombies but no incentive to utilize it. It would be cool if the zombies did a lot more damage and you could gib zombies legs with one pistol shot so that it was more efficient to shoot them and leave them alive than it is to kill them outright
Good work though, looking forward to anything from you in the future
I had so much fun playing this! hahahhahaahahahah!!!!!
Awesome, thank you :)
Show post...
love zombie psx :*
Thank you for checking the game out and sharing.
Fun game if you are in an early 90s mood! I donated some bucks after finishing the game. Because the dev is working on updates, I have a few more remarks:
Tested on Arch Linux.
Thank you so much for supporting. It makes such a big difference.
I have addressed the issues you stated above, so thank you for that too :)
v1.1 works on Linux, but v1.2 crashes. What happened?
Looks like an error due to the "Gamedata.sav". It seems like it happened on start up and was caused by not having write/read permissions for the folder.
I need to know, was it on startup of the game or during gameplay (end of a level/changing options)?
Did you copy your old (1.1) data file to the new version? If so, try simply deleting it.
It was on startup of a clean v1.2. I deleted the v1.1 directory and ~/.local/share/godot just to make sure. A startup of v1.2 as superuser shows some extra warnings:
I've just uploaded a potential fix (at least in terms of crashing).
If you could give it a run (1.21 experimental) and let me know if you get the same behaviour that'd be great. You should simply get a warning saying you cannot save progress rather than an out right crash. Running it with super user though has me worried that this isn't the issue.
The v1.21 boots! However, the game says:
Game progress/options data cannot be saved, no permissions for folder.
Edit:
The game itself saves just fine. I could restart and continue at level 2, despite the warning in the menu.
Well that's progress :)
Could you in a post me an output of an "ls -la" command in the game folder and another of it's parent folder.
It is definitely a permissions issue. If you run the game with super user does it still show the "cannot save" popup?
edit reply: Well that's good. I'll investigate this further and try some things out. Permissions are messy and complicated but hopefully there will be a couple of ways I can avoid issues. Thank you for the bug report.
I really enjoyed playing this game. The secrets and movement reminded me so much of doom and the gameplay and graphics made me remember my childhood. Keep up the good work. Also the laser gun is FIYA!
Thank you for the kind feedback and am very happy you enjoyed it :)
Made the last video
Beautiful, thanks for playing it through. These playthroughs have been very useful playtest data :D
Hi ! Please add option for keyboard.
Playing with arrows is "fine" but other keys may not be well placed.No qwerty, lefty, disabled, desk setting, and other good reasons to have key rebinding in any games, should be mandatory.
Hello,
I will try and get something implemented asap. Being a one man band and making these games in a month means I don't always get time to add certain features.
I'll look to develop a means for me to easily port keybinding code between my games. Thanks for the feedback and I'll push an update when it's done.
Made another video
Looking forward to the next part. Enjoyed seeing you guys get through it.
We will try to get that out for you as soon as we can
Made a video
Really awesome, so enjoyable to see you guys play through it. Looking forward to seeing the next part :)
Happy you enjoyed the video we will have the next part out soon.
What a great game ! This is the most sophisticated 3D Godot game i've eve played. I encountered no bug at all which is great. Everything feels right, the zombies being dismembered, the gun sounds..! The lights are great, I wished the level with the flashlight was more dark as I could see without it though. A good idea for your next game would be to make a loader with a progress bar when switching scenes. You can do this with godot's ResourceInteractiveLoader and if you're using a lot of shaders you might want to use a shader cache. Here is one of my projects where I implemented both : Circus Daddy Repo.
Congrats, keep doing your thing !
Thanks for the feedback and kind comments. Glad that bugs are a scarcity in this game :)
I certainly had an hunch that the flashlight level would be different on different screens. I need to add brightness calibration if I do any more games/levels with gameplay relying on dark/light.
A loading screen is basically done for the next version. As for the shader cache, I was doing this in all my previous games but gave up here. It doesn't always work and it was just unbelievably irritating ( I don't even use anything other than the basic spatial material).
Anyways, thanks again for commenting.
Ah yes gamma calibration seems the way to go. Well one thing to know about the shader cache is that it doesn't seem to work on particles. The godot spatial material is optimised (precompiled I belive) and should not cause freezes though.
Ah thank you! So I'm not going crazy. I always noticed it was on particles, I would have them spawn on my cache node, only to stutter again.
Enjoyed this. Well done.. you're levelling up fast with each game!
Found a bug before last door on first stage: no colliders on hedge to the left of last door.
Also, at the beginning there is an invisible wall where the first hostage is hiding beside the hut, maybe should be a hedge?
Suggestions: Maybe a fullscreen shortcut.
The torchlight energy meter maybe could have a little energy lightning bolt icon next to it?
Well done though, cant wait to play your next one!
Thanks for playing and for the feedback. Really happy you enjoyed playing :)
I'm getting some things together for a potential future update so I will be trying to add things such as fullscreen and interface improvements. Feedback such as this really helps me identify things I need to dedicate development time to.
Linux build not running for me for this one. I get the Godot window then hard crash. No problems previously running Office Point Rescue on my linux box. I can send you the log if you like. Here are the first errors logged:
Godot Engine v3.2.2.stable.official - https://godotengine.org
OpenGL ES 3.0 Renderer: Mesa Intel(R) UHD Graphics 605 (GLK 3)
ERROR: load_interactive: Condition "err != OK" is true. Returned: Ref<ResourceInteractiveLoader>()
At: scene/resources/resource_format_text.cpp:1228.
ERROR: _load: Condition "found" is true. Returned: RES()
At: core/io/resource_loader.cpp:278.
ERROR: poll: res://TestScene.tscn:3 - Parse Error: [ext_resource] referenced nonexistent resource at: res://Character/CharacterWithStates.tscn
At: scene/resources/resource_format_text.cpp:440.
ERROR: load: Condition "err != OK" is true. Returned: RES()
At: core/io/resource_loader.cpp:208.
ERROR: _load: Condition "found" is true. Returned: RES()
At: core/io/resource_loader.cpp:278.
ERROR: start: Condition "!scene" is true. Returned: false
At: main/main.cpp:1936.
WARNING: cleanup: ObjectDB instances leaked at exit (run with --verbose for details).
At: core/object.cpp:2135.
ERROR: clear: Resources still in use at exit (run with --verbose for details).
At: core/resource.cpp:477
Hey thanks for the report. This is gonna be a pain to work out. Out of interest what version and distribution are you using?
edit: replaced the linux download with a different build. Let me know if you have any success. Haven't yet been able to reproduce this but looking into it
I figured it out: it was crashing on startup because I was running the linux executable in a temp folder that held an existing options.cfg file (from some other Godot game). When I moved the executable to its own folder, it ran fine and created a fresh options.cfg file in there. I checked with the original build and that also worked once I extracted to its own folder. Sorry to give you a scare (well, it's almost Halloween, I suppose.) Interesting that Godot crashes when it reads an options.cfg file it wasn't expecting.
Awesome job with the gibbing and dismemberment, and the moody lighting. Your "Rescue" series is old-school fun.
Ah man, yes you did give me a scare. So glad that you got it sorted though :) I know I should handle checking whether you can write to the folder/the file is valid etc. but I thought I'd wait to handle it until it was a problem ( i.e now).
Thanks for the report and glad you find the games fun, makes it worthwhile!