Game Engine Design and Implementation: A Semester Post Mordem

It's been a long, hard semester but it's finally coming to an end. The past month has been overwhelmingly busy between programming Gamma Gears and wrestling with course work and the like. In this blog, I'll talk about a few of the lessons I've learned this semester and a bit about what I've been up to.

Lesson 1: Gamedevs Don't Do Documentation.

At the start of the semester we were required to use a pre-made engine, despite my requests to use our Dungeon Boy engine from GTFO: The Double Dungeon Debacle. My professor felt that by using a third party engine (in our case Sony's Phyre) we could get straight to the making the most important part, gameplay.

Yeah I mad.

I didn't believe him for a second. We had a pretty good workflow with our existing engine with working combat, and all necessary game engine components working in acceptable capacity. Getting set up with a new engine would take time. There would be so much troubleshooting and failure ahead, with no merit to what we had previously accomplished.

A wise prof once said: "Gamedevs don't do documentation". I thought he was kidding before I met Sony's Phyre Engine.

When using a tool as extensive as a game engine for the first time, there is a lot of uncharted territory. In some cases it's like being given a bag of futuristic Alien tools with little to no instructions on their intended use.

Samples like these were our primary means of deconstructing Phyre.

To clarify, the engine does come with some documentation that will get you started, but there are many common tasks that are not detailed or covered. The instructions are often incomplete and downright negligent. In order to get started making a game with this tool, I had to deconstruct the few sample projects I was provided with. Unfortunately none of these sample projects contained any form of combat, so this left me with very little reference for that aspect of the game. Chances are if you didn't help make Phyre engine, you're going to run in to some issues.

Thankfully for some of the more technical issues (like how to create a phyre base project) we were able to get help from one of our fellow classmates. His blog can be found here: http://mikedaprogramma.blogspot.ca/

Lesson 2: Choosing an engine should be about the right tool for the right job.

To make a long story short, development on Gamma Gears was slow and often confusing. Due to the intense learning curve in working with Phyre and minimal of availability of assets early on, getting the basics up and running took much longer than expected. Once we managed to get our skeletal animation system working, we had decent animation and locomotion with environment collision detection. All of these features were implemented in script as recommended in Phyre's documentation and demonstrated in the samples. We took this approach so that we could build our game scenes using the Phyre level Editor which we thought would make things easier. Not to mention the samples were implemented in this way. Once the game is constructed in the level editor, the assets are exported and the scene can be loaded in code.

We ran into problems when trying to access data between our script (lua) and code (c++) platforms. This was most likely due to our own inexperience with the tools, but as a result we were unable to implement certain "code only" features such as GUI and audio.

To make matters worse, despite my best efforts at implementing combat in script, things just weren't coming together.

I knew I had to present some form of gameplay to my Game Design professor today, so last night I coded a combat prototype using our Dungeon Boy engine in about 12 hours. Many new systems had to be added (multiplayer input, chain combos, multiplayer camera), as well as countless adjustments to movement, collision, animation states, and assets. This was only possible because I was working with tools that I had created.

Working Title Screen: Check

It may not look like much, but this is gameplay. There was very little time for visual adjustments.

I can't wait to sleep after this blog is over. 

In 12 hours we achieved fully functional 1 on 1 multiplayer combat (I wouldn't say it's super fun yet but you can beat eachother up pretty good), with GUI, sounds, and a basic restart event. This build is sadly, more playable than our Phyre build, which I've spent at least 10 times the hours working on.

If there's a point I'm trying to make here, it's the one about getting right to the gameplay. Sometimes the right tool for the right job is the one you made yourself.

Lesson 3: The Shawarma effect

Mmmmm Shawarma.

The shawarma effect is a term that refers to the continuous stripping down of an idea or project.

Often when designing games, the initial scope is set too high. The process of refining the idea is usually very much about simplifying it into it's most important parts. Over the course of the semester, Gamma Gears has been many different things. The Gamma Gears (both prototypes) you see in this blog is nowhere near as complex as planned in the design document. It's meaty bits have been trimmed down until only the base is present. This is a natural reality when creating early prototypes of games, especially when running on a tight schedule.

To deal with the shawarma effect, it's important to strip your game down early rather than later when it's time to actually implement your design.

Camera Systems: The Good, The Bad and The Ugly

I don't know who this guy is, but I hope you agree that his face is awesome.

Camera systems in games play an extremely important role in delivering an enjoyable experience. Not only does the camera represent the viewpoint of the player, it is also responsible for delivering a visually pleasing and functional scene. In this blog I'll be discussing some camera systems from older games and eventually, some much better ones from a few newer titles. Over the years developers have learned from each other's mistakes, and gamers' standards have risen. Back in the day, bad cameras were almost an acceptable part of 3D games. Now as games continue to grow in complexity, so do the cameras that power them.

Ok let's get started shall we.

Old Games, Bad Cameras:

Early Resident Evil Games

I remember this game being so scary in 1996..

Despite being one of my favorite game series' (with the exception of RE6), the Resident Evil franchise has had a history of awkward fixed camera systems. This was largely due to the levels being made up of 2D sprites (pre RE: Code Veronica). Often the player would be engaged by enemies located off screen, or occluded by objects in the level. To make matters worse the movement controls were not relative to the camera, giving the characters a tank like feel. Some would argue that the early RE games owe their scariness to the fumbly controls and awkward camera angles.

Skip to 6:24 to see what I mean.

Capcom eventually learned their lesson with Resident Evil 4, popularizing the now standard "over the shoulder" camera perspective. We'll talk about this one in the "good cameras" section.

Early Tomb Raider Games

Again don't get me wrong, I love these games. But boy did the camera make me rage.

The Tomb Raider series was one of the original innovators of the traditional 3rd person camera. The camera is offset a certain distance from Lara in the Y and Z axes, and follows her constantly. The camera interpolates to Lara's orientation as she runs forward (but not when turning on the spot). This is all well and good for the most part.

The real problems arise when the game's camera collides with the environment. This can make it very difficult to make precise jumps, or avoid the game's lethal obstacles. Combine this with the camera being unaffected by enemies (on screen or off) and you're in for some pretty frustrating scenarios.

Dishonorable mention: Prince of Persia Warrior Within

SPOILER: Sands of Time was better.

As you probably guessed, I am a fan of the Prince of Persia series. The camera system in the Sands of Time trilogy was very good for the most part. However in Warrior Within, whenever the Prince encounters "the Dahaka" the camera takes a turn for the worst (no pun intended).

The transitions from third person camera to fixed camera can be quite jarring, especially since the camera is moving in such a way that the player cannot see the platforms ahead.

Thankfully they did not continue to use this system in subsequent Prince of Persia titles.

Games with good cameras:

God of War

There are many cases where a camera system is so natural that we as players don't notice it all. Chances are if nobody is complaining about it, the developers have gotten it right. God of War is known for it's brutal cinematic gameplay that makes you feel like a total badass. The game gives no camera control to the player as the right analog stick is used for dodging, yet somehow it works nearly flawlessly.

The series is partially responsible for popularizing the node based, cinematic action camera. This camera system involves interpolating between set camera nodes (positions in 3D space) based on the position of the main character. Each camera node has it's own properties (orientation, field of view) that are also interpolated accordingly. The main character's movement may also have a weighted influence on the camera's movement depending on the scene.

In combat the enemies and player become weighted nodes, each with their own varying amounts of influence on the camera's target position. The larger and more threatening enemies have a greater influence than the smaller pawns. This ensures that the scene is always well represented, and the player rarely dies to off-screen threats.

The game makes heavy use of quick time events (QTEs) which trigger a separate camera, synced to the animation of the event. As the animation progresses (Kratos decapitating a poor foe), the camera shakes and interpolates along a curve. These camera curves are specified in the QTE animations themselves.

Resident Evil 4

Resident Evil 4 was a major departure from Capcom's previous RE titles. For starters, the worlds were rendered in full 3D. While Code Veronica and Resident Evil Zero had already used 3D environments, this was the first Resident Evil game to adopt (and perfect) the "over the shoulder" camera. 

This camera is fully controlled by the player, giving them precise aim during combat and a close up view of the game's many puzzles and objectives. These were two firsts for the series which lead to a change of direction to more action based gameplay, especially in subsequent titles.

Metal Gear Solid 4

I can't write a blog about cameras and not mention the Metal Gear Solid series. Notorious for being more movie than game, the MGS titles have always had a cinematic quality about them. Metal Gear Solid 4 is no exception.

As demonstrated in the video above, the game makes use of a variety of different cameras depending on the gameplay situation. The primary camera is a third person orbiting camera centered on Snake. It can be manipulated completely via the right analog stick. During combat, snake must aim in either first person view, or and over the shoulder view reminiscent of RE4. Gameplay aside, the MGS series has some of the best cutscenes in video games and much of this is thanks to the camera work. A typical MGS cutscene features many spline paths for cameras to interpolate along, as well as realistic camera shake and spring functions to make things feel lifelike.

If there's any one game that's demonstrated pretty much every camera technique I've mentioned (and more) to a tee it's this one.

So what have we learned?

A good camera system doesn't just need to make a game look pretty, it also has to work! This may seem self explanatory, but it can be easy for a camera to ignore information that is vital to gameplay.

Phyre Starter

For the past few weeks, I've been working extensively with Sony Computer Entertainment's Phyre Engine. This is the same engine that powers Namco Bandai's Dark Souls, as well as thatgamecompany's Journey among many others.

So far, I can't complain. The engine is free to use, gives the developer source level access and supports multiple platforms (PS3,  PS4, Vita, PC). To top it all off, it sports a very powerful editor tool with full scripting functionality. The editor is completely optional, and if you so choose you can ignore all additional features and use Phyre as a simple rendering engine.

The editor is very easy to use, with the standard array of property sheets, script editors, and object hierarchies you would come to expect from a tool like Unity or UDK. Game logic can be written in scripts through the editor, or implemented through C++ code at the source level.

The code above is the heart of your typical Phyre application header. The virtual functions marked "Phyre Framework overrides" encapsulate all of the top level functions of your game application (namely things like initialization, input handling, updating and drawing). The functions below the "PIEditEventHandler Implementation" comment can be called directly by the scripts attached to game components constructed in the Phyre Level Editor.

Speaking of which, Phyre follows a component-based model. This means that the game entities you construct in the editor are built up of multiple components. These components could be anything from your art assets (animations, textures etc) to character controllers, triggers etc. Below is a list of the components that make up the little girl shown in the screen shot above.

Not only is this an elegant way to organize data in our editor (good for us humans), but this is also very efficient for our game at run-time. By storing our data components in common sets, as opposed to an object oriented approach, we can reduce cache latency and thus lose fewer CPU cycles. That way we can use valuable time for things that matter (gameplay, graphics, gibs).

With it's wide variety of features and tools, as well as easy portability to multiple platforms it's a wonder that more people are not using this engine. My team and I are very excited to make our next game using this tool, and are looking forward to seeing what we can produce.

Lighting and Shaders Episode 1: Game Mockup

Another year, another school semester. And with that comes some new knowledge. This week I started learning about shaders, and how I can use them to make my games look nice. Shaders are small programs that run on a computer's GPU which augment or enhance the visual assets of a game. They are responsible for displaying (drawing) the game and can be used to achieve effects such as lighting, shadows, ambient occlusion, bloom, HDR etc. Finally (and most importantly) they do all of this at lightning speed.

Before I get down to the nitty gritty to start implementing this in my games, I've started with a few mockup designs for the effects I hope to achieve with shaders. The game I'll be working with is my team's current 3D prototype project "GTFO: The Double Dungeon Debacle". Below are some mockups I did in photoshop to simulate the look we're going for.

First let's have a look at our source image:

Nothing too exciting here... No lighting, flat shading, ugly particles, weak selection circle

Here's the first edit:

Changes:

- Added a radial light to the player
- Added cartoon cel shaded effect to the characters (painted on manually)
- Added a new fireball sprite with trailing particles, made a nicer selection circle
- Added dynamic shadows to characters
- UPDATE: Adjusted brightness and contrast

Second Edit: (My personal favourite)

- Started with first edit
- Added a bloom effect (using diffuse glow in photoshop)
- Increased saturation slightly to compensate for diffuse glow effect
- UPDATE: Adjusted brightness and contrast

Third Edit:

- Started with second edit
- Added a subtle film grain effect (would be optional or used in cutscenes)
- UPDATE: Adjusted brightness and contrast

Overall I think these mock-ups are a significant improvement to the look of the game and will be going forward with these visual goals in mind. Feel free to comment with any feedback.

Farm Phresh: A Non-digital Edutainment Game

Mmmm, antioxidants...
Image URL: http://images.mudfooted.com/fruit-and-vegetables.jpg

Where do you buy your fresh produce? Do you get it from the grocery store, or do you hit up the local farmer's market? How do you know what foods to choose for this week and the next? This week's non-digital game task was to create a fun experience which would teach local residents when specific fruits and vegetables are in season. How exactly does one make a game based on the availability of produce? For hours, we asked ourselves this very question. After intently studying Ontario's food availability guide we decided to divide the months up  into their respective seasons, and distribute the produce accordingly. 

Our game board. The 4 seasons are represented by the quadrants of the image, and the years by the numbers.

We created 4 decks of produce cards corresponding to each season. It was then decided that the game would take place over the span of 5 "years", with players collecting seasonal, and all season produce (seasonal produce being worth more money than all season). In the interest of adding depth and player interaction, we added the ability to trade produce, and gave players the option of purchasing farms. When a player owns a farm that produces a certain fruit or vegetable, they are able to profit from the goods of other players. This and the rest of the game's quirks are explained in the rules section below.

RULES:

------------------------------------------------------------------------------------------------------------

Players: 4 or more

Dominate the market in this all-out battle for farm produce domination! Compete to win the most money by growing and selling a variety of fruits and vegetables - or even trading for what you think could be the produce that rockets you to the top!

Set-up:

- Each Season Deck must be shuffled separately and placed next to their respective Season on the board.

- Each player receives $25 (each money piece is worth $5).

- The spinner is then set to “Spring.”

- Players can decide who goes first however they please.

Play:

At the start of a players turn, the player has the option to purchase a Farm Card by flipping over a Farm Card – your first purchase costs $10 and each subsequent purchase costs $5 more (2nd is $15, 3rd is $20, etc.)

Players may also trade any Farm or Produce cards with other players before beginning their turn.

The player then flips over a card from the current Season.

The player collects the money the card states – the rarer the card, the more money its worth. PLAYERS KEEP THE PRODUCE CARDS.

If another player has a Farm that produces the turned over card, the player who flipped the card must pay the Farm owner half of what they would’ve received.

After one whole round (e.g., when the first player begins their next turn), the Season changes to the next one in a clock-wise fashion.

After all four seasons have been played through, a new year begins.

Play ends after the end of the 5th year.

Players tally up all their Produce Card values and whoever has the highest value wins.

Players must also consider the End-Game Bonuses before confirming who wins:

o   Most Vegetables: $20

o   Most Fruit: $20

o   Rock a P (2 Peaches, Pears and Plums): $25

o   Garden Salad (1 Lettuce, 1 Carrot, 1 Cucumber, 1 Onion, 1 Mushroom and 1 Tomato): $35

------------------------------------------------------------------------------------------------------------

Afterthoughts:

While a game about produce isn't exactly the most compelling thing I've ever played, the resource management and acquisition based game-play makes for an almost monopoly like experience. The best edutainment games are the ones that make you forget you're supposed to be learning something, and I think we've accomplished just that.

Starry Nightmare: A non-digital "Art Game"

This week in game design class, we learned about a relatively new trend in the game industry known as "Art Games". At it's core, an art game is an interactive experience in which the player's main goal is not necessarily to win (or not to lose). Although this is a very broad description for a type of game which is not yet formally defined, I think the main point of an art game is to give each user a unique emotional experience which is often open to interpretation.

As you may have guessed, I was then tasked with creating a non-digital Art game. The constraint was that this game needed to be somehow based on Van Gogh's Starry Night painting.

How do you go about turning a painting into a game?

First my group and I examined the painting, read analyses and critique's of the work, and formulated a list of feelings and emotions invoked by the image. The general consensus was that we felt cold, alone, and melancholy.

As a stepping stone to creating our non digital art game, we were also asked to each draw a parallel between this work of art (and the feelings associated with it) and a moment in a video game we had previously played. For me, this moment happened in Chrono Trigger (my favourite JRPG of all time). At about 3/4's of the way through the game, players are presented with Magus, a boss who's intentions are seemingly unknown. You can either kill Magus, or persuade him to join your party. If you do choose to kill him, the game immediately hits you right in the "feel bads". Maybe it's the dark surrounding atmosphere of the battle, or the cutscene that follows... One thing is for sure, this song gets me every time. http://www.youtube.com/watch?v=aQx9QaAxhk8

Anyway, back to the game... The board turned out like this:

The game's premise is a walk through one's own psyche in a nightmare. Players each are given a unique experience as they are asked to share key memories with the game, which will affect the outcome of the game. As you may have guessed, this is a single player game.

Here's a rundown of the rules:

------------------------------------------------------------------------------------------------------------

Materials required:-

• Dice

• 20 tiled circular board

• 16 “memory-fragment” cards

• 4 blank “key-memory” cards

• Writing utensils for the “key-frame” cards

Rules:-

• The player must write down four personal “key-memories” on the empty cards and then shuffle the four cards with the rest of the “memory-fragment” cards.

• The cards are then placed face down individually on the tiles.

• The player then rolls the die and then moves the according number of tiles on the board

• Any memory cards on a tile that the player lands on are to be flipped and read. The player must then “relive” that memory in their heads. The respective card is then removed from the game and the tile it was on is considered “empty”

• If a player lands on an empty tile, he/she must advance to the next “non-empty” tile. 

• The game ends either when there are no more “key-memory” cards on the board but there remains at least one “memory-fragment” card or when there are no more “memory-fragment” cards but at least one “key-memory” card. In the first case the player “loses” and slips into insanity and in the latter, the player gets to leave with his/her mind intact.

------------------------------------------------------------------------------------------------------------

After thoughts:

This game didn't turn out to be particularly fun, per se. The aspect that I'm most happy with is that every player is given a personalized, unique experience.

Breaking Liar's Dice: Positive Feedback loops and their Importance

Like this, but less fun.

Image http://boardgames.about.com/od/dicegames/tp/dice-games.htm

This week in game design class, the name of the game was Liar's dice. The task was to make modifications to the game such that it's positive feedback loop is removed. 

What is a positive feedback loop?

A positive feedback loop is a continuous cycle of challenge and reward which allows a player to progress towards a goal, or win condition. In the case of Liar's dice, the positive feedback loop (or at least one of them) is the successful calling of someone's bluff. When this happens, the player who lied loses a die and is one step closer to losing. 

What did this do to the game?

To be perfectly honest, this made the game completely un-fun. Not only are positive feedback loops necessary to maintain good pacing in a game, but they are essential for rewarding players and providing dynamic game-play. With the modifications made by my group, the games took forever to finish and became uneventful, chores to complete.

Here's a rundown of the rules updated with our changes:

------------------------------------------------------------------------------------------------------------

The game is made for 2 or more players.  Suggested ages 12+

Each player has a cup and 5 dice (the cup can easily be replaced by using your hands). Players will roll the dice in the cups and hide what they rolled from the other players. The first player will make a guess about how many of a die facing there are. i.e. 3 fours or 2 fives. 

The next player will have 3 decisions to make: 

LYING: They can call their bluff by saying they are lying meaning there are less of the number that they guessed then there are between the players. i.e. if they say 4 twos and there are 3 or less between all the players then they are lying. If they are wrong and there are more or equal to the number they guessed they lose a die. i.e. if there are 6 twos.

CORRECT: The player can instead decide that the player is spot on meaning if there are exactly the number they guessed then every other player loses a die. i.e. if they said 4 twos and there are exactly 4 twos between all players they are correct. If there are not exactly as many as they guessed then they lose a die instead.

GUESS: The player can make their own guess if they think the player is correct but not exactly correct. When they make their guess their number of faces must be higher than the previous guess. i.e. if the player before them guessed 3 sixes then they must guess 4 or more of any facing such as 4 fives.

After one of the players choose lying or correct then the players reveal their rolls and determine if the player is right or wrong in their accusation. After that is decided the players roll again and the game continues with the next person starting the round off. After all but one player loses all of their dice then the game ends with the person with dice being the winner.

MODIFICATIONS

1. Players start off with 5 life counters. When a player would normally lose a die they instead lose a life counter.

2. If a player improperly calls a bluff, they lose a life counter

3. If a player correctly calls a bluff he cannot look at his hand for the next turn.

4. Each player is given a penny.  At any time when it is their turn, they can choose to trade in their penny to make the leading player show their dice to the rest of the table.

5. Once per game, you can make a winning player unable to look at their hand on the next turn. (trade in their penny)

My Rule: If a player improperly calls a bluff, they lose a life counter

How this affects the positive feedback loop: This adds a bigger risk to attempting to call someone’s bluff. This puts the risk/reward less in favour of impulsively calling bluffs, and more in favour of playing safe.

Predictions: Players would play more patiently and safely, rather than choosing to call a liar every turn.

Actual Outcome: This rule in combination with rule #3 made players rarely call bluffs unless they were guaranteed. This made games take extremely long.

\---------------------------------------------------------------------------------------------------------------

The lesson? Positive feedback loops are a good thing (We probably didn't need to ruin liar's dice to figure that out).

Fighting Game Psychology 101: Button Mashing

Because cats.

Alright, let me start off with an important statement. Button mashing is not OK. Sure, it can be fun to sit back and watch your character flail around with varied degrees of success. Unfortunately, mindless button mashing results in random, mindless gameplay and an overall passive experience.

Allow me to elaborate.

In a fighting game, every attack a character possesses is a tool appropriate for a certain given situation. Let's look at Ryu (everyone's favourite protagonist) as an example.

