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