Friday, April 5, 2013

Journey into a Design Exercise: Confrontation Web Card Game

And a howdy-do to all my fellow game enthusiasts!

Today I thought I'd start on a new little series on my blog. As a hopeful game dev, it's important to really start getting some design practice, and what better way to start than playing other games and breaking them down into their components. I plan to look at games of every sort and size, old and new. This week, I had a hankering to play a collectible card game. I figure since I'm trying it out, I may as well also examine it for it's good, bad, and ugly design choices (if any are to be found).

Let's take a Journey into a Design Exercise: Confrontation Web Card Game

Confrontation is a web CCG which is trying to cut a niche into the goldmine that is the facebook market. I'll admit my first impressions of the game where not flattering, but I pushed ahead to see the depth of the game (if any existed). In the few hours I've been playing it, it has grown on me a bit...but I digress. This is not meant to be a review. We're breaking down it's design! So let's get to it.

I'm a big fan of Extra Credits, and they did a great episode a while back where they did a basic breakdown of the mechanics of Bejeweled. Their method for breaking down a game's mechanics mimicked the Scientific Method; Ask a question, come up with a theory, test that theory. So, here are the questions that I will seek to answer in order to break down this game's design:

  1. Why do the battles play out automatically instead of allowing the player to choose the cards they play?
  2. Why are the deck sizes small, but you can make many decks and choose to use multiple decks in a game? Why not just allow the player to make a larger deck?
  3. What is the purpose of the leveling system in the context of this game?
  4. Why are there three types of currency (Silver, Gold, and Gems)?
  5. Why can any monster on the field only be attacked (a.k.a. can only defend) once per round?
  6. How did they deal with the issue of power creep?

I think answering these questions will give me a good insight into what the game's designers had in mind when creating Confrontation. So, let's dig right in.

1. Why do the battles play out automatically instead of allowing the player to choose the cards they play?

This was the mechanic that gave me a very bad first impression. When I've played a paper CCG in the past, I found that a big part of the engagement was playing your cards in a cleaver way and outsmarting your opponent. However, in this game, the battle are automatic, and are built to complete in less that a minute at the x8 speed setting. I'm sure I'm not alone in my enjoyment of actually playing the cards in my deck rather than letting a computer do the work for me. So why make this choice?

After spending some time with the game, I believe that there are several factors that add up to this design decision.

I think the biggest reason for this choice is that they choose Facebook as their release platform. The average person on Facebook who would play this game does so to "kill a few minutes." Rarely will you find someone who wants to play a half-hour long card game. Having the battles play out themselves means that the battles run quickly, allow the player to feel like they've accomplished a lot in a little amount of time.

Since the battles play themselves out, you don't need anyone else to be online for Player vs Player. This is especially important in the game's infancy, since there is nothing worse than joining up for a CCG online and finding no one to play with. With this mechanic  you're not really playing with people, but rather challenging the decks they built.

In pretty much every CCG in existence, there is some manner of condition that is required to be met before you can play a card to the field and/or activate it. In Confrontation, that resource is "time." A card will hit the field after a pre-determined number of turns has passed. Since this was their choice in limiting how fast a card can hit the field, then why not just have the card hit the field as soon as it's ready? To allow a player to hold onto cards after the time limit on the card has expired would cause some pretty severe balance issues, since a player could just hold onto ALL of their cards until a moment of their choosing, and then vomit their entire hand out onto the playfield.

From a programming perspective the "AI" is easier to program, since the AI doesn't need to account for player actions or even be truly competitive. The card game will play out as per the predefined set of rules. All abilities on the card that can be used are used, cards are played as soon as they are available, every card attacks whether or not that decision is wise, and the game ends when a person is unable to defend themselves or their "morale" (the player's HP) reaches 0.

Deck building is clearly the name of the game, since this mechanic takes control away from the player during the actual combat. So, the person with the strongest cards and the most coherently built decks will come out on top. They've target people who enjoy collecting cards, people who enjoy deck building, but who don't necessary need that one-on-one interaction that many CCG's provide. Also, it's important to note that since the game is centred around deck building, and some cards are vastly superior to others, that the mechanic draws the player to the store. The more they can get the player to the store, the better chance they have of dropping real money on the game. So, in other words, this mechanic draws people towards their monetisation strategy.

2. Why are the deck sizes small, but you can make many decks and choose to use multiple decks in a game? Why not just allow the player to make a larger deck?

The most obvious reason for this (at least in my mind) is to lower the barrier to entry for players. Again, since this is a Facebook game, they want to reach as many people as they possibly can. Other CCGs like Magic: The Gathering can be quite difficult to even get started. Creating a 40 to 60 card deck with no limit on how to build it can be very intimidating. With Confrontation, you pick a hero card, and that card limits what you can put in the deck for you. And the decks on average are only about 10 cards, which are much easier for the average gamer to wrap their head around.

However, by allowing players to build multiple small decks, it has the potential to keep the interest of more advanced players. Many of the battles down the road use two, three, four, and sometimes even five decks at the same time. The player will need to know how strategies can work together and build a coherent set of decks.

