It wouldn't open, task manager couldn't even see it. The log.txt says:
ERROR failed to create sdl window: failed loading vulkan-1.dll: the specified module could not be found.
error: failed to inialieze ptaform layer.
Play game
Night Owl Adventures's itch.io pageComments
pretty solid, cute little platformer. I wrote my review before reading through the game page and realizing that you built this in your own engine, so I'm guessing your focus is more on engine dev than game dev, and I think thats cool. great job on being able to make a solid game in your own engine that runs well.
as far as the game goes, I've got a couple tips that would probably be pretty easy to add that would go a long way in juicing up the game.
- when you die, the level instantly restarts, this is known to be pretty disorienting to players, especially in instant kill platformers like these. Adding even like a short death animation that hangs and gives some feedback would go a long way. I would also recommend not restarting the level but having checkpoints and resetting only the player. if the lights continued after a death it would allow the player to get more information about the challenge they died on which will motivate them to try again and learn instead of getting frustrated. of course, keeping the restart button in case they end up in an unwinnable situation and need to truly reset the level
- the jump feels extremely floaty. i would try and tighten the velocity curve such that the player ascends very fast but also quickly loses speed and falls back down. you could also make it so they fall slower until they release the jump button, then start falling down faster after releasing. I would recommend watching this video and paying attention to the breakdown on some of the fundamental movement mechanics in a few well known platformers
https://www.youtube.com/watch?v=yorTG9at90g - since this game is about an owl flying through night, maybe you could lean into the animal aspects of the owl character, like a hover / glide ability by pressing and holding space in midair? might give the player some extra tools to help them out with the tougher jump levels like 7 and 8
keep up the great work! I think you've got a really solid start here and you're poised to be able to add just tons of fun stuff.
Submitted
Robot Game (Early Prototype)Thanks for playing!
afterimages keeping a silhouette of part of the level up after the lights go out
That is indeed pretty cool!
the moving platforms are a little wonky
Yeah, I noticed things get weird when a platform pushes down the player, it's just because I didn't really decide what should happen in that scenario (whether to kill the player or have the platform be stopped by him), so I just intentionally kept it as is, using this quirk to get through the last level is actually intentional design.
Unfortunately it doesn't work on my rig. Windows 10, NVidia.
The console produces only "Segmentation fault" before quitting
Log file doesn't seem to have anything useful, it ends with
ERROR: Watching source asset directory failed, hot reloading assets will not work. INFO: Dispatching immediate load for asset: data/game/tiles.asset. INFO: Dispatching immediate load for asset: 6672901522637001722-13061930668416598832. INFO: Didn't find free command buffer, creating a new one.
Submitted
AGE OF BRASS (prototype)Sure, here you go.
ERROR: Program crashed :( Stack trace (most recent call last): #10 Object "KERNEL32.DLL", at 00007FFE2BFE7C24(+0000000000017C24), in BaseThreadInitThunk #9 Object "Night Owl Adventures.exe", at 00007FF632E2F1CE(+000000000047F1CE), in ?? #8 Object "Night Owl Adventures.exe", at 00007FF632E27C24(+0000000000477C24), in ?? #7 Object "Night Owl Adventures.exe", at 00007FF6329C7792(+0000000000017792), in ?? #6 Object "Night Owl Adventures.exe", at 00007FF6329D7CFA(+0000000000027CFA), in ?? #5 Object "Night Owl Adventures.exe", at 00007FF6329BC843(+000000000000C843), in ?? #4 Object "Night Owl Adventures.exe", at 00007FF6329BA6C0(+000000000000A6C0), in ?? #3 Object "Night Owl Adventures.exe", at 00007FF6329B2FE9(+0000000000002FE9), in ?? #2 Object "Night Owl Adventures.exe", at 00007FF632BD082D(+000000000022082D), in ?? #1 Object "Night Owl Adventures.exe", at 00007FF632BD6F4B(+0000000000226F4B), in ?? #0 Object "", at 0000000000000000(+FFFF8009CD650000), in ??
Nice, it works fine now.
I kinda like the execution of this game. The darkness gimmick in general sucks, but the projectiles being light sources has a nice dynamic where you need to navigate around them but not too close. That's something certain other puzzle projects lack while designing their hazards.
Player controls are ok at best (slow acceleration and floatiness) and hitboxes could be a bit more generous because in stage 2 (I think) it didn't look like it should hit when trying to stand right on top of the light blocks.
And what's up with all that 1.6GB declared RAM usage? It doesn't look like it leaks memory so I can't imagine what kind of horrors are happening there.
Thanks for playing!
The darkness gimmick in general sucks
Yeah, I understand how it can be irritating, but I tried to make it the least irritating I could while still having it be there (making everything predictable, having it not be a side-scroller so everything stays in the same place despite movement).
slow acceleration
Really? The acceleration duration is about half a second from idle to max speed, which I find to be reasonably responsive, maybe that's still too much for some players.
floatiness
The floatiness is intentional, I like having a lot of air control when jumping, but yeah, I can see how it feels odd if you're used to a certain kind of platformer.
hitboxes
I felt the same about them while making the game, they are "correct" in the sense that the pixels are actually touching each other, but it doesn't really feel fair. Maybe I'll tweak the player hitbox so that it's a bit thinner.
1.6GB declared RAM usage
In case someone is curious about this:
Most of that should not be resident and should never use up physical memory, in reality, the game uses about 40-50MB for everything, which is not great, but not terrible either, it's just not something I've spent time optimizing. A lot of virtual memory is reserved upfront for linear arena allocators, basically I just reserve a big buffer of virtual (non-resident) memory and I keep allocating stuff with it without freeing anything until I reset the whole thing, the small fraction of the reserved memory that I'm actually using is paged-in by the OS through page faults and becomes resident memory that actually uses system resources, I have two main arenas, one that gets reset every frame and another that gets reset every level. Currently, the frame arena alone reserves exactly 1GB.
This could be problematic on Windows if your page file size is too small, since, as opposed to Linux, it doesn't overcommit memory, so if the program reserves 1GB, it has to guarantee at all costs that 1GB will be available and usable somewhere , which in practice means that it takes up space in the system's temporary on-disk page file, if your system for some reason doesn't have a page file, or the page file is too small or too full, it'll have no choice but to make the entirety of the reserved buffer resident in memory.
If you would like more information on this, see https://web.archive.org/web/20180402190240/http://ourmachinery.com/post/virtual-memory-tricks#obscenely-big-array.
There actually is way to emulate memory overcommitting on Windows by manually handing page faults (see https://learn.microsoft.com/en-us/windows/win32/memory/reserving-and-committing-memory) so that reserved memory only takes up virtual address space (of which you have terabytes on a modern x64 system) instead of also having to be reserved in the page file. Alternatively I could just incrementally do MEM_COMMITs as necessary behind a check in my Alloc function, or just lower the upper bound when reserving virtual memory, which I might end up doing.
it works fine now
I can provide more information on the issue in case someone reading this is curious or is also writing a Vulkan engine:
This turned out to be a pretty tame "bug": basically, the program was trying to call a null function pointer returned from vkGetDeviceProcAddr for a specific recently-added Vulkan function because it was not supported, I wasn't checking that the function pointer that was returned was valid because I just assumed the target hardware supported Vulkan 1.3 without even checking for that either, to fix this, I now check the return value of every call of vkGetDeviceProcAddr, and I make sure that the GPU that's used supports my target Vulkan version, this still wouldn't have been enough to allow the game to run in this specific case because the root issue is that the hardware or driver in this case does not support Vulkan 1.3, which I guess means that Vulkan 1.3 support is not as common as I thought, so I just spent some time lowering the minimum Vulkan version to 1.1 by using less recent features, which should be much more widely supported.
UPDATE:
I shipped a new build that now does MEM_COMMIT incrementally, this should not make any difference with regards to the actual memory usage, but it should be helpful if your system's page file is small or non-existent. If anyone is curious enough to look at the difference, they can use https://learn.microsoft.com/en-us/sysinternals/downloads/vmmap, the working set (i.e the amount of physical memory that's actually used) should still be the same (it shows ~32MB on my machine), while as the amount of committed memory should be much lower.
I also doubled the player acceleration speed and made the hitbox thinner (also, the game now always sets its working directory to the directory where the executable is located, regardless of where you launch it from).
Reminds me of those super meatboy-type games where completing the level is like a puzzle. And then you get sucked in by all the near misses and close calls. Solid idea, and I think it can be a success with some refinement and input (in particular from those who play games in that genre, not me lol.) Also, the save feature is nice, I can quit the game and come back to the level at any time.
Some notes :
1. At some point you might want to try setting up native Linux support.
2. Might want to set it up so that the executable can be run from any directory (probably not much of an issue for most users since they are just going to double click the file on Windows anyways)
Thanks for the nice words!
1. I'm open to the shipping linux builds (all of my code is platform agnostic, it shouldnt take much to compile it to linux), but the main issue is that I don't want to ship untested linux builds, i'll definitely ship them if I get a proper linux testing setup going.
2. The problem with that is that it requires walking up the directory tree in a way that personally seems nosy and undesirable to me, I don't like it when programs that I run do things I dont expect them to do.
To answer point number 2, what I do is have the program get the full path to the executable and do everything relative from there. I'm not sure if that is what you are talking about.
readlink("/proc/self/exe", buf, bufsize)
But I don't know how you would do things on Windows. You mentioned 'nosy' so I wouldn't be surprised if its a pain to do so. Either way the Readme was sufficient to get things working on my end with wine.
Leave a comment
Log in with itch.io to leave a comment.