There are three components that are required in nearly every MMO team based encounter:

• A Tank to draw the attention of target mob or boss monster and soak up its damage.
• DPS to ensure the swift defeat of the target, and…
• A Healer to keep everyone on the team alive, primarily the Tank who should be receiving the most damage.

The classic MMO team dynamic: Tank, Healer & DPS

While this dynamic as been successful since the early age of pencil and paper games I expressed to my friend that it has grown extremely tired and I would like to see a change.  I think the reason my opinion was received so poorly was the idea that I was challenging the wheel, and what isn’t broke does not need to be fixed.  Really what I failed to do was clearly express what it was about the dynamic that I disliked so much.  Before I do that however, I want to refer to another genre that changed almost completely with a simple alteration in the dynamic of the game mechanics.

Left: Half-Life's "Health & Suit" - Right: Halo's "Shield"

Classic First Person Shooters utilized a Health system where damage was permanent (as indicated by the green arrow in the image above).  Users were required to collect Health Packs to restore their character’s health, without them the User would have to be exceptionally cautions when progressing with low Health.  Later FPS titles added an Armor mechanic (as indicated by the blue arrow in the image above), but really this only extended the character’s Health into two numbers.  Then enters Halo: Combat Evolved, a FPS like the rest but with a new Health system; Shields or Recharging Shields.  The first variant on this was like many of the classic FPS games, but instead of requiring the User to find both Health and Armor Packs they only needed to find Health because their Shield would recharge on its own.  The dynamic that this created was a lot more action packed and rewarded the User for utilizing cover to recharge their Shields.  This mechanic won over the community and has become a standard for nearly every FPS since, and now most FPS only have a Shield mechanic and no Health!  The objective was simple, create a more exciting experience that promoted the use of cover that never left the User rummaging around for scraps of Health.

I image that before this change someone would have been called crazy if they challenged the way Health was managed in FPS, but it happened and most FPS games are better for it.  I would like to point out however that the fundamental “Health” mechanic is still present!  Just because the Shield refills after a short duration does not mean the character cannot die, it just changes what it takes to die.

This is the point I was really trying to make to my friend, not that we needed to do away with Tanks, Healers and DPS, but simply redefine how these roles are utilized in these games!  I like to break these roles down into more specific element:

• CONTROL: the element of Control is important because it allows User to keep their Targets where they want them.  This is classically represented by the Tank that uses Threat mechanics to keep their target focused on them.  This is also represented in other class abilities to SAP, Stun, Polymorph, Confuse, Sleep, etc targets so they are not a direct hazard to the rest of the team.

• SUPPORT: while I am sure there is a better word to describe this element, the element of Support allows Users to restore lost health/energies, return themselves or others to life and grant buffs or debuffs.  This is classically represented by the Healing classes and as a bonus utilities on other classes.

• DAMAGE: this element is the most obvious in that its purpose is to kill Targets as fast as possible.

Control in the current Dynamic is dominated by Tanks, who are heavily armored melee combatants that sit face to face with the Target, but there are many ways to “Control” a target!  Support in the current Dynamic is dominated by Healers, who are soft magic based ranged classes that sit in the back spamming or waiting for the right time to heal a target, but does healing have to be managed by one or a few Users or by Users at all?  Damage in the current Dynamic appears more diverse than it really is, sure there are melee DPS and range DPS, some that use physical attacks while others use magic, but all of these attack hit the same [hit] box.  I am not suggesting we throw out these mechanics, I am simply suggesting we find ways to change the way we currently do it.

Clearly I am raging a bit, but I needed this massive brain-dump...

OK… I know this has pretty much just been me complaining about the wheel this whole time, proclaiming “it could roll better if you did it differently!” without actually proposing how one might do that.  I would like to start by pointing out a case where this has already been done to some degree in our very own World of WarCraft…

The High King Maulgar fight took two classes that were almost exclusively DPS and turned them into Tanks!  You may not get this from the video above, but a Mage class character would tank a boss monsters vulnerable to ice based attacks.  This vulnerably would cause the boss monster to become easily slowed and frozen allowing the Mage to kite the boss monster around until it was time to kill it.  At the same time a Warlock would use his ability to take control of a demon summoned by another one of the boss monsters.  With this powerful demon under his control he could use its power to help attack the boss monsters, while at the same time using a fear spell to keep another boss monster running around in terror!  When I first encountered this fight myself I felt that “Wow, this game’s team/raid dynamic may finally get mixed up.  Regrettably I rarely saw any sort of thing like this ever again.