And yet again, this brings the focus to deck building, which drives the player to the in-game store.

3. What is the purpose of the leveling system in the context of this game?

The leveling system in the game seems to serve three main purposes. It gives players a way to win the "Gem" currency in large amounts, it plays a factor in Player-vs-Player matchmaking, and of course a Skinner-box style reward system.

4. Why are there three types of currency (Silver, Gold, and Gems)?

This one I found a bit odd...I'll admit I'm not a huge Facebook gamer, but from what I've seen the usual strategy for monetizing a game on Facebook is to have two forms of currency. One in-game currency, and one real money currency. This game, however, has three types; Silver, Gems, and Gold.

Silver you earn by actively playing the game. Gems are earned by completing story missions (usually only one to five gems)  or by leveling. Gold is the "real money" currency that player need to drop actual dollars and cents on to earn.

When you go to the in-game store for more cards, you note that you have a choice in currency to buy most packs. The lower-level packs you can spend either Silver or Gold, some of the mid-tier packs and cards you can use Gems or Gold, and then the biggest and most powerful cards are locked away behind Gold only purchases.

Speaking from a mechanics point of view, this other in-game currency, Gems, seems superfluous. When a player levels, it would be just as easy to give the player extra Silver, and have all packs cost either Silver or Gold. So, as near as I can tell the purpose of Gems is to make the player feel like they're accomplishing more or something special when they level and get Gems. From the few hours I've spent with the game, there seems to be no way whatsoever to earn the real-money currency in-game as some Facebook games allow you to do. I believe "Gems" is the replacement for that, giving the illusion that when you level you're making more progress towards earning stronger cards.

5. Why can any monster on the field only be attacked (a.k.a. can only defend) once per round?

The answer to this became clear fairly quickly. I've played several other CCG on the web, and more than one suffer from a very nasty "snowball" sort of effect. When all monsters on one side of the field can attack the same monster more than once, the main strategy quickly becomes "fill up your side of the field first." In this scenario, it becomes near impossible to turn the game around when the other player has gained momentum.

While it is still true that a player who has gained heavy momentum in Confrontation can be difficult to beat back, with this design choice it is possible. Rather than a card hitting the field and being destroyed immediately, it has a few turns to get going. With two well built decks, momentum can shift so many times it can be impossible to tell who is going to win until the player's life hits 0. This can make for far more interesting games versus other games I've played. Knowing you've lost after the first four cards are played and having to wait it out isn't a lot of fun.

One thing I should note though, is that there is no limit to the number of cards you can have on either side of the playfield. This choice seems a bit odd to me, since a game can still snowball, despite this design choice. The only reason I can see them making that choice is allow a player to gain a definitive lead to make sure games don't take long. Each game (espically if you're playing on x8 speed) usually takes less than a minute to finish. Limiting the size of the playfield would lengthen the game.

6. How did they deal with the issue of power creep?

This game has a very big problem with power creep. In fact, it seems to have an issue with balance in general, greatly favouring the players who spend real money.

As I stated before, the packs containing the best cards are locked away behind the real money currency. It didn't take very long before I realized that the rare cards are worlds more powerful than the other cards, and a player without these rare cards can't even hope to compete against a player that does.

This is the worst way a free-to-play game can operate. No one wants to be forced to spend real money so they can feel competitive in a free-to-play game. If players want to spend money, that's perfectly fine, but in this game it puts them far ahead of the rest of the pack.

Obviously, I'm not suggesting that the common cards be just as good as the rare cards. That wouldn’t make for a good CCG. When you get a rare card, you want it to feel useful and powerful. However, well designed CCGs don't make their more common cards completely useless. There is NO motivation whatsoever to build you deck with any common cards if you can avoid it, which makes all your earlier efforts to build your collection basically pointless.

This is a very fast and unfortunate way to get players to lose interest. The moment they realize that all their efforts now will become completely useless later,  they'll drop the game (just as I plan to do).

- - - -

Well, that was a fun little exercise in game design. Had to play the game a fair bit to come up with the answers that I did. I hope the more I do this, the better at it I'll get.

If anyone out there wants to weigh in on my breakdown (or completely disagree with me), nothing would make me happier.

gl hf

Thursday, March 21, 2013

Journey into ReTaken: My First Game

Hello to all of my fellow hopeful game devs!

In my last post I stated that I'm starting to find my stride (thanks in no small part to the great bunch of people that are working on this game with me). I have a number of blog posts in my head that I plan to write. I'll be talking about my progress, the code challenges that I've faced and how I overcame them. Before I start pasting code snippets and talking about sprites however, I thought I'd talk about the game I'm working on.

Let's take a journey into ReTaken: My first game.

So, the "elevator pitch" for this game would be "a turn-based strategy game with a race-to-the-end mechanic incorporated into it's design." Simply put, you need to build and create units and structures to take on the enemy, as well as battle your way to certain places in the stage before it's "too late."

Having played a bunch of TBS and RTS games, ReTaken is inspired by the likes of the original Warcraft, Starcraft, and Fire Emblem. However, the game that plays the biggest part in it's inspiration is actually ActRaiser for the Super Nintendo.

