Happy 11th birthday to the blog. It’s not that important of a milestone compared to last year, but worth noting nonetheless.

But let’s get to the real news:

I did mention this partial rewrite in the last blog post as the last post took so long to write (I was busy with stuff, not that the post was long) that some of the work was done. But now I can get into more detail.

The hoverboard is now a model on top of a collider, an upright capsule collider to be exact. Propulsion works in more or less the same way, but is currently fully controlled by the player. Furthermore, in my last iteration of the hoverboard, when turning, I had a part of the script that would animate the board’s model to tilt it when moving, giving it a more believable look. I’m just adding a smooth damp value to the model’s rotation based on the input. Here’s a code snippet:

Vector3 newRot = hoverboardModel.transform.localRotation.eulerAngles;
if (grounded)
{
    newRot.z = Mathf.SmoothDampAngle(newRot.z, input.x * rollTurnRotAngle, ref rollRotVelocity, turnRotSeekSpeed);
    //newRot.x = Mathf.SmoothDampAngle(newRot.x, slopeAngle, ref pitchRotVelocity, 0.05f);
    newRot.y = Mathf.SmoothDampAngle(newRot.y, 180f + (input.x * yawTurnRotAngle), ref yawRotVelocity, turnRotSeekSpeed);

hoverboardModel.transform.SetLocalPositionAndRotation(hoverboardModel.transform.localPosition, Quaternion.Euler(Vector3.Lerp(hoverboardModel.transform.eulerAngles, newRot, playerTurnTorque * Time.deltaTime)));
}

(I’ve highlighted the code because it’s hard to see with the dark theme)
I’ve continued with that feature and made further additions to it, which gives it a lot more of a snowboard turning look. That said, I’m not finished with it.

I played more games for research during the process of rewriting the code, and one of the games I played was Extreme G Racing. An interesting thing to note about the behaviour of that game is that the player has a very large turning circle. So large in fact, that it is very difficult to get the player to face the wrong direction as you’re more likely to collide into the sides than get the vehicle to turn around on the track. I might change the behaviour to match that at some point.

In regards to the physics, I do mention this in the video at the top: the player’s gravity is relative to them and not the global value. This is set to the normal of the surface they’re on. In theory, it helps keep the player connected to the surface they’re on a lot better and gives me more flexibility in terms of track design. Previously, I couldn’t create loops as the physics driven system I had previously would break and push the player away from the ground. And now I can make corkscrew and loop sections of track without issue.

I’m really looking forward to making some new tracks with these mechanics; it’s certainly more interesting to look at than a flat track.

The big new thing is rails, and I didn’t really cover this in detail in the video, so I’ll be going into more depth about building it now.

My first attempt at this new version of rails involved making rails in Blender and then importing them into Unity, including even more CSV files with vertex points, and lining them up. As you can imagine this got very tedious extremely quickly and I began looking for alternatives.

I then updated Unity and began using its built-in spline tools to create the rails. As I said in the video, this worked great. But then I tried to use it with spline animate to have the player move on the things, and that’s where it fell apart. The camera was a jittery mess and the whole thing wasn’t smooth at all. So I deliberately made the splines linear instead of curves, then made a script that got all the waypoints on the line and used Vector3.MoveTowards to get the player to move along the rail path.

And it worked… Until I tried getting back on the rail to go in the opposite direction. This is when the trouble began. I had to figure out what direction the player was coming in from and their position on the rail. Plus some edge cases on top of that. This led to a lot of if statements, which I am not too happy with.

But as you can see, it did work. What came next was figuring out loop-de-loop rail sections. Which required further code changes and even more pain.

As you can see, the biggest issue was keeping the player upright properly while going through the loop. Unfortunately, I don’t really have a good solution for that problem with the system I’ve built. Someone did suggest to me pointing them up towards a point in the centre of the loop, but considering I’m going to arbitrarily build and place these rails, it seems like a lot of work, plus even more additional work if I edit anything thereafter.

I’ve been looking at the way other people and other games have built their rail grinding stuff, and more recent things seem to be using something similar to the spline animate system that the spline tools have built-in. So I may need to give it another chance and perhaps that’ll solve the issue.

One thing I am mostly happy with is the rail switching mechanic.

This took a lot longer to figure out, but the solution is quite simple in theory. When I’m on the rail and lean left or right, I shoot out a sphere cast (Spherical raycast) within a certain range to the left or right of the player. If it hits a rail, I then draw an arc from the player’s position to the hit position (Note that I said hit position, not spline track position). If the player then presses the jump button, I do a slerp using a sin wave to give it a curved arc. Here’s the code for that slerp:

private IEnumerator MoveToNextRail(RailSplineScript nextRailScript, Vector3 hitPoint)
{
    float timer = 0;
    float step = jumpTime / linePoints; //Line points refers to the number of points on the arc being drawn. More points = smoother arc.
    int i = 0;
    float progress = 0;
    Vector3 startPos = transform.position;
    while (progress < 1) //Should be using time progress, not number increments
    {
         progress = timer / jumpTime;
         transform.position = Vector3.Slerp(startPos, hitPoint, progress) + (transform.up * (jumpHeight * Mathf.Sin(progress * Mathf.PI)));
         timer += Time.deltaTime;
         yield return null;
    }
    transform.position = hitPoint;
    currentRailScript = nextRailScript;
    CalculateAndSetRailPos(); //Sets up some stuff for the spline points system mentioned earlier
    onRail = true;
}

