We have decided on a course of action when it comes to saving/loading online game data. That information will be temporarily held so that it loads quickly if the player is jumping in and out of their online games. However, if they quit the application we will trash the data. On resuming, the application will pull down the whole list of moves ever made and quickly, virtually make them all, returning the game state to its intended point in time.
So why do this?
1.Well, we are storing all of this data anyway so why not use it?
2. If we save the data locally & the user decides to uninstall then re-install the game we are going to run into major issues. When they reach for the online game what happens?
3. Saving game data is also seriously complex... Lots of variables and states that need to be saved out/ loaded in. With online, since it is asynchronous, I'm more than a little worried that the data could be corrupted on the user end, due to unknown issues. However, if the game state lives up on the cloud, it acts like the host, giving its clients (its players) the information they need. So it becomes a single data location instead of potentially 4 separate data locations (1 per player).
We may end up changing our mind/discovering a better way to go about this, but for the moment I believe this is the best path. Matt got this working on a local level, where he makes a bunch of moves, they are logged into a text-doc, he reads it back in & the game automatically generates the game board at the latest state. Its pretty sweet.
I created a custom Button class the other day (much less flashy/cool), however it was necessary. By doing so, we are now generating all of our buttons via code, not with art assets. Which means a few things.
1. No more bugging Marguerite about making X button.
2. Uniformity, since they are generated via code, everything looks the same across the board!.
3. Save space on our sprite sheet, which is the biggest reasons. Here, take a look.
Before:
After:
No comments:
Post a Comment