Ryu has 3 basic special moves in pretty much every version of Street Fighter. They are:

Hadouken: A projectile attack used to threaten foes from a distance and pressure them to jump, leaving them open to an anti-air attack.

Shoryuken: A very fast rising uppercut with invincible startup. This move is great for anti-air and cutting through an opponent's pressure. However this move has a long recovery time when blocked or dodged, leaving Ryu wide open for punishment after a poorly calculated shoryuken.

Tatsumaki-Senpuu-Kyaku (Hurricane kick): A horizontal moving spin kick, which travels through certain projectiles.

Ryu also has around 20 normal moves, each with their own appropriate uses, but for simplicity's sake I won't go into detail about these.

A good Ryu player will always know when and where to execute each attack. They throw fireballs at safe ranges, anti-air accordingly, and use the correct normal moves at their ideal distances. A player who mashes will execute a random attack, at a random time, in a random place. Not only is this experience not fulfilling for the button masher, but it is equally useless for his opponent. In a fighting game, being able to read your opponents moves and tendencies is paramount. However, if your opponent's actions are unconscious, it becomes virtually impossible to read them. If you don't know what move you're going to do, how the hell should I?

When players choose to mash instead of making conscious decisions, they are choosing to ignore all aspects (timing, spacing, risk/reward) of the meta game.

