Going on a break!

Thank you all for reading and watching my Swords, Shields, & Sorcery project unfold. Due to a wonderful new employment opportunity, I need to put development on hold for the foreseeable future.

Perhaps someday I can resume and kick this game off into retail space, but for now, I bid you all adieu!

Swords, Shields, & Sorcery | Tutorial Design - Teaching Through Gameplay

If you are unfamiliar with the wonderful training level that is World 1-1 from Super Mario Bros, I highly recommend reading over this dissection of it, or finding one of the many other design breakdowns for it available on the internet. In short, almost every single piece of World 1-1 is there to teach the player how to play Super Mario Bros without ever having to say anything. The best part of it is, the player doesn't even know they are learning!

Teaching through intuitive game design is something I have always dreamed about doing for my own projects. These days, I think a little text is unavoidable, but I am still obsessed with figuring out how to make learning to play my game an engaging experience. The following article covers a breakdown of the engaging tutorialization I plan on working with for Swords, Shields, & Sorcery.

Objectives:

• Teach players map and combat mechanics
• Get playing the game ASAP
• Get them personally invested in story progression

Story Introduction:

The adventure will start with a simple letter from your uncle, asking you to look after his cabin while he is in the capitol on 'important' business. He has left you the Cabin Key, and mentioned that he has hidden a great discovery in his house, which needs to be safeguarded.

After reading the short letter, the game will cut to the player character standing at a dock with a large pack of goods as a ferry pulls away. The player character will tuck the letter away, take a look at the key, then put that away as well. This establishes that the player has travelled, they only have the goods in their pack, and it also sets the initial goal for the game.

After this short intro, the player will be given full control of the game. No pop-ups telling players what each button does, no extended text from an NPC explaining the situation. Just a short snippet, a few quick animations, and away we go!

Story Screen and Map Navigation Introduction:

The Story Screen for the Docks that the player starts on will now have a single right arrow button displayed. This is a common button for most Story Events in the game. Tapping this will cause the player to walk right, and move to the next section of the screen (which for this event, is off screen). The game will then transition to the World Map.

The Map Screen clearly shows all important destinations: the Dock, the Cabin, a Settlement, and a Forest around a mountain. The player will also be introduced to map movement with the map node system. The first two nodes will be visible: the Dock node, and the next node on the only path towards the Forest, Settlement and Cabin. By tapping on the only available Path Node on screen, the player will travel to the node, and reveal the next node along the path.

After two Path Nodes, the player should have an understanding of how the map functions. The next node along the path is a mandatory Combat Event Node. After traveling to it, the player will be transitioned to another Story Screen, this time, one that leads to combat.

Combat Introduction:

On the Story Screen for the combat intro, the player will be shown the right arrow button again, which can be touched to move forward. This time, the player is tripped up by a band of speedy little Sprigands that quickly gather the player's fallen belongings (including the Cabin Key). Most of the Sprigands run away, but a few bumble around, fixated on their stolen goods.

I like this moment for several reasons:

1. The player has been robbed, and that should make them angry. Wonderful! That means the player now cares about what happened in the game and they will probably want to serve justice to the thieving little Sprigands.
2. With the Cabin Key gone, the player's curiosity for the secret in the cabin might switch to panic. With the key gone, and you can't discover the secret OR protect it until you retrieve it back.
3. This is a perfect opportunity to kick off combat! The player has been wronged, and now has a purpose for beating up some mischievous forest creatures.

As the player character gets up from the dirt, they draw their weapons, and shout at a nearby Sprigand to give your things back. The Sprigand, holding onto a shield-like object, refuses, and combat begins!


Fight 1 - Shield Sprigand
Health: 2
Sword - Shield - Sorcery Power: 0 - 1 - 0
Sword - Shield - Sorcery Chance: 0% - 100% - 0%

Once combat starts, the player is given all three combat options: Sword, Shield, and Sorcery. The player may select any of these attacks, but the opposing Shield Sprigand will ONLY use the Shield attack. This means, that in order to defeat this enemy and move on, the player needs to use the counter for Shield attacks: Sorcery. If the player uses Shield, the round ends in a draw. If the player uses Sword, they lose and take 1 damage.


After beating the Sprigand and collecting the stolen item, the player will transition back to the World Map. The next node is revealed, and is another mandatory Combat Encounter Node. This one transitions directly into combat with two more Sprigands (one after the other). The first of which will only attack with Sword attacks, and the second only with Sorcery.


Fight 2 - Sword Sprigand
Health: 2
Sword - Shield - Sorcery Power: 1 - 0 - 0
Sword - Shield - Sorcery Chance: 100% - 0% - 0%

Fight 3 - Sorcery Sprigand
Health: 2
Sword - Shield - Sorcery Power: 0 - 0 - 1
Sword - Shield - Sorcery Chance: 0% - 0% - 100%

