Updates to Valentine’s Day Escape source

After that email about the source for VDE, I received several others from them, asking for help with the source code. It turns out that I’d hard-coded several values, causing things to break when anything was changed. I’ve fixed these, and have decided to just upload the source code files rather than my entire project. I’m doing this for two reasons: firstly, there are some assets I probably shouldn’t share under the licence I’m using – namely, some sound effects under a noncommercial licence, and Benchy Profiler – and because it’s going to be quicker to download. Just import the scripts into your Assets/Scripts folder, and they should be fine.

What’s changed:

  • Some syntax in LevelManager.makeInitialTrack() was rewritten for clarity
  • Less hard-coding of some variables. In particular, the maxiumum number of pieces allowed in the current track is a public value, allowing you to define exactly how many you want. I’ve also set it so that the TrackUpdater is moved to the centre of the new track, instead of the fifth segment out of 10 – it’s exactly the same, but more flexible.
  • Extra comments explaining the code

One other thing: I’ve added a disclaimer to the manual, which I should have added earlier. I built and tested VDE using my low-end Windows 7 laptop, so I have absolutely no idea how well this would work on any mobile device.

If you have any further questions, don’t hesitate to ask me.

Valentine’s Day Escape: Source available

I got an email today, asking if I could provide the source for VDE. I did have that stored on DropBox, but I removed it recently. So, I’ve added it back to Dropbox, after going through my code and adding some extra comments. You can find it here.

It’s under the Creative Commons Attribution 4.0 licence, so if anyone does use this, please attribute this to me and include a link to the source in the credits. If you have any questions, don’t hesitate to drop me an email asking about it.

Update 13th of June:
I’ve been told that there might be a problem with the code I included, most likely on line 127 of LevelManager.cs:

newPiece = possiblePieces[Random.Range(0, possiblePieces.Count)];

I suspect that this is caused by the syntax I’ve used for Random.Range there. The indices of a List or array in C# run from 0 to 1 below the number of elements in the array – i.e. in the array [a, b, c, d], there are four elements and the indices run from 0 to 3. However, if Random.Range takes a pair of integers, it will return anything between the first and a value that is one lower than the second, e.g Random.Range(0, 2) will return either 0 or 1 if 0 and 2 are passed as integers. If they’re passed in as floats, it will return any float ranging from 0 to 2 – including 2.

The quickest solution, if this does happen, is to replace Random.Range(0, possiblePieces.Count) with Random.Range(0, possiblePieces.Count -1). If this does fix the problem, I’ll update the source code to match.

Valentine’s Day Escape: Finished!

So, it is finally finished. Valentine’s Day Escape, my first Unity game that wasn’t a piece of shite, has been completed. You can find it here.

Looking back on it, it was a good learning experience. The biggest (practical) problem I had was how to procedurally generate the track, or how to build a random track as the player progresses. My solution to this is not innovative, but it works quite smoothly: the track segments, along with every obstacle and pick-up, are already placed in the scene before the game even begins, and then swapped in and out as needed. The track updates are triggered by a static collider that sits across the track and ignores everything by the player; when the player enters it, the first five pieces of the track are removed, five more are chosen at random and added to the end of the track. The collider is then moved further up the track, and it continues until the player dies.

The key point here is that I used an invisible collider to make track updates event-based, rather than constantly checking if the next update is due. This is generally better practice, as it means the CPU has to track less. Polling is a bit like a kid constantly asking “Are we nearly there yet?” – about the only reasons you’d do it is because there are no alternatives, or you might be doing something every frame (e.g. movement and input). In fact, a lot of Web-based applications are becoming more event-driven, particularly by using WebSockets.

Another problem I had, about six months ago, was lack of motivation. After working on it for a few months, I just got fed up and did a few other things. Then somebody commented on my WIP thread on the Unity forums, partly because I had looked at one of his, and his suggestions gave me the motivation I needed to finish this. So, one thing I need to work for future projects on is getting more feedback. With Spamocalypse, I am going to start posting to the Feedback Friday threads that run in the Design sub-forum on the Unity3D site.

All in all, I am reasonably proud of this. It’s not my first game, nor even the first long-term one, but it is the first I consider polished enough for general consumption.