Bad Night by vknauss
Getting deeper and deeper into some on a really bad night.
A game about hiding a body, getting chased by a pack of dogs, and a surprise meeting with an old friend.
Content warning: explicit language and themes of violence
How to play
Playing the game
Controls:
- [WASD] : Movement
- [Mouse] : Look
- [Left Control] : Crouch
- [Left Shift] : Sprint
- [F] : Grab/Drop interactable (while crouched only)
- [E] : Advance fullscreen text
- [Esc] : Toggle pause
- [Q] : Exit game when paused
The game will tell these to you in the subtitles as you need them.
Note on mouse look
Prior to version 1.0.3, mouse look was inverted for the horizontal and vertical axes and was no configurable. 1.0.3 added a mouseconf.txt file that will be read when the game loads, if present. as of 1.0.4, this file should be present in the Linux and Windows distributions. The default behavior when this file is not present is non-inverted for horizontal and inverted for vertical.
Acquiring the game
There are release versions for the game for Linux and Windows. The game's code should be compatible with Mac OS as it only uses OpenGL 3.3 core profile functions, but I don't know anything about building for Mac. If you are a C++ developer on Mac and would be comfortable creating a binary distribution, please let me know!
The Windows version on the game runs successfully on Linux under Wine, as well. It may be possible to run the Windows version on Mac using wine. If you try it, please let me know!
Since this game is written in C++, it is possible that releases will not work on a given system if it is significantly different from the one it was compiled on. For this reason, it may be necessary to build the game yourself from the source code. See the section on building below.
Building
The source code distribution provides a CMakeLists.txt that can be used to create build files. This is my first ever CMake project, and I don't think I'm doing it quite right, so it may not correctly create build files for every configuration. However it should work just fine for Unix Makefiles and MinGW Makefiles, which I have tested. The compile flags assume you'll be using GCC to compile. It may work for Clang and (less likely) MSVC, I have no idea though. If in doubt, I'd suggest using GCC/MinGW-GCC.
In order to use the CMake build system you will need to install CMake. If you don't have a C++ compiler you'll need that too. Linkies: https://cmake.org/ http://mingw-w64.org/doku.php
This project uses several 3rd party libraries, which will need to be present for linking. I have the GitHub repo set up to use submodules to get the source for (all but 1 of) these libraries, so I'd suggest using Git to pull the source and passing --recurse-submodules when cloning. The only library that isn't set up to use submodules is GLEW. For that, you should download the latest release from their website: http://glew.sourceforge.net/. If you are on Windows and using MinGW, there are binaries you can grab there, otherwise you can download the source and compile from that. In any case see their documentation for more info. If you are on Linux, you may be able to install GLEW from standard repos. For instance, on Debian there is the package libglew-dev. When you build the game, you will need to tell CMake where you have GLEW installed (if non-standard). You can do this by passing -DGLEW_INCLUDE_DIR:FILEPATH="path/to/glew/include" -DGLEW_STATIC_LIBRARY_RELEASE:FILEPATH="path/to/glew/lib/libglew32.a" when you run CMake.
If I remember anything else I will update this. In the meantime please let me know if you have problems with building. I am happy to help if I can.
Changelog:
- [v1.0] : Initial Jam submission
- [v1.0.1] : Fixed a bug in the code that made it impossible to win. The collision detection with the dogs was using the wrong Bullet physics method, and testing whether the player and the dogs could collide rather than if they were colliding. The current release points to the updated version.
- [v1.0.2] : Fixed a segmentation fault that happens when terrain chunks are unloaded by "disabling" rigid bodies before deleting the entities they were attached to. No changes were made to gameplay.
- [v1.0.3]: Fixed the mouse look to be in line with people's expectations! It is no longer reversed horizontally but is reversed vertically still. You can change this by adding a "mouseconf.txt" in the folder with the executable with the lines "reverse horizontal false" and "reverse vertical true" with whatever value you would like for each axis true or false. Thank you to everyone who commented about this issue!
- [v1.0.4] : mouseconf.txt now provided with binaries. Fixed a segmentation fault when entering the cave (again, due to Bullet rigidbodies). Removed debug glGetError checking in renderer code. Boosted speed when dragging by 0.25 m/s
- Changed default mouse configuration to have non-inverted vertical movement out of the box, based on feedback
Ratings
| Overall | 1785th | 2.783⭐ | 32🧑⚖️ |
| Fun | 1726th | 2.625⭐ | 30🧑⚖️ |
| Innovation | 1260th | 2.966⭐ | 31🧑⚖️ |
| Theme | 1287th | 3.345⭐ | 31🧑⚖️ |
| Graphics | 1538th | 2.967⭐ | 32🧑⚖️ |
| Humor | 763th | 2.865⭐ | 28🧑⚖️ |
| Mood | 1331th | 3.167⭐ | 32🧑⚖️ |
| Given | 24🗳️ | 35🗨️ |
And if you are worried about post-jam changes : the ludum rules indicate that this is allowed.
Here, in "Additional Notes " : https://ldjam.com/events/ludum-dare/rules
>Certain Bug Fixes are allowed. You can’t add new features, but if something broke or didn’t work correctly as you were finishing up, you can fix this after the deadline. You are asked to highlight the changes you make in your submission (a short change log). You probably wont get a 2nd chance with some players, but at least it wont be a problem for future players.
On the bright side physics are always fun. I thought grabbing the body was pretty funny and dragging it had a certain physical charm. I also thought it worked pretty well with the theme!
I tried to play as further as I could into the game, but found some breaking bugs :( from minute 1, the mouse axis is inverted, both horizontal and vertical (moving my mouse down and left rotates camera up and right). Also, I never was able to get a message that isn't "I can see the road from here", and ended falling over the edge ot the map.
Aside from these that can be fixed, I would definitely play this if it had some backstory to unfold and learn more about! Kudos!
The mouse was backwards for me (both horizontal and vertical) making it hard to look around (but I didn't have to aim or anything so I managed!) I did have a crash once on entering the cave (console: "err: 1281" hundreds of time then "pure virtual method called"). That's on Ubuntu 20.04. The second time, nothing happening when I got in the cave and I didn't know what to do.
The second time, I'm curious what text you saw? I'm guessing that the "chase" sequence never properly activated, since checking for you to enter the cave only happens during this sequence. I think perhaps if you run from the dogs too early the game won't realize they are chasing you. The expected sequence is
:
"Better back away slowly..." => [moving away from the dogs triggers their AI to start running] => [the game checks the AI state of the dogs to see if any are in the RUN state] => "F*** Run!" => [The game checks to see if the player has ever used the SPRINT action before] => [If not, show an info tip and set a 5 second timer] => [if 5 seconds elapsed OR the player sprints begin the CHASE sequence].
In my tests all these steps worked but the ordering is important so it's very possible the game got confused somewhere. Anyway thanks for letting me know these are issues. I'm not sure how much I can do to fix them at this stage but it is good to know.
As for the mouse look, I'll double check the release version has the fix applied correctly. By default, horizontal motion should be correct (move left = look to the left) and vertical movement is inverted (move up = look down). This is configurable by specifying values in mouseconf.txt in the executable folder.
Yikes this is what I get for using a "Debug" build for all of development and then shipping a "Release" build without testing all the way through.
Apologies to everyone who's had to deal with these bugs. I appreciate your time spent!
The "err: 1281" starts about when the dog shows up, and unfortunately I still got a crash in the cave in my latest try. It is definitely possible I skipped a trigger the time when nothing happened, I wanted to start running soon since turning is a little hard.
Still, if you made this from scratch using raw OpenGL from C++ it is pretty impressive!
I'm still tracking down the source of that crash, but you're right it's for sure happening for me too. I'll run some more tests on the mouse thing, it was definitely reversed in the previous versions but I really think it should be fixed in 1.0.3, and when I downloaded and ran the linked linux version it seemed okay, so I can't say for sure what's happening. Thank you for your help letting me know!
Most of the OpenGL code I put together last week, knowing I'd like to make a 3D OpenGL game regardless of the theme, so I didn't do much OpenGL this weekend. Thank you though :)
Anyway nice to see other OpenGL projects!
No crashes and was able to complete it once I worked out the inversion. Good job.
@miej Yeah I totally get that, that sequence definitely didn't work out as well as I'd hoped. There actually is a destination, but it does take a bit too long to get there. I haven't timed it but it might be around a minute of dragging. Shortly after you see the second chunk load in, you'll get the text "This spot seems okay", letting you know to drop him there. However if you drop him anywhere else the the text will tell you to go deeper, which I suppose could be confusing if you already passed the spot.
@crychair Were they actually invisible? That's definitely not supposed to happen. Did they appear then vanish? Or did you never see them at all?
also might have made me think that the actual destination was going to be much further out, since the trail just seemed to keep going
On a positive note the beginning is pretty funny and I liked the physics for dragging the body :smiley:
PS, It looks like you play like elastigirl when your arm moves so far away from your body lol!
Dragging the body is cool. Doggo is kinda hard to see and confusing
Also, I managed to get to the car and hide behind it from the dog, but the dog pushed the car into me :D
The game really slows down if I look up to the horizon, though. (i7 6560u, integrated graphics, 1920x1080 or 3200x1800) So I have to stare at the ground while I drag the body, lol.
Escaping the dogs is _hard_! I keep dying there, and don't want to keep staring at the ground for a few minutes while I try again...
I like the design of the body, the car, the flashlight, all well done. Also the way you display the intercation "E" in the dialog. The color makes it easy to see how to go on, the font is well chosen. Also the pause and escape menu is a small but important feature for me.
The crazy ragdoll animations adds some more humor to the game.
Unfortunatly I was not able to win this game. The walking speed is just to slow.
It would be cool to be able to run with shift. I tried it 2 times, but also the dragging speed is so slow and you have to go in so far. I also needed some sound, atleast background music.
I apreciate you took the time to create a 3D game with a simple but unique idea, probably woul even pay for this kind of "hide the body" simulator. You inspired me to go with 3D someday as well.
Thank you and keep it on!
In all seriousness though this was a fun game.