It wouldn't even start, regrettably - most likely due to me using 'firejail' and me running on an ancient potato of a laptop. Might have gotten the same error in DD39.

[2021.11.09-20.52.20:130][  0]LogInit: Initializing SDL.
[2021.11.09-20.52.23:938][  0]LogInit: Warning: Could not initialize SDL: Could not initialize UDEV
[2021.11.09-20.52.23:938][  0]LogInit: Warning: FDisplayMetrics::GetDisplayMetrics: InitSDL() failed, cannot get display metrics
...
[2021.11.09-20.52.23:977][  0]LogInit:  -virtmemkb=NUMBER - sets process virtual memory (address space) limit (overrides VirtualMemoryLimitInKB value from .ini)
[2021.11.09-20.52.23:978][  0]LogInit: Initializing SDL.
[2021.11.09-20.52.23:984][  0]LogInit: Warning: Could not initialize SDL: Could not initialize UDEV
...
[2021.11.09-20.52.24:740][  0]LogInit: Initializing SDL. 
[2021.11.09-20.52.24:742][  0]LogInit: Warning: Could not initialize SDL: Could not initialize UDEV 
[2021.11.09-20.52.24:744][  0]LogInit: Error: FLinuxApplication::CreateLinuxApplication() : InitSDL() failed, cannot create application instance.

I really don't think that my ancient potato of a laptop will be able to run this, but: Do you have any minimum & recommended specs for running your game? I did not see any on https://tomodev.itch.io/pinkturtle-wip .

Thank you very much for playing and for the review!

I fear that the game still has a considerable "difficulty cliff" instead of a "difficulty ramp" - it was even worse in previous versions, but I am getting a strong impression that it is still not good enough yet in that regard. I think I should introduce more intermediate levels. I also designed one part poorly, for the level right after "Attacks from 3 sides" is one of the challenge levels, which is in its own level pack, and only the level description hints at this - I think I will add different graphics to the "previous level"/"next level" buttons when the previous/next level is in another level pack, and make it obvious (in addition, different background graphics for each level pack could also give a better indication that the level pack has changed). I also think I need to reinforce concepts and approaches more, and make the player less reliant on level description text.

As for more features, I have already added a minor mechanic in the not-yet-uploaded version, and I do plan to introduce a greater number in the future - including but not limited to unit conversion, various kinds of "status effects"/similar (like slowing), and other mechanics. I also intend to improve the AI, including AI that kites and for some unit producers slightly more complex approaches (like gathering units and sending out parties of units instead of sending off units one-by-one to their out-numbered deaths). Homing/gravitating missiles could also be fun.

I managed to get it running by downloading the Windows version and running "firejail wine ./Poke\ ALL\ Toads\ v0.07.exe" , something that also worked for another Godot game.

The game seems nice and very polished, I honestly don't have much to add.

The one thing that irked me a bit was the exploration/trial-and-error part - being able to scroll around the map and view it, as well as seeing where jumps go, etc., would be nice. However, only a fairly small amount of time is spent for the player on this, and I can imagine that adding the controls, UI, etc. necessary for avoiding this exploration/trial-and-error part is likely considerably larger than the gained benefit both game-design-wise as well as where to focus on improving the game. By "exploration/trial-and-error" I mean stuff like which point a jump-arrow tile goes when not hindered (for instance the level "Caution is for fools"). For any future longer and more difficult levels, where puzzles are harder to figure out, designing the levels in such a way that you can see the whole level easily from the start, as well as having "exploration/trial-and-error" happen somewhat early and at least not late, might be a good idea (unless part of the challenge is to figure the level out without being able to see it all at once). What would be bad in my opinion would be to for instance have an unknown/difficult-to-predict jump-arrow tile at the end of a very long level, making the player start all over again (this is OK for shorter levels).

There's also some silly "haha got you" parts, like with jump-arrow tiles going into space, which I personally am not quite a fan of. Though it fits the "pranky", silly and playful style and aesthetics of the game, so this might well be a positive and nice for players in general than anything else. It might also fit very well with the game's intended audience and market. Just be careful to ensure that it never takes a lot of the players time.

Edit: Clarifies a bit.

Maybe just a direction indication which indicates in which way the levels are unlocked?

I regrettably cannot test it well, but I can run it by using "firejail wine bearcycle.exe" with the Windows version.