In this successful example the Tank, or rather “Control”, mechanic were still there but just functioned differently.  Why must there be classes who are expected to play one role?  Sure heavily armored Warriors may be the best at taking full frontal physical attacks, but what if the creature is ethereal and can pass through hardened metals?  Then a magic user who can twist the laws of physics would be the best candidate.

What about Healing?  The FPS genre showed us that there is more than one way to skin a Master Chief.  What if everyone could heal themselves in some way?  Like the Shield mechanic, maybe they would have to step out of combat long enough to apply a suture, or catch their breath restoring some health.  In addition to that, maybe everyone could heal someone else in some way, but they would have to stop what they were doing to do it.

If given enough time, and I plan on investing that time as some point, I am sure I could come up with a bunch of fun solutions.  But without breaking the mold a little I feel many MMOs are following the same formula to closely for me to care about playing them.  This goes for more than just the raid/team dynamic, but also the class types, the setting, questing, crafting etc.

I look forward to following this up at some point!

An image pulled from the How to Play manual.

For those of you who would like to learn more about my boardgame The Island – formally titled Hill – please feel free to view or download the current rule sheet here —> How to Play The Island

Please keep in mind this document is a work in progress.  Many of the images are placeholder and the text is full of misspellings, grammatical errors and inconsistent terminology.

Needless to say, any and all feedback is welcome.  Cheers!

Example of the Iron Synapse Main menu. 80% of actual size.

For the last week and a half I have been working on updated all of the ingame art, excluding the characters.  This includes all of the interface, logos, buttons, bars, counters, timers etc.  While it has been a daunting task, it has been a fun and educational one!   Most of the content I have created is not all that interesting individually but I am excited to share it as whole in future updates.

Example portions of the playing board, called the Map.

Included in all of this work I updated the Map tiles; two point Elbo tiles for the corners, three point Tee tiles for the sides and four point cross tiles for everything in between.  Using procedural generation we can create any Map size using these three different tiles, which reduces the amount of content we have to create as well as the amount of content that the client/user has to load before playing.

You will also notice in the sample of the Map alphabetic and numerical coordinates on the top on left side of the image.  These coordinates will be shown on all four sides of the complete map which is common in most strategy games like Go and Chess etc.  To utilize a unique Font and glow effects, these tiles had to each be created by hand.  There are 21 numerical tiles and 21 alphabetical tiles.

Latest Node & Power Node artwork.

Creating each of the coordinate tiles was daunting, but I also had the pleasure of updating the Node and Power Nodes art as shown above.  Starting from the left side you will see the red and blue Nodes, or Basic Node.  These Nodes make up most of the game and will be seen throughout the entire game.  Each of the other Nodes are Power Nodes which have unique functions.  Starting from the left is the Strong Node, which can never be captured making them a great way to secure sections of your wall.  The next Power Node type is a Spiked Node, which will subtract points from your opponent if they capture it, detouring them from doing so.  The Power Nodes with the Golden rims are called Rich Nodes which grant the controlling or capturing User additional points.  Lastly is the Power Node without a color, this is called the Hollow Node.  This Node can be played directly over the top of opposing Node to immediately capture them turning them into a Node of User.

While we slowly complete and add the remaining features we are ramping up greatly on or content development and my hopes are that we can begin sharing the revised and cleaned up version of the characters really soon, as well as actual ingame screen captures with the new art.

An example of a Skill and Luck based mechanic for Arc Fantasy.

In both examples above it is Blue’s turn and he wants to throw a rock at Orange.  Like other trajectory based games, Blue must set the angle (purple arrow) at which the projectile (the rock) will be thrown and set the velocity to determine how much force is applied.  The velocity will also have an effect on how far or near the rock could travel, but to simplify things we are going to assume the velocity never changes in either of these examples, because it is the method of aiming that is really in question.

In the Skill Shot example, the user would only have a very general idea where the projectile will travel based on the angle of the arrow.  The same angle however would always send the projectile in the same direction, creating consistency.  That consistency combined with experience would generate a Skill for Users to choose the best angle for each target they confront.  Despite the limited information given by the arrow, Users would get better at predicting where the projectile will land.  This is the most popular method used by most of the games described above.

