Blogs Have Moved!

Hey everyone!

If you’ve landed here, a massive thank you for following or searching for The Great Beyond Company or Pathfinder or any other titles to come in the future!

Just to let you know, that all of the blogs have been moved over to www.thegreatbeyondcompany.com including a new article just released moments ago, at: https://thegreatbeyondcompany.com/posts/view/2019-09-02-pathfinder-dev-log-6–it-has-been-a-long-time

Thank you so much for your support, and hope to see you there!

Why Limiting/Scoping Your Game Is Not Only Okay – But How You Should Progress

Any developer that’s been in the role for some period of time will be able to tell you – that the most common pitfall that all of us fall into with a game at some point, is trying to make your game – everything.

Does this sound like you, or have you said a variant of the following sentence?

“Oh, I don’t know how to describe my game; I guess you could say it’s a bit of an action, adventure, sci-fi, RPG, MMO game, with puzzle elements and arcane magic components.”

– Every developer, ever.

The truth is, that while we think this would excite the minds of those listening – but in reality when it falls on experienced developer ears, we all think the same thing. That game – is going to suck.

WHY THAT GAME SUCKS

If it sounds so good, it contains so much, and there’s so much to do, why can I pretty much to a 99.999% degree of certainty, suggest that it’s going to suck?

As it turns out – quite a few reasons.

You CANNOT… Appeal… To Everyone…

The reason people even say this – is because they want a game that appeals to everyone. A game anyone can play, and find some fun in. But the truth, is that we’re all so different even as players, that there is no conceivable way we can all like the same elements in a game.

Imagine sitting down to play a story game on the PC, ready to delve into heavy character development, only to find you have to click the bottom right corner of the screen every minute to collect your coins you’re accumulating while you play? That right there, is someone who’s appealing to a mobile market, as well as a PC one.

Another example would be, I’d suggest a majority of people like Star Wars to some degree, and yet you’ll still find those who vilify it. Same with Game of Thrones, Harry Potter, or just about anything in the world, that you think is universally loved.

A great example for me, is I can’t stand the game Borderlands. Is it because it’s a bad game? No. It’s because the art style is too jarring to keep me engaged, and the constant damage number that pops up every time you hurt an enemy takes me out of the gameplay experience. It kind of reminds me it’s a game, and reminds me it’s not real – and so I feel less invested in the game. But again – it’s a well liked franchise.

Bartle Types
The Four Bartle Types

Don’t concern yourself with appealing to every gamer. We’re all different; we all like different kinds of elements in a game, it doesn’t make it good or bad. Just don’t worry too much about spending YOUR life trying to achieve an unachievable goal of having every extreme of a player satisfied. Perfection doesn’t exist. That doesn’t mean it can’t be perfect, to someone.

Buggy As Hell

With growing complexity, and a growing feature list; comes the potential for greater bugs. You might have implemented an effective loot player for your game, but now that you’ve added multiplayer, you’ve accidentally made it that they can duplicate loot by taking the loot and then trading or something bizarre like that.

Imagine doing that with EVERY single element of your game. Now that you can do 1 extra thing, you have to make sure that doesn’t break or subvert another mechanic you’ve already made. By the time you had another feature, you have to integrate it with those other two things before you can sign it off. So on and so forth.

The end result – TIME AND TIME AGAIN – is quite simply a buggy mess.

Unless you plan on spending your entire life maintaining the one game, using the same aging technology, you want to simplify where possible.

Fatigue Is Real

You’re not a bad person for running out of motivation with your game, or finding that you’re at a point where you’re stuck and are genuinely considering not going any further with it, just because you have no willpower to.

Making a game is hard. Making a GOOD game. Is really hard. It takes a shocking amount of determination. At the beginning you get the motivation of: I made X and it works, hooray! But as time goes on, there are less things that work straight from the off. As times goes on, the growing complexity of the projects, means that more often that not, you’re fixing, rather than simply creating a cool new feature.

By decreasing that unnecessary complexity, you’re not giving up, or not making your game as fun as it could be… You’re increasing the odds that it ever gets done. Once you’ve hit the point of fatigue, you need to give yourself a break. If you come back to it, and realise that it’s still too overwhelming, you’ll park it. It’s happened to us all.

Your First Game Is Probably Awful

It sucks to hear or to admit it. But it’s true. Have you ever heard of someone pick up a guitar and nail every chord? Rock out like Slash on the first go.

Turns out there’s a reason for that. Just because you’re a gamer, doesn’t mean you’re a game developer. By the time you start developing – you might think you have all the information and all the ideas needed to make an amazing game. But you don’t. Gamer and Game Developer CAN be mutually exclusive. They are different things altogether.

Don’t stress yourself out, by trying to make the perfect first game – instead. Make a terrible first game. Get it out the way. Make it buggy as hell. Make no money from it. Make it kind of purposeless.

But then… Improve. Get better. Experiment, fail, learn, repeat.

You WILL get there. If you want to.

You’re A Developer As Long As Your Developing

Remember, you don’t have to be famous to be included in the list of people who can call themselves a developer. If you are developing a game, you’re a developer.

Make the journey to success, the journey to progress, a fun and happy one. Don’t burn yourself out, and reap no rewards because you focus on the unattainable. It’s not giving in to admit your game can’t be perfect for everyone, it’s mature.

Finally and perhaps most importantly – keep loving doing what you’re doing. Keep that passion going. Creating content, is amazing. Having people love it, is wonderful. It’s worth the effort. Every time.

Pathfinder – Dev Log 5 – Game Audio (Soundtrack)

As always in order to get straight into this one – this one will be focused on the progress towards a soundtrack in the game, feel free to check out the other dev logs (a few included below) and as always, any help to raise awareness of the game including commenting, liking, linking and sharing is massively appreciated, and a big thank you to anyone following along!

The Daunting Thought of Making Music

I’m an avid fan of music in general. All kinds. The regular to some extent, but the weird and wonderful even more so (e.g Alternative, Synthwave, Electronica, 80’s Synth). I listen to it almost 24/7. Always have, and no doubt always will. In my home there will either be TV on in the background, or music. Even with guests over, it’s just a thing. I’ve also played guitar and sang a little for a long time. But I’ve never went as far as making digital music, despite the fact I’ve always wanted to.

The simple fact is that finding the right DAW (Digitial Audio Workstation) is a daunting process in itself, and then figuring it all out, buying sound packs, learning the ins and outs etc – it just seemed a little too much to add on top of making games.

But music and making any kind of content is a passion for me… So it only made sense that I would eventually go about learning it… In fact, I had no doubt in my mind that at some point I would get around to it.

And then I thought… I have the perfect opportunity to go about doing it now… Under the guise, of Pathfinder

And so… this past week… I went about learning how to make music.

The Right DAW for Me

I’d previously downloaded an Ableton Live 1 month trial, and bought a tutorial from Udemy, to see if it was a viable workstation for me. I’d heard a lot of people suggest many, like Cubase etc – but something about the way Ableton looked, appealed to me. And so I went about trying that.

And something about it just clicked. The idea of iterative experimentation in the Session View, and then transferring what you like over to the Arrangement View for the final track arrangement. I liked it… It made sense. Trial and error. Yeah that sounds nice. Nah try that same hook but with a different instrument. Yeah keep that, but not that. Export.

It seemed simple to me. I knew I would have to go about purchasing it, but even the Standard version is a whooping £319 ($417) … So I’d put it off when the trial ran out about a month or two ago.

However, last week (the Thursday) I bit the bullet, and purchased it. Along with a brand new Yeti Microphone, that I’d always wanted for various recordings.

Horrible expense for me – but very much a necessary one. And since setting it up took so long, and finding some packs was taking even longer – I actually only ended up being able to play around with it for an hour on Thursday.

But even still… I came up with this.

Which I think for a first attempt at making a song, is a pretty good one! However, you can clearly tell its amateurish, and a bit unpolished. A bit all over the place. I like the main hook, but it does get a bit repetitive, especially by the end, and the instruments I used were very basic.

But still, feeling proud of it – I exported it and put it online. And left it…

After a lovely relaxing weekend, chilling and spending time with some friends, I came back to Ableton on Sunday… to make the horrible realisation…

The Upgrade

Essentially, as I started farting around with Ableton Standard, I noticed that a number of features I had come to love in the trial version, were now not available to me. Like they’d just vanished.

I tried to make a Vocoder using an Analog input… And I couldn’t. I didn’t understand what I was doing wrong.

It was then I realised, that the trial version… Was of Ableton Suite… Not Ableton Standard. i.e. To get the same features I’d experimented with and needed, I’d have to upgrade. And that upgrade… Cost me another £269 ($352) …

Obviously I was gutted at the prospect of spending so much… But I’d saved up for a long time for expenses like this, and knew Game Development can get expensive if you let it. So fortunately I HAD prepared.

But… Almost immediately… Not only was it made worth it by the sheer number of new packs and new instruments. But I noticed that with them… I seemed to be getting the hang of it, much quicker than I had before. And by late afternoon… I had made this.

Now I’m hoping you’ll agree with me… But this is a massive improvement. As in, it actually sounds like a song, rather than an amateur collection of noises. And while I’m sure there’s lots that could be added or changed – I’m incredibly proud of it, seeing as I’d owned the program for a grand total of 4 days (or 1 for Ableton Suite) and then actually only touched it since buying it, for about 7 hours.