I get the impression that it is getting to a rather good state.

The only real proposal I have is to add some sort of graphical level options, where you could disable effects and similar, such that it can run more easily on lower-end computers (or abysmal-end like my ancient potato of a laptop 😃 ).

I think the next demo you upload, I will see if I can run it in something like a sandboxed environment on my Android phone (in case you want this and want to encourage me and others to do so, maybe write a small notice for this in the submission next DD, including such that I don't forget). I would imagine that you at this stage might benefit most from Android-testing, especially if Android is a major platform (apart from getting more content - I imagine there is a decent amount of replayability in getting all the collectibles, though I could imagine that you might plan a level section or two more). That said, I believe it is possible in Android development to share APKs with others through the Play store by making a limited beta. You have to set up a number of things when deploying at the Play store, but then you can give out keys to people you want to test - better in multiple ways than sharing APKs, though it does require paying and setting up with Play store.

I think Android-testing would be especially valuable, since it is really useful to test on a number of different Android-phones hardware-wise (and Android-API-level-wise maybe?). As I recall, you are using Godot, so how well it will run will depend a lot of Godot, though I developed and published a smaller Godot game a few years ago, and I recall the process was relatively smooth (exporting to HTML ended up not being possible, however, since the particle systems I used unexpectedly were not supported for web... they later added a warning for that, at least - but I should also have tested exports for the different platforms much earlier than I did, so not being able to export to web was mostly my own fault).

While you are targeting Android; Do you have any plans to target Steam as well?

Thank you, the game runs much better now.

The game seems really nice overall, though I haven't gotten far into it. The "platformer/exploration/exploration-puzzles/upgrades" part reminded me of Metroidvania style games.

What does the eggplants/aubergines that enemies drop do? While med-kits healed my character, the eggplants did not seem to heal my character. They didn't seem to affect ammunition either. Are they a future kind of currency? There are costs in the armory.

Very minor: When exiting the first "fight in elevator", the camera suddenly zoomed a long way from above.

I went with the "Benthic Desires" and "Fallacy of Flesh" artifacts, as well as the "Healing field" activation item. I imagine that you would normally only get those later on. The "Benthic Desires" might undermine one resource management aspect, but the intensive fights I encountered were typically in closed arenas where you may not flee and where standing still is typically a bad idea 😃 , so it may not break that aspect either way (I also don't know how artifacts are/will be handled in future versions - one artifact hinted at artifacts being affected/lost upon dying and respawning).

What happens if you run out of ammunition during an extended fight?

I believe I encountered one issue with one exploration-puzzle:

This occurred after I rotated it a couple of full rounds, becoming a little bit more skewed each time.

Thank you very, very much for the kind words as well as the video review!

I am beginning to think that my game may be harder for people than I initially thought, especially for people that do not play games similar to this one often (as you mentioned in the video review for DD39, you don't play these types of games as I understood it). Even prettysober, who is somewhat of an expert in playing a wide variety of games, found the game challenging (which I found was good, though it may be too challenging - there ought to be a (much) greater variety of levels regarding difficulty, such that people can learn, play around and improve and take on greater challenges at their own pace). What makes it harder is that it is in some ways like an action-puzzle - the tactical/puzzle part can be challenging, and then handling and figuring out the tactics/puzzle part while action is going on only makes things harder. Being able to pause and inspect the battlefield at any point in time should help with this, though that does take more real-life time for the player and is not something that players (including myself) is used to be able to do in games with action elements (it also consumes time during a review, which discourages doing it as well). For puzzle-games, there are typically video or text walk-throughs made by the authors of the game for each level; given that this game both has somewhat complex action and also tactics/puzzle elements in it, it is in some ways more difficult than regular puzzle-games, and thus it might be a good idea for me to publish walk-through videos for each level.

Also, thank you for the very kind words on the tutorial and the improvements I made (your video was really, really helpful for improving it, thank you very much again 😃 ), though there is definitely still a lot of room for improvement.

Edit: Also, some features and functionality that would make the game easier to learn and play are still being developed, which makes the game even harder than it should be, triply so for people that don't usually play games similar to this one.

Please do note that first, my laptop is an ancient potato, and second, I used "firejail" to run the game with, and third, it is not the first time I have encountered similar issues with other Godot games, so the problem may be entirely on my end and not at all with your game. So please also get feedback from other users of Linux 😃 .

See https://pastebin.com/YU8Ngjth for the command and command line output.

Alathough no, there is actually no "source" and "derived" images.

But... aren't most of the images interpolations of other images? I might have been unclear, if so I apologize. I meant "derived" as in "interpolation of two or more other 'source' images", and "source" as in an images that is not interpolated from other images and instead is interpolated from by other images".

Nice little game. I wonder if a minor improvement might be to have a small graphical indication for which tiles are "source fields", and which tiles are "derived fields", assuming I am guessing correctly on how it works. I guessed a bit in the last level on that.

Would it be possible/feasible to use this approach with non-animé/manga characters?

The fireball actually does have friendly fire - it is very powerful (and also cost-effective), but if you are not careful, you can end up damaging your own units or yourself with it.

I have uploaded a video of how to reproduce it here: https://streamable.com/rwbzy7 .

Good to know that all levels are beatable, I might give it a try later :- ) .

The game is definitely meant to be difficult and challenging, and I am not certain I make that clear enough. My descriptions of the difficulty of the different levels might also be misleading (hopefully not too much). As I recall, when I uploaded to DD39, the difficulty was a rather tall difficulty cliff and not a difficulty ramp 😃 , so I have definitely messed up difficulty levels in the past, and I might well have to adjust it further. Maybe mix in some easier levels earlier that teach and reinforce concepts more?

Thank you for the review, Tomodev 😃 .

walking at roughly the same speed as my enemies away from them until they catch up at a corner and kill me

This sounds like it might be a bug I haven't encountered before; the fast slime enemies should be a little bit slower than the player, enabling the player to kite them indefinitely assuming that there is enough room to kite them. If so, I apologize, that is a rather bad bug. Can you confirm that the player is not sufficiently fast to kite the fast slime enemies indefinitely given enough room and no bullets?

I tried to run the game with

firejail ./'Poke ALL Toads v0.07.exe.x86_64'

on Linux, but while I got into the menu successfully, and selected a slot with success, the game crashes with a long stack trace. I have encountered similar issues with Godot games in the past, and my laptop is an ancient potato, so the problem might well be on my end. I could also imagine running the game in a VM instead of using Firejail would work.

The music, audio and the menu seem nice, however.

Thank you for playing the game and for the very nice comments : -) . I have added the different points and suggestions to my TODO-list, I think you are right about them in general. As for directing and interacting with allies, I have gotten that feedback previously as well (one suggested looking into Pikmin controls as a source of inspiration). I am considering something along those lines (a predecessor game allowed very, very basic instructions), though I also hope to have AI that is a little bit more advanced, just basic stuff like with units massing at a unit producer before attacking, instead of them going one-by-one and dying, for instance. I am also considering stuff like healing as well as some sort of "temporary (de-)buff" system. Unit conversion could also be interesting, I believe. Again, thank you :- ) .