After defeating the three Sprigands, a tougher one will appear that uses Swords, Shields, AND Sorcery. This fight will act as a test, checking that the player's understanding of the combat mechanics, and providing a ramp-up to the rest of the enemies of the game that also use all three attack types.


Fight 4 - Sprigand Boss
Health: 3
Sword - Shield - Sorcery Power: 1 - 1 - 1
Sword - Shield - Sorcery Chance: 33% - 33% - 33%

The Sprigand Boss should be fairly easy to win, but still possible to lose. The player has quite a bit more health than the boss, but must still win 3 rounds total. Once defeated, the player will see the rest of the Sprigand gang flee into the nearby forest.


In Summary, these combat encounters should give the player a safe environment to see how the three combat options affect the outcome of battle. If everything works as intended, players will learn how the combat system works without ever having to be told!

Additional Considerations:

One thing I still need to design for is how to introduce players to the equipment mechanic, which does not necessarily need to be introduced until the player receives their first equipable item. One possible method might be to introduce the first item after the Shield Sprigand story fight, and require that the player equips it in order to complete the next fight (ie. Equip a shield in order to win against an enemy that uses Sword attacks exclusively).




© Scott Balmer - Game Design - 2014

Swords, Shields, & Sorcery | Map Prototype

I was originally going to post this last week in its very early stages, but decided to hold off to get some more interesting features in. Aside from just being able to move around, I now have a path reveal system implemented, and the framework for random encounters.

A special thanks to my good friend Gary Yau for helping with some of the map coding. I would be significantly more frustrated with C# and programming in general without his guidance.

Please note that all images are placeholder and will be updated with appropriate art in the future.




© Scott Balmer - Game Design - 2014

Swords, Shields, & Sorcery | Enemy Concept - Sprigand

I spent the last day creating a little thief creature for the first demo level and I am rather happy with how it turned out. Behold the Sprigand!

Get it? It's a little thief sprite. Spriggan + Brigand? Yeaaahhh, that's right.

They're small, fuzzy, and love to pilfer your goods. Sprigands are rumored 

to appear in areas where wild herbs grow in abundance.

Sprigand color tests

Sprigand concept sketches

© Scott Balmer - Game Design - 2014

Swords, Shields, & Sorcery | Character Concept Art - Round 2

Did you know that Sorcery isn't just for magic spells? It's also used for... Corgis?

© Scott Balmer - Game Design - 2014

Swords, Shields, & Sorcery | Character Concept Art - Round 1

I have been working on the character style concept for Swords, Shields, & Sorcery for a few weeks now, and finally have it close to where I want it. Sort of has a stumpy-puppety vibe.

Next steps include turning one of these characters into its sprite components and fitting it together for animating.

Enjoy!

© Scott Balmer - Game Design - 2014

Swords, Shields, & Sorcery | Test Animations

Test animations have been added to the previous combat prototype to help flesh out how the game will look as it is being played.

All images, animations and text are placeholder and will be updated with appropriate art for the future playable demo.


© Scott Balmer - Game Design - 2014

Impulse | Design Document and Concept Images from 2006

Today, I discovered a most exciting ancient artifact on my hard drive: the files for an old Design Document that I made while I was enrolled at the Art Institute of Vancouver (2006). I had a blast working on this project and remember it fondly. Looking back, I think that this was the first major step in realizing that game design, not game art, is my true calling.

I would like to present to you all, Impulse, a game concept that I designed exclusively for the Nintendo Wii:

Click here to view the full Game Design Document (PDF)

'I', the main protagonist of Impulse. As you can see, I have a penchant for blob creatures.

Concept:

The core idea behind Impulse is that the player controls both of the main character's plasma arms to interact with the game world. Using the Wii Remote and Nunchuk's accelerometers and gyrometers,  as well as the Wii console Sensor Bar, the player can mimic real life arm motions to grab, pull, throw and slash. The Rumble motor is used to replicate tension feedback when stretching too far, or trying to lift something heavy. Progress through the game unlocks various 'morphs' to the arms, including swords, cannons, wings and jet engines.

In hindsight, mimicking both arms would be a little difficult to realize due to the lack of sensor component in the Nunchuk. Alternatively two Wii Remotes in each hand could produce the desired result. Nevertheless, the idea of being about to virtually feel your way through a game is incredibly compelling to me.

Additional Images:

Along with finding the document itself, I also found a my old UI mock-ups and some concept art. I have added a selection of them below:

UI Mock-Up | Main Menu

UI Mock-Up | Character Creation (Multiplayer)

UI Mock-Up | Planet/Level Selection

Flow Chart | Boot Screen Flow

Enemy Sentient Beings | Gaulian, Polluxian

Planet Concepts

© Scott Balmer - Game Design - 2006 - 2014

Swords, Shields, & Sorcery | Story Delivery

Contents:

This article covers design details on the story delivery mechanics for my Swords, Shields, & Sorcery mobile game project.

1. Overview
2. Story Screen
3. Controls
4. Dialogue
5. Audio
6. Animations

1. Overview:

Goal: Create entertaining and immersive stories that blend seamlessly with the other game mechanics to help portray a whimsical, memorable, living world.

Story in Swords, Shields, & Sorcery is delivered to the player through combat, cinematic narrative and the implied narrative of the world visuals and locations. Cinematic narrative takes the form of scripted dialogue and animations that are displayed in the Combat Screen (called the Story Screen hereafter for Story Events).

2. Story Screen:

Story Events take place on the Story Screen. These Events can be triggered on the World Map and Location Maps via Event Nodes, as well as occasionally through Random Encounters.

When the player activates an Event Node, they will be taken to the Story Screen, where animations, dialogue and occasional context based buttons are available. During Story Events, Combat Controls and Combat UI are deactivated. If a Story Event transitions into combat, the Combat Controls and UI can be re-enabled.

3. Controls:

During Story Events, player controls will be predominantly used for cycling through the scripted character animations and dialogue.

3.1 - Story Event Controls:

• Tap (When a dialogue string is finished) - Continues to the next animation event or piece of dialogue.
• Tap & Hold - Increases the speed at which dialogue text is displayed.
• Tap Right Arrow - Transitions to the next section of the Story Screen. This button is only displayed when character movement is possible (eg. Moving between rooms of a house).
• Tap Left Arrow - Transitions to the previous part of the Story Screen. Generally used for leaving one-way Story Screens (eg. leaving a house).

Note: Depending on how involved the 'movement' mechanic becomes, it may be best to include an up and down arrow button.

3.2 - Combat Controls in Story Events:

Under specific situations, the normal combat controls may become available. These combat controls can be used for puzzle solving, opening treasure chests, and generally help provide extra immersion to Story Events.

When the player chooses a combat action, humerous dialogue and/or audio/visual feedback should play to inform the player of the outcome of their action. Not choosing the most logical option should not be overly penalizing to the player. Story Events with contextual combat can generally be repeated until the required outcome is reached.

Note: Depending on the complexity of Story Events in the future, branching paths can be used based on combat decisions (eg. Choose 1 of 3 doors to go through. Each door has a combat symbol above it to denote what action chooses which door).

4. Dialogue:

Character dialogue is displayed in a custom style of speech bubbles. Each letter of the dialogue string will appear on screen one after another at a set text speed, which can be sped up by tapping and holding.

Character dialogue should generally be short and snappy to prevent players from getting bored and skipping the dialogue out of habit. Players should WANT to read the dialogue.

Text size and Text color changes should also be utilized to help draw attention to important points, as well as providing an emphasis on character emotions.

Text animation can also be used for situations where someone might exclaim something loudly, or be shuddering in fear.

5. Audio:

Sound Effects will play a major role in Story Events. While Swords, Shields, & Sorcery will not have voice overs for dialogue, it will have mock-speech SFX that plays along side the dialogue. Golden Sun (GBA) is a good example of this psuedo-speech with dialogue.

Mock-speech SFX should have tunable pitch and frequency in order to fit the audio to the character In the event that this cannot be done in Unity, a variety of pre-made mock-speech audio files can be made.

Additional SFX support will be needed for character actions during the Story Events.

6. Animations:

Much like the Sound Effects, Animations will play an enormous role in bringing Story Events to life. Most characters in Story Events will be human-like, any pre-made human animations can be utilized. This will not allow for a reduction in the amount of custom animations, but will also provide a wider variety of animations to all human characters.

© Scott Balmer - Game Design - 2014

Swords, Shields, & Sorcery | Map Design

Contents:

This article covers some deeper design details on the Wold Map portion of my Swords, Shields, & Sorcery mobile game concept.

1. Objective
2. Map Layout
3. Nodes
4. Exploration
5. Combat Encounters
6. Art
7. Audio
8. Tunables

1. Objective:

Create a field map that has simple controls, can be explored, and is immediately accessibly even after picking up the game after a long break.

2. Map Layout:

There will be two main types of maps used throughout the game. The World Map, which is the main game hub, and Location Maps, which represent subsets of the World Map. Both map types have the same controls and effectively function the same.

The World Map will have a smaller number of Path Nodes in order to make it quicker to move from place to place. Some locations on the World Map cannot be accessed until certain requirements are met, such as clearing an area or completing a story objective.

Location Maps are more elaborate than the World Map, and contain many more nodes. Locations are effectively the 'levels' of Swords, Shields, & Sorcery. Most Location Maps can be accessed via the World Map, but others are nested in other Location Maps, and sometimes even placed in Settlements.

Note: It may be more conducive to a pick-up and play to allow a quick escape option to take players directly back to the World Map.

3. Nodes:

Nodes are spots on a Map that players can travel between. This is done by tapping on a Node. The player will then travel directly to that node.

Non-Path Nodes can be 'accessed' by tapping the Node again once arriving on it. Nodes are also color coded, to provide easy ways of distinguishing their type. If the Node the player is currently on is accessible, the Node will visually glow to coax players into tapping it.

3.1 - Different types of Nodes:

• Path Node
• Location Entrance/Exit Nodes
• Mandatory Encounter Nodes
• Secret Nodes (not displayed)
• Event Nodes (Story, puzzles, treasure, etc)
• Location Nodes (typically found on the World Map)
• Settlement Nodes (typically found on the World Map)

In the event of a distant node being selected, the player character will travel the shortest distance possible to get to that location. When travelling to a far node, there is a chance for a random encounter to trigger. If this should happen, when the player returns to the map, they will remain on the node the encounter took place on until further input is received.

When a Node is tapped in the middle of transit, error VFX and SFX should play to display that actions cannot be completed in transit.

Note: While I want players to have a sense of exploration, I want to shy away from providing too much freedom. This is the reason I did not design an open world map using point-and-click controls. As a player myself, I tend to examine every nook and cranny in open world games, and that often eats up a lot of time with little to show for it. I want to provide a way to explore, but still keep the main goal in focus. I believe this will be especially important for people who may only play for short periods of time.

4. Exploration:

As outlined above, players should be offered a sense of exploration as they traverse a Location Map. This will be done in several ways.


4.1 - Map Reveal:
When the player first arrives on a map, they are likely to only see two Path Nodes: The node they entered the map on, and the next node on the path. Each time the player moves to a new node, the nodes connected to it are revealed. Once a node has been revealed, it will remain revealed.

Note: This Map Reveal/Node mechanic provides the opportunity to make randomly generated maps, rather than hand crafting each one. This option is not required and can be explored in the future should we choose to.


4.2 - Treasure:
Some Path Nodes will sparkle when near or on them. These are Treasure Nodes. No random encounters can occur when moving to this node type. When accessed, Treasure Nodes will transition to the combat screen, but display a treasure chest in place of an enemy. Striking a treasure chest with a Sword attack will open it, and reveal its loot.

BEWARE! Some treasure chests are actually mimic creatures that only look like treasure chests. Attacking them with a Sword attack will cause it to attack. Careful players can use their Sorcery attack to check to see if a treasure chest is a mimic or not before attempting to open it.


4.3 - Event Nodes:
These Nodes are usually denoted by having unique landmarks near the place of the node in addition to their specific color coding. Accessing an event node will usually transition to the combat screen, but some will not require any combat or button input. Event Nodes can be anything from narrative, to puzzles, to stores, but are most often used to push story along.

Note: The inclusion of puzzles is not necessary to the core of the game and may be cut in the future.


4.4 - Secrets:

Many secrets lie in wait for players to discover! Secret nodes generally remain hidden and inaccessible on Maps until specific conditions are met. Secret areas can reveal all sorts of new nodes to the map, and can be uncovered in many different ways. Some different ways secrets can be revealed include:

• Exploring all non-secret nodes on a map.
• Completing all Mandatory Encounters on a map.
• Collecting specific items.
• Defeating a certain number of enemies.
• Activating specific Puzzle/Event objectives at Event Nodes.
• eg. Using Fire-based Sorcery attacks to light torches at 4 different Event Nodes in order to summon something at a secret altar.

Note: Secret areas should generally appear as distinct landmarks on a map, with the exception of having no nodes leading to them. This should help players understand that there may be something there to discover.

Note: Maps that contain Puzzle/Event nodes that require specific types of attacks to be executed must include a way to obtain that type of attack within said map.

5. Combat Encounters:

Enemy encounters generally occur in two ways: a random enemy encounter, or a mandatory encounter specifically placed on a node. Entering an encounter will transition the player to the combat screen.

5.1 - Random Encounters:

• Random chance for an encounter to trigger each time the player lands on a Path Node.
• A single enemy is selected randomly from a pre-set pool of enemies (the pool changes per location).
• Random encounters can be lost or run from with no penalty.
• Enemies from a random encounter are typically less powerful than mandatory encounters.

5.2 - Mandatory Encounters:

• Pre-determined fights with a specific enemy at a specific location.
• Mandatory fights are generally more difficult than their random counterparts.
• Players will be visually informed of what creature they will be fighting before they enter the encounter.
• Victory is required in order to continue past an Encounter Node.
• Running away or losing a Mandatory Encounter will result in a small penalty (eg. currency reduction).
• These encounters usually result in better rewards than Random Encounter enemies.

6. Art:

Maps should visually show off a high-level view of the world of Swords, Shields, & Sorcery. The World Map, being the highest-level view, then Location Maps, then the combat screen. In addition to general Node art, maps will need to have the following:

