![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee10:12pm - Well I think it's time for some more work. My plan was to make the "IsGrounded" checker into an independant component, and a ScriptableObject Property, but it got me thinking about a problem I don't know the solution to with regards to this pattern.
When I'm setting up the player's data it's not unreasonable to have an individual ScriptableObject .asset file for each property that the player wants to have. But if I do the same thing for every enemy, that's a heck of a lot of unique .assets and they'd all be coupled to individual enemies.
So, I've got to figure something out. I've got some ideas on how to solve this problem, but first I'm going to go back to the video talk and see if I forgot a point or idea in this plan.
10:59pm - I watched the relevant points in the talk and also checked out the comments section on the YouTube vid where the speaker, Ryan Hipple, goes over some possible solutions to the problem I realized. It's about the same as some of the soloutions I had thought of, and I'm hemming and hawing over if I should use the ScriptableObject Variables/References or plain old ordinary variables on the relevant components.
With the one I'm trying to put together, isGrounded; Every mobile in the game would need an isGrounded variable asset. I could make a single superasset with all of the isGrounded variables together, but that's a strong coupling. I could also make a manager that adds an isGrounded property for each mobile that's added to the scene. That's a bit more sensible, but it's still a big mess just to keep track of if something is grounded.
An alternative using the component pattern in Unity would be to have those components that need to check if their gameobject is grounded, keep a local reference to the isGrounded component, if there is one.
The trouble might come if something outside of the gameobject wants to know if it's grounded, but it should be able to use the same method for getting the data.
I'll do it that way for now.
11:10pm - Oh I just had a thought! For the grounded check, I'd be doing a raycast to check for the ground every frame. But, I've got a collider! Why don't I just use that, and when it's colliding with something on the ground layer, it's grounded! That should be more sensible.
11:52pm - The isGrounded thing worked with the collider except I accidentally implemented wall jumping. ^.^;;
I'll have to go back to the raycast version.
12:55pm - I've been in the call for a while but I'm still programming, which is pretty good. I went back to the raycast version but that had problems with edges, so I switched to a circlecastnonalloc and that seems to work great. Lots of math in determining the location and size of the circle. But it works!
1:03pm - Okay I did some testing and if I scale it up the circle gets a bit too big, but that's the thing with circles isn't it?
Anyways I'm not sure what to do next! Hmm... I've got my player, and my platforms. I need a main menuish thing or effectively a preloader. I need something to move between the levels, and enemies. I'll probably make the thing to move between levels during Ludum Dare itself since the theme may change how I want to end the levels. I'll probably make a couple of enemy AI brains, one for walking straight and turning when they hit a wall, and one for walking back and forth on a platform. Your basic green and red turtles.
I think this is actually a good time to take a break. I've been working on this for a long time, and I haven't taken a real break in like a day. Heh.
When I'm setting up the player's data it's not unreasonable to have an individual ScriptableObject .asset file for each property that the player wants to have. But if I do the same thing for every enemy, that's a heck of a lot of unique .assets and they'd all be coupled to individual enemies.
So, I've got to figure something out. I've got some ideas on how to solve this problem, but first I'm going to go back to the video talk and see if I forgot a point or idea in this plan.
10:59pm - I watched the relevant points in the talk and also checked out the comments section on the YouTube vid where the speaker, Ryan Hipple, goes over some possible solutions to the problem I realized. It's about the same as some of the soloutions I had thought of, and I'm hemming and hawing over if I should use the ScriptableObject Variables/References or plain old ordinary variables on the relevant components.
With the one I'm trying to put together, isGrounded; Every mobile in the game would need an isGrounded variable asset. I could make a single superasset with all of the isGrounded variables together, but that's a strong coupling. I could also make a manager that adds an isGrounded property for each mobile that's added to the scene. That's a bit more sensible, but it's still a big mess just to keep track of if something is grounded.
An alternative using the component pattern in Unity would be to have those components that need to check if their gameobject is grounded, keep a local reference to the isGrounded component, if there is one.
The trouble might come if something outside of the gameobject wants to know if it's grounded, but it should be able to use the same method for getting the data.
I'll do it that way for now.
11:10pm - Oh I just had a thought! For the grounded check, I'd be doing a raycast to check for the ground every frame. But, I've got a collider! Why don't I just use that, and when it's colliding with something on the ground layer, it's grounded! That should be more sensible.
11:52pm - The isGrounded thing worked with the collider except I accidentally implemented wall jumping. ^.^;;
I'll have to go back to the raycast version.
12:55pm - I've been in the call for a while but I'm still programming, which is pretty good. I went back to the raycast version but that had problems with edges, so I switched to a circlecastnonalloc and that seems to work great. Lots of math in determining the location and size of the circle. But it works!
1:03pm - Okay I did some testing and if I scale it up the circle gets a bit too big, but that's the thing with circles isn't it?
Anyways I'm not sure what to do next! Hmm... I've got my player, and my platforms. I need a main menuish thing or effectively a preloader. I need something to move between the levels, and enemies. I'll probably make the thing to move between levels during Ludum Dare itself since the theme may change how I want to end the levels. I'll probably make a couple of enemy AI brains, one for walking straight and turning when they hit a wall, and one for walking back and forth on a platform. Your basic green and red turtles.
I think this is actually a good time to take a break. I've been working on this for a long time, and I haven't taken a real break in like a day. Heh.