For the invisible mouse cursor issue, restarting my laptop did fix the issue - I still cannot help but wonder whether the bug might be specific to Linux, or even a bug in Ubuntu/elsewhere. While Linux distributions tend to be robust, they are much less often used for games than Windows is, and thus the features that are commonly only used in games are much less well-trodden and tested in Linux than for Windows.

You're welcome :- ) . I believe the expression "DOM-based" UI is a self-made description by me, it was the best description I could come up for differentiating it from "Canvas-based" UI. Canvas-based UI is very rare outside of niches such as web games as far as I know, so when referring to web UI, DOM-based UI is (I believe) the norm and what is typically assumed.

Seems like a fairly nice and somewhat large game. It has a very large number of weapons, and it had a number of special abilities/artifacts.

I tried running the game on 30 FPS (due to my laptop being an ancient potato), but I ended up getting a number of issues with physics and platforming (see https://streamable.com/nbrfj9 ). When I then tried to run it on 60 FPS, everything worked well (apart from it being a bit slow at times due to my laptop being an ancient potato). Are the physics update loop time-step-size fixed or is it based on time elapsed? If it is based on time elapsed, that can cause a number of issues. I am not an expert on this topic, but I believe one common approach is to let the time-step-size for graphics be time-dependent, and make the time-step-size for anything physics-related or game-logic-related be fixed. Otherwise, the simulation may change dependent on FPS, lag and similar, which can cause a variety of issues. Though, this might also be a Linux/'game engine'-combination issue. Box2D has a fixed time-step-size, right?

My mouse cursor pointer has also turned invisible after quitting the game (despite me using "firejail ./HadalCalm" ), and entering the game, changing the cursor to "default", and exiting, did not fix it. I am currently hoping that my mouse cursor pointer will turn visible after restarting my laptop :- ) . However, I suspect that it again is due to me using Linux.