It’s gave me this amazing motivation and rejuvenation, I didn’t even know I needed. I guess I’ve been working on Bug Fixing and making things compartmentalised for so long, that I’ve not been able to create something NEW. It’s just been adding, or fixing, or making compatible, or better in the long run.

But now… I can create something entirely new whenever I feel like I need it. And it’s part of a world I love as well – MUSIC.

Moving Forward

Moving Forward, I’m going to be creating lots more tracks, an abundance of them – and then be very selective of those ones, which ones will end up in the game.

However, if in the coming weeks, I make the same improvements I made in just those few days, I’ll be able to be very proud of what I’ve made to the game.

What do you think of them? Are you a fan? Let me know in the comments or on Twitter, and if you fancy checking out the latest tracks I’m making – I’m putting a bunch up on SoundCloud just to get feedback etc, so feel free to follow them, and like or comment there too so I know which ones to include in the final game!

Until next time, have a great one guys!

Pathfinder – Dev Log 4 – Procedural Generation & Reusability

Diving in straight away as usual, got a lot to get through in this one! (Seriously; big apologies it’s long) Just a reminder as always to check out my other dev logs, tutorials, and to like and follow them if you’d like to keep up – it’s a massive help and motivational booster!

This one is a very disjointed dev log, as so much has changed since the last dev log – but stay with me on this!

Also, feel free to catch up on some other dev logs!

Transition from Prototype

Personally I would argue that the key difference between taking your game from the prototyping stage, to a playable one, is replay-ability. Your game isn’t REQUIRED to look good. It isn’t even REQUIRED to be polished. We’ve all played terrible looking games, and we’ve all played buggy ones. (SEE LATEST AAA TITLE THAT NO DOUBT DISAPPOINTED)

But if you can’t PLAY the game… well it isn’t really a game. It’s not even really a demo, it’s probably closer to a tech reel. Of course, if you have one level that you play from start to finish for testing purposes, that’s fine because it serves it’s purpose. But give it to a person and say it’s a game, they’ll stumble through it, quickly finish it, and then look for more. When no more is available, they’ll leave. Ultimately, gaming is an obstacle that we’ve defined for ourselves, that doesn’t exist. I.e. there are no obstacles to occupy my mind just now, so I’ll play a game which creates a challenge, and an obstacle to overcome based on the conditions of the game. If there are no more obstacles, my mind is not occupied, and so I will search for something else.

So what have I done since last time to make Pathfinder, a bit more of a game? Thankfully, the answer is: a lot.

Procedural Generation

Essentially, as I mentioned – previous to the past two/three weeks work since the last dev log (I know it’s been a long time, just been very busy!) before the game was more of a tech demo. You started, you receive the basic menu, and then you began from the star map. You’d select a mission (but while other missions were shown, only the first one was accessible), select your ship (only one ship was selectable) and then you’d be shown the pilot select screen, but this didn’t actually do anything. When you were done, you’d confirm start, and play the Tutorial level which explained the basic concepts.

Essentially, an object would be spawned containing the sequence of events by which the tutorial should follow; and you’d play through that. When you got to the end, you’d be redirected to the star map.

NOT ANYMORE! … Kind of!

Limitless Environments

Now you might be thinking – “He’s just said your game doesn’t have to look good, and then he’s dove right in to procedural generation of the environment, which is directly to do with graphics… is he on glue?” Well, the answer is no. The reason I’m starting with the environment, is simple:

It is shocking how much of a difference just making your environment procedural can make to the look and feel of your game, for both yourself and your playtesters (and also ultimately your actual users). It is astounding, how by simply changing the environment around you, you can feel as though even the same objective is somehow varied. It simply because it implies that there is more to come. This game is not just X playing over and over again, it’s got possibility now, and the proof is in your eyes!

So I began by looking into how my level was constructed. Previously, as mentioned, I literally manually placed a number of objects that were set to a scrolling speed, and asked some of them (such as the stars or nebula in the background) to repeat when they reached just below the bottom of the page. Essentially, by moving the background instead of the ship, not only can I imply movement, but it also allows me to track its position more easily, and more reliably track and measure all other background components, because they are relative to a short distance around 0,0,0 – rather than having my ship constantly move forward, and my backgrounds would have to spawn and de-spawn, or activate and deactivate as and when necessary. This way I can literally look at the same window when my game runs, and everything will happen to the player, around this small window of gameplay. Again, this manual placement is totally fine, while it was my prototype. But by attempting to take it beyond that – I had to get rid of this method of placement; yet still keep my method of moving the background instead of the player. * Small note just for clarification incase I’ve worded this poorly, the player DOES still move – but they move within a window of gameplay, i.e. around a short space of movement. So the camera doesn’t actually ever move or follow the player, because it doesn’t have to!

So to begin making my levels and their environments able to be procedural, I had to start by breaking the game down in the state it was in. I took every element it current had, and how it was handled, and compartmentalised it; so that every single environmental element could be controller, and could even exist at any point and in any quantity, irrespective of all other elements around it. Essentially by changing it so that the level was built by the controllers that handle the level itself, at any time we can control every aspect of the background, including the density of everything. By then applying the potential for randomisation, we can even have the same set of conditions/parameters return us with different looking results, but it’s all handled the same!

For example: below are six screenshots – taken from Pathfinder. It’s the first playable frame, of the same level, with the same set of conditions/parameters just loaded six different times. (For spoiler reasons I’ve removed the objective)

As you can see the planets vary in size, if they have moons is determined, their rotation, their placement, their skins, the nebula are placed differently, the stars, the shooting stars, the multi-coloured brighter stars, EVERYTHING! And let me just re-iterate, this is with the SAME starting conditions… i.e. I didn’t change a single variable to achieve this result.

Imagine just changing one or two variables, to change the density of the nebulas (proximity), or change their thickness, or the number of planets that appear etc etc. This is also with a fairly limited set of potential objects that can appear. This object list will grow as the project grows. And so complexity will of the environments will grow, but still be controlled easily!

Probes Lead To Content

With the ability to alter and randomise the backgrounds, we can facilitate the potential for procedurally built levels, which are essential to the main mechanics of the game! Essentially, let’s say I create 10 story levels (just for example, I’m hoping to create significantly more at release and then add more after release) and each level requires you to be 5 ranks higher than the previous level.

Well, rather than having it so that you have to replay the same levels to up your rank – we have it that you only earn rank, or credits, or scrap relative to your last registered score for story levels, and then provide you with the alternative, which is procedural levels. Let me explain this in a different way: if you play level 1 and get a score of 10, and are awarded 10 credits that are tracked persistently (i.e. they are saved), then if you play the level again and score 11, you will only get 1 credit, because it’s only 1 better than your previous high score.

So instead of just replaying levels and edging your way along, I decided to make procedural content (and let’s face it; unending content and reasons to return) so that you could play these instead, to increase your rank and your various currencies.

My method of doing that for Pathfinder; turned out to be the probe.

Star Map Selection Screen

This is an older (but still accurate in terms of content) screenshot of the Star Map where you select your missions. As you can see in the top right there is a little icon, with a number. This represents the number of probes you currently have! – (A newer screenshot would show that the number has been changed so that it’s number you have against maximum you can have)

Essentially you can drag the probe icon down to anywhere on the Star Map, and when you release it, it’ll send a probe from off-screen, firing directly to where you let your finger go. The probe will then search for nearby opportunities for you to gather resources, or fight enemies, to advance your goals and rank up your pilots!

Thankfully, the potential level types are so varied, and have varying levels or rarity, that you’ll feel you’re always discovering new mission types as you progress through the game! The only caveat to these missions, is that you won’t discover new enemy types here or any new mechanics you haven’t already discovered in the story – as in the story the mechanics are more thoroughly explained and on-boarded.

It’s Become A Game

I could ramble on about the specifics of it on a technical level, and how some things have been tweaked and others have been changed altogether – but a lot of the stuff I did since the last dev log, was just making it transition from being a one-level prototype which showed the processes you would go through to play the game – to an actual game. In theory, now you could play x number of procedural levels and rank yourself up and finish the story to completion!

I just so happens that for now, there isn’t a lot of IMPLEMENTED procedural missions or even very many story missions for you to play – but the core has been built! Now it’s just about extending this outwards, until I have a couple of working procedural missions to work with, and at least the first sector of the game to play in terms of story missions (about five or six missions including an in-depth tutorial).

Once I’ve got that – I might see about extending the testers list to 10+, so stay tuned for that if you want to get involved.

SO MANY OTHER THINGS

There are SO MANY OTHER THINGS that I worked on during the past month, and I’m dying to show them off. But they’re just shy of being completed, and I always prefer talking about stuff I HAVE done versus stuff I WILL do – because that way anyone following along feels as though I follow through on the things I talk about.

So if at any point you wanted more… Trust me… It’s coming.

Hint hint… It’s not just asteroids you’ll be encountering anymore.

Upgrade to Unity 2019!

Part of this update was also the upgrade to Unity 2019!

Anyone involved with Unity will know it’s a bit of a roll of the dice as to whether your project is okay or not after the upgrade – and this time!… *DRUMROLL*

It broke everything! – … Yeah. Yeah it sucked. It broke so many little packages I was using for various reasons and so unfortunately it broke and it’s taken a shocking amount of time to get it back to its working state again.

However, I can confirm, all is good now, bar a few tiny *not even remotely game breaking* bugs that I’ll fix over the next few days alongside actual development.

Not a Burnout – Just a Slowdown

