I'll keep things rather short today.  There have been a lot of additions to the game and I'm hoping to get a version of the game finished by June 30th.  There's a game competition I want to enter and hopefully it will provide me with an opportunity to get some publicity for the game and maybe get feedback.  The competition is called the Indie Game Maker Competition and the grand prize is $10,000.

The game doesn't have to be long.  In fact the judges will only play each game for about an hour.  That means I really need to tighten things up here. 

The game I will submit will be a survival simulator, with the goal of going as far South as possible before having to return home.  The player will be reliving all the events that Shackleton, Scott, and Wilson experienced so he/she will have to make educated evaluations about how much risk there is in continuing South.   Meanwhile, the historic events from that journey will play out through dialogue, journal entries, and survival tasks - fleshing out the characters and adding context to the player's actions.

Not an impossible job to do, just difficult. 28 Days and counting!

This is another relatively technical post to do with the Ruby scripting system or RPG Maker VX Ace.  If you like following the logic of programming and want to see under the hood of my game read on.  There are gaps in the information presented here, mostly because the information is tedious or covered in the previous post, and shouldn't affect your understanding.

This is a relatively technical post for anyone who wants to do something similar with the Ruby scripting system or RPG Maker VX Ace.  If you like following the logic of programming and want to see under the hood of my game read on.  There are gaps in the information presented here, mostly because the information is tedious and shouldn't affect your understanding.  Feel free to message me on twitter or post a comment here if you have a question.

I've made a major step forward in an important aspect of my game: exploration.

For exploration to matter in a game like this one, we're going to need bespoke maps that are randomly loaded as the player moves to new areas.  Those maps must then become integrated into the environment so the player can return whenever they want.  There's no point in exploring if there isn't something new worth finding, and there's no point doing all that traveling if the game doesn't keep track of where you've been.  So what does this mean for the game? It means I can make map after map after map, content will be easily expandable!   We're done here but keep reading if you want to know more about Arrays.

This week was spent setting up the movement framework.  The game already has the basic mechanics built in (up arrow to move up, left arrow to move left etc) but storing data related to the player's movement and position needed work.

I programmed in a few variables that the game will keep track of as the player moves through the Antarctic.  Namely, the total distance travelled, total Southerly distance travelled, and the constant tracking of the player's X and Y coordinates.  The last piece of data will be used for some basic vector mathematics.  It's the most simple version of what NASA scientists do when they're trying to figure out where the rockets are going and when they'll get there.   But rather than land a rover on mars, I'm figuring out if a couple of guys pulling some sleds will ever make it to the South Pole.

The data collected by the framework can be manipulated to make energy cost deductions and reveal useful information to the player.  As I introduce useful tools like the compass, altitude scale, sextant, and distance measuring wheel into the game, the player will be able to retrieve the information stored in the framework in a more human friendly way, but also an early 20th Century way too.  Miscalculations will be added.

So, the data is all being carefully calculated and tucked away in the background until the player reaches for it using in-game tools.  Meanwhile, the data will also be used to calculate which map to load next, remember the order in which those maps appear, and store unique geographic locations.  This way, as a player travels forward from map to map they will almost always encounter a randomly (most likely hand crafted as opposed to procedural) selected map, and yet on the return journey encounter those same maps in the order they appeared.  Random away, ordered return.  That is the primary work I am doing this week and the following weeks, along with continuous efforts to get The Formula under some sort of earthly control. 

Here's an inkling of what the programming looks like "in words:" (it reads right to left.)