Tuesday, December 27, 2011

Journey into Technical Game Requirements

Hello again fellow game enthusiasts!

So, over a nice glass of holiday eggnog, I've been thinking about my previous post and a comment that was made on that post. Basically that "a plan" is one thing, but how to go about executing the plan is another. I've decided to take this post from the perspective of aiding a person who does not have a great deal (or any) technical planning experience. In other words, how do you take your epic game idea from your head and translate it into it's digital form. Let's journey into technical game requirements.

From an IT industry standpoint, a technical requirements document is a big detailed document that can be handed to a programmer and then they can...well...program the system. It lists the recommended tools for programming the project, how the project's technical architecture will be laid out, the problems the system will solve by being built....all that good stuff. If you have no clue where to start programming, a technical requirements document is the place to start.

That being said, I know phrases like "technical architecture" can be pretty scary to a non-techie (or to a techie depending on who's writing the document...*ba-dum, tish!*). You don't need a huge fancy document with a cover page on your TPS report. Basically your document should answer the following questions:
  • What platform are you designing for? (iPhone, Android, PC. XBLA, PSN, all of the above?)
  • What tools will you use?
  • What programming language will you use?
  • How is your game laid out? (a.k.a. what are all of it's pieces)
Let's do a quick example. Let's say you played every Final Fantasy six times and you think the iPhone app store deserves an awesome JRPG-inspired game. And you have just the game for the job! If that's what you want to create then what would your technical requirements document look like? It would look a little like this:

Super-Special Awesome JRPG Technical Requirements Document

Platform: iPhone
Tools: Unity
Programming language: Javascript and Objective-C to complement Unity
Game Modules:
  • Overworld map
  • Battle System
  • Item menu
  • Character menu
  • Sprites 
  • Music
  • SFX
  • Ability to Save
  • Ability to Load
  • Ability to delete saved games
If you know how to create and read Unified Modeling Language or UML document, that would be even better still for mapping out the relationship between all the parts of your game. While there are admittedly some pretty glaring gaps in the "game module" section, that's really all you need as a starting point. If there is any bit of advice I've heard from the local game dev community repeated over and over it's to not get caught up in planning forever. A plan is very, VERY important. However, when you have a good, solid idea of what you want to do, then just start!

For instance, in the above sample document, a great place to start would be to program the battle system. If you're doing traditional box battle style, it will have independent mechanics from all the other components. Start with simple text menus and basic geometric shapes to start. Then work your way up!

There was a lot I was going to say about learning how to program if you don't know how, but I decided to scrap it all and say one simple thing: just get started. The internet is flooded with great tutorials on programming in whatever language you want to.

I hope that was useful! Now if you'll excuse me, I need to refill my cup of eggnog. Have a game filled holiday!

gl hf!

Thursday, December 8, 2011

Journey into Game Development Goals

*Sigh.* O.K, so I've been playing with the idea of becoming a game developer since...well...since I first laid my hands on an Atari 2600 controller when I was 4. After doing my Computer Science degree at Memorial University of Newfoundland (a degree I choose because I wanted to develop games) I found that getting into the game industry was far more difficult that I had originally imagined.

But wait! A glimmer of hope! With different gaming platforms becoming more ubiquitous (smart phones, tablets, etc), gaming becoming more mainstream, and a true "indie" market just starting to be tapped into, you could make games in your basement and actually have the opportunity to be very successful. JOY!

So, I have options! I can totally do this!...but I really haven't been going anywhere. I feel like those clouds from Family Guy...you know...the one's that will "attack tomorrow?"


Yea...those guys.

However, thanks to a very inspiring meeting of the local IDGA (check out I Code By The Sea for details on the meeting) and reading a few good wikiHow articles, I finally realize what I've been lacking...

A Plan.

Sure, maybe now you're thinking "duh, of course you need a plan!" The true problem was I thought I DID have a plan. It was along the lines of:
  1. Learn to program games
  2. Become a hot-shot indie developer
  3. PROFIT!
I'm sure anyone who knows how to set goals and stick to them can see the problem. I really haven't set any goals at all...I've set big, broad "hopes" but no real destination. O.K. then...lets get serious.

Step 1: Set the ultimate goal

Ultimate goal: Become a Hot-shot indie game developer

This is the ultimate destination. The holy grail. This is the goal that I'm going to write on a sticky note and paste it on my bathroom mirror so I can see it every morning and be inspired. Now, to just leave it at that won't get me there...the goal is way to big and unspecific, so lets break it down.

Step 2: Take ultimate goal and break it down into sub-goals

  1. Become comfortable with game development
  2. Design a very simple game
  3. Develop previously designed game
  4. Publish simple game
  5. Take what you've learned and repeat steps 2-4 as needed
  6. Design a more complex game
  7. Program more complex game
  8. Publish more complex game
That's getting better! But we're still not there yet, are we? These goals are still in the realm of big, scary, and unspecific. So, I may as well use some of that development know-how that I've learned in my past five years of industry programming to break these down further. Rather than calling them "goals", let's call them "milestones." Lets continue to break each milestone down, so that way our journey becomes far more clear. We should also include a few rewards in the steps as well. After all, who doesn't like being rewarded for their efforts!

Step 3: Map out a specific path to reach each milestone

Become comfortable with game development
  • Pick a platform to practice development on (Unity, pre-made engine such as UT, OpenGL, DirectX, etc). If possible, think ahead slightly to where you'd eventually like to release a game. That will help with the choice.
  • Pick a simple game that you are very familiar with. One where the mechanics are easy to pick appart (Tetris, Space Invaders, Missile Command, Solitare, etc).
  • Program that simple game on chosen platform using nothing but simple shapes as the avatars.
  • $$Reward!!$$ Five to ten dollar game on Steam
  • Upgrade the graphics of the game to include more detailed avatars, animation, etc
  • Check and see if it's legal to distribute clone for free. (sourceforge, linux community, link on blog, etc)
  • $$Reward!!$$ New small canister of tea from local specialty tea shop
  • If still lacking in confidence, repeat steps to milestone with new game or new platform.
 Design a very simple game
  • Find inspiration. 
    • Play games from genres you don't normally play.
    • Brainstorm with trusted friends
    • Think about how whatever you're currently doing could be made into an interactive experience
  • Design core mechanic. Base game around this mechanic. Keep things simple.
  • Sketch out full design on paper
  • Prototype on paper if possible and play-test before coding even begins.
  • $$Reward!!$$ Twenty bucks at your favorite hobby shop
Program game you designed
  • Choose the platform that you wish to see your game released on. This will inherently narrow down the set of tools and programing languages you will use.
  • Settle on a set of tools. Research cost (if any) of using tools.
  • Program game using simple shapes and sounds
  • $$Reward!!$$ A new art supply
  • Upgrade graphics and animation of game.
  • Hire friends for pizza to play-test game
  • Polish until bug free
  • $$Reward!!$$ Meal at a restaurant
Publish game
  • Seek advice from local game devs if possible
  • Find out what it means to make a company / studio in Newfoundland
  • Send prototypes of media to try and generate buzz
  • Plan for associated costs of publishing product
  • Publish!
  • $$Reward!!$$ Release PAR-TAY!

Whew...O.K....now we're actually getting somewhere. Looks like it's going to be a long journey, but a worthwhile one. If you ever make a list like this, make sure that your rewards are meaningful to you. Also if you are in need of more constant motivation, you could even give yourself a small reward after each and every step. Really, now all I'm missing are self-imposed deadlines. I'm hoping the promise of reward will help to push me forward, but I may find that I'm still wavering and need to set deadlines.

I also know that some of these steps to the milestones may need to be broken down even further. For instance, "improving the graphics of the game" may result in me having to learn Blender, which would be a whole new set of steps. That's the beauty of setting flexible goals...they can flex!

Well, this blog post is certainly hefty enough, so I'll wrap up here. Remember, no matter how big your goals, be they to create a popular game, write an award winning novel, or creating an acclaimed work of art, they are always obtainable. You CAN do it, but you won't make it there by reveling in passivity. Fate won't make it happen. Take small steps on your journey every day. I look forward to reading all about all your successes!

gl hf!

Saturday, September 3, 2011

A Journey into Unity

I'm back after far to long to talk about my adventures with Unity, a cross-platform gaming dev tool from Unity Technologies.

I actually heard about Unity when I attended the first meeting of the IDGA Newfoundland chapter (they have a Facebook group...if you live in good ol' Newfoundland and love games, join the group. We need as many people as we can get!). I was talking to some of the local game devs and mentioned that I'm looking to improve my game programming skills. One of them suggested Unity, and gave it high praise. After using it, I can see why...without knowing the first thing about the tool, I had a fully functional (albeit simple) Space Invaders clone whipped up in 6 hours. What did I do to make that happen? Glad you asked! Buckle up!

The above image is what my unity set up looked like after the game was ready to play. Quite simple looking, wouldn't you say? To make the game, I used geometric shapes that come ready to use with Unity (I wasn't worried about making it fancy, just functional). The entire game is made up of seven components, used one or more times:

  • The player's ship object (the square)
  • An enemy (the circles)
  • The bullet (a cylinder)
  • The camera
  • A light source (the little "sun")
  • Sound objects
  • The bullet boundary (large rectangle above all the other objects)
Now, there are some really great resources that give details on how to place the objects, adjust the lighting, e.t.c., so I don't plan on getting into all that. What I do want to talk about is the coding that went behind the objects to transform them from geometric shapes to elements in a game. For this learning exercise, I stuck with good old JavaScript. I'm quite familiar with it thanks to my day job, so I didn't need to learn a new tool AND a new scripting language.

The Player's Ship Object

There are two scripts attached to the player's ship object. One that controls the player's movement, and the other object activates a "Game Over" condition if an enemy should drop low enough to collide with the player.

var speed = 10.0;

function Update () {
    var translation : float = Input.GetAxis ("Horizontal") * speed;   

    // Make it move 10 meters per second instead of 10 meters per frame...
    translation *= Time.deltaTime;   

    // Move translation along the object's x-axis
    transform.Translate (translation, 0, 0);

The above script seems pretty self-explanatory. It sets the player's ship to move at a desirable speed and sets the access along which the movement can occur. One thing worth mentioning is the Input.GetAxis call. You'll note that it's accepting a string, namely "Horizontal". This tells the script to capture the input keys if it is one of the buttons mapped for horizontal control (by default the left and right arrow keys. These keys can be changed via the editor). Finally, the Update function itself is a construct of Unity, and defines the game loop. In programming with Unity, the Update function is your bread and butter...you'll be calling it A LOT.

function OnTriggerEnter (other : Collider) {       
    Application.LoadLevel ("GameOver");

Simple as it gets with this script. If the player object collides with ANYTHING, load the Game Over level. The Game Over level is simply a screen with the text...you guessed it..."Game Over."

The Bullet Object

 var shootSound : AudioSource;
var bullet : Rigidbody;
var speed = 10.0;

function FireBullet () {
    var bulletClone : Rigidbody = Instantiate(bullet, transform.position, transform.rotation);
    bulletClone.velocity =   transform.TransformDirection (Vector3.up * speed);

function Update () {
      if (Input.GetButtonDown("Fire1")) {

PewPew.js spawns the bullet object, sends it in a vertical direction at a constant speed, and plays the "pew" sound effect. This script was basically taken straight from the api on the Unity site.

The Enemy Object

The two scripts attached to all the enemy objects are DestroyEnemy.js and EnemyMovement.js.

var deathSound : AudioSource;
static var enemyCount = 21;

function OnTriggerEnter (other : Collider) {   
    enemyCount = enemyCount - 1;

function checkGameOver () {
    if(enemyCount == 0){
        Application.LoadLevel ("GameOver");


So, this script is actually doing a fair bit of work. When an object collides with the enemy, it both destroys the object that collided with it as well as the object itself. It plays the enemy "pop" sound effect as well. Finally, it decrements the enemyCount variable. This was the way I decided to handle the "player win" condition. Simply, there are a total of 21 enemies on the play field. When the enemyCount has hit 0, it takes the player to the game over screen. Destroying the bullet and enemy object were simple calls to the Destroy function (another native Unity function) since I know that the only object that will hit the enemy will be a bullet object. The player may eventually hit an enemy if they drop low enough, but at that point calling this function wouldn't matter, since the game over script attached to the player object would be called and the game would end.

function Start () {   
    for(var i = 0; i < 6; i++){
            gameObject.transform.Translate (1, 0, 0);
            yield WaitForSeconds (1);       
        for(var j = 0; j < 11; j++){
            gameObject.transform.Translate (-1, 0, 0);
            yield WaitForSeconds (1);       
        gameObject.transform.Translate (0, -1, 0);
        for(var k = 0; k < 11; k++){
            gameObject.transform.Translate (1, 0, 0);
            yield WaitForSeconds (1);       

I think that writing this script was the biggest challenge in getting the game to function similar to Space Invaders. I'll admit that I kind of copped out a bit, as you can see from the script. The movement of the enemies in Space Invaders seems pretty darn simple (move right, drop down, move left, drop down, repeat) but coding it can actually be a bit of a challenge. For instance, if an end row of enemies is destroyed, the enemies do not drop down until the next row hits the edge of the screen. This is a feature that is NOT accounted for in this script...hence saying I copped out. Also, the enemies do not speed up as they're numbers are depleted. The script simply moves each and every enemy object to the right, drops them down, and them moves them to the left at a constant speed. I'd like to improve this script later on to give the game that true Space Invaders feel.

The Bullet Boundary

function OnTriggerEnter (other : Collider) {

Another nice, simple script. This is attached to a large, invisible plane hovering above the play field. This was to make sure the bullets do not pile up at the top of the scene and cause eventual slow-down. Plus they could bounce back down and get in the way. Keeps things nice and clean.

And that's pretty much it! The muscle behind my little Space Invaders clone using Unity. Like I said before, I hope to improve on some of these scripts (especially the enemy movement). I'll post those scripts whenever I should write them.

Until next time,

gl hf!

Thursday, March 31, 2011

Real Life Combined with Gaming

We’ve all been there. In one hand we have a messy kitchen which we know we really need to clean. In the other hand, we have that World of Warcraft character that’s just about to level, or a new mode in Bejeweled that we haven’t tried yet. A standard choice between something fun and something..well...not fun. Responsibilities butting heads with our want to be entertained. However, does what many people call “real life” have to be in such conflict with our ability to have fun?

The guys over at Extra Credits don’t think so. Yes, another one of my blog posts is making a reference to their content. In fact, this post has been 100% inspired by their most recent video. They talk about “Gamification,” which refers to taking the mechanics of play and working them in with “non-play” aspects of life. Real life combined with gaming.

Now, I love this idea. Making medial chores more fun? Where do I sign up?

The guys over at Extra Credits didn’t go into any examples, because they didn’t want to advise, say, credit card companies on how to use Operant Conditioning to get customers to rack up more debt. Can’t say I blame them. I would, however, like to put out a few ideas of my own on how to use gamification to make the work place and chores at home more fun.

I actually thought about something similar once before. “If I were a manager at my work”, I once thought, “I would make a big pizza board, and for every good job add a ‘pizza token’ to the board. When the board was full of pizza tokens, all the programmers would get a free pizza lunch!” You can almost hear the standard xbox ping, can’t you? Achievement unlocked: pizza token. I think this is a pretty good but simple example on how to use gamification to enrich “real life” tasks.

Let’s take my pizza board example to a higher level, one that includes more “game.” For example, how about making a big board and putting it up where every member of the team can easily see it. All the people on the team have their own exp bar which would display their current amount of experience points and what level that they are on. You could have a team exp bar as well, or even just make that the only record of progress if you’re worried about pitting your employees against one another. Anyone reading this who has managed a team and doesn't play a lot of games may have already closed their browser, but stick with me.

OK, so everyone has their own exp bar. Anytime a member of the team does a good job, or completes a required task, they get exp points. When they level (or ding as it’s known in most MMORPG’s) then some sort of reward could be supplied. This does not have to be a massive thing. A 5 dollar gift card to the local coffee shop, a spiffy pen, maybe a plant to decorate their cube with, the list goes on. Hell, depending on the people you’re working with, you may not even need to give monetary rewards. If a member of the team levels up by, say, fixing a really nasty bug in the software, the manager could send out an email to the rest of the team. The email would let everyone know that “person x has leveled up and earned the new title: Bug Smasher!” Plus, when a person levels, it can add to the total exp of the team. When the team levels, that can be when you reward everyone with a pizza lunch or something the team in question will find rewarding.

You could even turn the exp board itself into a game. You could actually make a board game, and whenever someone levels up or completes a task, that person can roll the dice and see where they land. You could make chance cards like Monopoly to make the player’s life more interesting, or put rewards/events on the spaces and the player has to hope they land on one...just be ready to deliver if they do.

I know that if you work in a place that takes itself very seriously (like I do at the time of this writing), this whole idea may not be received well. It truly depends on the people you’re working with. However, if motivation and engagement is at a low, then why not give it a shot? The worst possible result would be that it gets flat out rejected by the members of the team, everyone has a good laugh and life in the workplace goes on. Nothing to lose, everything to gain.

Finally, I’ll end with a quick comment on how to bring this idea home. I’m sure you’ve heard parents or even been “that parent” that complains that they can’t get their children to clean up their rooms. Well, why not make an “allowance board,” or something similar. Have a checklist posted where the children can see it, and if at the end of the night their beds are made and the toys put away, they get a sticker. If they have 5 stickers by the end of the week (5 out of 7 isn’t bad in my opinion), they get their allowance. If not, they don’t. If they have stickers for every day of the month, they get an extra treat.

Remember, keep the people that you’re trying to engage on the edge of their seat. Don’t reward them for every little task, and don’t reward them regardless to try and “be fair”. This concept of taking real life and combining it with gaming relies on Skinner’s theories on operant conditioning. One of the core rules of Skinner’s findings is that rewarding all the time is actually not as effective as rewarding every so often. Keep people lean, and they’ll stay engaged, working for that distant payoff...and if you do you’re part right, having lots of fun doing it!

gl hf!

Thursday, February 24, 2011

What Keeps a Player Playing

I’m back this week to give my take what keeps a player playing a game. This is an important question when you’re trying to make a game yourself. Now, I have yet to really delve into making a game, but I do play a lot of games. I’d like to think that I have an idea why someone would want to keep pushing their way right to the end of a title.

It’s rarely the case today (especially with large AAA titles) that there is a single factor that keeps a player enthralled in a gaming experience.  However, I can think of several things that have kept me, personally, playing a game. The biggest of these things are challenge, storyline, and engagement.

I’ll speak on challenge first. Before I get into my opinions on it, I’d like to direct your attention to another Extra Credits video. These guys spoke on “easy” games, and they make a lot of really great points. If you don’t feel like watching it, the long and the short of it is challenge is best achieved by depth. As I’ve heard time and time again from fellow children of the Nintendo Entertainment System era, people feel that games have gotten way to easy.

I collect NES games, and I've gotten quite a few under my belt. I’ve gone back and replayed some games that I remember being crazy challenging, such as Karate Kid and Silver Surfer. Turns out they are not actually what I would call a challenge....they’re what I would just call crazy and stupidly hard. What’s the difference you ask? A game which provides a good challenge supplies resources in it’s mechanics to overcome the obstacle. Those old school NES games I mentioned however, give their challenge though poor design and the need to memorize everything that comes in the areas to follow. Karate Kid had nasty control and enemies that popped out faster then you can react, thus being maddeningly hard. Silver Surfer, while having it’s share of design flaws just had so much projectiles firing at you the player needed to know exactly what was coming to have any chance of survival. In other words...these old games are great examples of a challenge based around being just plain hard versus providing a challenge though depth.

Grand Theft Auto IV has some examples of good challenges (at least the way I experienced it). For instance, I can think of a few shootouts that occur in warehouse settings that are really, really hard if you just run around with your guns blazing. However, if you use what you’ve learned in previous missions the challenge becomes manageable. A well thrown grenade, a few good shots of a sniper riffle, hi-jacking a car and running everyone on the first floor over; these are all examples of how the player can use the game mechanics to beat the challenge and feel like they’ve accomplished something.

Moving on from challenge, I’ll now touch on storytelling. Mystery is a key storytelling component that helps to draw a player into a game, and keeps them playing. Bioshock, for me, was a great example of not only a wonderful story, but had a constant air of mystery about it that keep me wanting more. After I had played Bioshock for a hour, I couldn't stop. All other games I was playing at the time were shoved to the wayside, because I could not and would not rest until I had unraveled the entire plot. Keep a player guessing, and they’ll keep playing.

That being said, you can’t just have things the player doesn’t know, call that “mystery” and expect the player to be drawn in. You need to make sure the player actually cares enough about the character their controlling, the environment that they are traversing, and the question that they seek an answer to. The way you deliver the mystery is important as well. Give the player too much and they’ll become overwhelmed or just not care, and give them too little and they’ll get bored.

In playing Final Fantasy XII, I found that there was a great deal of mystery in the game, especially near the beginning. However, the story writers began to revel that mystery by allowing the player access to giant blobs of explanatory text describing characters, areas, etc. Frankly, after reading a few of these glossary entries, I stopped caring because breaking up the action (not that there is much action in FFXII) to read a novel’s worth of explanation is just not fun...not when you’re trying to play a game at least. This is a very good example of very bad storytelling.

Finally, I’ll talk about player engagement. Granted, this is quite a broad term when you’re talking about designing games, and both challenge and storytelling can play a huge part in keeping a player engaged. What I’m going to touch on in this post are game mechanics that keep the player playing. For example, what is it about World of Warcraft that have so many people hooked? I’ve plugged some time in the lands of WoW, so I have a pretty good idea. If you think about the concept of WoW, it just seems like a giant grind-fest up to max level, and few people would disagree with that statement. Despite the fact that the player has just accepted their fortieth “kill x of this monster” quest, they continue to pay 15 bucks a month to play it. Why? The goal of hitting the next level, unlocking that next ability, getting those new stat points keeps the player glued to their keyboard. The player feels rewarded by hitting that next milestone, and has a record of their accomplishments via their character and the gear that the character possesses.

Is this sort of engagement actually good? Blizzard Entertainment’s bank account would certainly think so, but is this true engagement? As I’ve said, I’ve played Wow...I’ve also quit WoW, wondering why in the world I spent so many hours of my life playing it. At the time, reaching that next level was the most important accomplishment in the world, but now looking back on it, it feels like I didn’t achieve anything at all. I feel that a game which is truly engaging feels satisfying after you’re done with it.

Whew...well, I’ve typed quite a bit for this post and haven’t really said that much at all. Perhaps talking about something so large requires more detailed posts. I’ll have to look at breaking down how to make good challenges, intriguing storytelling, and engaging game mechanics in future posts...just as soon as I learn how to do that myself...

gl hf!

Thursday, February 10, 2011

Baby Steps to Becoming a Game Designer

So, the plan this week was to provide scripting examples to help people along in making their Amnesia: The Dark Decent custom stories. However, as Frictional Games had warned, the editor is still in beta...and it shows. Put down a table and try and rotate it, the editor would crash. Try and select a subset of entities, the editor would crash. Try and load up one of the professional levels to see how they did a specific trick or puzzle, the editor would crash. I really and truly wish I was over-exaggerating, especially since I don’t feel “done” with this little journey. Sadly, though, I’ll have to wait until either an update is released for the tools or I figure out why my system hates it so. After all, it’s clearly working for some people.

With that downer out of the way, I have exciting news! I, along with some good friends/skilled colleagues of mine, have decided to create a game. A game that will go above and beyond my “Mathtris” learning experiment. There are still a lot of questions we need to answer and a lot of wrinkles to iron out before we even really get started. What platform do we plan to make it on? Do we use an existing engine or make everything from scratch? What genre of game are we going to tackle? Are we going to just do this for the fun of it or actually try and make money? Big questions that, as of yet, do not have answers. We’re going to have a sit down sometime in the near future to iron some of that out.

In preparation for game creation, I’ve been taking slow baby steps towards being a good designer. There is a show hosed on The Escapist Magazine called Extra Credits, and their videos have been very insightful as to what skills a designer of interactive experiences should have to be successful. The videos are entertaining to watch, so if you haven’t checked out their stuff, I highly recommend giving them a look. These videos along with my own effort have started to shift the way I think about decisions made when designing games. I actually have a recent example of this that I’d like to take you though.

I was having a conversation about RPG’s and design choices with one Ms. Bursey over at Bursey15's Blog (one of the people who will be working on our super-secret game of awesome). She has been re-playing Chrono Trigger recently (a very popular JRPG from the golden Super Nintendo era) and she came to a design choice that annoyed her as much today as it did back when the game was first realised. There comes a point in the game where you have a large series of battles across a bridge, ending in a final epic boss fight. After beating the bridge, you can skip from one end of the bridge to the other by use of the over-world map without having to enter the bridge stage again. As she pointed out, this is the only place that you can do that. Every other stage in the game forces you to enter it at one end, play though the stage, and exit though the other. She asked some very good questions; “Why did they do that! Why can’t I skip every other area I’m done with? The forest in front of the castle for instance...Why can’t I skip that?”

I should note that I was thinking like a gamer at the time. My response to her frustrated query was “yea, I agree. That was pretty silly of them.” However, after the conversation was over and I went about my business, that question kept gnawing at me. Why did they do that?

Those of you who have played Chrono Trigger know why it’s a favorite among JRPG lovers. It was a very well designed game. So, was this a screw-up? The designers were human after all, so maybe they just put this function in without actually thinking? Was it a tactic to artificially extend the amount of hours you needed to spend finishing the game? Maybe, and maybe not...I put my “game designer hat” on and really gave it some thought.

Every other level in the game has something, and a great many of them, including the aforementioned forest, has special chests that you need to return to get later in the game. The bridge however does not have anything else in it. There are no battles, no treasure, no storyline tidbits, no nothing.

Ok, so, skipping the bridge makes perfect sense. After all, if there is nothing interesting for the player, why make them play though that part again? The question still remains as to why the player can’t skip to the opposite end of other levels after they’ve completed it. This question made me start to think like a programmer. For this to work, another very important question will need to be answered; “How would we know when a player is done with an area and would not want to return?” Would you need to keep track of all the possible items and paths the player has seen or not seen? How would you know if the player wanted to re-enter to level up their characters? How would you know if the player wanted to double check if they missed anything? Trying to program that would be a nightmare.

The only real solution to knowing exactly what a player would want to do would be to give them a dialog option each time they came to an area. “Would you like to skip to the end of this level? Yes or No?” The mere thought of that makes me shudder. NOTHING breaks game immersion more than out-of-place dialogs popping up. So, what it comes down to, at least the way I see it, would be a trade off between keeping the player immersed and giving the player convenience.

Convenience of travel is at the heart of this design choice. The big travel convenience that you get later on in the game is (spoiler alert) the Epoch. This wonderful flying machine not only allows you to jump around to different time periods as needed, but you can fly to any point on the map. I specifically remember my first experience with the game and the moment I achieved that freedom. It was monumental.

At one point later on in the game I needed to return to the castle that is normally blocked by a forest. However, this time instead of having to run though the forest and try to dodge the enemies therein, I could fly right to the castle’s front gate. I remember that moment specifically, because I was so happy that I no longer had to run though the forest, and was so glad to have this flying machine.

So, now the question is would the achievement of obtaining the flying machine and the freedom it offers have as great an impact if you could previously just teleport between the levels? I think it’s safe to say that it would not. Sure, it would still be wonderful to fly around and jump time periods with greater ease, but it would not mean as much if there wasn’t so much previous effort to get around. Plus, would the world feel as free-flowing, large, and complete if you didn’t have to travel around in the way that you did before gaining access to the skies? I’d also have to say no to that question as well.

That was quite the large analysis for one little part in the game, I’ll admit. Were the above reasons the actual reasons the designers of Chrono Trigger made those decisions? I frankly have no idea. Am I over-thinking things to much? Well, maybe...but I don’t think so. A well designed game like Chrono Trigger is popular for a reason. Every button press, every level, every battle, every bit of interaction shapes the player’s experience. The difference between a good game and a bad game is the thought and effort put into making the mechanics work.

I hope this post proves some useful insight as to what thinking like a game designer is like. Now, I’ll follow up that statement by saying I’m new to this line of thinking, and I’m far from perfect. It’s a skill that’s going to take time to develop, without a doubt. For those of you who have played Chrono Trigger and have different ideas/theories as to why they made the decisions they did, then my mind (and comment section) is always open.


Thursday, February 3, 2011

Amnesia Level Editor: Free Fall Adventures

So, continuing on from last week, I’m going to talk further about the Amnesia: The Dark Decent level editor and my experiences therein. After learning the basics of the level editor and setting up my dev environment, as explained here, I dove right in and tried to make a very simple level. A map with a floor, four walls, a ceiling, and a light source. I always like to do the most basic thing I can when trying something new just to prove to myself that it works. My experience in the past has been if you do a lot of work up front and then try and test it, you’ll have more headaches then you can deal with. Start small, work your way up...the standard programmer’s motto. Also, should you try to set up your own development environment, I highly recommend backing up the “main_settings.cfg” file before you get started. On my first attempt at configuring the file, I messed up something and I could not figure out what it was. I simply reverted to my backed up copy of the cfg file and I was good to go.

When I first loaded up my trial map, I spawned in complete darkness, I could not seem to move, and then I heard the “crumple up and die” sound effect with the death screen shortly to follow. After re-examining my level I realized that my light source didn’t have enough of a radius (in fact it had no radius), so there was no way to see how my completely non-threatening room was killing me. After giving the area some well needed illumination, I tried to load up my map again. Turns out I was falling past my floor because the protagonist spawned outside the room, and then just plummeted into darkness until he hit the bottom of the map and died.

Oh, the humanity!
Fun times.

Clearly, my player spawn entity was not working the way I had hoped (i.e. not dropping me into the abyss of the map). According to the tutorial I was following, you can make any “entity” object a start point as long as the name starts with “_start”. I double checked my entity, and everything seemed to be fine. While trying to debug my falling though the floor problem, I noticed that in the user_setting.cfg file had a “StartPos” property in the <Map> element that was left blank. 

Hoping this may be the solution, I took the name of the player start object and placed it into the configuration file. Sadly, when I loaded up the map again, I was still falling to my doom. Reading further, the “StartPos” property is used to set a different player start position if you don’t want to use the first one you have defined. So, if my understanding is correct, leaving it blank should force the map to spawn me at my current start position, since it was the first one I created and there are no others on the map.

Finally, after some experimentation, I found that the “Area” tool can create a “PlayerStart” cube. After creating an actual starting position and placing it in my room, I stopped falling to my death and appeared in my room as I had intended.

So, after some playing around and a few mistakes, I’ve gotten my very basic level up and running. Now all I have to do is make it interesting. Design the level, put in difficult but engaging puzzles, make lighting effects to keep with Amnesia’s wonderful and creepy atmosphere...you know, the easy stuff.

While making a full custom story interests me, what I plan to do with my little sandbox level is try out the scripting language. Frictional Games has a full api listed here of all the functions that you can use in the levels. Most of the functions seem self-explanatory just by their names. I think I’ll make my next post less of a rant and more of a demonstration of the functions as I try them out. Perhaps I’ll create a level with a series of bland rooms, each one demonstrating some function or combinations of functions.


Thursday, January 27, 2011

Amnesia: The Dark Decent and Level Editor Controls

I’m not making the post this week that I thought I was going to make. Instead of designing my Tetris clone and looking into DirectX, I spent that time playing, finishing, and experimenting with the development tools for Amnesia: The Dark Decent. Never fear, the game I have lovingly coined as “Mathtris” shall be coming in the future. However if you’ll permit, I’d like to talk about this fantastic journey into the survival horror genre and my experience with the development tools.

Any of you fans of the horror genre or those who keep up with gaming news have likely heard about this indie gem by now. Frictional Games have done the industry proud by producing a truly oppressive style of horror game, which is something the industry has been lacking in as of late. Most recent games that have the “horror” tag line attached tend to be less about a looming threat and more about keeping ugly spawns of hell away with very large guns ( Dead Space being a prime example).

Now don’t get me wrong, I do enjoy exploding various types of demons into their respective giblets. That being said, there is something truly exciting and truly terrifying about being both under the constant threat from unspeakable evil, and being helpless to do anything but flee from it. The ambiance is such that you feel there’s danger around every corner, even though that is not always the case. The atmosphere sets up the scares, and your imagination tends to do the rest, and every room you enter becomes the next possible death trap.

If you haven’t played Amnesia: The Dark Decent yet, I highly recommend that you do.

OK, now that I’ve got that rant out of my system, lets talk development tools. To allow for the creation of custom stories in Amnesia, Frictional Games has produced a level editing tool along with a custom scripting language. I personally found the documentation felt a bit scattered, but just about everything you need, both tools and tutorials, can be found here.

My advice before starting any development would be to give a very quick read to all the basic tutorials they have. Making a level and scripting for a level are two separate chunks which are separated out in the tutorials. Get the big picture first, then jump right in. Only way to learn is by doing after all.

I’ll list the Amnesia level editor controls that I’ve read about and discovered though just playing with the editor to make your journey a bit easier (such as how to copy and paste). Please keep in mind that these are the windows controls (Linux controls may be different).

Rotate the camera in perspective view = Alt + left mouse button
Zoom in and out = Alt + right mouse button OR mouse wheel scroll
Move the center point of your camera = Alt + middle mouse button
Copy/Paste (a.k.a. Clone) = Ctrl + D with object selected
Translate mode hot key = Q with object selected
Rotation mode hot key = W with object selected
Scale mode hot key = E with object selected
Select multiple objects = Ctrl + left mouse click
Undo previous change(s) = Ctrl + Z
Redo previous undo(s) = Ctrl + Y
Change a view to full screen = space bar while hovering over the desired view
Remove the selected object = Delete key OR Backspace key
Find and Select objects = Ctrl + F

I hope that the above list of commands will lessen the difficulty curve of learning to make your own Amnesia custom story maps. There’s actually a fair bit more I’d like to talk about such as a more in-depth look at the level editor and the scripting language, but I think this post has enough “heft” to it. I’ll continue this topic in posts to follow.


Saturday, January 15, 2011

Let the Journey Begin!

Hello internet!

I've been meaning to do this for quite a while, and I've finally decided to do it. "This", of course, is to create a blog where I can post both my progress on becoming an apt game programmer and  random thoughts about gaming in general.

As the "about me" blurb in my profile suggests, I've been gaming for a LONG time. One of my earliest memories is playing my older cousin's Atari 2600 as he babysat me for some extra cash. I was pew-pewing at the age of four, not even sure what I was doing, but completely drawn in by the glorious flashing lights and sounds of such classics as Missile Command, Space Invaders and Plaque Attack. Growing up I continued to evolve my gaming experiences through mediums including the Nintendo Entertainment System and the Sega Genesis. Now, at the age of 27, I continue to partake in interactive experiences of a much higher level (Left 4 Dead, Mass Effect, and Starcraft II are just a few examples). However, even as I buy new graphics cards so I can play the biggest and brightest triple-A titles, I never forget the classics. I never forget my roots.

Which brings me to my career choice: Programming. I always wanted to make games. My friends and I, in between playings of Mega Man and Castlevania, used to invent video games on pieces of paper. We drew out level designs, item drops, and enemy spawn points (ah, how I wish I had kept those binders full of random gaming ideas...even though most of them were basically Super Mario clones). During my junior-high year, a recruiter from Memorial University of Newfoundland paid my school a visit, and spoke of the computer science department, and how I could learn programming methodology. My eyes lit up. I had decided then and there to attend MUN, get my computer science degree and program games that would change the industry!

I did indeed go to university and  I got my degree, but somewhere along the lines of doing so reality set in. Or more accurately, the disillusionment of what I thought "making games" was. I know now that there are many, MANY different aspects to building a game. There is level design, engine programming, A.I., and so many others. I now also know that there is no room in the industry for a specialized "idea guy", where a studio would hire me to come up with awesome game ideas to pass them along to the team (which is what I had pictured in my youth). On top of all that, there were sadly no gaming studios here in Newfoundland (a fact that has changed over the last two years). And while I was not completely opposed to moving away, I do love this province. So in the end, I choose to take my degree and get a job at a respectable non-game-making company.

My degree was not a waste however, since during my studies I discovered a great love for programming. Building a program to make use of that bubble-sort algorithm I learned gave me great joy. No kidding! It was awesome! :-) So, no regrets on that front. I do enjoy my job and all the neat problem solving that comes with it.

I still, to this day, have that nagging itch. That "want" to have my hands in game development. Which brings this first (and as it turned out longer than I had expected) blog post full circle. In the future I hope to use my base programming skills to learn how to be a great game programmer. Even if I never work for a gaming studio, this journey should improve my overall programming abilities. And hey, who knows...maybe one day I'll release that next big indie hit, or even create a gaming project on http://sourceforge.net/ that would bring some joy to the open source crowd.

I hope as this blog gains more content/code snippets/game rants that it will prove to be useful to people with the same ideals. As we say in the Starcraft community,

glfh (Good luck and have fun!)