And you know what, if that's fun for you then I guess that's ok. But against any half decent player, you're going to get bopped. That being said, fighting games are certainly not for everyone. The execution barrier can  often be an obstacle that prevents new players from understanding and enjoying a game. But we'll talk about that at a later date.

TLDR: If you want to be good at fighting games (or any games for that matter) stop mashing.

From Atari to Cardstock: Lunar Lander

Image taken from http://ataricade.videoarcade.it/lunarlanderscr.jpg

This week's non-digital game task was to create a game based off an Atari classic. Being a child of the 90's, I had very little hands on time with the Atari, and neither had my team mates. After the group of us tested a handful of Atari games, we came to the conclusion that Lunar Lander would translate well to a turn based environment. Here's a quick description of what the game is all about in case you weren't already aware.

In Lunar Lander, the player's goal is the land their ship right-side up on the moon. Preferably on a spot containing a large score multiplier. In order to control the landing, the player must operate their 3 thrusters (left, right, centre) and guide the lander to the surface with the proper orientation and approach angle. If the player runs out of fuel, they lose control of the ship and must accept whatever fate awaits.

Since the game is traditionally single player, we decided to keep player interaction to a minimum. In our version of the game, players compete to construct ships to collect ore from the moon (note: The ore is irrelevant to the game itself and serves solely as backstory). Once each player constructs their ship, the goal is to land it with the highest degree of difficulty allowed by their fuel cost (increased by upgrading your ship). Players can sacrifice their turn to trade ship parts with others. If this sounded confusing, good. It's supposed to. Have a look at the rules, that should clear things right up.