In the Luck Shot example Blue is given the full range of information, except the projectile’s movement is NOT consistent.  In the example above (right) Blue knows the shortest distance the projectile could land (lower purple line) and the furthest distance the projectile could land (upper purple line).  The user has no control over where the projectile will land, only a matter of where it could land making it a matter of Luck.

The primary reason these mechanics are in question is because of their effect on another mechanic I am implementing into the game; action specific accuracy.  Users would be given the opportunity to choose between less powerful but more accurate attacks or very powerful less accurate attacks.  In the Skill Shot case, the arrow would get much longer, giving the User a much better idea where they are sending the projectile.  In the Luck Shot case the cone would become much more narrow reducing the possible places the projectile could deviate to increasing the chance of success.

To be clear I intend to take a little from each of these mechanics, but what I am really interested in is what other people think about these two concepts, and which one they would be more compelled by.  I should have more information about the project and its other systems and features soon.

This is a dramatization of music coming out of my mouth.

My Music Page is finally here, and you can view it by clicking on the link to the left or using the navigation bar at the top of my blog!  Check out some of my favorite home brewed tracks and find links to the rest of my music on SoundCloud.com!

Synaps Characters, Rough Pass 01

Needless to say our team was pretty stunned at the quality and creativity of these character, and I hope you agree!  If you have been following along you may notice that these characters are a little different from the ones we have displayed in the mock-ups.  Well there have been a few changes.

While browsing Joanna’s portfolio I came across an image that caught my eye.

Steam-Powered SPN Chibi set 1 by Joanna Johnen

Being a sucker for steampunk I immediately asked Joanna a little more about the image.  Among her description she asked me if this was the style we were looking for our Synaps characters.  At the time it had never crossed my mind because our original goal was to create a spacey, web 2.0, sleek iPad looking world, but almost immediately I thought “HEY, why not?!”  So I ran it by the team and they all felt very much the say way.  So now the spacey world of Synaps is slowly turning industrial.

However, my goal is not to have consumers see the product for the first time and think “steampunk”, I simply wanted them to say “hey this looks cool”.  That said we are going to avoid many of the classic steampunk cliches, explicitly cogs, steam and of course goggles.  And while these things are not evil we just want to avoid or rater limit the cliches.

Despite being completely bowled over by the characters there was a lot of feedback generated for the next pass.

Character #3

Character concept #3 is the first in our lineup that we would like to see back in the next pass.  While the image of this character looks refined, his clothing is a little uninteresting.  As a commoner this character would be perfect, but we are dealing with 6 to 9 unique characters that will represent the user during the fight, so a little more depth is in order.

Characters #5, #6 and #7

These three female characters are great because they are diverse and interesting!  We expect to see them again in the next pass, especially #7 who we would like to see refined to same polish as the others.

Character #8

We liked this character because he was a bit younger than the rest, and that also meant he was a little smaller in size.  We aim to take a page from Team Fortress 2‘s book in character design by creating characters that are recognizable in silhouette.  So characters of different size and proportion will be important to achieving this goal, in addition to hairstyle, clothing and expression.  It was also with this character that we decided to avoid the cliches of steampunk and remove his goggles.

Character #10

While greatly unfinished, this character really caught my eye.  We wanted to have a multicultural group of characters to represent all the regions around the globe who are coming together to play this game.  I almost immediately imagined this character from a South American region with cornrows, large golden earrings, ornate bracelets and a silky red dress that just sort of drapes.

Character #11

At first glance I did not like this character, he did not appear to have anything going on and the unrefined nature of the image did not help.  However, after a few comments by the team we found a lot of value in this guy!  First off we liked his stature, it was different than many of the others.  We also liked his large belt, and later discovered that it looks like he is wearing a hood.  After some thought we came to the conclusion that this would make an interesting monk, one who dresses in simple robes but with a grand belt to match his stature.  We look forward to his revision.

Character #12

I was quick to like this character, his clothing pretty much won me over in terms of style and dept.  However I felt like his expression was inappropriate for the character as a whole.  Without changing much about his clothing I requested that this character’s expression be changes to look stoic, like he is a serious dude ready to win.

Characters #15, #16 and #17

As previously stated, diversity in the characters is paramount, and we felt these guys fit the bill.  Posture, expression and style is different on each of these characters, so needless to say we decided to keep them on for the second pass.

We look forward to seeing the results of these discussions by the end of the week.  If you would like to see more and learn more about Synaps please check out he FaceBook fan page HERE!