• Backdrop
• Custom Location/Landmark icons
• Set dressing sprites (such as trees, fences, bridges, rivers)
• Ambient VFX (such as birds flying in the distance)

7. Audio:

Each Location has its own custom theme music that is played while on the map. The music for combat and other events should generally use a variation of the Location's theme music to carry on the consistency of each map.

Node SFX should also occur when moving over each node, with some nodes playing alternate SFX to differentiate them. Audio puzzles could also be used in the future using different SFX between nodes.

8. Tunables:

8.1 - Map Tunables:

• Random Encounter Enemy List
• Encounter Rate

8.2 - Node Tunables:

• Node Type (Path, Event, etc)
• Can be bypassed before completion? (all Non-Path nodes)
• Enemy to spawn (for Encounter Node)
• Item or currency reward (for Treasure Node)
• Mimic? (for Treasure Node)

© Scott Balmer - Game Design - 2014

Swords, Shields, & Sorcery | Creature Concept Sketches

Here are a few quick creature concept sketches that I whipped up yesterday for a demo level theme I am fleshing out.

"I think I see something in those bushes... WAIT! That's no bush! It's a... hedgehog!?"

Enjoy!

Top: Hedgehog, Porkupine | Middle: Minnowtaur, 'O' Deer | Bottom: 'O' Deer God

Credit for some of the fantastic creature names goes to my fiancée, Coral.

© Scott Balmer - Game Design - 2014

Swords, Shields, & Sorcery | Combat Prototype

This combat prototype was built in Unity 4.3 using JavaScript.
Total scripting time ran cumulatively at 6 hours.

All images and text are placeholder, and will be updated with appropriate art and animation for the playable demo.




© Scott Balmer - Game Design - 2014

Swords, Shields, & Sorcery | Combat Design

Contents:

This article covers some deeper design details on the combat portion of my Swords, Shields, & Sorcery mobile game concept.

1. Combat Mechanics
2. Game Flow
3. Player Controls
4. AI
5. User Interface
6. Victory/Defeat
7. Art
8. Audio
9. Tunables

1. Combat Mechanics:

Once in combat, the attack choices are simple, but the mechanics under the hood are a little less so. The options available are thus: Sword, Shield, and Sorcery. Sword beats Sorcery, Shield beats Sword, and Sorcery beats Shield. Each weapon type can easily be compared to the components of Rock, Paper, Scissors.

After both the Player and the Enemy have selected their attack, the game will compare the choices and determine the winner. There are 9 possible outcomes:

Player will draw with the Enemy if:

Sword vs Sword

Shield vs Shield

Sorcery vs Sorcery

Player will win if:

Sword vs Sorcery

Shield vs Sword

Sorcery vs Shield

Player will lose if:

Sword vs Shield

Shield vs Sorcery

Sorcery vs Sword

Once a winner is determined, damage calculation will begin. The losing party will have their health reduced by the amount of damage the winner's weapon deals.

Example: The Enemy's Sorcery attack loses to the Player's Sword attack. The Player's sword deals 3 damage, so the Enemy's health will be reduced by 3.


The amount of damage taken can be reduced by equipping damage mitigating armor. Damage mitigation will only function for the type of attack that particular item defends against.

Example: The Enemy's Sorcery attack wins against the Player's Shield attack. The Enemy's Sorcery attack normally deals 4 damage, but the Player is wearing a piece of armor that mitigates Sorcery damage by 1. The resulting damage to the Player is 3, instead of 4.


The Player and the Enemy will continue this duel until one of the combatants health is reduced to 0.

2. Game Flow:

Similar to classic Japanese Role Playing Games, Swords, Shields, & Sorcery will have the game map and the combat screen separate. While traversing the game map, a random battle with a randomly selected enemy from the area will appear, which immediately transitions the player to the combat screen. Once in combat, the battle flow will function similar to the below outline.

2.1 - Combat Flow:

1. Enter Combat
2. Display Intro Animations for Player and Enemy
3. Provide Player Control Options (Sword, Shield, Sorcery, Run Away)
4. If Run Away is selected, combat ends and the player returns to the map.
5. If an attack option is selected, the Player's choice is compared to the Enemy's choice while attack animations play.
6. If Player's health or Enemy's health has not reached zero, return to step 3.
7. If the Player's health has reached 0, the Player is returned to the map.
8. If the Enemy's health has reached 0, the Player receives rewards, such as experience and currency.
9. The Player is now returned to the map.
10. If the enemy was a mandatory fight on the map and not a random encounter, they are now able to progress forward.

3. Player Controls:

As outlined above in the Game Flow section, when the game is accepting input during combat, players will have the a selection of choices.

3.1 - Players can:

• Attack with their equipped close-combat weapon with the 'Sword' button.
• Defend with their equipped defensive weapon with the 'Shield' button.
• Cast the equipped spell or ability using the 'Sorcery' button.
• Escape the current encounter with the 'Run Away' button.

