Work Post

4:36am - Well I'm down at the McDonalds now and getting ready to work on my new version of my 2D Platformer Base Code. I've got Ryan Hipple's code from his 2017 presentation open for reference to some of the ScriptableObject stuff he did, and I'm getting ready to begin.

I'm going to be trying to follow his advice of making each scene a clean slate, and each game object an independant prefab. So the first thing I'm going to make, or remake, since I'm starting from scratch on something I already did once, is a basic platform.

4:59am - Okay I've got some basic platforms now but I'm not sure about their quality and qualities, so I need to make my first player character.

6:48am - It took a while but I've got my very basic player. It's using some very complex scripting that should be very easy to modify, if I'm doing everything right.

Anyways now that I've got a player in my scene it's pretty clear I set the platforms up wrong. Instead of colliding with the side, the player just slides through it.

7:08am - Alright, I've got the platforms working properly, next I want to implement jump behavior on my player. <3

7:38am - I've implemented a jump, but it's super floaty, and so are the ground controls, and you can double-jump infinitely, so I'll have to fix all of that. Well first I'll fix the double-jump thing by adding a grounded state.

8:04am - Well great, the internet's only gone and died on me right when I need to look something up. :/

I'm also really tired so I think I'll pack it in for now. I've been working for almost four hours already.

I'll try and post this when I get home.

Work Post

9:39am - One last work post for the day/night/morning/whatever. I've gone ahead and fixed the double jumping problem and started working on the floatiness. I added my own gravity component instead of using the global gravity, and I was going to make it so that your horizontal move speed differs depending on if you're grounded or not, but then I realized I should extract that value from the components and make a new component just for determining if the Mobile is grounded.

I'm tired so I'll do that next time. But what I need to do is redo the grounded check using the raycast data to determine how far the ground is, rather than checking if there is ground at an arbitrary point. I also need to set a ScriptableObject style property with the IsGrounded state, so that various systems I create can test that value. For example, I want both my Jump component and my Move component to change their behavior depending on that, and I think I'll probably want to check it in animation and sound effects too.

So that's what I'll do next time. For now, I'm going to bed.

Work Post

10: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.