Tile Spawning

Worked on finishing up the tile spawning functionality. I ended up having to go with using prefabs instead of scenes, like I had originally intended. Scenes don't allow you to position them at runtime (at least not without some hokey workarounds). Instead, we now spawn in prefabs that are the full tiles.

I also created a Tile Spawn Trigger prefab that allows the player to spawn the next tile in the sequence when they walk through it. This has a configurable number of tiles it will keep loaded in at a time and automatically unload the oldest tiles to get back under the max. I did run into an issue where the trigger would hit multiple times and just spawn a bunch of them if the player walked through it repeatedly. I fixed this by only allowing the trigger to be hit once. Since the game is linear, and the player cannot really go backwards, this should be more than adequate.

The gif below (slowly) shows the new tiles spawning in when a trigger is hit, then it shows the old tile despawning when hitting the next trigger. I probably should have made the gif before I made the tile size bigger but oh well.

In the gif, you can see the tiles popping in and out pretty well, but this should not be an issue in the final game, since there will be fog and it will be dark.

There is probably a better way of doing this but it works for now!

Conventions and Wikis

I added a Wiki to the DevOps project. The main articles are about conventions. We now have a coding conventions article that outlines how the code should look and an asset naming convention article for how we should be naming our assets.

The coding conventions article is primarily just the style that I have developed over the years that seems to work well for me. It is more on the "standard" C# side, rather than the Unity C# side, because that is what I am more used to from my day job.

The asset naming conventions are primarily based off this Unity Style Guide I found online. We mainly took the actual asset naming styles from it, but may incorporate some of the other styles as well. I don't agree with some of the stuff in it but there is obviously a lot of thought put into it.

We still need to figure out our folder structure, so that'll be one of the next things to tackle.

Caravan Manager

Got the sled and other models pulled into Unity and put into prefabs. I was able to get the sled spawning using a spawn point. The difficult part is that the sled needs to persist/exist between prefabbed tiles, so I spawned it in the main scene. This presented a challenge because I had to put a spawn point where it would need to be in the first prefab. I was able to temporarily add the starting Outpost prefab to the scene to get things lined up. This worked pretty well but I had to add a configuration field to the Caravan Manager to offset the rotation of the sled when it was spawned, to make sure that it pointed the right way down the road.

As you can see, when you are just looking at the main scene, it is hard to tell where the sled spawn point should be. Why there? Who knows!

However, once you pull the starting tile into the scene, it makes much more sense. Ideally, the starting tile would actually have the spawn point on it and the Caravan Manager would look for that and pull it in. Because the starting tile is being dynamically spawned in that makes trickier. However, now that I think of it, I could have a property exposed on the Tile to hold a reference to the spawn point (if it has one) and when the Caravan Manager goes to spawn the sled it can grab the reference. I think there might still be some timing issues with that but may be something to explore.

This is the spawning in action. A nice mix of terrible programmer art and much nicer models. You get to see my full range of art skills, from the hideous to the moderately decent!

So far today, the code has been pretty straight forward, but you can see the coding conventions I alluded to earlier in action. I like to use the Header to organize the types of serialized fields I have. This has made it much easier to determine where data should be coming from and how it is expected to be used. I don't remember where I first heard this suggestion but so far it has worked the best for me. If only Unity supported sub-headers, then it would be the perfect setup!

using UnityEngine;

public class CaravanManager : MonoBehaviour
{
    [Header("Prefabs")]
    [SerializeField]
    private CaravanSled _sledPrefab;

    [Header("External Dependencies")]
    [SerializeField]
    private Transform _sledSpawnPoint;

    [Header("Config")]
    [SerializeField]
    private Vector3 _spawnRotationOffset;

    private void Awake()
    {
        var spawnRotation = Quaternion.identity * Quaternion.Euler(_spawnRotationOffset);
        var sled = Instantiate(_sledPrefab, _sledSpawnPoint.position, spawnRotation);
    }
}

Brainstorming

I need to figure out how to get the sled to move along a path. I know that I'd like to make a spline of some sort that the sled will travel along. This will allow us to play with the shape/contours of the path, like winding it around the terrain. However, this presents a problem. We are using tiles for our environment, so we can dynamically adjust how long the "run" will be and also slot in different random events and such. Because of this, we cannot just have a singular spline that goes through the entire run. We want to have more variety in the environment tiles, otherwise we could just move the sled in a straight line.

Before we get into the rest of my thoughts, regardless of the spline implementation, I'd like to have a target that is moving along the spline then have the sled move smoothly from its current position to the target (probably just using a simple lerp). This should give us more flexibility in how we move the target because any jolts to the target won't necessarily reflect in the sled, assuming that the jump isn't too big. I think this will also make the halt mechanic more interesting, since the sled will slowly come to a stop naturally, but that is a feature for another day.

There we a couple of options that Terra and I thought of while discussing it over our dinner break:

1. Could we have multiple splines (one on each tile) then somehow reparent the target to the next spline when it reaches the end of the current spline
   1. Trigger to detect the next tile coming up and grab a reference to its spline, then reparent to it when the target reaches the end of the current spline
      1. This was the initial thought. It is more complicated, since it has trigger volumes that have to be placed physically in each tile prefab.
   2. I already have the list of loaded tiles, when the target reaches the end of the current spline, just reparent to the next spline in the list
      1. This came to me while I was typing all of this up. Don't know why it didn't occur to me earlier, as it seems like the simplest answer to the problem. It relies only on an existing data set, so it should be really solid. That only leaves the challenge of reparenting the target but that should be fairly trivial (famous last words...)
2. Could we somehow "append" the next spline onto the current spline, recalculate the current percentage (since if we were 90% of the way through the original spline but we add another 100% onto it, we'd be at around 40% of the new spline), then we only have to deal with "one" spline.
   1. The main problems with this one are:
      1. I don't know if you can append/truncate splines after they are created
         1. Frankly, I don't even know if Unity supports splines out of the box
      2. The percentage needs to be recalculated and I don't know how accurate that would be
         1. When I worked with splines in Godot, I used a function to find the closest point on a spline to a given position. I don't remember if that was something built into the spline object in Godot or if there was a mathematical equation to determine it

I think I will pursue to having one spline per tile, then using my loaded tile list snag the next spline in line when I reach the end of the current spline. Sounds simple enough! Now, to figure out how to move an object along a spline and tell when you are at the end!

Other Stuff

I worked with Andrew to get him more familiar with Git, since this is his first time really using it. He is picking it up pretty well. I made this silly diagram to help explain what is going on. It is a little simplistic but it helped me explain the flow of everything. Whether it helped anyone else? Who knows!

Overall, as a team, we seem to be getting more into the flow of things and are figuring out how to work with Unity and git. It is definitely a learning experience. We spent quite a bit of time hammering out workflow issues and conventions today, which goes a long way. Moving forward things should be much smoother sailing!