Running away from a random encounter does not result in any penalty, but can hinder the player's ability to level up and prepare for future challenges. Running away during a mandatory encounter (one specifically presented on the map) will result in a small penalty (penalty is TBD, but could be as small as a minor reduction in the player's currency).

4. AI:

Enemy AI consists of three main choices, which are identical to the choices provided to the player, with the exclusion of running away (this may be available to select enemies depending on development time).

4.1 - Enemies can:

• Attack in close-combat range with 'Sword' attacks
• Defend themselves with 'Shield' attacks
• Cast spells and other special abilities with 'Sorcery' attacks.

Each enemy's choice is weighted manually by the designer, who will determine the percent chance an enemy will use each type of attack. Weightings should be based on the appearance and equipment of each enemy.

Example:
 A Prickly Slime has sharp spikes, and has been assigned a higher chance to use Sword attacks. 

• Sword Chance: 60%
• Shield Chance: 30%
• Sorcery Chance: 10%

Late game enemies and most boss enemies should have additional AI weighting to compensate for player actions. If the player uses their Shield attack three times in a row, a smart enemy should have a much higher chance of using their Sorcery to counter the player. This additional AI can help prevent combat from becoming too easy or stale.

5. User Interface:

The combat UI should be somewhat minimalist and as out of the way as possible. The goal is to only display necessary information, and keep the game field clear of clutter.

5.1 - UI Elements to always display:

1. Player Name
2. Player Level
3. Player Health
4. Enemy Name
5. Enemy Level
6. Enemy Health

5.2 - UI Elements to display when input is accepted:

1. Escape Button
2. Sword Button
3. Shield Button
4. Sorcery Button

Note: Sword, Shield and Sorcery Button icons should use the icon for the currently equipped item for each slot. This should allow for an easier association between the player visual, and the action choice to be made.

Additional considerations for UI include flipping from horizontal to vertical display. To provide the best user-experience possible, both formats should be supported.

5.3 - Additional overlays and screens:

• Victory/Defeat overlays
• Loot distribution overlay
• Level up overlay

6. Victory/Defeat:

When the Player wins a fight, they will be notified with much fanfare, and a tally of collected experience and loot. Once the Player selects to continue, they will be returned to the map screen. A list of potential rewards include:

• Experience Points
• Currency
• Rare chance for item and equipment drops.
• Even more rare chance for two items to drop.

Should a Player gain enough experience during a battle to level up, they will be presented a special Level Up overlay after confirming their victory. This overlay will visually show what new reward the player has access to at this level, in addition to their Level Number. This overlay will also need Player input confirmation before closing and returning the player to the map.

If the Player should be defeated, they may be forced to relinquish some of their currency. This only applies to mandatory fights that can be seen on the map screen. After confirming their defeat, the player will return to the map screen at the same location node they were last in before battle commenced.

7. Art:

The combat screen is the most important screen in the game for showing off the environment and the characters. While the map should capture the look and feel of the area from a high level, the combat screen takes the player front row-center into the detail. The player character, also seen on the map and inventory screen is shown in its largest size here. In addition to the player sprites and animations, which will be fully captured in the future Player Design article, there are many other pieces of art and animation needed to make the combat screen look its best.

7.1 - Background/Foreground Elements:
This is the set dressing for the combat. Each map area has its own unique combat screen set dressing. Eg. A desert area would have a desert motif for the combat screen. Set assets required:

• Backdrop
• Foreground
• Animated objects (such as flowers blowing in the breeze, and clouds in the sky).
• Additional VFX as required.

7.2 - Enemy Sprites and Animation:

Each new enemy will need custom sprites and animations to be created. A total of 12 new animations should be made for each non-humanoid enemy. Humanoid enemies can borrow player animations to cut down on development time. Enemy assets include:

• Custom sprites per new enemy.
• 12 new animations per new non-humanoid enemy.
• 3x win, 3x lose, 3x draw, 1x intro, 1x defeat, 1x victory
• Additional VFX as required.

Note: Enemies that appear similar in shape and mannerisms can recycle already made animations to lower development costs.

7.3 - User Interface:

As mentioned in the above User Interface section, UI art assets will need to be created for the combat screen. UI assets required:

• Hearts to indicate player/enemy health.
• EXP bar.
• Button images, and their associated item icons.
• Victory, Loss, Level Up and Loot overlays.

Time permitting, the UI elements could be subtly changed for each type of environment.

8. Audio:

Most of the audio played during combat will be dependent on the Player's equipment and what the Enemy is. All of these sound effect files will be pre-determined in the Player or Enemy's code before the fight begins. The following audio assets will be needed for combat:

• Battle Music
• Victory/Defeat Fanfare
• Level Up Fanfare
• Button Selection SFX
• Currency and Item collection SFX