Repeating what Tomodev said, a nice little puzzle game.

I believe I encountered a bug in this level:

Did you test and complete all levels before uploading?

The DOM-based UI libraries I think of are the major ones, such as React, Angular, Vue, etc. However, these options comes at certain costs, especially the part where you mix Canvas-based graphics with DOM-based UI. For my game, I thought the trade-offs have been worth it (using a web game framework together with React), though it is by no means a free trade-off. I would recommend that you investigate it thoroughly before attempting it.

For browser-based games, I believe there are 4 main options for UI in a game:

• Roll your own UI in Canvas - this is what you are currently doing. It doesn't quite scale without a fair amount or lots of effort into the UI library itself, and writing a good UI library is not easy, but you skip the issues with the interaction between DOM-based UI and Canvas-based graphics and the issues with DOM-based UI itself.
• Use DOM-based UI. The interaction between a DOM-based UI and Canvas-based graphics has a number of challenges and issues, and DOM-based UI does have drawbacks of its own (the DOM APIs are many and often large, meaning that even mainstream browsers like Firefox and Chrome will have bugs or missing functionality even in somewhat basic features - these are some of the browser bugs I encountered: https://bugzilla.mozilla.org/show_bug.cgi?id=75324 , https://bugs.chromium.org/p/chromium/issues/detail?id=836244 - and this is worse for mobile browsers - and since web game using DOM-based UI have much less well-trodden parts than regular web applications, expect more and worse issues). You can then additionally use a DOM-based UI library, like React, Angular, etc., which have their own benefits and drawbacks, including in the interaction with Canvas-based graphics.
• Use a web game framework that features its own Canvas-based UI library. It depends on the web game framework in question how well-developed it is, and web game frameworks tend to have less momentum than the major game engines.
• Use a game engine that exports to web and which features its own UI.

Of course, it also depends on how much you want to invest into the project, your goals with the project (is it learning? Is it to show off something to others? Is it a long-term project? Is it commercial? Etc.), and so on. I do know of at least one (commercial) project that combines a Canvas-based web game framework with a DOM-based UI library: "Citadels" (there's Facebook and Android versions), by this Russian company: http://corpwebgames.com/en/ (grinding game I believe - I don't play that kind of game, but someone mentioned it as an example of a major/popular game made in the same web game framework that I use for my current game project, and I looked a little bit into which technologies it used in both the web version and the Android version - I recall it using Cocos2D-X or something on Android).

Nice concept and a number of nice things in the game.

Is it correct that the game is written against pure Canvas-API? Not using some web game framework or game engine that exports to web? And not using WebGL with Canvas? And also not using DOM for the UI? If so, the game is somewhat impressive, though I could imagine that you could accomplish considerably more if you used some of the options I  mentioned. That said, those options do come at some costs. In the game I am currently developing, I think it was worth combining Canvas-based drawing with a DOM-based UI library, though that does pose a number of new challenges and issues in itself. And learning a web game framework or game engine does take time and effort, and likewise if you additionally use a DOM-based UI library.

Pathfinding and AI in strategy games can be somewhat complex. If you do not have an education that included algorithm development and analysis, this part of the game might regrettably become a big challenge - I tried to move maybe 10 units from one walled-off "shelter" to another, and the game (on my ancient potato of a laptop) ended up being stuck for maybe half a minute until I closed the tab. You can learn a lot developing a game like this - but studying algorithms and data structures directly might be helpful or necessary. If you have a talent for mathematics and logic, and have time to study this subject, this may be especially opportune. But even with algorithmic knowledge, designing the game to make it easier to handle pathfinding and AI, and having creativity when figuring out solutions to pathfinding and AI, are typically good ideas. The map being tile-based does help in this regard.

While not strictly necessary, if you don't mind learning a new programming language, or find it fun to learn new programming languages, and you either are good at setting up Javascript projects or else can find and use an existing template for a Typescript-using project, Typescript might be a nice option to learn. Though the technologies I mentioned first are more important for the game itself.

Which IDE do you use? Visual Studio Code?

Yes, that did fix most of it, it is fairly nice now :- ) . The cut-scene events and dialog messages were nice and worked well.

