I can see that Tenet like puzzle at the end has insane potential. Like, the player could be made to find the correct time to rewind a clone so that one thing is untriggered and another is still triggered, and also use time paradoxes where one clone can't fully execute his path because something else triggered in the meantime. I'm getting excited.
What I did in my project was to not have the object be a child, then on the object ran a coroutine that kept the object in the right position each frame. Whenever something else needed to happen I'd just turn off the Coroutine and let that something else happen. This gave all the benefits of having the object be the child of the thing it should in a specific distance to while avoiding randomly tripping over local vs world space issues.
Simulating Unity's parent-child relationship like that also works. If I run into this issue in other places than when rewinding transforms I might take that approach for better visibility and debugging on what is going on.
@@BobsMudHut Yeah, it also works for things like generalized pooling. I don't know if my implementation of pooling is better or worse but it's nice to be able to organize the things I am pooling. My pooler works on a three step process. The pooler itself, the PoolItem class which has a few goodies about the object being pooled. Then a specified sub pooler. The benefit is say I have 5 enemies shooting bullets and they shoot at a rate of 3 before the bullets get disabled and are cycled back. In a normal pooler each enemy would have 3/4 bullets assigned to their pool on initialize. Instead mine does it at run time by adding it to the general pooler and then tying that reference to a subpool typically on the monobehavior requesting the object. So instead of needing to instantiate 15/20 bullets (3/4 for each enemy) all the enemies share the same reference in their sub pools. So I'll end up needing like 10 or so objects assuming the enemies aren't shooting synchronously. Since it checks against the sub pool which is always smaller than the main pool it's pretty cheap. If you are interested I can share it with you.
@@dibaterman Sounds like a good approach. I haven't implemented any pooling yet. It's going to be a little trickier for my use case because objects can be rewound so I won't be able to return them back to the pool immediately when they are disabled which means I either need to hang on to them until they can't possible be rewound to a state where they are active anymore (which leads to large pool sizes, not good) or decouple the rewind data from the object itself and delete the data over time but not the object.
@@BobsMudHut Hm, objects in this case are never removed from the pool. They simply become inaccessible while they are active. So in theory it shouldn't have the issue a normal pooler would have that you'd need to do overhead for. As I noted above, in normal pooling you'd do a first in first out kind of system. In this one all it does is put everything in a massive pool and then anything that would use something that is to be pooled instead of pulling the item from the pool grabs that things reference for their own cache in a sub pool. Once a sub pool is established (the maximum uses of the pooled items are set) technically all the sub pool cares about is if the item is active presently. If nothing is active it will then go to the main pool which checks again for any similar items and if nothing then it instantiates one adds it to the pool and pushes out the reference. ```Edit In a game with say 3000 objects going into the main pool becomes slower which is why the sub pools only tap the main pool when needed. Again, I don't know the top end of this and if its better as in my case I at most had 500ish items and well it wasn't a problem. But I'd imagine it would get slower at higher numbers. Since the main pool only cares about gameObjects it can hold anything really. It's the subpools that care about specifics like ParticleSystem or Animator, etc. ````Edit 2 The down side to my system is that these pools are built at run-time per demand. Where other pools build at run-time on initialization. This means that if the main pool gets crazy large. The fix for this that I am considering is to make a dictionary of subpools which is grabbed whenever a specific item is requested. It's just that performance hasn't been an issue as the upside to this system is the minimal use of instantiating things.
🤔 the "Paradox" is if bob can rewind time (thus creating more copies of himself) and bob's clothes/armor/outfit is also duplicated... then logic would infer that duplicate gears should also be created (as long as bob is holding it)... the paradox is that there is only one gear, but multiple bobs. 😅👍
I didn't mention this explicitly in a video yet but the way the cloning logic works is that at the moment of duplication every item attached to Bob is also duplicated. In this video every clip I show Bob clones himself while not holding the gear so no clone of the gear is created. If Bob clones himself while holding the gear a temporary copy of the gear will be created that will replay alongside the past version of Bob and disappear with it.
@@BobsMudHut Hm, you'll have to be very careful with this. Right now it seems like you have two cases, you rewind time while holding the gear, creating a temporary state where two gears exist, and a case where you drop the gear before rewinding, meaning your clone will pick it up. But what you pick it up, drop it, pick it up again and then rewind? The whole thing sounds like it could be exploited as an item duplication glitch if the right combination of picking up, dropping and rewinding can be found. This is why I hate time travel mechanics.
@@raenfox Yeah avoiding infinite item duplication in unwanted cases is something I'm thinking about. If it is something like a combat item (such as a throwable bomb or something) being used by the clone I don't mind it being duplicated because it costs the player mana to do so and I can design items like that with duplication in mind. Cloned items disappear when they run out of replay data so I don't have to worry about persistent item duplication. Just to be extra safe I might also make it so the player can't directly interact with a cloned item. In that case if you clone the gear only your clone will be able to pick it up/put it down.
Nice changes, makes the game better! You should do something about the camera clipping through floors and objects I.E. camera moves closer instead of going through floors and trees and other objects could fade partially instead of camera going through them.
Add a day and night cycle where some enemies that are around in the day leave to sleep and other enemies come out in the night and Bob has the ability to change day to night and visa versa
your project reminds me a lot of the Portal 2 mod "thinking with time machine", still a really bloody cool game your making man. Looking forward to seeing how you develop the idea, cheers :)
All i can say is that this has already come a long way since the first devlog and i'm really exited about what's next. Also good luck with the tenet time shenanigans because god that movie was confusing
The rewind/acceleration isn't too bad, it's the clones that are the killer. Not only do you need to have a smart way of disambiguating the original game objects references in timeline records to point to the newly cloned objects you have all the other problems outlined in the video. I'm sure I'll come across more as the project continues.
I thought you were talking about the actual gear lol As someone that is now in game dev, but did mechanical engineering back in the day, I can tell you that calculating and drawing a gear by hand is very, very hard and complicated :)
Very interesting journey to follow. As someone doing long and painful combat with multiple conflicting game systems presently I really appreciated this. :)
It would be cool to make clones with some effects to distinguish them from the player. Maybe some ghost effect with a little traces behind their movement? Each new clone can have a little different hue to it. Just what i thought after seeing how chaotic looks a few clones at the same time.
I relate to this so much. Istg everything that seems extremely easy to make ends up taking so long and coding ends up being way more complicated than you originally anticipated. I think the new name sounds way better, btw!
"But why investigate the root cause of an issue when instead you can spend hours coding an overcomplicated system designed to mask the original issue?" - oh jeez, i felt that to often
You should have the cloned player be a "player" too that basically "presses buttons", so instead of "picking up the gear" it just presses A and B to drop it, then it works with every item and only if it really is there
I thought about that but it doesn't really make sense because (1) that isn't the approach I'm taking for anything else and (2) it would lead to other problems because I have one button control the pick up/put down for the gear (and in the future other interactable objects) which would lead to weird situations like the player putting down the gear right before the clone attempts to put down the gear causing the clone to pick up the gear and then disappear with it. I could mitigate these issues if I also kept a reference to the object its interacting with along with the button press but that's basically the same thing as what I am already doing.
What are you planing to use the clone for? couldnt you check if the clone will interact with anything while lifespan, and then generate a clone for everything he's gonna interact with? dunno if thats understandable XD
So rarely YT indi game developers has such humour and eagerness to jokes around. You feel more unique to me partially because of that. That's my feedback as a viewer and subscriber, do with that whatever you want and goodluck with whatever you will to do.
Actually Unity-Physics are deterministic. If you launch the same scene over and over, things always react in the same way. I could only imagine that time has some influence on the outcome and maybe the setting in the physics tab "enhanced determinism" fixes it? Could be worth to try if you intend to add more physics objects in the future. (I'd send a link to a video that proves the phyics determinism in Unity but RUclips deactivated links in comments, but you can still search for it)
You are right that Unity physics are deterministic if you run the same scene on the same machine, but this only applies if you completely restart the scene (or do some fancy managing to soft reload all the physics objects as outlined in support.unity.com/hc/en-us/articles/360015178512-Determinism-with-2D-Physics). The problem for my use case is that I can't reload all physics objects, so there isn't a good way to guarantee deterministic physics on a single interaction (like the clone and the gear) because I can't reset the state of all other objects. Even if Unity's physics did work that way, I would also have to ensure that every part of my code that even remotely touches physics interactions is deterministic, and if I missed something it would be a nightmare to debug. As far as I know no one has ever managed to get physics replay working in Unity after a rewind by relying 100% on deterministic physics (except maybe in very simple cases). If I wrote my own physics system I could make it deterministic across rewinds, but then I'd have to write my own physics system :P
@@BobsMudHut Writing your own physics system wouldn't even be necessary - ECS Physics is stateless (it was built that way to support multiplayer more easily) but I wouldn't recommend using it for your game. Also you have already solved all issues so far, so there's no reason to change everything again, now that it's finally working. ^^
I put a pause on testing things in multiplayer in the last devlog to wait for the networking library I'm using to add some features that I need. The most important ones have been added so after the next devlog I'll start testing in multiplayer again. The last couple months have shown me just how complicated the time system by itself is making things and while I do think it's doable to have an online multiplayer implementation I also have to solve the game design challenge of making multiplayer work when everyone has control of time. So for now I'm still planning on doing it but I'm not as committed to it as I was before. When I made the first devlog I was 80% sure I was going to add online multiplayer but now its closer to 50/50. One of the other reasons I am putting off testing things in multiplayer is so that I can have a period of time to focus on just that aspect of things and not other game mechanics so I can get a better measure of how long a good netcode implementation is going to take to make. I also have the option of just doing local multiplayer which doesn't get me out of the game design challenge but does make the technical challenge a lot easier.
Found Blades of time recently. It has cool time mechanics as well :P And is pretty fun overall, just dont mind the voice actors ^^ You might want to check it out
Classic "My solid code was already working I just needed to add this line of code to add this new intended behavior but I thought it was a bug and added a ton of new system and verifications to try to solve it until it got too complex overwhelming that I started over and then did the first thing I should've done before."
Honestly, you painted yourself into a pretty narrow corner with the time mechanic. Of course every little thing is going to be immensely difficult. There need to be serious restrictions on the timey wimey stuff, there's a reason it's not a casual mechanic. Even though it's super interesting
I havent finished the video yet but I would simply turn off physics on the gear (I think physics is a bad idea on important puzzle pieces, like what if the player kicks it under a house and softlocks their game), and then in rewind mode, don't even bother trying to perfectly match the gear to its original spots and path, just attach it to the player's hand joint and let the rewinding player control where the gear is, who cares if it's not a 1 to 1 perfect replica of its position
I'm not worried about softlocking because in most cases if the player manages to glitch the gear through a wall or some other object they can rewind it back. Depending on how timing dependent the puzzles are I might also have restore points specific to that puzzle so the player doesn't have to keep repeating the same actions if they mess up on a later part of the puzzle (this would also mitigate softlocking). I like having physics on the gear, it makes the rewind system have a better feel. Even if I decided turning off physics for the gear is fine I would have to develop the same systems anyway for any other physics objects I want the clone to interact with consistently. The approach of temporarily turning off physics while rewinding was my original approach, but it was really buggy and if I am going to spend a lot of time debugging I'd rather spend it on making sure my time system is frame perfect.
Quick question, are you making the gear become a child of Bob’s arm and then detaching it whenever Bob needs to drop it? If so, why not just use rigging?
Guess I forgot to put it in the description. The tutorial is in HLSL so translating it to shader graph or amplify shader editor isn't exactly one-to-one but I found it pretty easy to convert and my knowledge of shaders is close to 0: roystan.net/articles/toon-shader/#
Time Manipulation just makes objects 10x harder
Time manipulation is hard, but its really the clones that make everything 10x harder than it otherwise would be.
@@BobsMudHut Yeah ur right
"Perfect is not when there is nothing more to add,
it's when there is nothing left to take away."
^ Adding new systems until you found the root cause
I can see that Tenet like puzzle at the end has insane potential. Like, the player could be made to find the correct time to rewind a clone so that one thing is untriggered and another is still triggered, and also use time paradoxes where one clone can't fully execute his path because something else triggered in the meantime. I'm getting excited.
W game, will get when done. Love to see this game improving along with you.
make at least 1 JoJo reference please, Im begging you. Za warudo could be cool...
Cell shading makes the game so much more visual appealing!
Been waiting for deterministic physics in Unity for over a decade. Some day... Some day...
What I did in my project was to not have the object be a child, then on the object ran a coroutine that kept the object in the right position each frame. Whenever something else needed to happen I'd just turn off the Coroutine and let that something else happen.
This gave all the benefits of having the object be the child of the thing it should in a specific distance to while avoiding randomly tripping over local vs world space issues.
Simulating Unity's parent-child relationship like that also works. If I run into this issue in other places than when rewinding transforms I might take that approach for better visibility and debugging on what is going on.
@@BobsMudHut Yeah, it also works for things like generalized pooling. I don't know if my implementation of pooling is better or worse but it's nice to be able to organize the things I am pooling.
My pooler works on a three step process.
The pooler itself, the PoolItem class which has a few goodies about the object being pooled.
Then a specified sub pooler. The benefit is say I have 5 enemies shooting bullets and they shoot at a rate of 3 before the bullets get disabled and are cycled back.
In a normal pooler each enemy would have 3/4 bullets assigned to their pool on initialize. Instead mine does it at run time by adding it to the general pooler and then tying that reference to a subpool typically on the monobehavior requesting the object.
So instead of needing to instantiate 15/20 bullets (3/4 for each enemy) all the enemies share the same reference in their sub pools. So I'll end up needing like 10 or so objects assuming the enemies aren't shooting synchronously.
Since it checks against the sub pool which is always smaller than the main pool it's pretty cheap.
If you are interested I can share it with you.
@@dibaterman Sounds like a good approach. I haven't implemented any pooling yet. It's going to be a little trickier for my use case because objects can be rewound so I won't be able to return them back to the pool immediately when they are disabled which means I either need to hang on to them until they can't possible be rewound to a state where they are active anymore (which leads to large pool sizes, not good) or decouple the rewind data from the object itself and delete the data over time but not the object.
@@BobsMudHut Hm, objects in this case are never removed from the pool. They simply become inaccessible while they are active.
So in theory it shouldn't have the issue a normal pooler would have that you'd need to do overhead for.
As I noted above, in normal pooling you'd do a first in first out kind of system. In this one all it does is put everything in a massive pool and then anything that would use something that is to be pooled instead of pulling the item from the pool grabs that things reference for their own cache in a sub pool.
Once a sub pool is established (the maximum uses of the pooled items are set) technically all the sub pool cares about is if the item is active presently. If nothing is active it will then go to the main pool which checks again for any similar items and if nothing then it instantiates one adds it to the pool and pushes out the reference.
```Edit
In a game with say 3000 objects going into the main pool becomes slower which is why the sub pools only tap the main pool when needed.
Again, I don't know the top end of this and if its better as in my case I at most had 500ish items and well it wasn't a problem. But I'd imagine it would get slower at higher numbers.
Since the main pool only cares about gameObjects it can hold anything really. It's the subpools that care about specifics like ParticleSystem or Animator, etc.
````Edit 2
The down side to my system is that these pools are built at run-time per demand. Where other pools build at run-time on initialization. This means that if the main pool gets crazy large.
The fix for this that I am considering is to make a dictionary of subpools which is grabbed whenever a specific item is requested. It's just that performance hasn't been an issue as the upside to this system is the minimal use of instantiating things.
This is one of the best devlog project I've seen resently, good job!! I can't wait to see the game once finish! Good job
Good job or good bob?
I'm sorry
@@sonowbrand7824 both, both are good
🤔 the "Paradox" is if bob can rewind time (thus creating more copies of himself) and bob's clothes/armor/outfit is also duplicated... then logic would infer that duplicate gears should also be created (as long as bob is holding it)... the paradox is that there is only one gear, but multiple bobs. 😅👍
I didn't mention this explicitly in a video yet but the way the cloning logic works is that at the moment of duplication every item attached to Bob is also duplicated. In this video every clip I show Bob clones himself while not holding the gear so no clone of the gear is created. If Bob clones himself while holding the gear a temporary copy of the gear will be created that will replay alongside the past version of Bob and disappear with it.
@@BobsMudHut Hm, you'll have to be very careful with this. Right now it seems like you have two cases, you rewind time while holding the gear, creating a temporary state where two gears exist, and a case where you drop the gear before rewinding, meaning your clone will pick it up. But what you pick it up, drop it, pick it up again and then rewind? The whole thing sounds like it could be exploited as an item duplication glitch if the right combination of picking up, dropping and rewinding can be found.
This is why I hate time travel mechanics.
@@raenfox stop your breaking my brain
@@raenfox Yeah avoiding infinite item duplication in unwanted cases is something I'm thinking about. If it is something like a combat item (such as a throwable bomb or something) being used by the clone I don't mind it being duplicated because it costs the player mana to do so and I can design items like that with duplication in mind. Cloned items disappear when they run out of replay data so I don't have to worry about persistent item duplication. Just to be extra safe I might also make it so the player can't directly interact with a cloned item. In that case if you clone the gear only your clone will be able to pick it up/put it down.
@@BobsMudHut Makes sense. Even if you could infinitely duplicate items, it won't be as useful if you can't interact with them.
this keeps getting more impressive
and its great to watch a fellow unity dev in action
i love the cel shading! the low poly look makes it way more stylized than other games ive seen, so it doesnt look like a copy of botw
Nice changes, makes the game better! You should do something about the camera clipping through floors and objects I.E. camera moves closer instead of going through floors and trees and other objects could fade partially instead of camera going through them.
I just finished the vid and- APPLE ATTACK!11!!!!!1
i love the new shading, kinda looks like breath of the wild
This is extremely impressive!
I’ve been inspired (by mainly you) to make my first game so, THANK YOU!
The rewind system seems like a nightmare to code. Well done on figuring all that out, very impressive!
Nice, I love cel shading!
You know its gonna be good when you can't even comprehend what the dev is saying. This looks awesome
Add a day and night cycle where some enemies that are around in the day leave to sleep and other enemies come out in the night and Bob has the ability to change day to night and visa versa
your project reminds me a lot of the Portal 2 mod "thinking with time machine", still a really bloody cool game your making man. Looking forward to seeing how you develop the idea, cheers :)
EYEWINDER is a sick name I love it
All i can say is that this has already come a long way since the first devlog and i'm really exited about what's next. Also good luck with the tenet time shenanigans because god that movie was confusing
This just gets better and better.
You'd think with so many gamers you'd get more views. Man you deserve more viewers.
Awesome I like Your Videos (How they are made) awesome Keep it up Mate 👍
This has successfully convinced me to never ever use a time manipulation mechanic 😭
I LOVE the cel shading tho. Nice work!
The rewind/acceleration isn't too bad, it's the clones that are the killer. Not only do you need to have a smart way of disambiguating the original game objects references in timeline records to point to the newly cloned objects you have all the other problems outlined in the video. I'm sure I'll come across more as the project continues.
I thought you were talking about the actual gear lol
As someone that is now in game dev, but did mechanical engineering back in the day, I can tell you that calculating and drawing a gear by hand is very, very hard and complicated :)
i like the cell shading
Very interesting journey to follow. As someone doing long and painful combat with multiple conflicting game systems presently I really appreciated this. :)
This game looks amazing, Keep up your great work! 👍
Another name idea could a combination of the two ideas.
TeyemWinder
That gear was worth the wait! 😁 Well... the overall video was at least 😋
lets go another dev log
Interesting and great devlog! Wish you a lot of good luck in the next part of this path with your new ideas.
the cell shading makes the game look ten times better and it also doesn't look like you got the assets from an asset store.
Ahhh the classic "This won't take long" haha
#APPLEATTACKINGEVERYWHERE
It would be cool to make clones with some effects to distinguish them from the player. Maybe some ghost effect with a little traces behind their movement? Each new clone can have a little different hue to it. Just what i thought after seeing how chaotic looks a few clones at the same time.
I relate to this so much. Istg everything that seems extremely easy to make ends up taking so long and coding ends up being way more complicated than you originally anticipated. I think the new name sounds way better, btw!
Looks good
It's bobbin time
"But why investigate the root cause of an issue when instead you can spend hours coding an overcomplicated system designed to mask the original issue?" - oh jeez, i felt that to often
You should probably redesign the whole thing from the ground up considering everything at once.
let's go
This is perfect I need gears too
You could make a cool dragon boss fight where you above an abyss and have to grapple around like in one of the Zelda games
You should have the cloned player be a "player" too that basically "presses buttons", so instead of "picking up the gear" it just presses A and B to drop it, then it works with every item and only if it really is there
I thought about that but it doesn't really make sense because (1) that isn't the approach I'm taking for anything else and (2) it would lead to other problems because I have one button control the pick up/put down for the gear (and in the future other interactable objects) which would lead to weird situations like the player putting down the gear right before the clone attempts to put down the gear causing the clone to pick up the gear and then disappear with it. I could mitigate these issues if I also kept a reference to the object its interacting with along with the button press but that's basically the same thing as what I am already doing.
I forgoted about The game, in my mind i was searching for this game i was like where i's the flying cost game btw another banger video loved it.😅
love the shader, I do
What are you planing to use the clone for? couldnt you check if the clone will interact with anything while lifespan, and then generate a clone for everything he's gonna interact with? dunno if thats understandable XD
Doing time mechanics with physics should be considered self-harm.
So rarely YT indi game developers has such humour and eagerness to jokes around.
You feel more unique to me partially because of that.
That's my feedback as a viewer and subscriber, do with that whatever you want and goodluck with whatever you will to do.
W bob, W game fr
Actually Unity-Physics are deterministic. If you launch the same scene over and over, things always react in the same way. I could only imagine that time has some influence on the outcome and maybe the setting in the physics tab "enhanced determinism" fixes it? Could be worth to try if you intend to add more physics objects in the future. (I'd send a link to a video that proves the phyics determinism in Unity but RUclips deactivated links in comments, but you can still search for it)
You are right that Unity physics are deterministic if you run the same scene on the same machine, but this only applies if you completely restart the scene (or do some fancy managing to soft reload all the physics objects as outlined in support.unity.com/hc/en-us/articles/360015178512-Determinism-with-2D-Physics). The problem for my use case is that I can't reload all physics objects, so there isn't a good way to guarantee deterministic physics on a single interaction (like the clone and the gear) because I can't reset the state of all other objects. Even if Unity's physics did work that way, I would also have to ensure that every part of my code that even remotely touches physics interactions is deterministic, and if I missed something it would be a nightmare to debug. As far as I know no one has ever managed to get physics replay working in Unity after a rewind by relying 100% on deterministic physics (except maybe in very simple cases). If I wrote my own physics system I could make it deterministic across rewinds, but then I'd have to write my own physics system :P
@@BobsMudHut Writing your own physics system wouldn't even be necessary - ECS Physics is stateless (it was built that way to support multiplayer more easily) but I wouldn't recommend using it for your game.
Also you have already solved all issues so far, so there's no reason to change everything again, now that it's finally working. ^^
i forget is multiplayer still happening or did you give up on the netcode?
I put a pause on testing things in multiplayer in the last devlog to wait for the networking library I'm using to add some features that I need. The most important ones have been added so after the next devlog I'll start testing in multiplayer again. The last couple months have shown me just how complicated the time system by itself is making things and while I do think it's doable to have an online multiplayer implementation I also have to solve the game design challenge of making multiplayer work when everyone has control of time.
So for now I'm still planning on doing it but I'm not as committed to it as I was before. When I made the first devlog I was 80% sure I was going to add online multiplayer but now its closer to 50/50. One of the other reasons I am putting off testing things in multiplayer is so that I can have a period of time to focus on just that aspect of things and not other game mechanics so I can get a better measure of how long a good netcode implementation is going to take to make. I also have the option of just doing local multiplayer which doesn't get me out of the game design challenge but does make the technical challenge a lot easier.
yay
Found Blades of time recently. It has cool time mechanics as well :P And is pretty fun overall, just dont mind the voice actors ^^ You might want to check it out
Classic "My solid code was already working I just needed to add this line of code to add this new intended behavior but I thought it was a bug and added a ton of new system and verifications to try to solve it until it got too complex overwhelming that I started over and then did the first thing I should've done before."
And I like the cellshading
Niiiice
Yes.
Honestly, you painted yourself into a pretty narrow corner with the time mechanic. Of course every little thing is going to be immensely difficult. There need to be serious restrictions on the timey wimey stuff, there's a reason it's not a casual mechanic. Even though it's super interesting
Fun fact; Unity physics is deterministic. But it’s floating point so it’s not deterministic across devices.
I tried to add combat clairvoyance to a vr game I'm making, been a couple months since I last touched it 😅
Eyewinder... Eyew-EYE-nder?... Timew-EYE-nder?... t-EYE-mew-EYE-nder?... W-eye-NDER?
my brain hurt
Took you a long time to gear up for it
I havent finished the video yet but I would simply turn off physics on the gear (I think physics is a bad idea on important puzzle pieces, like what if the player kicks it under a house and softlocks their game), and then in rewind mode, don't even bother trying to perfectly match the gear to its original spots and path, just attach it to the player's hand joint and let the rewinding player control where the gear is, who cares if it's not a 1 to 1 perfect replica of its position
I'm not worried about softlocking because in most cases if the player manages to glitch the gear through a wall or some other object they can rewind it back. Depending on how timing dependent the puzzles are I might also have restore points specific to that puzzle so the player doesn't have to keep repeating the same actions if they mess up on a later part of the puzzle (this would also mitigate softlocking). I like having physics on the gear, it makes the rewind system have a better feel. Even if I decided turning off physics for the gear is fine I would have to develop the same systems anyway for any other physics objects I want the clone to interact with consistently.
The approach of temporarily turning off physics while rewinding was my original approach, but it was really buggy and if I am going to spend a lot of time debugging I'd rather spend it on making sure my time system is frame perfect.
Quick question, are you making the gear become a child of Bob’s arm and then detaching it whenever Bob needs to drop it? If so, why not just use rigging?
Huh, just go with an inventory
Maybe make it a 2 player game, when one player controls time, the other controls space(teleport maybe)
When releasing the game can you make a setting to turn off the shader for potato pcs
just wait until another month is added when you keep finding bugs :)
Don't jinx me haha
seems you need a more consistent physics system
Please can you share the Cel Outline course? I NEEED IT !!!!
Guess I forgot to put it in the description. The tutorial is in HLSL so translating it to shader graph or amplify shader editor isn't exactly one-to-one but I found it pretty easy to convert and my knowledge of shaders is close to 0: roystan.net/articles/toon-shader/#
If the timeKeeper script tracks objects position, rotation, scale, why wouldnt the game lags a lot
Uff I hate to say it, but it'll be hard for you to make something outta this if you don't make it interesting enough, the new Zelda's already out
Go FM Öl
v
too easy