The Battle Music that is played will be dependent on the map area combat takes place in. As each map area will have its own theme, so too will that area's combat. Each area's combat music should be a more energetic version of the map theme.

9. Tunables:

This is a list of tunable values that the designers should be able to modify in order to balance the combat difficulty.

9.1 - Enemy Tunables:

• Enemy health.
• Enemy Sword, Shield, and Sorcery choice weighting.
• Enemy 'Sword', 'Shield', and 'Sorcery' item.
• Enemy Sword, Shield and Sorcery damage values.
• Enemy Sword, Shield and Sorcery mitigation values.

9.2 - Player Tunables:

• The player will have similar tunables to the enemy, but can be manually done so in the player's inventory screen (accessible on the map). Further details on player tunables will be found in the future Player Design article.

© Scott Balmer - Game Design - 2014

Swords, Shields, & Sorcery | Game Concept

A few weeks ago, I was trying to think up some simple placeholder gameplay that I could use as a stand-in for a Matchmaking design exercise I wanted to do. Rock, Paper, Scissors eventually came to mind. Simple enough. Since then, I've been mulling the idea over further, and somehow came up with the a game concept that is the inverse of my original intention. Instead of focusing on multiplayer rock, paper, scissors, why not make a single-player RPG out of it? Voilà:

Concept:

Enter the charming, easy to play mobile RPG of Swords, Shields & Sorcery. Fight humans and creatures alike using a twist on the classic Rock, Paper, Scissors formula. Level up and gear up to shape your character into the hero that you want to play. Travel across whimsical lands, encounter strange, memorable characters, and see how mundane events transpire into a ridiculous and enchanting story.

Details:

Swords, Shields, & Sorcery is a fantasy mobile game that uses Rock, Paper, Scissors as its core combat concept. Swords beats Sorcery, Sorcery beats Shield, and Shield beats Sword. Instead of victory being dependent on winning a set number of times, players have health, as well as damage values for each type of attacks. Each of these values is increased based on levels gained and items equipped. This changes the game from winning almost entirely based on luck, to winning based on either overpowering an opponent, or trying to counter them.

Each player and each enemy in the game changes from just a game of chance, the game becomes a lot more psychological. "This goblin has a huge Sword, a tiny piece of wood as a shield, and no visible magical spell for sorcery. I don't want to get hit by that huge Sword, so I will try to use my own shield more often so I can win."

In addition to stat boosts, I really want to throw in some items that mix up the standard Rock, Paper, Scissors formula; Items that change HOW the game is played, rather than just increasing stat numbers. Perhaps some shields can have reflective coating, which repels a portion of the sorcery damage. This changes a lose for one player, to a partial win.

Every level of the game is chock full of colorful, witty and whimsical characters and environments. This game needs to stand out with polished visuals and clever story-writing. Instead of trudging through a generic sorcerer's tower, why not fight through an enchanted bakery? Flying cupcakes, ravenous loaves of bread, and the beast de résistance; a giant wedding cake with pincers and crustacean features: The Crab Cake.

The interface is simple to understand and easy to use. Even though each screen has a minimal number of options to choose from, each choice feels engaging due to a high amount of visual and auditory feedback. At it's core, Swords, Shields, and Sorcery is all about providing a simple and easy, yet engaging experience that players can pick up and play at any time.

Key Features:

• Easy to Pick Up, Easy to Play
• Minimalist interface and simple player decisions.
• Easy to follow, but fun to experience story.

• Rock, Paper Scissors with a Twist
• Rock, Paper, Scissors using damage and health stats instead of turn limits.
• Size up opponents based on their equipment and appearance.

• Level Up, Gear Up
• Fight to level up, level up to equip new gear, equip new gear to change how you fight.

• Chock Full of Wit and Whimsy
• Colorful characters, playful worlds.
• Puns, jests, and imagination around every corner.

Potential Expansion Features:

• Player vs Player
• Test your strategy against a world of live opponents. Leaderboards and special multiplayer rewards available for participating.

• Online Shop
• Purchase new aesthetic armor and items for your character that can't be found in the game. Sold at low, low prices, and cycled seasonally!

• More Single Player Content!
• New worlds, new enemies and new items to discover!

© Scott Balmer - Game Design - 2014

Boss Design Review | Gohdan from LoZ: WindWaker (Spoilers)

I have recently been watching my fiancée play through The Legend of Zelda: The WindWaker on the Wii U; a game I have played through the GameCube version several times and loved. Today she tackled the Tower of the Gods, and the accompanying boss encountered, Gohdan. Now, Gohdan isn't going to get the Boss of the Year award, but it does have very cohesive mechanics and theme, which I personally find fascinating.

Image source: zelda.wikia.com

Mechanics & Theme:

Gohdan is a mechanical implement stationed to test the worthiness of any challenger for the power of the Master Sword. It's not some foul beast the hero needs to slay. Gohdan isn't programmed to murder, it doesn't need to be destroyed. It is a test!