As for accidentally deploying debug builds, I had a similar problem before I slightly improved the way I built and deployed my current game (it was made more complicated by uploading to both Itch and Kongregate, though I only upload to Itch now), and I have also encountered the same problem in a number of other Itch games in previous jams. My build and "asset pipeline" process is almost fully automated, though my project is also very simplistic and primitive/limited in regards to its graphical assets, which I believe makes it much easier to automate (I even wrote a script using Gimp as part of automating the asset pipeline :- ) ). The deployment process to Itch is still fully manual for me, however. I believe that Godot handles most or all of the build/export process, it has been some time since I last used Godot.

You seem to have added some nice updates to your project.

I encountered a bug with the dialog system: I pressed "Z" next to an NPC in the town, and I ended up getting this dialog, which never went away, even when I exited the town, and I couldn't attack in this "state":

As for combat, the dragon boss as such is nice. For some enemies, mostly wolf, I was confused about the size and positions of collision masks (both the unit collision masks as well as the collision masks for attacks) - attacking with the main character from certain directions seemed to hit more easily than for certain other directions, though I might be mistaken about that.

As for minor aspects, I wonder whether some sort of "Z"/order-system or depth system could be useful - currently, the character stands on top of trees. For some background and other objects, making its "origin" be the base of the graphical element (like, for a tree, it would be where the trunk meets the ground, for instance, and for humanoids, it would be where their feet meet the ground). I also had some issues with movement when attempting to slide along palisade walls, stopping momentarily and only after about a second continuing.

I would like to re-iterate my warning about scope, but it very much depends on your own goals for the project, so the current course might be on point :- ) .

The concept seems really interesting.

Have you considered using Typescript? There's a template starter project for Phaser 3 on Github using Typescript, which might be useful to adapt to your own project.

Seems like a nice little game, though I didn't get far before encountering a bug upon dying (and dying subsequently a lot of times):

I think it would be good if the default music volume was a bit or somewhat lower.

Nice Sokoban game, with good graphics.

I suppose you could add an 'Undo' button if you wanted and think it would be nice.

Nice beginning to a game, several parts seem nice, and there are both animations and decent and clear graphics.

About the look-ahead mechanism, I believe it might be nice if the view changes more gradually at the beginning of changing look-ahead. Currently, when you are facing downwards and going up a bit, or vice versa (all along the vertical axis), the initial view-movement of the look-ahead makes the view start of with somewhat suddenly move in the new player direction, while the ending view-movement is more gradual and smooth. I am not certain that I am explaining what I mean well. There are no issues for the horizontal direction, which may be because of the view being larger horizontally.

It is currently possible for enemies and the player to be completely hidden behind obstacles, which I think is an issue. While it in some ways fits the geometry and graphics well, I believe that it would be a good idea to either prevent monsters and the player from going to such places where they can be completely hidden by the terrain graphics, or else give some graphical indication (like showing a color outline on top of the graphics for the unit that would otherwise be hidden). For this game, I could imagine that both the best and the easiest approach would be to simply prevent units from going to such places, for instance by placing collision masks/similar on tiles where units would otherwise be obscured - though it may be best to reference similar games and see their approaches.

You seem to have a nice beginning to a game, though it seems like it could also have a somewhat large scope. About the scope: If you mostly just want something to work on once in a while, and it is not a strict requirement to have something very playable and fun for others, I think it is fine as is, and that can be useful in multiple regards, both for learning, experimentation, playing around, etc. However, if your goals include the game being fun for playing, I think managing scope, managing resources, planning, etc. would be a very good idea, especially if you are the sole developer/programmer. Since the game is inspired by SNES RPGs, and I would assume that SNES RPGs typically had teams of developers and other professionals behind them working full-time for longer periods, I think two approaches might be useful (though this is just somewhat superficial ideas I have off the top of my head, and they do have drawbacks even if they work as intended):