Rules:

------------------------------------------------------------------------------------------------------------

Players: 2-4 people

Set-up: Place the cards in two separate piles: one for Ship Parts and one for Landing Difficulty. Shuffle the decks and deal out 5 Ship Parts to each player. Each player may play one part at the count of three (e.g. Player 1 counts to three and on three, each player shows their card). Players then decide who will play first in whichever fashion they wish.

Instructions: Players try to build ships to collect ore off of the Moon while using the least amount of fuel. This is done by completing a whole ship (Hull, Thruster, Left Wing, and Right Wing). Each part generates a different amount of fuel, with higher ranked cards generating more. Each player picks up a ship part card at the beginning of their turn OR starts a trade with another player. When trading, the trader (person initiating the trade) shows the card they wish to trade. Any player may then call for the trade, with who says they want it first getting it. Players may trade as many parts as they want for the offered part. The trade may also be cancelled at any point, provided the trader hasn’t already accepted the deal. If the trade is made, that player’s turn is done. If no one takes the trade, then play resumes as normal. They may then play one card from their hand towards their ship. There is no max to the number of cards a player may hold.

Once a ship is built, the ship goes into pre-launch mode, meaning that the ship can only launch on any turn after it is built. Players may continue to modify their ship at this point, but doing so delays launching the ship for another turn. When a player wishes to launch, they must pick up a Landing Difficulty card. The Landing Difficulty card multiplies your fuel into points, which are only tallied if the player lands successfully. Players land successfully if their total fuel amount for the ship is more than the amount on the Landing Difficulty card. Harder landings require more fuel, e.g. landing for a 4x costs 200 or more while landing for a 2x costs 100 or more. Players calculate their fuel cost by adding all the points on each of their ship parts. The different fuel gained by each ship part is as follows:

Rank A: 70     

Rank B: 60

Rank C: 50

Rank D: 40 

If a player lands successfully, they then subtract the total for landing from their fuel cost. They then multiply that remainder by the respective multiplier on the Landing Difficulty card and tally their points, e.g. if Player 2 has a fuel cost of 300 and the landing costs 200 for a 4x multiplier, Player 2 gets 400 points (100 times 4). If a player does not have the necessary amount of fuel points, then the player only gets 10% of their fuel amount, e.g. if Player 3 has 200 points and his landing costs 300, Player 3 gets 20 points. After a landing (whether successful or a crash) the player returns all the cards used for the ship to the Ship Parts pile. The player then tallies their points. The first player to 2000 points wins.

------------------------------------------------------------------------------------------------------------

Things I liked:

Overall I'm pretty satisfied with how the game was translated. The game still feels competitive, while maintaining the isolated single player-esque  experience you would expect from lunar lander. This is reminiscent of competing for high scores against other players back in the day.

Things I didn't:

I honestly wish we were not forced to choose from a finite list of Atari games. I had not played any of the options before making this game, and would have chosen Pitfall hands down if I were given the choice

Sons of Noah: A Biblical Collection Game

This week's mandatory non-digital game assignment was to create a collection game of some sort. This means the objective of the game must be to collect a certain amount of items in order to win. After spending many hours volunteering at a nearby cat shelter, my group mate Divakar Dev threw out the idea of rescuing animals. I then took this idea a step further and suggested we make the game about Noah's arc.

