What a day it has been. I’ve basically wasted most of my evening fiddling with some nice to have stuff. I won’t jot it down as a complete waste as I’ve now discovered how to properly add extra projects into the Unity generated solution as well as optimizing the Unity asset serialization to cater better towards using Git.

Devilish cameras

One of my other successes today was to fix the issue I had with my camera yesterday. My previous implementation made use of some tweening that would cause it to lag farther and farther behind the player ship when accelerating in one direction. I fixed that using the code below:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

using UnityEngine;

public class CameraFollowShip : MonoBehaviour
{
    public float DampTime = 0.9f;
    private Camera camera;
    private GameObject ship;
    private Vector3 velocity = Vector3.zero;

    // Use this for initialization
    void Start()
    {
        this.camera = GetComponent<Camera>();
        this.ship = GameObject.FindGameObjectWithTag("Player");
    }

    // Update is called once per frame
    void FixedUpdate()
    {
        if(!this.ship)
        {
            return;
        }

        var speed = this.ship.GetComponent<Rigidbody2D>().velocity * 0.5f;
        var cameraOffset = this.ship.transform.position + new Vector3(speed.x, speed.y, 0);
        var point = this.camera.WorldToViewportPoint(cameraOffset);
        var delta = cameraOffset - this.camera.ViewportToWorldPoint(new Vector3(0.5f, 0.5f, point.z));
        var destination = this.transform.position + delta;
        this.transform.position = Vector3.SmoothDamp(this.transform.position, destination, ref this.velocity, this.DampTime);
    }
}

This is a very rough work in progress still, but I can quickly explain the gist of it all. I firstly calculate a “speed” vector that is used to offset the current camera position. Using the new offset point I’m able to leverage the nice smoothing camera we used for Spitballin’ as part of Ludum Dare 32. I haven’t spent enough time to fully grasp what that code is actually doing under the hood, I just know that it will smooth out camera movement and make things feel a bit more natural.

I’ll also have to add some value clamping to ensure that when the ship is moving at a fast enough speed it does not cause the camera to lead too far ahead. I don’t really see that as a massive problem while testing as a player is far more likely to lose control of their ship before that happens, but it will have to be looked at to decrease the likelihood of losing control because you can’t see your ship. Once I’ve got a cleaner better solution I’ll be able to more easily explain what is going on.

Asteroid bitmap

I haven’t yet settled on an implementation to follow for reading some map data and then building the game state from that, but I’m really considering opting to use bitmap images for that. Each pixel can store an astonishing total of 24 bits!

I’m most likely scope creeping myself here, but splitting the 24 bits into the three colours used (Red, Green and Blue) I’ll be able to nicely define what enemies/asteroids are stationed where as well as have the player position defined with possible pickups etc. The possibilities are quite vast and would allow for quick and easy game setup.

Foolish plans

I’ve also come to the realization that I need to plan what I want to do a bit better. My ideas are currently floating about on different posts, pieces of paper, a notebook and some are still just ideas. I’ll have to setup a Trello board so that I can properly manage what I still need to do and what I’ve done, but that’s tomorrows worries as it’s already late. That’s it for today!