Tag: javascript

Episode 14: Saving & Loading

admin Leave a comment

Hopefully this episode is short, because all I’m going to talk about is saving and loading player data.

Web Storage

As I mentioned, I used JavaScript to write this game, and it turns out that modern browsers support a feature called Web Storage, which lets you save small chunks of data on the user’s computer. Here’s how saving works:

1
2
3
4
5
6
7
// Check if the browser supports Web Storage
if (typeof(Storage) !== "undefined") {
  // Save the data
  localStorage.setItem("Zyrian", data);
} else {
  // Web Storage isn't supported
}

And loading:

1
2
3
4
5
6
7
// Check if the browser supports Web Storage
if (typeof(Storage) !== "undefined") {
  // Load the data
  data = localStorage.getItem("Zyrian");
} else {
  // Web Storage isn't supported
}

I love it when things are simple and easy to use.

The next step was to organize these functions in a factory, as I’ve done with all my other code. I ended up with these functions:

  • new
  • load
  • save
  • reset

I later realized that I didn’t need reset, because it’s just a combination of new and save.

Anyway, once I had the factory working, I just set up the calls to the the appropriate functions during gameplay (mostly from the menu).

One tricky thing is keeping track of the data you are saving and loading. After all, you may want to store a bunch of different things, and you may want to save or load each of them separately. Here are some of the things that I store:

  • Progress
  • Items
  • Money
  • Custom missions
  • Settings

Potential Problems

One choice I made that was probably a mistake was to store the player’s data in a global variable. I probably should have written functions in the storage factory that gave access to this data. Perhaps I’ll change it in the future.

Another problem I’m anticipating is that game data may become corrupted as I make changes to the game. I imagine a good solution would be to add a version name to the local storage key (like Zyrian 0.41), so that any player who accesses an updated version of the game starts with new data.

This could end up aggravating players who lose their data, so it would probably be smart to write some code that checks if the existing Web Storage data is compliant with the current version of the game. Now you can see why I haven’t done this yet.

Episode 7: JSON

admin Leave a comment

In the last couple episodes I talked about how I separated my code into different components. First I broke it down into states, then into factories. I was feeling really good about how I was organizing things, and I had an idea about how I could make it even better: JSON.

What Is It?

If you don’t know what JSON is, it’s basically a way of storing data in a format that JavaScript can understand. JSON stands for JavaScript Object Notation, and that’s exactly what it is: the code for a JavaScript object. As an example, let’s say we wanted to create an object in our JavaScript file. There’s two ways we can do it:

First, we can use a constructor…

1
2
3
4
5
6
// Define the constructor for a person object
function Person(age, sex)  {
  // Set the age and sex of the object
  this.age = age;
  this.sex = sex;
}

And then create an instance of the object…

1
2
// Create an object called Bob and pass the values for age and sex into the constructor
var Bob = new Person(37, "male");

The second way we can do this is by describing the object literally…

1
2
3
4
5
6
// Define an object called Bob
var Bob = {
  // Define Bob's properties
  age: 37,
  sex: "male"
}

This is how JSON works. You just describe a literal JavaScript object and save it in a file. Then you just load the JSON file into memory. No parsing, no reading lines, no need to define delimiters and special characters. A number of libraries even simplify the process of loading the file, including Phaser…

1
2
3
4
5
6
7
8
9
// Read the JSON file
var preload = function() {
  GameSystem.game.load.json('Bob', 'Bob.json');
}
 
// Save the JSON data to a variable
var create = function() {
  GameSystem.data.settings = GameSystem.game.cache.getJSON('Bob');
}

The reason this takes two steps is that the JSON file is loaded asynchronously, which just means that the computer keeps doing other stuff instead of waiting for the file to load.

Magic Numbers

So how could JSON help make my code better? Well any time I encounter a magic number, I can move it to a JSON file. If you don’t know what magic numbers are, they’re these nasty critters that make your code confusing and difficult to maintain…

1
2
// Create the player's sprite in a specific location
var player = GameSystem.game.add.sprite(400, 300, 'ship');

In the code above, our x and y values for the sprite’s location are magic numbers. They’re magic because they aren’t based on any logic or conditions. They’re just hard-wired into the code.

It would be better to set the x and y values based on the game’s resolution…

1
2
3
4
// Create the player's sprite in the center of the screen
var x = GameSystem.game.world.width / 2;
var y = GameSystem.game.world.height / 2;
var player = Game.add.sprite(x, y, 'ship');

This works fine, but it would probably be even more smarter to move the starting location to a JSON file called something like settings.json and store it in an appropriately-named object…

1
2
3
4
5
6
{
  "playerStartingLocation": {
    "x": 0.5,
    "y": 0.5
  }
}

Once we’ve loaded the JSON file into a variable (like GameSystem.settings), we can then create the player’s sprite without using any magic numbers…

1
2
3
4
// Create the player's sprite based on settings in JSON file
var x = GameSystem.game.world.width * GameSystem.settings.playerStartingLocation.x;
var y = GameSystem.game.world.height * GameSystem.settings.playerStartingLocation.y;
var player = Game.add.sprite(x, y, 'ship');

As I kept exporting more and more magic numbers out of my code, I found that my settings.json file was pretty big and difficult to read, so I decided to create a number of JSON files and store relevant stuff in each of them. Here’s what I ended up with:

  • settings.json
  • assets.json
  • items.json
  • entities.json
  • factions.json
  • menu.json
  • worlds.json
  • missions.json

I know I said this in the last episode, but I’ll talk more about these things in the future.

Anyway, JSON is awesome. I don’t know what a professional game programmer would think of this approach, but it works for me!

Episode 2: The Framework

admin Leave a comment

In this post I’m going to talk bit about how and why I chose my programming language, IDE, and framework.

JavaScript

When I started this project, I was familiar with a number of languages including Java, C++, and PHP, but I had recently spent a lot of time using JavaScript for some web stuff, so I was kind of in the JavaScript zone. In addition, I really liked the idea that I could just upload the game to my website and let people play it in a browser, regardless of platform. I also love the fact that rebuilding my project means saving a text file and refreshing the browser. The console is also pretty awesome for debugging.

For these reasons I chose to use JavaScript as my programming language.

Sublime Text

I’m going to say something controversial right now. I use Windows. I’m sorry, and I regret it every time I talk to other programmers. I know I should have a MacBook Pro and be using the Linux terminal for everything, but I’ve always owned a PC with Windows, and I never used the Linux terminal until university.

Anyway, I had used Nodepad++ and other text editors in the past, but a friend had recently told me to check out Sublime Text, so I did, and I liked it. Sublime Text lets you open multiple files at once, save projects, search and replace in multiple files, customize colors and highlighting, and much much more!

Phaser

As I mentioned in the previous post, I had never used a game engine before, so I really had no idea what I was looking for. I basically Googled “JavaScript game engines” and quickly chose one that had good examples and documentation.

Having only used Phaser, I can’t really speak about its strengths or weaknesses. However, it seems easy to use, especially for 2D sprite-based games like Zyrian. I’ll talk more about Phaser in future posts, including examples and everything.