The thought process behind this wonderful game:

Before

Image taken from www.allpetnews.com

After

Screencap from Super Noah's Arc 3D

Yeah, that's pretty much how it happened.

After realising that only one player could be Noah, we decided to have each of the players take the role of one of his sons (Shem, Ham, Japeth, and Bill (who is both fictional, and adopted for the sake of 4 player functionality)). Each son of Noah is in a race to round up 5 pairs of animals in order to win their father's love and respect. The first player to collect 5 pairs of animals is the victor.

Here's how the board came together:

Each coloured square represents an ecosystem, each housing a specific group of animals. (These colours are not final and will match those of the cards below)

Here's a close-up of one of the ecosystems. On the full-size board, these are all inter-twined as seen above.

The Animal Cards: (Fun fact: We almost had unique male and female animal cards, but we figured the game might take too long to win among other issues. As a result, animal cards contain no gender.)

RULES:
----------------------------------------------------------------------------------------------------------------------------

Players: 2-4

Set-up: Players shuffle the animal cards and put each pile into its respective zone. Players then roll for highest to see who goes first. 

Play: Players take turns going around the board to the different zones while trying to collect matching pairs of animals. Movement is made by rolling the die. Players must collect 5 pairs of animals before they can take off in their ship and escape the end of the world. Players must land on an animal space in order to pick up a card from that zone’s pile. If a player lands on a space with words, players must follow whatever is written on the space.