So to anyone who follows the twitter @dalriadaconnor, you’ll know that I took a week off work to essentially get things sorted, and work on the game. And while I had an amazing time – I really should have spent a little more time for myself. Essentially I literally woke up everyday and worked at least a 12 hour shift on the game – which is amazing and I did so many amazing things – but it just so happened that when I came back from work, there was a bit of a hectic two weeks – so I completely slowed on progress with Pathfinder. Particularly because of the aforementioned Unity 2019 bug list.

To put how busy I’ve been into perspective, I started writing this blog on the 12th of April, which was already a few days late. It’s now the 29th of April.

But – alas – I believe that wee period of slowdown is over, and I’m excited to get things back to the way they were in terms of the pacing! – Although I will absolutely be sure to take more of a break next time, so that even if something unexpected comes along, I won’t feel absolutely overwhelmed!

Conclusion

This has easily been the hardest dev log I’ve ever written – because the most has been done in a short period of time, but it’s so difficult to describe EXACTLY what’s been done. Essentially, procedural generation now implemented, and the game is no longer just a showcase, it’s an actual game with testers able to rank and progress through the game in a similar fashion as to how the endgame could run.

Hopefully the next dev log will be available much sooner, and be a little bit more succinct!

Any tips or advice for what you’d like to see next time? Maybe a TD:LR style feature change/commit list? Let me know in the comments!

Until next time!

Last Three Posted Blogs :
Pathfinder Dev Log 2 : You Can’t Build Without A Foundation
Pathfinder Dev Log 3 : The Benefits of Prototyping
How to Handle Saving And Loading In Unity: Part One – Player Prefs

How To Handle Saving And Loading In Unity: Part Two – Serialization + Bonus At The End

For the first part, and the easier to implement and grasp version of saving and loading, but less secure and scalable, read:
How To Handle Saving And Loading In Unity: Part One – Player Prefs.

Since this is part two; I’ll just do a quick recap on what this tutorial is about:
Essentially Saving and Loading is a scary concept to approach as it needs to be handled right, but it’s surprisingly easy to work with once you have a grasp of the concept.
Player Prefs can be implemented quickly, but is not secure and has limited scaling. Serialization takes a little longer and is more difficult to grasp, but is easily scalable, and much more secure if you’re handling sensitive information.

So let’s dive right in!

Serialization

What exactly is Serialization?

Quite simply, the Microsoft Documentation on Serialization for C# puts it best :

Serialization is the process of converting an object into a stream of bytes to store the object or transmit it to memory, a database, or a file. Its main purpose is to save the state of an object in order to be able to recreate it when needed. The reverse process is called deserialization.

Microsoft Documentation –
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/serialization/

This probably describes more conventionally what you would expect a Save File to be, and do; as opposed to Player Prefs which is Unity Specific. What this means, it that all we need to make this work, is an Object we want to Serialize, and some C# libraries. With C# being an Object Oriented Programming Language, and Unity being built upon Game Objects, we need very little to actually get us up and running.

In no time, wWhen we’re done with this tutorial, we’ll have a .dat file, that consists of some variable names, and the values we hold within them. Due to the conversion, even if people were to discover your file, there is little they can do to alter the values of it, and alter our information. Especially with a little bit of creative honey-potting*.

Implementation of Serialization

So for illustrative purposes, the example we’re going to use is that we’re making a Sci-Fi First Person Shooter, where we wan to keep track of certain Weapons we’ve unlocked throughout the game. We also want to keep track of the player level we’ve reached, and our player’s name.

Let’s set up a scene same as before, although this time we’re going to dive more into what Serialization can do, so we won’t spend time setting up buttons for everything:

  • Create a new project and a new scene in Unity. Call both the project and scene whatever you feel like.
  • Go to the GameObject Menu at the top of the screen, and select Empty GameObject. Click on the new GameObject, and rename it to “GameController”. Go to Add Component, and add a new Script Called “GameControllerScript”.
  • Go to the GameObject Menu at the top of the screen, and select Empty GameObject. Click on the new GameObject, and rename it to “SavingLoadingController”. Go to Add Component, and add a new Script Called “SavingLoadingScript”.
  • Below I’ve included both scripts. Simply copy and paste the GameControllerScript below into the corresponding Script in your scene, and do the same for the SavingLoadingScript.
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class GameControllerScript : MonoBehaviour 
{
    /* Normally the following variables should be private and we would 
     * access them only using the functions below. However, to allow us
     * to edit the variables in the inspector while we test, we'll keep
     * them as public.
     */
    public List<string> weaponsUnlocked;
    public string playerName;
    public int playerLevel;

    public void SetWeaponsUnlocked(List<string> w){
      weaponsUnlocked = w;
    }

    public void SetPlayerName(string p){
      playerName = p;
    }

    public void SetPlayerLevel(int p){
      playerLevel = p;
    }

    public List<string> GetWeaponsUnlocked(){
       return weaponsUnlocked;
    }

   public string GetPlayerName(){
      return playerName;
   }

   public int GetPlayerLevel(){
      return playerLevel;
   }
}

While You’re Here – Check Out Some Of My Most Recent Dev Logs!

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using System;
using System.Runtime.Serialization.Formatters.Binary; // Needed to format binary files
using System.IO; // Need to access filing system
using UnityEditor;

public class SavingLoadingScript : MonoBehaviour
{

    public GameControllerScript gameControllerRef;
    private const string GAME_SAVE = "/game_save.dat";

    private void OnEnable()
    {
        if (!gameControllerRef)
        { // If we haven't set the Game Controller Ref in the inspector.
            gameControllerRef = GameObject.Find("GameController").GetComponent<GameControllerScript>();
        }
        Load(); // Load our Data
    }

    private void OnDisable()
    {

        Save(); // Save our game on level quit.

    }

    public void Load()
    {
        Debug.Log("Loading Game...");
        if (File.Exists(Application.persistentDataPath + GAME_SAVE))
        {
            BinaryFormatter bf = new BinaryFormatter();
            FileStream file = File.Open(Application.persistentDataPath + GAME_SAVE, FileMode.Open);

            GameData data = (GameData)bf.Deserialize(file);
            file.Close();

            gameControllerRef.SetWeaponsUnlocked(data.weaponsUnlocked);
            gameControllerRef.SetPlayerName(data.playerName);
            gameControllerRef.SetPlayerLevel(data.playerLevel);

            Debug.Log("Load Complete.");
        }
        else
        {
            Debug.Log("No Save File Found");
        }
    }

    public void Save()
    {
        Debug.Log("Saving Game...");
        BinaryFormatter bf = new BinaryFormatter();
        FileStream file = File.Open(Application.persistentDataPath + GAME_SAVE, FileMode.Create);

        GameData data = new GameData
        {
            weaponsUnlocked = gameControllerRef.GetWeaponsUnlocked(),
            playerName = gameControllerRef.GetPlayerName(),
            playerLevel = gameControllerRef.GetPlayerLevel()
        };

        bf.Serialize(file, data);
        file.Close();
        Debug.Log("Save Successful!");
    }

    public void Delete()
    {
        Debug.Log("Delete Save File");
        if (File.Exists(Application.persistentDataPath + GAME_SAVE))
        {
            File.Delete(Application.persistentDataPath + GAME_SAVE);
            Caching.ClearCache();
            #if UNTIY_EDITOR
            UnityEditor.AssetDatabase.Refresh();
            #endif
            Debug.Log("Save File Deleted");
        }
        else
        {
            Debug.Log("Deletion Failed: Could not find save file.");
        }

    }
    
}

[Serializable]
class GameData
{

    //Game Save Data
    public List<string> weaponsUnlocked;
    public string playerName;
    public int playerLevel;
}

Now that we’ve got our scripts in the respective GameObjects, we can Play our scene.

On the first play, since we haven’t actually SAVED our game yet, nothing will load. You’ll get the Debug Log that we set saying, “No Save File Found.” – Don’t worry – of course we’ve expected that and anticipated it.

Navigate to your GameController game object, and edit the values we created. Change the player name to something memorable, or absurd, edit the player level too, and add a few values to our list.

When you’re done editing the scene, stop it, and thanks to our OnDisable method which Saves the game as the last thing we do before the game ends, when we replay the same scene, our saved values will be there!

And that’s it! Our files are securely being save and loaded at Runtime!

Now this is all your need to get Serialization working, and to expand or alter this list, simply add variable to both Scripts – but let’s look a little closer at exactly what’s going on and why.

Breakdown

I’m not going to break down what the GameControllerScript does, because it simply holds variables we can then use or reference in our scene later on. So for instance in our example, if we load a weapon prefab, but we want to know if the player has unlocked it or not, we would simply iterate through the weaponsUnlocked List of the GameControllerScript, and if it’s found, keep it, if it’s not, GET RID.

The SavingLoadingScript however, looks like it has a lot going on, but it’s surprisingly easy to understand when broken down. First we grab the libraries we need, and create our Class:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using System;
using System.Runtime.Serialization.Formatters.Binary; // Needed to format binary files
using System.IO; // Need to access filing system
using UnityEditor;

public class SavingLoadingScript : MonoBehaviour
{

