Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

šŸ•¹ Game Review: Mayday: No Time to Wait

Submitted by: ArleGames

šŸŽÆ First Impressions
Arle is a returning dev, and it’s always exciting to see follow-up projects—especially when previous feedback has been considered and applied. Right off the bat, I noticed you can load a save that doesn’t exist, which probably needs a safeguard in your logic to prevent triggering that function without saved data.

Jumping into the game, I’ll give credit where it’s due: mouse movement has definitely improved from your last project. However, it’s still far too slow and unresponsive, making basic navigation feel clunky. The camera sway and movement tracking is extremely disorienting—it actually triggered some nausea for me. That alone makes this an immediate high-priority issue. Remember: the two things players do most are move and look. If either one is uncomfortable, it will immediately sour the experience.

Narratively, however, there’s a thread of cohesion. Despite the core mechanic frustrations, the fetch quests feel grounded and appropriate for the setting. With some work on fundamentals, this could become a solid little survival narrative.

šŸ”„ Fun & Engagement
Due to the camera and control issues, I had to force myself to continue playing. That said—I do see how this game could be fun with smoother mechanics. You’ve set up tension, stakes, and a reason to keep going. The bones are there.

šŸŽÆ Theme Use
Time as an enemy is reflected through your survival narrative—a literal race against the clock in a hostile environment. Checks the box for me.

šŸ›  Execution
Execution is rough in its current state:

  • Mouse look is sluggish and inconsistent

  • Movement and camera mechanics are disorienting

  • Dialogue transitions cause temporary lockouts, making it unclear if progression is happening

  • Melee animations are rough

That said, you did execute on structure and narrative:

  • There’s a clear through-line from A to B to C

  • Stakes are established

  • The gameplay loop has meaning

šŸ’” Originality
While the survival genre is well-tread, your crash survival premise brought me flashbacks to Hatchet by Gary Paulsen—and that’s a pretty unique lens to view this genre through. I appreciated the narrative angle.

✨ Polish
Still rough around the edges. Issues include:

  • Movement and camera (again, top priority)

  • Placeholder-like visuals with background artifacts (text visible in the skybox)

  • Clunky animations and UI transitions

These are all clean-up tasks that don’t require major systems overhauls—just time and polish.

šŸ›  Areas for Improvement:

  • Camera and Movement: This is your biggest blocker. If it feels fine in testing, compare your setup to what players may be using. If timing is involved in your code, make sure everything is normalized with deltaTime.

  • UI/UX Pass: Eliminate jarring transitions, fix the load system, and check for background artifacts (e.g., the text above mountains).

  • Combat and Animation: Consider investing time into animation timing and responsiveness, especially for melee actions.

🧠 Final Thoughts
It’s great seeing another submission from you, and even better seeing that you’re improving. While camera and movement still need work, there was noticeable progress from your last title, and that deserves credit. With more attention to core mechanics and polish, your next project could land much stronger. Keep putting in the reps—looking forward to what you bring to the next jam!

Thank you so much for this incredibly detailed feedback, i truly appreciat the time and insight you put into it!

To be honest, I hadn’t realized how disorienting the camera could feel. I’m truly sorry if that made your experience less enjoyable. You’re absolutely right: what feels smooth on my machine doesn’t always translate the same way elsewhere. I’ll definitely revisit the camera behavior and make it a priority.

About the dialogue transitions—my original idea was to temporarily block the player’s movement to keep them at a specific location where the story unfolds. But I now understand how that could feel like the game is frozen. I’ll think it through again, and if needed, I might add a small on-screen indicator to let the player know what’s happening (whether the game is paused or in a dialogue phase).

Regarding the mouse movement, I actually increased the sensitivity after earlier feedback, but it seems it’s still not quite there. I’ll look into it again and bump up the sensitivity further. Ideally, I’d like to add an option where the player can manually enter their preferred sensitivity value.

The floating labels like ā€œhill01ā€ weren’t mistakes—they were intentionally added to help players navigate the environment, since I haven’t implemented a minimap or directional arrows yet. That said, I’ll look for a more elegant solution in the future.

The melee combat system also needs some polish—you’re right. Just like the camera, it feels okay on my screen, but the experience can vary. I’ll rework that part as well.

I didn’t know about the book Hatchet, but it sounds interesting! If I get the chance, I’d love to read it—who knows, maybe it’ll inspire some new ideas for the future.

Lastly, about the save system: it’s something I’m still learning to handle properly. The current setup just loads the initial game phase by default if no save is found. But I’ll improve it so that loading is only possible when an actual save file exists.

Again, thank you so much for the support and helpful advice. It’s very motivating—and you’re right: the next project will be stronger, thanks to everything I’m learning and to feedback like yours!