Before a player takes a turn, they have the option to attempt to trade animals with another player. There is no ratio on trading animals, i.e. a player can attempt to trade 3 animals for only 1 from another player. A player can deny any trade without question. If a player’s trade is successful, that players turn ends. However, if the trade is denied, then the player may roll and continue their turn as normal.

----------------------------------------------------------------------------------------------------------------------------

Things I like about the game:

Overall, the thing I like most about the game is it's premise. From the way it was conceptualized to the final product, there was no shortage of lulz.

Things that could have been better:

If I could, I would add a more competitive, head-to-head element to the game. I think the game would be significantly more entertaining, if Noah's sons could have ship battles, and maybe even kidnap each-other's animals. After all, Noah is a hard man to please, and these sons will do whatever it takes to be guaranteed safety from the great flood.

=)

Sense and Sensibility: The card game (Hey at least it's not another board game)

This week, I was once again tasked with making a non-digital game. This time the constraint was that the game had to be somehow based off of a Jane Austen novel. Now, I admit I have never read a Jane Austen novel (nor do I plan to). After staring at the wikipedia pages of several Jane Austen novels, my group and I decided Sense and Sensibility would be the least terrible to make a game out of. Here's what we came up with.

Sense and Sensibility: The Card Game is essentially a dating sim in which players compete to woo a significant other. Players accumulate traits (good and bad) and assets/liabilities to modify their love and money scores respectively. The player's goal is to accumulate enough love or money to woo their suitor. Players can also use action cards to influence the love and money scores of other players and themselves.

Here's a run-down of the rules:

Players: 2 – 5

Setup:

·         Players shuffle the Greed, Love, Trait, Asset/Liabilities and Action cards into their respective piles.

·         The Action cards are split in half and each half is put into the Greed and Love cards.

·         Each player draws 3 trait and 2 Asset/Liabilities cards. They are then placed face-up in front of them.

·         A die is then rolled to see who goes first.

NOTE: Traits and Asset/Liabilities modify how many points you get from either Greed or Love cards – be it an increase or decrease boost. Read the card to see how your points are affected.

Play:

·         Players draw a card from the either the Greed or Love pile and place it face-up in front of them at the beginning of the turn.

·          There are three kinds of possible cards: Love cards, Greed cards and Action cards. Action cards are mixed into both piles.

·         Players collect the points on the card they draw, unless it’s an action card. Action cards are activated immediately on drawing and are played towards another player.

·         Once a player has accumulated enough Love points (15) OR enough Greed points (10), they can go for a chance to woo their suitor.

·         The die is rolled to see if the woo is successful. If a player is going for the Love win, they must roll a 3 or higher.  If the player is going for a Greed win, they need to roll a 5 or higher.

·         If a players woo is unsuccessful, that player loses half the points in the mode they chose to woo with.

·         Play continues until a player successfully woos their suitor and wins their heart.

A few card Examples:

What I would change:

- Obviously, Jane Austen novels are not something I'm interested in or knowledgeable in. If I could base this game around an entirely different premise, I would. However I understand the reason for this constraint on the assignment and that this point may not be the most valid.

- As it is right now, you can win the game with either love or money. If possible I would make a win condition which allows for combinations of both.

- If I could do it again, I would make specific characters as love interests, each with their own preferences and criteria for affection. This would effectively solve the second issue I mentioned (mixed win condition).

H.A.C.K.E.R.S: The Movie: The Game (Yet another board game, made in slightly more time.)

This week, I was tasked with making another board game. This time in a group setting, and instead of a race to the end game, the assignment was to make a territorial acquisition game. My group and I came up with H.A.C.K.E.R.S, which stands for: Having All Computer Kernels Every Real-time Second. The goal of the game is to acquire (by hacking) the largest number of computer nodes on the game board, after a set number of turns. The game plays similarly to risk, but with subtle differences in the flow of resources (bits).

Here are the game's rules:

RULEBOOK EXERPT:
-----------------------------------------------------------------------------------------------------------------------------

H.A.C.K.E.R.S.: Having All Computer Kernels Every Realtime Second

Players: 2-4 players

H.A.C.K.E.R.S. is all about the war for the Cloud. Control the Cloud, control the internet. Join a Faction and out hack the enemies to control the Cloud and get one step closer to world domination! 

Set-up: Each player chooses a Faction to represent in the war by choosing a colour of bead. Factions then roll to see who goes first or play Rock, Paper, Scissors. Players chose a starting node based on turn order. Each node is assigned 10 bits of power. Players then decide how many turns the game will run for. At the end of the last turn, the player with the most nodes wins.

Play: Each node runs on bits. Players accumulate bits at the beginning of each turn. Players amass bits based at a flat rate of 5 with a boost based on how many nodes they own, according to the following chart:

• ·         3 nodes = +2
• ·         6 nodes = +4
• ·         9 nodes = +5
• ·         12 nodes = +7

After capturing 12 nodes, you gain +1 for every 2 more captured nodes. The collected bits are then distributed to each node based on the players choosing. Nodes are indicated by placing the small blue beads on the node you control.

There are 3 phases per turn: Transfer, Boost and Hack. During the Transfer phase, players can transfer power to any nodes that they are connected to. When a bit is sent, it is subtracted from the current total as well, (e.g. if node A has 12 bits and sends 4, node A will have 8 bits after). Players may only transfer bits once per turn. Nodes can only hold 30 bits max. 

In the Boost phase, players may sacrifice bits to set up Firewalls. Firewalls make you harder to hack during the Hacking phase and disappear on your next turn. To indicate a Firewall has been placed, select a bead colour for “Firewalls” and place it on your node. Firewalls are powered up based on the following:

• ·         Firewall Lvl 1 (costs 5 bits): protects you from 2 bits of damage
• ·         Firewall Lvl 2 (costs 7 bits): protects you from 3 bits of damage
• ·         Firewall Lvl 3 (costs 9 bits): protects you from 4 bits of damage
• ·         Firewall Lvl 4 (costs 12 bits): protects you from 5 bits of damage

During the Hacking phase, players may sacrifice bits to attack other players. When sacrificing, players must leave at least 10 bits in the node to sustain their capture of it. Players may only attack once. To attack, players select any node they are connected to. Players may then attack that node with any other nodes they own that are connected to it. The defender then decides how many bits to use to defend. If the defender uses more bits than the attacker, the difference is dealt in damage to the attacker; e.g. if the attacker sends out 10 and the defender defends with 15, the attacker loses 5 bits on their node(s).

 -----------------------------------------------------------------------------------------------------------------------------

Things I liked about how the game turned out:

Overall I am most pleased with how the game's premise ties in with the game-play. The concept of an cyberspace hacking war feels fresh and very appropriate for a territorial acquisition game. I also find the game's system to be very strategically sound and rich in the variety of plays.

Things that I would change:

Firewalls are currently useless as they result in a net loss of bits. In all scenarios, a player is better off keeping their bits and playing them in a standard offensive or defensive play. Also, the game board was printed with a lack of Yellow ink. The real version happens to be even uglier than the one shown above.

Fight to the Finish: A board game made in 1 hour

This week in game design class, I was tasked with making a prototype for a "race to the end" board game with a unique theme. Due to my fixation with fighting games, I made a board game themed around combat. Here's what I ended up with.

Rules: Players must roll a (6 sided) die to advance on the game board. The number a player rolls corresponds to the amount of squares they may move. If a player lands on a red square, they are thrown into the ring where they must wait for an opponent. Once there are two players in the ring, a battle will commence.

Battle Rules: Before the battle can begin, the players must both roll a die to determine who is attacking and who is defending. The player who rolls the highest number is the attacker. Once the battle has started, both players count down (3, 2, 1, Fight!), then reveal their Actions at the same time. Each player has 3 hit points, and the battle ends when either player’s hit points reach 0. 

Attacking Actions:

-          Physical Attack:

o   Beats: Throw Reversal (Scoring a hit)

o   Loses to: Guard (negates attack, no damage taken), Evade (avoids attack, defender becomes attacker)

-          Throw:

o   Beats: Guard (Scoring a hit), Evade (Scoring a hit)

o   Loses to: Throw Reversal (Defender Scores a hit)

Defensive Actions:

-          Throw Reversal

o   Beats: Throw (Scoring a hit)

o   Loses to: Physical Attack (Attacker scores a hit)

-          Guard

o   Beats: Physical Attack (Attack/Defense roles do not change)

o   Loses to: Throw (Attacker scores a hit)

-          Evade

o   Beats: Physical Attack (Attack/Defense roles are switched)

o   Loses to: Throw (Attacker scores a hit)

Once the battle is over, the winner returns to their place on the game board, rolls the die and continues to advance. If the winner scores a perfect (winning without losing any hit points), they are awarded a buff card from the top of the pile. The loser must stay in the ring and fight until they can defeat another player.

Buff Cards:

-          Spiked Knuckle (Physical Attacks do 2 hits of damage), Physical Obstacles can be broken immediately

-          Kung Fu Grip (Throws do 2 hits of damage), Throw Obstacles can be moved immediately

Obstacles:

If the player lands on an obstacle, they must wait 3 turns before it is cleared (assuming they have no buff cards). If the player has a buff card, they can choose to use it to bypass the appropriate obstacle. If the player uses the card on an obstacle, the card is forfeit and can no longer be used in battle.

Things that suck and need fixing:

- Evade is always a better choice than Guard, making guard essentially useless. Originally I was going to limit the amount of times a player could use a certain attack or defensive action, however this was problematic as there are two options for attack and 3 for defense. If there were some other sort of limit to how often a move is used, guard could potentially become useful.

- The game can be very random. In one playtest, a friend of mine was able to traverse the whole game board without fighting. This was totally not cool.

- The prototype board is ugly, boring and way too small. That's probably because I made it in a half hour.