    public GameControllerScript gameControllerRef;
    private const string GAME_SAVE = "/game_save.dat";

We also need a reference to our GameControllerScript so that we can actually edit it, and for safety (so we don’t misspell our game_save data file later on) we set a private const string GAME_SAVE.

Next, we add our OnEnable and OnDisable methods, which will allows us to Load the Game on Scene Start, and Save it when the Scene Ends.

private void OnEnable()
    {
        if (!gameControllerRef)
        { // If we haven't set the Game Controller Ref in the inspector.
            gameControllerRef = GameObject.Find("GameController").GetComponent<GameControllerScript>();
        }
        Load(); // Load our Data
    }

    private void OnDisable()
    {

        Save(); // Save our game on level quit.

    }

Now we’re actually going to skip the saving and loading methods, and come back to them in a second. You see, as per the Microsoft C# documentation at the top of the page, we actually need an object to save in order for this to all work. So we need to do that first, and that’s where the GameData class at the bottom of our script comes into play.

[Serializable]
class GameData
{

    //Game Save Data
    public List<string> weaponsUnlocked;
    public string playerName;
    public int playerLevel;
}

The “[Serializable]” is required before the class, to even allow the object to be serialized in the first place. Without it, none of this script will work, so be sure that’s included. Then it’s simply a case of creating variables that will hold our save data.

*Note, that there are some restrictions to saving, like you cannot simply save a whole GameObject unfortunately. There are workarounds to this, such as saving the variables instead, and then using them in a newly instantiated prefab when you load the game.

Now that we have our GameData object, we can look into what’s happening when we load that object!

public void Load()
    {
        Debug.Log("Loading Game...");
        if (File.Exists(Application.persistentDataPath + GAME_SAVE)) // If the file exists
        {
            BinaryFormatter bf = new BinaryFormatter(); // Create the binary formatter which will allow our file to be converted from bytes, to usable variables etc
            FileStream file = File.Open(Application.persistentDataPath + GAME_SAVE, FileMode.Open); // Get the file

            GameData data = (GameData)bf.Deserialize(file); // Create an instance of the GameData object and set it to the result of our Deserialized file i.e. our converted file
            file.Close(); // We're done with the file as we have the object we need, so close it.
            
            // Set our GameControllerScript variables to the one's we've found in our saved datafile
            gameControllerRef.SetWeaponsUnlocked(data.weaponsUnlocked);
            gameControllerRef.SetPlayerName(data.playerName);
            gameControllerRef.SetPlayerLevel(data.playerLevel);

            Debug.Log("Load Complete.");
        }
        else // If we can't find the save file, it hasn't been created yet...
        {
            Debug.Log("No Save File Found");
        }
    }

In the above I’ve covered everything in the documentation/comments so that you can see exactly what’s going on, line by line. But essentially it’s this:

Check Save File Exists -> Create Binary Formatter Instance ->Get The Save File -> Create A New Game Data Object and Set The Values Based on the Values of the Binary Converted Save File -> Close the Save File -> Set The GameControllerScript variables to the Save File Ones.

And quite simply, the Save Method works in a similar fashion, but instead of getting the values, it’s setting them. So it’s pretty much doing the same thing, but the key parts are reversed:

public void Save()
    {
        Debug.Log("Saving Game...");
        BinaryFormatter bf = new BinaryFormatter(); // Create the binary formatter which will allow our file to be converted from variables to bytes for storage
        FileStream file = File.Open(Application.persistentDataPath + GAME_SAVE, FileMode.Create); // Create our file in the location specified

        // Create a new Game Data object and set its values to the values we have in our GameControllerScript
        GameData data = new GameData
        {
            weaponsUnlocked = gameControllerRef.GetWeaponsUnlocked(),
            playerName = gameControllerRef.GetPlayerName(),
            playerLevel = gameControllerRef.GetPlayerLevel()
        };

        /* Serialize the game file. Essentially write to our file, the
         * resulting bytes from converting our data GameData object to
         * bytes.
         */
        bf.Serialize(file, data);
        file.Close(); // Close the file, since we're done with it
        Debug.Log("Save Successful!");
    }

Again I’ve documented it all, but the saving works as follows:


Create Binary Formatter Instance -> Create The Save File -> Create A New Game Data Object and Set The Values Based on the Values of The GameControllerScript -> Serialize the file.

In a weird way – the loading part actually looks more confusing than the saving part. Saving is, relatively easy!

Lastly, although it has nothing to do with serialization, I’ve included a Delete Method should you want to Delete Your Save File and Reset!

Debug.Log("Delete Save File");
// If the file exists
        if (File.Exists(Application.persistentDataPath + GAME_SAVE))
        {
// Delete it
            File.Delete(Application.persistentDataPath + GAME_SAVE);
// Clear any Caches to ensure it doesn't persist
            Caching.ClearCache();
// If in the Unity Editor, refresh the asset Database
            #if UNITY_EDITOR
            UnityEditor.AssetDatabase.Refresh();
            #endif
            Debug.Log("Save File Deleted");
        }
        else
        {
            Debug.Log("Deletion Failed: Could not find save file.");
        }

And that’s it! Everything you should need to know to be able to apply Serialization to your game project!

Of course, there are limitations and if you want to find out more about why they happen or how to work around them, I strongly suggest reading the Unity Docs – but hopefully this Dev Log has helped to De-Demonise the whole concept, and you’ve found it useful enough to implement in your future projects!

Pros and Cons of Serialization

Pros:

+ Secure
+ Scalable
+ Reliable

Cons:

-More difficult to grasp
-A little more clunky for quick testing

Essentially, Serialization is the way to go, once your project gets going, and certainly it’s required if ever you want to hold any sensitive information. It has very few limitations on DataTypes it can hold in terms of C# DataTypes, it just so happens that it doesn’t like holding entire GameObjects as this is Unity Specific. But as mentioned, there are workarounds to this.

Conclusion

Thanks very much to those who made it this far! If you enjoyed this, please get vocal in the comments, like, follow, and of course check out the rest of the content both here, and on Twitter @dalriadaconnor

I really appreciated the response to the first part of this tutorial, so hopefully you like this one too.

If you have any more questions also, please feel free to ask questions in the comments, and ask questions on Twitter too! Additionally, if you feel any more information may be helpful, feel free to get in touch there too!

Until next time!

BONUS

As promised – a bonus Unity Tip that will save you countless hours in the long run! It’s such a useful tip that I might make a tutorial on this alone one day, just to spread the word – but for now I’ll include it below. It’s saved me countless hours already while I develop Pathfinder, the mobile game I’m working on (check out the other Dev Logs on this site)

What is this Bonus? … Personalised Menu Items / Development Tools! See the screenshot below, where I’ve created my own personal menu item at the top of my Editor, and I can then use this to achieve Saving and Loading etc, or whatever I want!

To do this, simply create a new Script in your Unity Project. I like to name it something like “DevelopmentToolsScript” so that’s what I’ll use, but you can name it anything you want.

Then simply add the following code :

using UnityEngine;
using UnityEditor; 

#if (UNITY_EDITOR) // Only apply the below code if we're in the editor, don't attempt it in the build!

public class MenuItems
{
    private const string MENU_NAME = "Development Tools/"; // Create a constant for our menu name, to keep things consistent
    private const string SAVING_MENU = "Saving/"; // Create a constant for our saving name, to keep things consistent

    
    // Saves Game
    [MenuItem(MENU_NAME + SAVING_MENU + "Save", false, 1)]
    private static void Save()
    {
        SavingLoadingScript saveRef = GameObject.Find("SavingLoadingController").GetComponent<SavingLoadingScript>();
        saveRef.Save();
    }

    // Loads Game
    [MenuItem(MENU_NAME + SAVING_MENU + "Load", false, 2)]
    private static void Load()
    {
        SavingLoadingScript loadRef = GameObject.Find("SavingLoadingController").GetComponent<SavingLoadingScript>();
        loadRef.Load();
    }

    // Delete Save
    [MenuItem(MENU_NAME + SAVING_MENU + "Delete Save", false, 3)]
    private static void DeleteSave()
    {
        SavingLoadingScript deleteRef = GameObject.Find("SavingLoadingController").GetComponent<SavingLoadingScript>();
        deleteRef.Delete();
    }

    

}

#endif

That is literally it… Such an easy tip, but just a hard to find one. If you go back to your Unity Scene, you’ll see your menu at the top updated, and you can now click any of these to Save, Load, or Delete your save files!

To add more, simply copy everything between the commented lines, and use the same syntax.

The MenuItem syntax goes as follows, MenuItem(string itemName, bool isValidateFunction, int priority)

itemNameThe itemName is the menu item represented like a pathname. For example the menu item could be “GameObject/Do Something”.
isValidateFunctionIf isValidateFunction is true, this is a validation function and will be called before invoking the menu function with the same itemName.
priorityThe order by which the menu items are displayed.

Then add the function you would like to attach to it, directly below!

Enjoy this handy tip!

*Side note – all functions underneath it, must be static functions. You can read up more on why this is: in the Unity Documentation for Menu Items.

*Honeypotting –
https://en.wikipedia.org/wiki/Honeypot_(computing) Interestingly enough… Don’t look this up without safe search on.

How To Handle Saving And Loading In Unity: Part One – Player Prefs

The concept of saving and loading can be a daunting one, both with the impending fear of implementing the thing properly, but also with either a distinct lack of information, or an abundance of misinformation on how it works.

Well, fortunately – I thought I’d cover this topic in detail, so that should you ever need a guiding hand, you can use this as a reference to implement your own systems. I’ve split this particular tutorial into two parts, Player Prefs, and Serialization; for better readability. This part contains Player Prefs, with Serialization coming soon.

So without further ado let begin covering the first of the two types of saving and loading within Unity, PLAYER PREFS.

Player Prefs

Player Prefs is a platform independent means of saving, that’s incredibly quick to implement, and consistently reliable, which is the main upside of using player prefs in your game. The downside, is that it’s not entirely secure, and unfortunately should someone be determined enough to break into it, they can. It also can only handle a certain number of data types.

So if your save information contains non-sensitive information, this is an entirely ideal method for you to use, or even practice with in development – however, if you find yourself saving information that may pertain to monetisation availability etc, then you may want to skip this part, and go to SERIALIZATION (coming soon).

Implementation of Player Prefs

Let’s suggest in our exact example, we are making a fantasy game, where you can name your character, and for every orb you collect, you increase in power by one.

Meaning that we want to remember how powerful our character is, and also we want to remember their name.

Well, in this exact example we only need to save our name once, and simply reference it later. So let’s take a look at the code we would need to implement that.

** To create an example that will allow you to follow on with this tutorial, perform the following steps:

  • Create a new project and a new scene in Unity. Call both the project and scene whatever you feel like.
  • Go to the GameObject Menu at the top of the screen, and select Canvas. Set the Render Mode to Camera, and set the Camera to the Main Camera in the scene.
  • Right-Click on the Canvas you created and Navigate to UI. Create an InputField, and position it somewhere the Canvas that you can see. Also, Create a Text GameObject, and equally position it somewhere you can see, ideally above or below the InputField you created. Place a Button somewhere and change the text to something like, “Get Name”.
  • Click on the GameObject Menu at the top again, and then Create an empty Game Object. Name this something memorable, like “CharacterNameController”, and add a new script component, called “CharacterScript”.
  • Open up the CharacterScript and paste the following code. Save it.
  • Back in the inspector, drag the Input object you created, onto the script characterInput, and drag the Text object onto the script characterText.
  • Click on the InputField you created, and under End Edit, click the little plus sign. Drag the CharacterNameController object you created onto the new function you created. When you’ve done that, click on the assign script section next to it, and select InputSet().
  • Click the button you created, and under OnClick, click the little plus sign. Drag the CharacterNameController object you created onto the new function you created. When you’ve done that, click on the assign script section next to it, and select InputGet().
  • This should be your scene set up, so that the following code can be demo’d.

I’ve shown the full final code for editing the character name, below, and then following that, I’ll break it down, section by section.

using UnityEngine;
using UnityEngine.UI;

public class CharacterScript : MonoBehaviour
{

    public Text characterText; // The text object where we display our characters name
    public InputField characterInput; // The input object where we type our characters name
    private string characterName = ""; // Private reference to our character class
    private const string CHARACTER_NAME_KEY = "CHARACTER_NAME_KEY"; // Set a CONST value to avoid spelling errors in save file

    private void Start()
    {
        InputGet(); // Display the character name.
    }

    /*
     * Here we get the player name, and return it, from any location
     * it exists. If it doesn't exist anywhere, we will still return
     * blank, but leave a debug for us to know why blank was returned.
     */
    private string GetCharacterName()
    {

        if (characterName != "")
        { // If we don't need to load, don't
            return characterName; // return the character name
        }
        else if (PlayerPrefs.HasKey(CHARACTER_NAME_KEY))
        { // If the playerName has been saved before and exists
            characterName = PlayerPrefs.GetString(CHARACTER_NAME_KEY); // Set the characterName based on the name in our save file.
            return characterName; // return the character name
        }
        else
        {
            Debug.Log("Player name has not been set yet!");
            return "Enter Name"; // return placeholder, but submit a warning so we know why a name wasn't returned.
        }
    }

    /*
     * Set the character name, based on the string provided.
     */
    private void SetCharacterName(string name)
    {

        characterName = name;

    }

    /*
     * Save the character name in our save file. This is separate from save, because we might not ALWAYS want to save the name to a save file, but we would still like to set it at runtime.
     */
    private void SaveCharacterName(string name)
    {

        PlayerPrefs.SetString(CHARACTER_NAME_KEY, name); // Save the characters name, using the key 'characterName' and setting the value to the provided string value of name.

    }

    /*
     * Deletes the characters name.
     */
    public void DeleteCharacterName()
    {
        if (PlayerPrefs.HasKey(CHARACTER_NAME_KEY))
        {
            PlayerPrefs.DeleteKey(CHARACTER_NAME_KEY);
        }
        else
        {
            Debug.Log("No save file to delete!");
        }
    }

    /*
     * This function will actually start the process off. It allows us to keep the rest of the code private, and our variables secure.
     */
    public void InputSet()
    {
        string name = characterInput.text;
        SetCharacterName(name);
        SaveCharacterName(name);
    }

    /*
     * This function actually allows us to grab the information.
     */
    public void InputGet()
    {
        characterText.text = GetCharacterName();
    }

} 

And that’s it!

Now, load up your scene, and it’ll grab your previous characters name. On your first time loading, we’ll be given the default placeholder of “Enter Name”.

When you type in a name, and it’ll automatically be saved to the GameObject, and then saved via Player Prefs!

Breakdown

So what exactly is going on here, and why do we need what we need? Well let’s take it bit by bit.

using UnityEngine; // For Player Prefs
using UnityEngine.UI; // For the UI Elements

public class CharacterScript : MonoBehaviour
{

Player Prefs is built in to the UnityEngine, so to physically get it to work, that’s all we need to include at the top of our file. However, because we use UI elements to access our functions, we must include the UnityEngine.UI namespace to get access to it’s methods. Public class CharacterScript : MonoBehaviour simple declares our class, which our object becomes an instance of.

public Text characterText; // The text object where we display our characters name
    public InputField characterInput; // The input object where we type our characters name
    private string characterName = ""; // Private reference to our character class
    private const string CHARACTER_NAME_KEY = "CHARACTER_NAME_KEY"; // Set a CONST value to avoid spelling errors in save file

The characterText holds our Text UI object in the Editor. InputField holds the InputField UI object. Because both of these are dragged into the inspector (in our example, but there are other methods of doing this also), then we must keep them as public variables.

The characterName will holds our actual character name. We need to declare this in the global space (at the start of our class) so that it can be used in other functions. The CHARACTER_NAME_KEY simply holds the string CHARACTER_NAME_KEY and cannot be changed. This simply allows us to reference the PlayerPrefs data file, using this key name – without ever accidentally using spelling errors. i.e. If we didn’t do this, then we increase the chance that somewhere in our code, instead of looking up “CHARACTER_NAME_KEY” we may accidentally try to look up “cHARACTER_nAME_KEY”, or more realistically if we forget, “characterNameKey”.

private void Start()
    {
        InputGet(); // Display the character name.
    }

We grab the character name on start to save us a button press. You can leave this out if you’d rather demo by pressing the button.

    /*
     * Here we get the player name, and return it, from any location
     * it exists. If it doesn't exist anywhere, we will still return
     * blank, but leave a debug for us to know why blank was returned.
     */
    private string GetCharacterName()
    {

        if (characterName != "")
        { // If we don't need to load, don't
            return characterName; // return the character name
        }
        else if (PlayerPrefs.HasKey(CHARACTER_NAME_KEY))
        { // If the playerName has been saved before and exists
            characterName = PlayerPrefs.GetString(CHARACTER_NAME_KEY); // Set the characterName based on the name in our save file.
            return characterName; // return the character name
        }
        else
        {
            Debug.Log("Player name has not been set yet!");
            return "Enter Name"; // return placeholder, but submit a warning so we know why a name wasn't returned.
        }
    }

The GetCharacterName method could be simplified, in order to perform the function and nothing more, but I’ve tried to write the code as close to a real-world example, which would have to include some error handling, as we can’t have our entire game breaking, just because there was an error grabbing the players name!

Because this method is of type string, we’re expecting a return type of string. This is why characterText.text = GetCharacterName(); works later on. So would string test = GetCharacterName();

We then immediately hit our first check. If the characterName on the gameObject is not empty, it must have been set! If so, we return this name, and that’s the end of it. If however, it IS empty, it may simply mean we’ve not grabbed it yet. So we check to see if a Player Prefs Key exists, i.e. has the characterName been saved, but we’ve just not set it in this instance. If that’s the case, then we get the character name from Player Prefs and use it to set our objects characterName. If however, there is no player key, and it’s not been set locally in the game object, then it hasn’t been set, and we can return any string we please to alert the user to this. For our example, we used “Enter Name”.

    /*
     * Set the character name, based on the string provided.
     */
    private void SetCharacterName(string name)
    {

        characterName = name;

    }

