I think the audio file got corrupted, i downloaded it 3 times and it consistently blasts earrapingly loud noise between 0:03-0:43 before going back to normal.
The music itself is really nice tho
The way the movement gradually speeds up instead of being a constant speed is just wrong. In a platformer you want to make the player feel like they're in control of almost everything and actually being in control doesn't always mean feeling like you're in control. Instantly responsive movement in a platformer makes the player feel more like they're in control and anything else just makes it worse.
Rotating the camera together with the player like that can make the game feel very disorientating, but fortunately there is a very easy solution to this: smooth camera movements - instead of snapping the camera to the player make it a separate object and move it smoothly to where it's supposed to be. There are two ways to do this:
1. At each frame move the camera by the difference between the players position and it's own multiplied by some constant between 1 and 0. This approach would be best for rotation control.
2. Alternatively if your gameplay features teleporting the player around or having them move quickly you can move it by the difference squared multiplied by a much lower constant.
Advanced camera controls like this are mostly only used in platformers and other games that require some precision but they can be used any time your camera controls feel disorientating.
Now that i've spent ~140 words yapping about the camera, I can say finally say that considering all the aspects that actually matter, this game is one of my favourites this jam.
To point out something that not many devs take into account: self-balancing - this is what i call the tendency of certain game mechanics to subtly balance themselves in response to the players abilities. This game does this nicely; when that player grows larger algee spawn and once the player inevitably starts getting hit and losing in size all of those large algee stick around providing an extra chellenge to the players that proved their abilities by getting big in the first place.
As for the bad part: the hitboxes are way too unforgiving. Remember: our reaction time isn't zero, for anything that the player interacts with hitboxes should always be a little (or sometimes a lot) smaller than the object itself. This has many good effects like making mistakes feel more like the players fault (first rule of game design) and giving the player a sense of cutting it close when they pass slightly through an object but don't get hit.
I love the atmosphere in this one, that combined with the simple objective of shooting at viruses which forces the player to think about their actions is the perfect formula for a great horror game. To put it simply when a player is forced to consider things in order to progress through a simple objective (keeping track of the maze, spotting viruses, listening for sounds, etc.) they might lump the slight fear from the creepy environment in with the things that actually influence the objective. This causes them to see danger where there is none - exactly what every horror game wants to accomplish.
As for the camera: i really like that you have a freely rotating one instead of the same kind that almost all games use - so many games that feature cave exploring get this wrong (cough-cough-subnautica). Y-inverting the camera movement was definately a mistake tho, that tripped me up the entire time i was playing.
Overall, good game for 6 hours.
Gotta say, I've only rated a few games so far but this one is just amazing. I like how it creates a survival experience by simply alowing the player a bit of control over which parts of the map are safe-zones and establishing a clear but dynamic objective. Overall great game, especially given the dev time; would absolutely play longer if there were elements after oxygen.
you could, but doing them in parallel makes it a bitwise operation, or in simple people terms: this way the operation completes instantly. this is important because it means you can throw in another input without having to wait for the previous one to finish looping. in traditional division you subtract the divisor from the dividend and count how many times you can subtract before you reach 0 (15 - 5 - 5 - 5 = 0, so 15 / 5 = 3) the long division algorythm takes this operation on numbers and expresses it as an operation on individual digits, the whole point of it is to be bitwise.
there are three wire states: high-voltage (red), low-voltage (dark-red), no-voltage (black). normally when an input receives 2 conflicting wires (low-voltage and high-voltage) it will flicker, but if one of the wires is no-voltage it won't conflict with the other, this is incredibly useful for merging signals from multiple chips onto one output.
use the long division algorythm:
start by considering only the MSD (most significant digit) of the dividend (blue) by setting it as the LSD (least significant digit) of the remainder and subtracting the divisor (yellow) from it. if the result of the subtraction is not negative then the quotient is at least 128 which means we can set that as the corresponding digit. next left shift your remainder and set the LSD as the next bit of the dividend (64), from here just keep on repeating this process until you have each digit of the quotient, after which the remainder will also be done.
i hope my reply to your previous topic helps: https://itch.io/t/2950562/some-ideas#post-8427360
the button idea is absolutely possible like this:
inside the pulse chip:
the rest of the chips you should be able to find by just searching up their names
the multi-wire would be a lifesaver for me. it's possible to make a thing that uses a clock to encode a bunch of signals on one wire
and a synced clock on the receiving end to continously update the signals but the more signals on one wire the longer the potential delay before it updates on the receiving end
in this approach each bit will update every 16 frames, it's also possible to make a 4-bit multi-wire that updates every 4 frames, any other number of bits would be sub-optimal since the clock has 4 settings: every 4 frames, every 16 frames, every half second and every 1 second. also in case you can't see from the images each pulse chip activates the pulse chip below it
here's the modded version i made for more space: https://www.mediafire.com/file/nrry9bvscl2ki8f/DLS_%2528modded%2529.rar/file
W A S D - move
E - zoom in
Q - zoom out
i don't have any ideas for a screen but i'll definately post about it if i come up with something
an HDD is unfortunately impossible without modding the game, if you open one of the JSON files that store the chips, you can see that it only stores the subchips, their positions and all of the wire connections
also here's the modded version i made for more space: https://www.mediafire.com/file/nrry9bvscl2ki8f/DLS_%2528modded%2529.rar/file
W A S D - move
E - zoom in
Q - zoom out
the showcase got kinda broken during compression, sorry for that
inputs:
prev line - moves to the previous line
next line - moves to the next line
WRITE - writes the specified bits to the current line
EXECUTE- increments thru the lines one by one
bit [1 to 16] - the specified bits to be written
next i'll attach it to some simple CPU
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
progress update!
the console records a number or letter on the bottom displays pushing older records up
it's also full of spaghetti
i also replaced the "counter" with a "navigator" which allows me to choose how many lines i want to go forward by rather than just incrementing and decrementing
there are 64 lines in total and they rollover so moving forward by 63 lines is equivalent to moving backwards by 1, this allows the creation of "while true" loops
conditional loops will also be possible with this when i add math and logic operations into the CPU
here's what the ISA for this looks like at the moment with unimplemented features written in bold text:
10-ww-xxxx-yyyy-zzzz - logical test
writes 1 to xxxx if the logical test is true and writes 0 otherwise
ww:
00 => yyyy != zzzz
11 => yyyy == zzzz
01 => yyyy > zzzz
10 => yyyy >= zzzz
01-ww-xxxx-yyyy-zzzz - math operation
performs a math operation on the numbers from the registries yyyy and zzzz, writes the result to the xxxx registry
ww:
00 => yyyy - zzzz
11 => yyyy + zzzz
01 => yyyy * zzzz
10 => yyyy / zzzz
0010-xxxx-yyyy-zzzz - modulo (division remainder)
writes the result from yyyy % zzzz to the xxxx registry
0000-xxxx-yyyyyyyy - write to registry
write the bits yyyyyyyy to the xxxx registry
11000001-x-yyyyYY - jump back
if x is 0 it jumps by yyyyyy lines, if x is 1 it jumps by the number of lines in the yyyy registry (last two YY is ignored)
jumps by the number of lines in the yyyy registry
keep in mind that there are 64 lines in total and they rollover so jumping 64 lines won't do anything and jumping 63 lines will jump forward by one
11000011-x-yyyy - print to console
prints the number in the yyyy registry if x is 0, displays its letter representation if x is 1
11000000-xxxx - input
writes the input pins into the xxxx registry
the program running in the video is:
0000 0000 01000101 //save 69 into registry 0
0000 0001 00010111 //save 23 into registry 1
11000011 0 0000 //print the contents of registry 0 as a number
11000011 1 0001 //print the contents of registry 1 as a letter
11000001 0 000010 //jump back by 2 lines
if anyone wants a screenshot of any of the chips i'm using here, feel free to ask.
lastly i have a question, which of the below looks more like a W?