• First, to cut features, scope, etc. out from typical SNES RPGs while still maintaining the properties of the game that you would like to keep, like exploration and discovery, challenge, fun, story, etc., in order to decrease the scope of the game and increase the chances of success;
• and second, to create different "stages" of the game development, where each stage has something fun and playable and easy to share with others, while still allowing for continuing with increasing the game and its features and content with the next stage. That way, even if you do not reach all stages that you would like, you still have a nice and fun game from an earlier stage. I think a number of development processes for various games do this in various ways - for instance, some games split their content into for instance chapters, and then once deadlines approach, cut content from (typically later) chapters (or even cut whole chapters, with varying levels of elegance of the cut). Some game development processes also end up postponing content/mechanics to sequels.

- that said, this is again just somewhat superficial ideas I have off the top of my head on how you could approach this. And if your goal is more learning, experimentation, exploring game design and development, having fun with developing (which is important in itself :) ), etc., these ideas for development might well be counter-productive. It depends on your goals as well.

If I may ask; which game engine/framework and libraries are you using for the game, and which programming language are you using?

(also, sorry for the long rant :) ).

A nice little game.

A way to restart the game would be nice.

I also think some sort of pause functionality (for instance accessed through a button), that still lets you investigate and ponder the blueprints and resource tree, could be good, though that depends on the game's design - it could make sense not to include such pause functionality, especially if the game not allowing pause is part of the challenge.

The game seems inspired by "factory" games such as Factorio, Satisfactory, shapez.io , and the like. I guess it is because the game is early in development, but one thing I am wondering about is how the game handles a surplus of resources at a node. Unless I am mistaken, there are no graphical indications what happens with it, whether it is stored or whether it simply disappears, which would be a little bit nice to have.

I succeeded in rushing out a new Sniper bot assembly line, and that ended up base-camping the enemy teleportation portal without any more actions from me, for at least wave 15 (I didn't use the existing assembly, so both Microbots and Sniper bots were produced). It was a bit annoying having to scroll up and down quickly to get transport belts, though that added to the challenge (and in hindsight I probably should have planned ahead and tried to place all the transport belts either before or after the other dispensers and processors.

Thank you for the feedback, your feedback is very similar to the feedback that has already been posted, and I am still busy addressing it :) .

I do hope to add lots of easier levels, though the game will also have a number of somewhat harder levels. I suspect that some of the levels are harder than they should be due to parts of the game that are missing, which I need to focus on and fix. For instance, the player gets no feedback on how much time they have until they can take an action again, and the cool-down of actions is only available through a tool-tip in the in-game documentation. That makes the first producer level harder. I have gotten a lot of excellent feedback from the jams I have participated in, and since I have a lot of feedback that I haven't gotten around to address yet, I think that I will not participate in further jams or the like until I have addressed it.

As for sound and audio, as you write yourself, others have written that as well :) . I do hope to avoid overstimulating the player, which I think would be good, though audio feedback to the player can be helpful in a number of ways.

By running 'firejail ./Multris', I get this error:

./Multris: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./Multris)

I am running Ubuntu 20.04 if it is any help. I imagine that this specific error would go away if I upgraded to a newer version of Ubuntu.

Surprisingly fun (and silly) game, somewhat rough, but nice. Arguably a bit "horror"-like and psychedelic in style.

That makes sense, though by itself in this case it may be counter-productive in some ways.

Any alternatives to the '.nes' file? Or a link to instructions on how to run it (I assume by downloading some NES-emulator or similar).

Running with the Linux version failed, and running 'firejail wine Multris.exe' on the Windows version resulted in my 'Gnome' desktop freezing, using Ubuntu 20.04 :( . Though it should be mentioned that my laptop is an ancient potato.

(why is the game page black text on black background?).

Nice beginning of a game (I played the web version).

I think it would make sense to make the camera focus on the player or at least always keep the player in the view, possibly having the camera quickly move such that the area in the direction that the player is moving has the largest part of the view, so to say. And then to signal where the player will be killed by having a graphical line/rectangle (for instance transparently red) that marks the "death line/zone", and where the speed of the "death line/zone" is dependent on the difficulty level (like low initial speed and maybe low/very delayed acceleration on "easy" difficulty level). The "death line/zone" would be completely independent from the camera.

In addition to that, you could have a minor mini-map, for instance in the lower left corner - possibly only showing the "death line/zone" and how close it is to the player's (or alternatively the camera's) position. Not all runners have this kind of stuff, but I imagine that it could work well in this game, given that the player can move ahead of the current game iteration's camera.

A lot of what I otherwise think have been covered decently by other reviews.