    /*
     * Save the character name in our save file. This is separate from save, because we might not ALWAYS want to save the name to a save file, but we would still like to set it at runtime.
     */
    private void SaveCharacterName(string name)
    {

        PlayerPrefs.SetString(CHARACTER_NAME_KEY, name); // Save the characters name, using the key 'characterName' and setting the value to the provided string value of name.

    }

SetCharacterName simply takes a parameter of type string, and sets the character name to that. We COULD have this code written in SaveCharacterName also, but in some scenarios we may not want to always SAVE it.

WHY? – Well, when we type the name and end the edit, we may want to set the name in the GameObject, but to avoid the slight performance delay where the games saves, we might wish to delay the save until the end of this gameplay section, i.e. when we’re about to load the next level.

The SaveCharacterName also takes a string parameter, but this time we use it to Save the name to PlayerPrefs, using our KEY we defined in the CONST “CHARACTER_NAME_KEY”. Again, using this CONST is helpful here, to ensure what we SAVE to, is what we LOAD from.

/*
     * Deletes the characters name.
     */
    public void DeleteCharacterName()
    {
        if (PlayerPrefs.HasKey(CHARACTER_NAME_KEY))
        {
            PlayerPrefs.DeleteKey(CHARACTER_NAME_KEY);
        }
        else
        {
            Debug.Log("No save file to delete!");
        }
    }

If ever you want to simply delete the key reference in PlayerPrefs, use the DeleteKey function, and provide the Key you wish to delete. You can also use PlayerPrefs.DeleteAll() to delete all key and values pairs currently held on PlayerPrefs, but for obvious reasons this should be used with caution.

/*
      * This function will actually start the process off. It allows us to keep the rest of the code private, and our variables secure.
      */
     public void InputSet()
     {
         string name = characterInput.text;
         SetCharacterName(name);
         SaveCharacterName(name);
     }

/*
 * This function actually allows us to grab the information.
 */
public void InputGet()
{
    characterText.text = GetCharacterName();
}

The InputSet method is a public void, which allows our button to access the method, whereas our other methods are mostly private methods. Setting it as public allows our UI objects to access these methods. We then set a local variable “name” of type string, which simply holds the current text value, of the input we’ve just finished typing to. We then Set the characterName locally, and then Save the characterName to PlayerPrefs.

To get our name, from the UI objects, we also need a public method. This is why we need InputGet.

And that’s it everything, that’s every section of our code, broken down into manageable chunks, to make it easier to understand not only what it’s doing, but why it’s doing it that way.

If we wanted to add in our orb example, we would set up the same methods, except instead of using PlayerPrefs.SetString/GetString, we would use PlayerPrefs.SetInt/GetInt! Try doing this yourself without further reference to see if you fully grasped the concepts.

Which leads us to the next section :

The Pros and Cons of Player Prefs

Pros :

+Quick to implement
+Platform independent
+Reliable and not performance intensive

Cons :

-Limited Data Types
-Not massively scalable
-Not secure for sensitive information

Essentially PlayerPrefs is perfect for saving quick snippets of information, and ensuring they work on all kinds of platforms. It consistently works, and won’t draw any really noticeable amounts of power from your computers hardware to save this information. However, due to the nature of the syntax, and the limitations of the data types that it facilitates, you cannot store massive amounts of information. So you can’t store arrays or information, and as such you have to access them one by one also. Quite simply, this doesn’t make it scalable enough, when you’re working with massive amounts of gameObjects, or complex pieces of information.

The Data Types that PlayerPrefs CAN save :

  • String – PlayerPrefs.SetString(), PlayerPrefs.GetString()
  • Int – PlayerPrefs.SetInt(), PlayerPrefs.GetInt()
  • Float – PlayerPrefs.SetFloat(), PlayerPrefs.GetFloat()

You can also visit the Unity Docs to find a full list of the methods you can use with PlayerPrefs, however, all are covered at some point in this tutorial, except for PlayerPrefs.Save(), which simply saves the player prefs to disk, manually. (by default it does this when you quit the application)

Conclusion

Hopefully you found this tutorial handy and feel it gave a thorough enough explanation to allow you to use PlayerPrefs in your own Games! If you enjoyed this, please get vocal in the comments, like, follow, and of course check out the rest of the content both here, and on Twitter @dalriadaconnor

If you have any more questions also, please feel free to ask questions in the comments, and ask questions on Twitter too! Additionally, if you feel any more information may be helpful, feel free to get in touch there too!

Until next time!

EDIT : The original article wrote about saving and loading boolean values using PlayerPrefs – which is actually incorrect! Thank you to @weirdbeardgdevwho pointed it out! What had happened is that I had written an extension a while ago, and forgotten that it was not actually part of PlayerPrefs code!

If you DID want PlayerPrefs to handle bool values, we’d simply write out own static class, and use that to access boolean values, and simply take advantage of Unity’s PlayerPrefs.SetInt, GetInt functions. Like so:

public static class ExtendedPlayerPrefs{