It works pretty well; it’s not the smoothest looking thing in the world, but it does work. Although I suspect some of the issues with the smoothness have to do with the camera, which I will probably fix soon anyway. Another issue is just the positioning of the player themselves when they switch rails. They’re off-centre. It is a problem that eventually corrects itself as they keep going on the thing, but it is annoying.

But yeah, that’s the new stuff out of the way. As for improvements and what’s next, well here’s a list:

• Fix the camera on rails
• Change the rail system again and see if I can get spline animate working
• Create tracks using the spline tool, minimising Blender usage for level creation
• Create some levels using all the existing tools and mechanics (Demo!)
• New character animations
• Better foot placement on the board
• Overhaul the trick system

I’m probably giving myself a lot more work to do than I’d like, but hopefully it works out. I really want this idea to work out. I’ve put so much time into it, and it’s really fun to just move around.

What Else Is Going On?

Well I did the WWII COD Marathon and it went alright. I gained some new followers out of it and some of them have hopped back into chat and such since. Wasn’t a massive gain, but whatever. The COD games I’ve never played before will be mentioned in the year end “ADMAN’s Den” post along with my usual top 10s, but I will say that I enjoyed WWII more than I thought I would, but it’s definitely got some issues.

I do want to do a highlight video for it, but honestly, after looking through the highlights for the first COD game, it’s very difficult to find clips that are worth putting in a video. I could make a death counter video, but I don’t think it would be that entertaining. So maybe what I’ll do is grab clips from all the games and shove them into one video instead of doing a video per game. More time spent in prep, but less time editing.

As I mentioned in the video at the top, Unity did something stupid, and now I’m finally in a position where I’m thinking of changing engines. But I want to do a video about the experience of learning new tools. However, since making the video, I’ve come to realise just how busy I am with all the videos I need to make and all the work that Cybersurfer still requires, and I think I might need to delay the original timeframe I wanted to work on it.

On that note, Rotaction needs to be updated soon, or it’s going to be pulled from the Google Play Store. Or at the very least, unavailable to download on modern phones. It will continue to be available on Itch.io, so don’t worry there. The deadline is November 1st, so I need to deal with that soon.

Another thing is back-porting the new hoverboard code into SandSurfer, and changing it to be an actual sand surfing board without all the hoverboard stuff. It’ll take some work, but hopefully it’ll be better than it currently is. But I have no idea when I’ll get a chance to work on it.

But that’s your update. Sorry for the radio silence, but that’s just how it is sometimes. I’ll probably post again once the demo is available for Demo Day. If I can get it working by then. Till next time.

-Adam

It’s very early, but I need the feedback. This is Cybersurfer, a follow-up to my GGJ game SICKHACKS.root.

I’m not gonna retread the same things that are in the video, you can watch it yourself, but I do want to talk about what I want the game to be going forward as well as some of the games I’m gonna be looking at or re-looking at.

But as I said, I’m not terribly happy with where the project is at the minute. It plays OK, but it definitely feels like it’s lacking something. Plus the physics driven hoverboard is now more of a hinderance as I look towards different level design aspects. Specifically verticality. The game Distance as well as Wipeout are my two points of reference in terms of what kind of level design I want.

And here’s where I have to admit that I took too long writing this blog post that everything in that video and previously written is now outdated.

Following the that video, I did another stream where I played a handful of games and made notes about various aspects of them, and how they handled the same problems I was having. It was a very informative stream and helped me realise that I was trying to over design everything.

And now, as I’m writing this, the whole physics driven hoverboard system has been scrapped. And the spline based system that I attempted to follow it with has also been scrapped.

The new system is fairly simple, a player model on top of a collider acting as a cushion of air. I’ve ditched the waypoint system, and instead I’m just letting the player control their forward speed and turning themselves, and it’s working out pretty well now. On top of that, I have a bit of rotation to the player model when they turn and a sine wave to make the model bob up and down like they’re on a hoverboard.

It’s a night and day difference and a definite improvement.

Next up is getting the player to stick to the track regardless of the verticality of said track. I’m using Distance’s magnetism as a reference here. My plan is just use a downward force while grounded, and magnetise the player to surface once they get close enough. I suspect it’s going to be more difficult than I’m envisioning though.

Learning To Rig

I recently had a Twitch stream where I taught myself how to rig a robotic arm model.

It’s a very basic model with some problems due to some of the ways I was trying to rig it, but once I figured out the issues it was too late to re-do the model. However, the animation side of things turned out alright.

The next stage of this is getting more familiar with IK stuff as well as other bone constraint systems.

YouTube Content & Future Plans?

Demo Day 51 happened, and although I did not submit a demo, I did stream other people’s demos and provided as much feedback as I could. Here’s the playlist. I do want to get more content on to my channel as it would likely help my Twitch performance, but it’s difficult to find the time to make stuff that would be palettable.

YouTube’s algorithms prefer shorter videos, so uploading whole VODs would probably be a bad idea, but I could cut down my playthroughs into highlights. But requires time I just don’t really have, either to watch 30 to 60+ hour playthroughs to find stuff worth putting it, or to find time to edit it down. But I think I’m gonna be forced into doing it because I am at the absolute mercy of the algorithm gods.

As for future plans, well it’s coming up to the 78th anniversary of the end of WWII, and I want to commemorate it by playing through all of the WWII Call Of Duty games. Those being COD 1-3, World At War, Finest Hour, Big Red One, and WWII. I’ll probably using that stream as the experiment for creating highlights for YouTube, alongside uploading the VODs of it, possibly. Either way, the playthroughs will be available in my Twitch collections page as per usual.

That’s it for the time being. There’s probably more I’m forgetting to mention, but I took so long in writing this blog post it’s better just to move on. I’ll see you next time.

-Adam