It’s been a week (and a day) and we’ve done some things that we thought you might like to know about so here they are.

First, I know I said in the last post that I was going to write a little something that went more into the plot of our new game and I haven’t done that. But there’s a good reason why! I was about to write the post when Austin sent me a message saying that he was going to met with a writer who was interested in this sort of thing and might be interested in helping us out. So I decided that it would be better for everyone if I let the someone who’s more inclined to being elegant with their words write the story. So that’s why you didn’t see anything more from us last week, but hopefully we’ll have a more professionally written story to share with you shortly!

So with that cleared up, lets get into some of the interesting stuff we handled this week. I think the biggest thing we had to tackle was the idea of saving the current state of the game. In our previous games we didn’t really do much saving beyond a few high scores. But because this new game is more of a story we had to figure out how to make sure when a player comes back to the game they can pick up exactly where they left off. This means not just having to save a few numbers, but having to save a whole slew of information. So much information that our previous techniques would not cut the mustard. Luckily, Unity has a great video tutorial on how to save game data even when a player quits the game (which you can watch here. Aren’t they the greatest!).

So after a quick viewing we were in business. We had a lovely singleton class set up that stored all the data and then saved it to a neat little file that it would then open up when we loaded the game and everything was wonderful! But our time of care-free coding would be fleeting.

Thinking everything was working as we planned we moved on to another important aspect of the second act: day tracking. We already had a great mechanic in place that kept track of time and faded the screen out as it becomes time for the player to sleep; all we had to do was increment the number of days and save it to our wonderful data storage class. We hit our first speed bump when we realized that, because the sleeping method involved a fading element it was being called in our update script. In other words it was being called roughly 60 times a second every second. So when we tried to increment the days we were all-of-a-sudden going through about 60 days every second. So a couple clever boolean gates later and. . . our game data class stops working. . . but we didn’t. . .we didn’t even touch the game data class. . .and in one second. . . everything came crashing down. . .

Initially we thought we had broken something in the game data class when we added the boolean gates. So we took those out and it started to work again. But as quickly as we (thought) we had fixed it, it was was broken again. . .

In the end, it turns out that the scripts weren’t being loaded in the right order. The game data class needed to be loaded first when the game starts so that the level loader class can look at the data to load the level. By default, however, the scripts are essentially loaded randomly (which explained why it was working for a little while and then stopped working). Luckily there is a way to manually set which scripts are loaded first (which you can read more about here). So with that implemented we finally had our game saving data!!

We did get a few more things accomplished this week, most notably we got the swipe to move interface working for mobile devices and we got a good start on a few other game mechanics that we’ll tell you about when we get them finished up (hopefully next week).

I hope you enjoyed our little weekly recap story and, as always, thank you for reading.

-Matt.