This may seem odd to most of you who have experienced this Enix classic. After all, ActRaiser was mostly known for it's platforming, right? True, but if you recall, before you got to fight the second boss in each area you took control of your little angel helper rather than the sword-wielding god and built a town. Well, you less "built" the town and more guided the little mortals down paths, using your heavenly magic to burn forests, destroy rocks, and otherwise clear out the land.

Above is a screenshot of ActRaiser.

I loved the town building sections of ActRaiser. To me, the platforming sections where a vehicle to get to the next desolate, unpopulated area. I used to wish that you could skip the platforming sections all together and just do more town building. When the sequel to ActRaiser came out and they cut out the town section for pure platforming, I was devastated. I always wanted Enix to release a full game that was just ActRaiser's town sections.

When I re-played it as an adult (it should be noted that when I call myself an adult in this blog I'm using the  loosest sense of the word), I found that the town building parts of ActRaiser were...far less engaging then I remembered. They were still charming, but they were very, very simple. I also found out that they were impossible to lose. The sense of danger that I once held when a monster flew out of a den and barrelled towards my town was no longer present. Still, I was longing to recapture that joy and fun I had with that experience as a kid.

Thus, the idea for ReTaken was born.

Don't worry, ReTaken is not just going to be a quote-un-quote "rip-off" of the town sections of ActRaiser. I hope to make it a whole lot more than that. At worst, this game is going to turn into a nice little portfolio project for myself and the team (since right now it's just a labour of love), but with a little luck and a lot of effort, it will reach a high enough quality to actually get accepted by the Steam Greenlight project. That's the goal at least!

gl hf

Thursday, March 14, 2013

Journey into Acknowledging and Overcoming Fear

Hello gamers and game devs!

I hope you can forgive the overly dramatic title...and also forgive me for not posting in so long. Has it really been over a year? I haven't been entirely idle for the full year though...just a fair chunk of it. Now that I'm finding my stride, I think it's time to start sharing my experiences with the world again.

And this one is a bit of a doozy. Let's buckle up and Journey into Acknowledging and Overcoming Fear.

Since this blog (an yours truly) is dedicated to video games and game development, I'm not talking about the fear of the dark or your the of spiders. Not being a trained psychologist, I can't really help with that. However, I can speak to my experiences of trying to overcome my own fear of actually getting a project started. The type of fear that can paralyze you from meeting your goals.

As I wrote in my very first blog post, I've wanted to do game dev for quite some time. I'm talking as early as the age of five or six, when my little brain had matured enough to realize that games didn't just materialize from the ether. I fantasized about being in a fancy suit in front of a big board of directors at Nintendo, presenting my idea for the next big game. The presentation was met with a standing ovation, and had that one obligatory old man in the back with a tear rolling down his cheek, happy to have staved off his retirement long enough to see such beauty (so I watched a lot of T.V...give me a break, I was six).

When I got to my adult years, and had the base set of skills I needed to really start digging into game programming...I didn't. There was always an excuse. I didn't have enough time, I needed to learn more, I just need a better idea, blah, blah, blah. My loved ones and friends who I would rant to about my indecision to would always be supportive. They would say things like "what do you have to lose by at least trying? Just go for it!" I adopted that mantra myself. I should just go for it! I've been saying it for a long time now! I don't have anything to lose, so why not just do it?

I was lying to myself. I did (and still do) have something to lose.

I had my dream to lose. That's the thing about dreams...until you try and make them a reality, the dream is still a perfect and beautiful thing. Untouched by reality and as warm and comforting as it was when you were a kid. Trying and failing at a dream isn't like trying and failing at anything else. It's scary.

Without even realizing it, I was too afraid to really try. By not trying I could always hang onto the hope that I could one day do it. By not trying I'd never lose my dream.

But I'd never gain it.

It was only when I finally acknowledged my fear of failure could I start to overcome it. It was like a light bulb went off in my head when I finally answered the question "why can't I get started?" The fear of failure can be an intense thing indeed, but when you have admitted to yourself that you're afraid, you can then ask yourself the important question "how do I get past my fear?"

Not an easy question to answer. For me, it was deciding that my dream was important enough to risk being hurt if I found myself unable to see it though. It's actually amazing how much easier it was to start making progress toward my ultimate goal (starting up my own dev studio) after I acknowledged my fear of failure. I've decided to really try and turn my dream into a goal, and that goal into a reality...and it's scary as all hell.

I guess if there is any moral to be taken from this blog post (other than an excuse to be slightly dramatic), is that if you find yourself having trouble getting started toward your goal, ask yourself if it's fear holding you back. I personally didn't even realize that I was making excuses because I was afraid of failure, and couldn't move forward because of it. Maybe it's the same for you? If you find that it is, then acknowledging that fear is the first step.

Whew...good to get that off my chest. I hope you can forgive my slight foray into the dramatic. I hope to start bloging again on a regular basis. My plan is to get a large(ish) post every Thursday, with smaller posts randomly sprinkled throughout the week.

Thanks for reading, and to my friends and family, thanks for your support! Let's make this happen!


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 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! 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'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 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!