In the last articles I showed you the following image of the game:

SYNAPS test screen roughly four weeks into Release 1

Originally you were only able to place stones one at a time and there was not way to actually capture opposing stones, not to mention we were using placeholder art from the Go Wikipedia page.  Now we have not only implemented our own original placeholder art, but we have also added many of the important features!!!

An image of Synaps after Release 01.

Excluding the background art, every asset has been replaced with an original one.  And while most of it is still placeholder, we feel the final content may not be too different in terms of style… quality on the other hand should be much higher!  Some of the added features include:

1. Capturing opposing Nodes (stones).
2. Random Node Arrays, that allow the user to place multiple Nodes at a single time in a preset, but rotatable, pattern.
3. Node Array display at the top of the screen.

A concept image of the Versus screen.

The image above is a mocked up concept of what I image the Versus screen would look like in the end.  While different that the image of the actual game right now, there are many similarities which means we are getting close!!!

Some of the features illustrated in this concept art are:

1. A stylized score board that uses unique characters for the numbers.  A minor detail but one that makes things look even better!
2. Dead spaces, indicated by cross shaped icons, communicating to the user where Nodes can no longer be played.
3. Synapse connectors between each of the nodes indicating where the walls have been formed.  Hence the title Synaps!

And of course the two characters (from Advance Wars: Day of Ruin) on the left and right of the Map!  These characters will represent each user as they compete against one another and will react to the game as it is played, like the characters from Puzzle Fighter but probably with a little less animation.

Concept cards in each of the five FanCan Battle suits; Clovers, Spades, Moons, Diamonds and Hearts!

An example of a FanCon Battle card based on MineCraft's Creeper & details that break down the card.

All these updates to the game mean we have been busy working on it!  However FanCon Battle’s development has been put on hold due to time issues.  Our goal was to complete the game for Fanime 2011 but due to uncontrollable circumstances we are going to have to put the game off until a later date!

On the other hand we now have more time to refine the game by getting a lot more play-testing in as well as collecting a lot more original art that we have, and need, at the moment.  Also, if you are interesting in seeing this game through to completion, please like the official FanCon Battle page on FaceBook.

The placeholder logo for SYNAPS has been in the Games section of my blog for some time now with little to no explaination, yet quit a bit of buzz has spawned from it!  For those of you who have been  interested I am please to say that the development for SYNAPS has been underway since February and it is coming along swimmingly.

An image of the classic Chinese strategy game Go.

SYNAPS is a strategy puzzle game based on the classic Chinese strategy game Go, where users capture and secure territory on a grid using Stones to indicate ownership.  SYNAPS follows many of the same rules as Go while expanding on others and adding completely new ones.

Image of StarCraft 2

As stated, Go is a strategy game based on playing stones to earn points and acquire territory.  Our goal is to take elements from other strategy games that would make the classic Go experience even more exciting and diverse.  I will touch on this a lot more in the near future as we still need to complete the foundation for the game.  In the mean time, here is a sample of how far we have come…

SYNAPS test screen roughly four weeks from Release 1

It is not a lot to look at, but we have almost completed implementing the fundamental Go rules and mechanics, sans some major play-testing.  But after Release 1 we will begin adding advanced features and ultimately taking it beyond the standard game of Go.

PS:  The original team is still polishing off Kernips.  It’s a slow process at the moment but we expect it to be ready to play when we launch the official Uncharted Interactive website.!

Near the end of our production (some time in December) key contributors to the project fell on hard time and had to allocate their time to more life saving activities, such as making enough money to eat!  This drastically reduces our ability to complete the game at the level of quality we would have liked.

So we had to make a decision, to ultimately end development of the game, even in its underdeveloped state (play sad music here).

A month or so later I had my birthday and for my birthday I was given an updated version of the game!

New Art Oh My!

There are a few outstanding issues that should get addressed, but we are all still dedicated to completing the game… at some point.

On one hand we can view the development of Kernips as a failure, not meeting our final deadline and not making any sort of return.  This is not uncommon to indie project, most of which never get played or completed at all!

On the other hand, we started this project as an experiment with no intention of creating anything great.  But when we discovered the potential that we and the game had we pushed ourselves a little further.

In the end we are happy to have come this far and glad we experienced the pitfalls that we did.

I plan to post more about the state of Kernips as time progresses, but don’t hold your breath.