I hope everyone has been enjoying their Christmas (or whatever you celebrate) break. Last week I stumbled across something which I think is kind of cool. I have an Xbox One with Kinect. Now, I may work with computer security by day, but at night, my secret identity is a programmer who loves programming for games. I don’t get much time to do anything programming wise much with school, work, and family, however, when I do, it puts me into another world.
Project Spark by Microsoft’s Team Dakota offers an often attempted method of getting into programming which I appreciate. In particular, it offers a basic programming method to get into programming which allows even a novice programmer a way to create a game.
While they claim to offer the ability to create complex RPG style games, I have realized some immediate hurdles which they must overcome before it can be taken really seriously. The first thing is that it does not offer a method of saving and loading a profile, without purchasing it or spending weeks using less than usable materials. All advanced notions such as Saving, Loading, Management of the Sun Position, and connection of levels are premium content. It also does not offer the ability to make an array, forcing programmers to use countless variables when a single array would do the trick and allow for a much better experience.
That aside, I do see it as a very nice way to learn how to program. The first thing I noticed is that it simplifies the entire language into two sides. A “When” side and a “Do” side. This makes sense as almost every language has a form of this for instance, Visual Basic has “If-Then” statements. The idea is that “When” an event occurs, “Do” the following actions.
To be fair, likening it to just an If-Then statement is kind of over-simplifying it. The When-Do also acts as a one time command, Comments, and Functions. Commands are created by stringing tiles together, each tile represents an action, object, value, etc. The given tiles allow for a good amount of creation, but as I mentioned earlier, the tiles required for more advanced scripting like saving and loading profiles, time of day, and more advanced sprites are all premium content.
Groups of commands are grouped together by shifting them left or right (think of it as a hanging paragraph. Each subsequent indented command belongs to the command above it.)
A page can be thought of as a class in normal programming with the ability to call individual pages at will.
Each object, be it wall, rock, villager, monster or tree has what is known as a brain, which dictates how it reacts with its environment. Each brain contains the pages and each page contains commands.
However decent the language has been developed, and its detriments, I decided to continue on to make a simple game. However, there are several hurdles in place for me to do that. The first thing you have to do with any game is get an idea of what your intentions are with the game. I know I want an RPG style game with a quick story. The more in depth a story, the longer the game, and really we are limited with no save functionality in our game. I am looking for a 30 minutes to 1 hour play through. However, I want to include functionality which will allow me to expand it later.
So, now that that is out of the way, I want to figure out what the story is. Overly basic at first, and then grinding down to the nitty gritty. The depth in which you go can easily determine the length of your game.
Layer 1: An entity has infested the local mine, and the player must kill it.
Layer 2: An entity has infested the local mine, and is killing villagers, and the player must kill it to save the village.
Layer 3: A group of monsters have infested the mine, and is killing villagers, and the player must kill it to save the village.
Notice how at each layer, I am clarifying more and more. Some could call this fluffing it out, but really, even very advanced storys can be made in this way. By clarifying until you get to the nitty gritty, you can come up with something like:
5 years ago, a group of goblins known as the Ent Clan came into town. They killed several villagers and asked for a yearly tax. The villagers reluctantly paid, giving each goblin the life tax as it was called. The villagers were very strapped for money as it is, and soon came on hard times. As each one could not pay their tax, they were silently killed in the night. Our hero, Andrew Roberts by name, comes from a wealthy family who lived on the outskirts of town. As butchers, they were well prepared for this life tax. Unfortunately, with less people in the village, even they had come upon hard times. So, eventually the time came when the goblins came for Andrew’s family. They took his father, mother and sister away in the night. They normally left no bodies, but Andrew had been hidden away in the cellar. As he emerged, he knew what he had to do. We begin our story as he walks towards the Cave on the edge of the town where his family must surely be hidden, armed only with a wooden practice sword and leather shield.
So yes, this strategy of story building works for games. We aren’t going into too much more detail because we don’t need to. I just keep asking either who, what, when, why, or where at each layer, which adds another detail to the story.
Now we have a story. I will focus on the next part of our game in the next blog post on Game Mechanics.
What I learned today: The traditional waterfall method of System Analysis and Design focuses on a phased approach in which each phase depends on the one before it, and progresses in a line from start to finish.