  public void SetBool(string key, bool val){

    int result = 0;

    switch(val){
      case true:
        result = 1;
      break;
      case false:
        result = 0;
      break;

    PlayerPrefs.SetInt(key, result);

    }

   public bool GetBool(string key){

   bool result = false;
   
   int p = PlayerPrefs.GetInt(key);

   switch(p){
     case 0:
       result = false;
     break;
     case 1:
       result = true;
     break;
     default:
     Debug.Warning("Key does not contain a boolean convertible value");
     return null;
     break;
    }

    return result;
   
}

With this class written on a script in your code, you can simply set and get boolean values using PlayerPrefs like so:

// To Set Keys and Values
ExtendedPlayerPrefs.SetBool("mytest", true);
// To Get Values From Your Key
ExtendedPlayerPrefs.GetBool("mytest"); // returns true (or false if you set it as such)

Pathfinder – Dev Log 3 – The Benefits Of Prototyping

When you first start developing a game, regardless of whatever format you choose to do it in (design it in it’s entirety first, or play about with it and see where that takes you) there is one thing you have for certain, that will unequivocally make that game unique.

You have a vision. Your vision. No matter if your game is about blocks fitting into succinct patterns and clearing a stage, and you feel its’ been done before – the fact that you’re going to do it YOUR way, guarantees that it be unique in some way. It’ll have little imprints of you. Whether not your potential players believe this imprint is enough to gain their adoration is another topic entirely, but regardless, no matter if you fear your game has a similar counterpart, it will stand out on its own in some way.

And while that’s wonderful, essential, and one of the magical components to making content – it comes with its own fatal flaw – and that’s a lack of perspectives. You have YOUR perspective – which is a start, unfortunately every other player isn’t you. They might not like things to work exactly as you do.

And so while something may appear obvious, to you, from your perspective; it may be hidden or obscured, or unenjoyable, or undesirable, to other players. And if even one of the above occurs, your player will be abducted from the experience of FLOW and enjoyable gameplay, and instead their attention will be brought to something ultimately unenjoyable, and so as a rational human being eventually they will cease to do that thing. Simply put – other people have ideas and suggestions on what makes something good. And listening to them doesn’t detract from your experience, or your vision. It simply allows it to be appreciated from other unique views, than your own. Moreover, just because someone has a suggestion doesn’t mean you have to take it. But if it sounds valid… and it’s interesting. You can try it. You might just like it. You might just like it better.

So… Prototype it.

Case In Point

To anyone following along, I’ve been thoroughly enjoying making Pathfinder, as a 2D Sci-Fi Action Adventure Game, based on the Accelerometer of modern mobile devices. However, as discussed in the first dev log the notion that you cannot move forward or backwards due to a lack of reliability, has always annoyed me. But quickly I got over it – for the sake of moving forward. However, as I playtested the game, and it was casually noticed more and more – a colleague of mine gave me an interesting idea of how movement COULD work.

And so, I prototyped.

And that’s the thing – as this game is still very much in its early phases, you CAN prototype. In fact, at any time you can prototype, as long as you COMPARTMENTALISE the appropriate features/tests/units.

In a single night – I had protoyped a new mode of movement, where instead your finger dictates the movement of your ship, simply by dragging it around. How quick or slow this is, can then be altered via boosting, upgrading your ships (or a better ships) handling component.

So I don’t lose any of my core features that are compelling to the game, but the way in which you achieve them have changed, to a move that allows greater flexibility, and verticality.

The Response

Every. Single. Playtester… Said they preferred the new method of movement. Not a single person decided that the old version was better. They all felt their movement now indicated what they WANTED TO DO, and not what they were LIMITED TO DOING. Which is ultimately what will appeal to, and attract players.

It meant a quick restyling of my UI and some components, which while was a hassle, I did manage to do the mock up (shown above in the Twitter video) to accommodate the new playstyle. i.e. now that you move via the finger, you cannot swipe to change abilities, as in the end it would require the player to either be shockingly specific with their movements, or it would increase errors throughout. Instead, button presses on UI components will now activate these same abilities. How I implement that however, is VERY much subject to change.

Why Stop There?

If you have an idea – try it. Especially at those beginning iterative changes, where the bigger changes take less effort to propagate across, should you wish to pursuit that particular change to its completion.

One thing that was bothering me immensely, upon designing the new UI, was how completely out of sync the new UI was, with the look of the core game. The core game (i.e. the actual ship flying component) had an air of realism about it, where the rest of the UI had an air of cartoonism about.

And while I’m a massive fan of realism in games… Something just told me that I should go a different direction with my game… And so I did this:

Now, look a little less to the smaller stars in the background, and instead look at the larger stars, the planets, and general hue of the colours. Comparative to the version shown at the start of the blog, you can see that one is clearly more stylised, and more fitting with “a style”

And so even after this first test which didn’t take me much time at all, I’ve designed three planets with about 20 variations, and numerous new asteroids and star variations to be replaced too. Next up will come the hue’s, nebula changes, and general space oddities, which should add to the feel and style of the game.

Conclusion

The conclusion is that to get where you want your product to be, you need to understand that your implementation, and your vision may differ. So try things. Don’t be afraid. Throw out components, and add news one in – and the sooner you do it, the better.

Thank you to anyone who made it this far – if you have any suggestions for what you’d like to see next, send me a message and let me know – I can do a more technical focused blog to examine how certain aspects of the game are handled, or we can continue on a more design aspect discussion of gaming in general, pertaining to Pathfinder.

All in all, the game is making huge strides in development. Now that some building blocks are there, I’m insanely proud of the new things being added, changed, and improved upon, even on the daily. After a few more weeks (sooner rather than later) I’ll be opening up Test APK’s on Google Play. So if you’re happy to test this cheeky little indie game and have your feedback heard, feel free to get in touch with me (via Twitter: @dalriadaconnor), and of course when the game is released you’ll be added to the credits!

Thanks a lot for joining me this week everyone, until next time!

Pathfinder – Dev Log 2 – You Can’t Build, Without A Foundation

The Boring Bit

Hello everyone, thanks for checking out the second Development Log for Pathfinder the upcoming mobile game! If you find yourself liking what you see, please do follow the blog, and the twitter accounts also @DalriadaConnor (me), @greatbeyondcomp

This week’s dev log focuses particularly on UI along with the design elements and decisions that came with it.

As always, with extreme excitement and lots to do I want to dive into this blog straight away, so let me help you get caught up with some other relevant information, should you wish (although it should be fine without):

Now We’re Getting Into It

So last time we discussed some general aspects and mechanics; how initial play-testing and conceptualization brought about the core elements of the game. This led us to the point where there was a clear mission for what the game should be, and a focused path towards moving to that goal. Excellent. Good start I’d say.

However – it’s important to note that no matter how interesting a game you can develop, if people cannot understand your game, if they cannot visualise it in a tangible, manageable, and enjoyable way, then this equates somewhat to not being able to play the game at all. i.e. If I were to implement an upgrade path, but either it was difficult to tell it was implemented, or it was unenjoyable to use – then I may as well not have put the feature in, in the first place. Because it will be boycotted, vocally or not.

And sometimes it can be worse if your players hate a game, and keep it to themselves. Something that irks them or turns them off to your game, but it’s not big enough to convey an outcry – because if elements could be improved to a standard by which THIS game is your go to game – then every developer should be working towards that. You can’t and don’t want to force someone to play you’re game. They have to be compelled and have a desire to, and having an irritating feature will certainly only serve to turn them off it.

So with this in mind – I decided that it was not taking a step back – but instead making a time saving move laterally, to stop physical development of the game , and ensure I had everything scoped out from start to finish – UI and UX wise. I was thoroughly enjoying my game and where it was heading – but that’s not quite enough if it doesn’t meet professional standards in terms of usability and aesthetics. It was important that I thought about the game, and how players would discover and interact with each element.

All that follows – is in keeping with the last dev log, that everything is moving from tutorial outwards. It’s just that some on-boarding, occurs in the main gameplay elements, but also the side elements and the reasoning for actually wanting to play and persist with the game. It’s important that from the off, the player feels their is a strong foundation, for them to even bother continuing with the tutorial, and so this is where I thought I’d move to.

All That Follows

So, while I only had about two weeks to do it ( on top of my full time job as a full-stack developer ), I’ve finally managed to come up with a fairly comprehensive UI layout that I would like to begin approaching and implementing. Let me get into it – with the screens I want to talk about, and then I’ll break them down one by one.

Pretty cool right? – I’m really chuffed with how these turned out as initial concepts, although I’m sure they’ll be expanded upon in GREAT depth in the coming weeks and months. But for now, the screens are broken down as such.

The Star Map

So clearly there is quite a lot going on in the Star Map, but what exactly does it all mean?

Well to be frank, I’m actually hoping that for at least some of it, you can guess for yourself, as this is kind of the purpose of UI design! – And I did work very hard! However, for clarity sake, I’ll quickly go over each element and explain WHY it is the way it is.

1 : This bar will be stuck to each of the screens at all times. It represents how much of each currency/valuable you possess.

1 (cont) : So for instance, on the left we have medals/or rank, in the centre, credits, and on the right, scrap. Credits will most likely be used for upgrading and painting ships, whilst scrap is necessary to build new ships, and perform certain upgrades. By consistently keeping this locked here, you know exactly what you have, and why, at all times. It’s so important to know WHERE you’re at in terms of progress, and exactly what you can afford and achieve.

2 : This simply represents what stage of the three stage process you’ll repeat through the game. Choose your mission from the star map – find out more about that mission (I’ll go into that in a second), choose your ship, choose your pilot, play. By letting people know which stage in the process they are at, they can know what’s to come and also become familiar with the core repeating elements.

3 : This represents the number of probes you have. Probes are a way to find new missions. So when you have a probe, you simply drag this icon from where it is, to wherever you want to search for missions. A little ping will then come from that locations, and search for nearby missions (including procedural ones, indicated by the 6 on the screen. When you see an available mission, you can tap on it to learn more, and the screen below will overlay. Having this here lets you know your potential for finding more within the game, and implies MORE. Mobile = MORE MORE MORE.

4 : Red represents a blocked mission – so regardless of whether you are there in the path or not – you cannot begin that mission because you have not met a specific requisite. (Red = Blocked)

5 : Blue represents a mission you can play, assuming it is one of the next available missions on your path. (Blue = Available Story Mission)

6 : White (will be made smaller in future UI increments), represents procedural missions, i.e. specific missions that pop up that will have an objective just like the rest, but no story will be revealed at this point. (White = Procedural)

The small image above is the pop-up screen that appears when you click on any mission.

7 : Green is where you are. On your pathfinding missions, if you succeed you will move to that story block, if you fail you will revert to the last successful story block. If you attempt a procedural mission, regardless of success or failure, afterwards the white mission will fade (cannot be played again) and you will be returned to the previous story block before commencing that mission.

8 : This is hopefully obvious. You can quit the whole process here, or select the mission you would like to proceed with.

9 : This is obvious also, but I included it as a separate number because this element is also persistent on every screen except for the main menu and the actual in-mission screen. We always want the player to know they don’t HAVE to continue, and they can make changes at any time as it’s been suggested that the idea of finalizing can be too daunting to be enjoyable.

Conclusion of Star Map

All in all, the Star Map is the FIRST screen you will see which actually represents gameplay (so just after the main Menu), it’s important then that very quickly the player feels there is a lot TO DO, but not that they are blocked or hindered by this fact. i.e. Onboarding has to convey a long way to go – but not a long way to start. It also has to feel usable and engaing, and I really do feel these first designs convey that.

Ship Selection

The Ship Selection screen is a VERY important one. Both personally and pretty objectively with this kind of game. It can’t be boring as the player is going to be seeing it A LOT.

What’s more, it has to convey options, progression, and give you that sense of achievement, and like you’ve earned whatever you’re looking at.

If we can personalise it as much as possible also, you’re much more likely to feel like whatever ship you’re about to take control of has meaning.

You instance, personally for me, if I play a game with a spaceship, and I cannot name it, I’ll stop my emotional attachment to it almost immediately, as I feel a little less like I’m making the decisions or the connections, and more like I’m being told what to do. For instance, in Civilization 6, when you originally couldn’t rename your cities, I actually stopped playing it after just a few hours, when I’d actually played Civilization 5 for countless hours.

So – sidestep aside – what exactly is on the Ship Selection screen.

1 : Name editor. I cannot stand playing a game where I can’t name my own spaceship. It seems like madness to me. So while each of the ships will come with their own name, you can change this for yourself at any time. Although I’ve beat this point to death, the purpose of this is to embed attachments and personification to the ships you build.

2 : The ship you currently are viewing – you can use the arrows left and right to see the ships that you’re aware of, even if you can’t build or unlock them yet. (Spoiler, you might find ships or research them along the way, so the list will grow!) This lets the player select their ship (obviously) but also know that there is more to come, and more to work towards.

3 : The colour / skin of your ship. This works in a similar fashion to number 2 and should hopefully convey their is more customization along the way. (As a side note, in the future I’ll probably add trailing dots on the left and right to convey that there are MORE options once you start scrolling left and right)

4 : The Shield Icon – I’m going to replace the text in the main game that says shields with this one. This saves space, and builds familiarity

5 : The Agility/Handling Icon.

6 : The Weapons Icon.

7 : The upgrade button. For the displayed price, you can upgrade this specific attribute of the ship, as long as you have the currency requested, AND the ship can actually be upgraded. Of course, green represents that it CAN be upgraded, while RED would suggest it cannot.

8 : White represents the current status of the specified attribute, green represents where it WILL be after you click the upgrade arrow, and the white dotted section represents to WHERE that particular ship can be upgraded to. The white, green, and dotted line are examples of a micro UI element, which I’ll talk about in another Dev Log, but long story short it’s shockingly important, and not often done well.

Conclusion of the Ship Selection

Every player wants to feel like they have control of their gameplay, and the ship selection is a fantastic way to do that. Their decisions here will influence largely whether they can succeed in the coming missions, and so it is upto them at this point to spend some time here, and ensure they have suitable inventory, to complete the mission.

There is actually a lot more to the Ship Selection screen plan – but this has not yet been implemented, so I’ll bring this up in a future dev log!

Pilot Selection

Every ship needs a pilot! – And this means we have more potential for control and customization.

My hopeful intention was that by the time you reach the Pilot Reaction screen you should at least be familiar with some of the UI elements. That is to say, that without further explanation you should be able to tell which elements do what.

1 : This information panel here represents a pilot and the stats attributed to them and where they can grow too – similar to that of the Ship Selection screen. In the future, I may add specific powers or traits here too, but for now it should be left as is. (Note a pilot image will be here, but I just don’t even have one drawn up yet.)

2 : Should you run out of Pilots, i.e. should your pilots die or are otherwise decommissioned then you can acquire new pilots by clicking that icon. New pilots will be acquired and trained all the time, so it’s worthwhile to check this often. Of course pilots require payment, so they’ll have to be bought.

3 : Of course you can name your pilot. (Ignore the overlapping UI element as this was a last minute error)

4 : If a pilot is selected, they will have a green border around them. To view other pilots you HAVE acquired, you just tap left and right on the screen.

Conclusion of Pilot Selection

All in all, this game will heavily promote progression and customization, and I believe the Pilot Screen (while relatively simple) does a good job of conveying that. We want our favourite (probably funnily named) pilots to do well and stay alive, so we’re more likely to give them the better missions and the better ships and in turn that makes us try a little harder too.

Overall Conclusion and Where To Discuss Further

All in all, I am very happy with my first drafts of the UI elements within the game, and I believe their supplied evidence for those decisions backs up my excitement, immensely.

Each of the discussed elements have particularly been designed with the platform of mobile in mind, and I’m very happy with how they have changed in response to that.

Elements that used to be complex or like they belonged in a PC were redesigned to be simplified but still conveying the complexity and potential of the game. And the secret to this – is Micro AND Macro UI elements.

However, this will be reserved for another day – as I’m aware how long this one has gone! ( Sorry about that, a lot has changed ! ) Thank you so much to anyone who made it this far – I’ll probably post a short development log (it won’t be short… ) regarding the importance of Micro and Macro UI elements in gaming, especially mobile, and I’d really appreciate you checking out that too.

If you’re enjoying these, please do follow along the dev logs, get involved in the comments and as always feel free to follow both myself and the company at @dalriadaconnor and @greatbeyondcomp.

Let me know what you like and how I’m doing!
Until next time… – happy gaming!

Pathfinder – Dev Log 1 – Building Outwards

Hello to everyone who’s decided to come find out a little bit more about Pathfinder, the upcoming mobile title to be released by The Great Beyond Company. I want to dive right into this, so if you want to find out more about who I am or what the company is about, then please check out the About page.
This is a long one, as it’s long overdue; so without further hesitation, here…we… go!

Why Am I Doing This?

Originally this game started out as an experiment. A test to see how basic a game I could make that would be fun – and so I started with a concept that was not even remotely unique – a side scrolling 2D shooter. Now, just because something has been done before, doesn’t mean you can’t do it better; this I know – but I just still wanted to make a game fun – quickly, and simply. And to do this, I decided to develop for mobile, on my personal operating system of choice, Android.

The Great Beyond Company Logo. A single large circle in the centre, surrounding by a dotted line, and within that dotted line, is another smaller circle. It is meant to represent the a planet body orbiting another.

However; immediately at the first design hurdle, I realised something – and this realisation was what would eventually propel me to pursue developing this into a fully fledged game.

(Interestingly, all Pathfinder logo concepts so far, have some elements of The Great Beyond Company logo incorporated into it.)

Masterpieces are Built on Limitation

The very first hurdle, was that on a mobile device, you do not navitively have the advantage of a keyboard, and/or other controller to play the game. i.e. While you can now buy devices and controller to play games through your mobile, most players will either not have one.
So what this does is limit us to the number of events we can monitor in terms of user interaction. We can’t check for every letter on a keyboard and invoke an appropriate call to action as we could on PC.


On mobile the user interacts via:

  • Tapping
  • Swiping
  • Holding

Additionally we have a reduced screen size by which we can display elements to the user – so things like health, or full words, must be replaced by smaller icons or noticeable changes, rather than just objective plain text like in a lot of other games.

With all that in mind – it made no sense to me to have movement controller by the user interacting with the screen. It just didn’t. That would involve taking away one of my potential interactions – it would mean the movement would have to be represented by the UI, and also it would mean the players finger is on the screen and they then can’t see elements underneath their own digits.

And so – there is one other thing a mobile device tracks… the
accelerometer. i.e. the gyroscope which detects the orientation of your device. If I could allow the user to move up, down, left, and right by tilting the device, I could solve my problem of wanting to keep my event handlers, and also keeping the screen clear. It also allowed me to facilitate my own design mentality, which is that a mobile game should be able to be played with one hand. It doesn’t have to be, but I believe you should be able to. And so, that’s where I started.

The Orientation Problem

I was very happy with my first implementation of the accelerometer moving about my spaceship. It worked fluidly, using forces rather than just dragging the spaceship around, which gave it this lovely responsive feel, that you were gliding rather than being thrown.

However, I immediately noticed a problem – and upon testing it with friends, the problem became intensified ten fold. The problem was that everyone is under the same understanding of how to hold a phone. You hold a phone in portrait or landscape mode (I force portrait – meaning you can only play Pathfinder in Portrait mode). But the problem is that, not everyone holds their phone on the same y axis. i.e. how far people tilt their phone forward and backwards, varies greatly. Moreover, even I when testing, would sit my phone on the desk when the game began, and immediately it would shoot off screen.

So I could not tell the game, when “forward” or “backwards” was, relative to the player.

I did experiment with detecting their orientation upon game load, and then altering movement relatively from there – but again, people like to see things the right way up, but they still hold it vertically anyway they like, and it can change often even in a single game session as frustration or difficulty mounts.

And so came the first cut : you cannot move up and down. Only left and right. And to be fair the response was immediate’ people were more engaged from the offset and less frustrated with their ship floating off screen. It started to allow the game to actually be played, rather than just a simple prototype. And even from this moment, it became apparent… The game was fun.

It’s Fun Already? Now What?

The game was already fun. I’d done it. It didn’t have a main menu or really any UI, but it was fluid, and it felt nice. With little asteroids moving down the screen at you, it was entertaining enough just to see how long you could last.

Originally, I just spawned basic temp image asteroids, and for every asteroid you destroyed, you got 100 points. The number of asteroids spawned per minute increased rapidly, until eventually you would lose and get a score.

So good. We’re done. Sweet. Bye. Thanks for joining!

Well… No… Not quite. Sure the original challenge was a success, but there was something about the agile way I was developing this game that just glued me to it. I knew I was actually looking into the core concepts of what makes a game fun and expanding upon it from there.

And so I revisited my limitations. What can I do on mobile? Well… I can swipe… In any direction. Stop.

My ship moves. Its shields regenerates. It fires lasers. Bingo.

Three vertical columns labelled SHD (shield), HAN (handling), and WPN (weapons) respectively. Each column has a bar inside of it, which is halfway filled.
The Three Components I Can Work With

It made compete sense to me now. My game was an action strategy game about SHIP RESOURCE management. (It ended up becoming more than that, but I’ll explain that another day)

So essentially, if objects were coming at you so fast that your ship currently couldn’t dodge them – boost your handling. If lots of weaker enemies were filling the screen, and you needed to obliterate them quicker – boost your weapons. And if you’re taking too much damage – boost your shields. All of which are at the sacrifice of the other components.

Now the game had a hook – it had a challenge, it had an element of skill about it. Players actively being knowledgeable and skilful could make a tangible difference in the outcome. And so, as is natural – I was presented with the next big issue.

The Developer Standing Over Your Shoulder Problem

ANYONE interested in game development will tell you, and one of the most frustrating things in the world, is watching someone play your game for the first time. It’s also a wonderful moment; but the frustration comes from the fact the following sequence of events:

  1. The Player begins playing your game.
  2. You display in huge blocks letters at the beginning of the game, “Tap X to Run” (For example)
  3. You notice they clicked for the tutorial message to go away faster than any human can read.
  4. They lose, or start losing.
  5. “WHAT THE HELL? How do you run?” or even worse, “This game sucks, you can’t even run in it!”
  6. You give them the biggest, sneering eye glare any human has ever given anyone.
  7. You accept this is part of the job, and emit a fake laugh.

So when the game was originally just tilting, on average even without a tutorial to tell them, every player figured it out in under 10 seconds. However, with swiping involved, they were lost. They wouldn’t innately try to swipe, and if they did, they didn’t correlate that a swipe left which engaged shields would result in a different outcome if you swiped right.

With me over their shoulder I can nudge them in the right direction – but a player – potentially one of you guys, won’t have that advantage. So how do I overcome that.

Well… I make the horribly monotonous but worthwhile decision, to build the game from the tutorial out.

That means, I’m starting with the tutorial as I finalise all other concepts along the way, and then I won’t fully move on from the core gameplay until I ENSURE that EVERYONE feels they get a grasp of the game concept, and that it’s a rewarding experience, straight from the offset. If I can do this, and keep it short and sweet as bonus, then I believe I’ll succeed.

This is currently where I’m at just now.

Currently I’m building and iterating upon the tutorial of the game, and making amazing strides at that. The gameplay has been improved upon massively, and the tutorial is complete from start to finish – I just need to gamify it a little more to make it more engaging and rewarding, all the while, keeping it short enough that the player can jump into the game as soon as possible.

If you made it this far, thank you so much, it’s really very much appreciated. This particular dev log was less technical, and a bit more design oriented/an overview of the current situation. In the future, they’ll sometimes be ART focused, PROGRAMMING/TECHNICAL focused or even MUSIC focused. If any of that appeals to you, please do stick around – follow the blog, and follow me on twitter too @DalriadaConnor.

Until next time, here’s an image of the game as it currently looks.

TEST IMAGE FOR PATHFINDER – UI at the top in progress and will change.