Mechanically, it does very little damage, and requires the use of some of the techniques learned from its dungeon. Chiefly among these being shooting moving targets with arrows, and throwing bombs into mouths to destroy enemies (such as the Armos Knights enemies). Once again, the test theme comes up.

The fight itself is shoot arrows at the eyes on the hands to deactivate them, shoot arrows into the eyes on the head to deactivate it, then place a bomb into the head's mouth. Rinse repeat. This seems simple enough, but the complexity lies in dodging the multitude of attacks, hitting the targets as they move, and deactivating the hands within a specific window of time, or they will become active again. Gohdan doesn't require the player to overpower it, it requires the player to have the skill and the timing to execute on what they learned. 

Image source: www.zeldadungeon.net

My favorite part of this fight is what happens when you run out of Arrows or Bombs. Most boss fights have jars laying around the exterior of the room to allow refills. Not this fight. Gohdan sneezes out some ammo for you when you run out! How nice! Unfortunately for the player, it will also reactivate one of its hands every time you run out of ammo. This will push the player to make good, accurate use of the 10 arrows presented to the player, before you run out again. This helps emphasize that this machine isn't trying to kill you. It is simply providing you with the opportunity to prove yourself.

To wrap everything up, when you defeat Gohdan, it does not explore. It does not fall apart. Gohdan simply returns to the fixtures in the wall from which it came. You passed the test, and it has completed its programming.

Image source: www.zeldadungeon.net

End Note:

As I stated earlier, Gohdan isn't going to win Boss of the Year. Never-the-less, this fight has still stuck out as one of my favorites in WindWaker for these many years, and now I know why. It just goes to show that cohesiveness of the mechanics and theme can help make an immersive and memorable experience. That is something that I strive to emulate in my own work: Cohesiveness, and creating a memorable experience.

Swords, Shields, & Sorcery | Creative Brief on Matchmaking

Objective: 

Provide a quick, accessible matchmaking system that keeps players actively engaged in multiplayer and single player.

Experience:

·         Toggle Matchmaking on to show others you're ready for a fight.

·         Bump into real-life opponents as you continue on your journey.

·         Take down challengers for currency, rewards and prestige!

Vision:

·         Easy to start and stop matchmaking.

·         Minimal data transferred to prevent excessive data usage on mobile.

·         Snappy access to basic Player vs. Player matches.

·         Clear information presented with minimal UI.

Anti-Vision:

·         Long waits in queues and menus for matchmaking partners.

·         Excessive screen flow between the initial menu selection and gameplay.

·         Custom parameters to set-up specific match types.

Details:

Matchmaking Toggle

·         Toggle matchmaking on and off with a single button.

o  Matchmaking button is clearly surfaced in the main player interface.

o  Toggling matchmaking on will attempt to connect to the server.

§ If no connection can be made, an error message is displayed.

·         Player visually update based on matchmaking state.

o   When matchmaking, the player's character appears battle ready.

o   A Player vs. Player banner is placed behind the player character.

o   An unobtrusive notification message should also be displayed on screen after toggle, then fades out.

§  eg. "Searching for challengers!" and "Avoiding challengers."

Search Criteria

·    All players are subject to the same search criteria.

·    Search checks for players of the same level first.

·    If a player of the same level is not found, the search checks for players one level lower, then one level higher.

o   This process should repeat until all levels have been searched through, then restart the matchmaking process until a match has been found.

·    Players should not be matched with the same person repeatedly.

o   Players that have recently fought each other are not matched together for a short duration (~5m).

o   This should provide more matchmaking variety and prevent potential griefing.

o   If there are no other players online, this rule will be ignored.

·    Searching is halted when already in a match, or a single player fight.

o   Searching resumes as soon as combat has concluded.

·    Once an appropriate match has been found, both players are notified with an Accept/Decline Notification.

o   If a player declines, the other is notified. Both players return to matchmaking.

o   If a player does not accept within a certain time limit, they automatically decline.

o   If both players accept, a fight will start.

Matchmaking Flow

·    Matchmaking Flow Chart:

Disconnections

·    Players who disconnect from the server will have matchmaking toggled off.

o   An appropriate error message will be displayed.

·    Disconnecting when a match has been found but not accepted will automatically decline it.

o   Like above, an appropriate error message will be displayed.

·    Disconnecting in the middle of a match will result in a loss for the disconnected player.

o   An appropriate error message will be displayed outlining the loss to the disconnected player.

o   The player who has not disconnected will win the match.

o   Match win/lose data will be discarded for situations where both players disconnect during the match (eg. Server down).

Other Considerations:

·    Desyncs and Lag

·    Countdowns

·    Leaderboard Statistics

·    Rewards

·    Transitioning to a match from various screens

© Scott Balmer - Game Design - 2014