Play game
Evil Past, Vicious Future's itch.io pageResults
| Criteria | Rank | Score* | Raw Score |
| Creativity | #1641 | 3.824 | 3.824 |
| Enjoyment | #2603 | 3.235 | 3.235 |
| Audio | #3178 | 2.941 | 2.941 |
| Artwork | #3610 | 3.118 | 3.118 |
| Narrative | #5588 | 2.000 | 2.000 |
Ranked from 17 ratings. Score is adjusted from raw score by the median number of ratings per game in the jam.
How does your game fit the theme?
You have to do the same task each time as you stuck in a time loop, dealing with your versions from the past
(Optional) What would you like to be called if GMTK features your game?
Misha
Leave a comment
Log in with itch.io to leave a comment.
Comments
a very fun game! a cool soundtrack to flex to
Thanks
I liked this game, great use of the theme!
Thanks
I had a very similiar idea with dealing with your past selves, nice to see more game using that aspect of the loop. If I may give criticism, the clones hp should lower after each loop they are on the map, not by a really high value, just a little bit lower. You usually run out of time before getting to kill everything. Still this a really good game!
Yeah I'm a bit surprised that many people interpreted the theme the same way as us xd
Thanks for the suggestion!
Nice!
I think the game would benefit from some randomization, so that level is not always the same.
also why do clones have sooo much hp :(
Haha thanks! appreciate the advice
Fun game and mechanic, our team was something similar so its good to see someone execute a cloner loop idea, well done!
Thank you! Did you also submit a game to the jam? Because it doesn't appear for me (or I misunderstood your comment)
Cool puzzle!
I know how hard it is to make a perfectly reproducible replay, especially with physics simulation, when every tiniest difference entirely changes the outcome ¦3
I like the scattering transition when you return to the menu.
And the eurodance is my weakness, great track by Cecilia! (I hope you have the permission to use it, though ¦3)
Thanks! My goal wasn't to make the enemies repeat the player's position from the last stages (like in your game), but rather have them act as they are giving the exact same aim & keyboard input as the player did in his past (I'm basically saving the keys the player is pressing and the position of the mouse in every given moment, instead of his position), this leads to a way bigger chaos and change of plans ;)
Yeah, I do the same recording and replicating of player inputs ¦3
What I discovered was that to make it consistently reproducible, I had to somehow tie each input to a specific step of the physics simulation. And then having physics calculation at a fixed rate allowed me to use the count of such physical steps as a pretty solid measure of time for inputs (e.g. if I repeat the "jump" action exactly at step 119 every time, the end result will be exactly the same, if the surrounding world hasn't changed).
However, in your case, with all the moving platforms that would not work, as in the next run you can change the configuration of walls, making previous enemies hit them as they move, changing the result of their movement.
So that's a pretty hard task ¦3
You're absolutely right, but luckily that's exactly what I intended when I made the possibility to move walls, and block other players. I didn't want them to follow exactly the same path as they did in the last stage because in the context of my game that would turn everything boring (I rather want a similar behaviour and only an estimate of the path).
Hope you don't mind me asking how did you make your game? (Engine/language) your explanation is interesting
As some runs I tried very hard to keep all the walls intact in hope that a perfectly recorded replay will help me killing some of the enemies (unfortunately, it didn't work, though).
My tech is not very straightforward to explain, but in a nutshell it's just WebGL on Kotlin/JS without any engine, using a port of Box2D for physics ¦3
But I am pretty sure the general approach is engine-agnostic.
Yea I agree, I also coded this with JS only
I saved and pulled the input data in my update loop, which made it synchronized even when the call interval slightly changes (I guess that that's what you meant)
Good luck on the jam ;)
Yeah, that really depends on your implementation then ¦3
Usually, the update loop is based on requestAnimationFrame, which can return inconsistent durations. If you apply a force for 0.00161 seconds, it will be different from applying the same force for 0.00159 seconds. This delta time can be used for animations and visual stuff, but for consistent simulation, it's better to use a hardcoded step (usually referred to as a "fixed update" in different engines and articles), for example, exactly 0.0015, and sometimes you may have more or less than 1 physical step per rendered frame.
But I checked your code, and it seems that you already use the fixed update, so all of that explanation does not make much sense ¦3
Thanks, good luck to you too!
Nc
ty
Wow! what a concept! sadly I wasn't able to reach past stage one ):
Edit: I tried again and I got further and saw the concept in action. very cool B)
Thank you!