Entry 15

Winter Break Worklog 1 (December)

With the 2024 Fall Semester wrapped up, the next couple of entries will be formatted and uploaded slightly differently until the spring semester. My winter break work is very much going to be a "I'll work when I want to" sorta thing as opposed to previous entries where I'd try to get em out on a weekly basis and had specific due dates set for myself.

I have goals that I want to get done this winter, but generally speaking I am treating this in a more relaxed manner.

12/11/2024

So today I decided to tackle the zoom in/out and moving platform bugs since that latter's been a pretty big thing impeding my progress. As for the zoom in/out... I just wanted to make it properly scroll able instead of just having it snap between two states. This actually wasn't all to hard to implement and took me under an hour since honestly I had the harder controller stuff out of the way, it was just a matter of making a float for the zoom in/out amount and using Mathf.Clamp to set my min/max values.

And then we went into the pit of despair. The platforming troubles were not as kind, I believe I was at this for 4 hours? Most of that time was spent researching alternative methods to try and get the player to "stick" to the spinning platforms and raycasts. Which I have used in the past!! but again!! the fact I'm mostly familiar 2D has bitten me in the ass since when using raycasts in the past, I'd rely on ridgidbody 2D when utilizing them. With Doc's controls, I'm using a Character Controller so I'm not using the traditional ridgidbody component. This has both pros and cons, the character controller is wayyyy easier for me to fine-tune BUT because it uses it's own RB and capsule collider it's a bit strange for me to work with at times since I cant just. Call the ridgidbody/collider like I could with my other projects.

All of that just to say that raycasting was definitely going to be my answer to this, I just had to figure out HOW to work with it in this state. 

See initially, for whatever reason, I had been trying to get it to work with the character controller's collider, but that was making Doc "stick" to the platform even after they jumped off, causing them to move in the air when they shouldn't be. They'd only "unstick" from the platform after landing on the ground/another platform. 

But then I realized. Hey. If I'm using a raycast. Why do I need the character collider.

After that grand revelation and a bit more research I finally figured it out. And this is how stupidly simple the code was for it.

(what's not seen is the "RaycastHit _hit" I had to put at the top of the script. Which. You'd think I'd know by now right? But I guess that's what happens when you tunnel vision yourself trying to figure out how to code one way.)

I think the other thing that tripped me up with the raycast (or. in this case the BoxCast) is that on its own there's no visualization for it. You'll have to include that elsewhere in your code if you want the raycast/gizmos to be drawn in engine. This is something I was vaguely familiar with but much like raycasting in general, not an expert with in the slightest.

I think if there's anything I need to take away from this project is that I tend to overthink things that wind up being relatively simple/straightforward. Like this happened with the camera to this cannot keep happening (/silly).

12/18/2024

Didn't do a ton of work today, I wanna say I only worked for only a little over an hour. During that time I made the script for Cloudskipper's moving platforms and began to put those in and actually try to assemble the stage a bit more. We're getting closer to having builds I could actually try to have people playtest, yippee!

Speaking of, I did decided to build cloudskipper in it's current state for the sake of camera and player testing (and. well. just making sure it actually builds) and while it is working the feel is still a bit off. So I think I am going to try to implement the following changes:

• When zooming into 1st person, the camera will need to move upwards a bit since it's a bit too close to the ground as it currently is
• The cursor still shows, so either I get rid of it entirely OR find a way to lock it in the center
• Also when in 3rd person I want to see if I can lock the view until the right mouse button is clicked and held down, then the camera can move freely. I feel like this will allow for more precise movement in 3rd person
• Make Doc slightly less heavy and also decrease the power of their double jump
• There is also part of me that still wants to implement a dash of some sort but we'll see
• Also in the player code I do have mechanics for adding more jumps but they get weaker over time so... maybe that could be fun...

That's about all for now though, next work session I'll either be fixing up Doc's physics or beginning to remodel Cloudskipper in maya we'll see what I'm in the mood for. 

12/21/2024

Worked at trying to redo Doc's physics and solve some of my camera problems (cursor locking). While they aren't entirely how I envisioned them working I'm just going to leave it for now. Also Doc has a sprint now when the player holds down shift so that's cool. Originally I had instead wanted to implement a quick dash that the player could perform to help with platforming but I was having trouble getting it to work properly with the gravity so I scrapped that idea and just went with a sprint. This happened while attempting to implement the dash:

 I will admit lately I have not been feeling great about this project. I'm hoping it's just because I've been stuck on the character controller, but throughout this whole process I find myself thinking "man I wish I went 2D/went with my other thesis idea (2D platformer)". Granted, again part of the reason I went with 3D for this project was to try and hone my skills more so going into this I knew it wasn't going to be "perfect" and that'd I'd be learning more as I go, but I guess I'm just feeling as though I'm going to be disappointed with the outcome of this as I have been with most of my other unfinished game projects.

There's also the fact that I am unsure if I want to continue using Unity engine for future projects, so part of me is like "what is the point if I'm just going to jump to Godot or Gamemaker 2 for my next project." I guess just knowing the Unity engine is good to have skill-wise, but after the stunt they pulled in 2023 with the runtime fee charges hopefully you can understand why I feel hesitant to continue with the engine... even if they rolled that awful decision back. 

Moping aside, I'm done toying with the character controller for now. I'm not entirely happy with it but I think at this point I'd need to gut most of the player controller's code if I wanted to implement a quick dash instead of a sprint like I currently have, so I'm just... gonna leave it. It works, it's playable, doesn't feel like complete garbage so I'll take it. Next work session I plan on either starting to refine Cloudskipper's pieces or clean up the animations for Doc's actual sprites... something frontend related basically. 

12/30/2024

After a short break for the Holidays I decided to clean up Doc's sprites. For the time being I have their front and back idles done.

I should be able to get the walks and jump/land animations done relatively quickly, the walks in particular will probably go by fast since I don't really have to redraw Doc all that much, just redraw the arms and legs and a bit of the cape... thingy.

I also decided to throw the new sprites in engine to see how they'd look. Fingers crossed that getting them to animate as I want isn't a total nightmare when that time comes.

For now though, I think this'll be my last entry for 2024 so I'll see you in the new year!