Tuesday, January 12, 2010

Focus

So, I've been busy. That's my excuse. For not bothering to post in a while.

I've been re-working the Shipwreck game a bit lately. It's now on version 4.

It's been a sort of troubling game. The core mechanics are fun and everyone who has played it seems to enjoy that part of the game, but the surrounding structure of it has never seemed to gel very well.

The core structure is finding clues to find locations of shipwrecks, which players salvage for points. There was always an intended structure for the points allotted, based on various things, such as the class of the ship, the quality of the salvage crew you've hired, and how deep the shipwreck was in the lake.

And ultimately, most of that stuff never really mattered.

So much time and effort was spent on finding enough clues on a particular a shipwreck, that if you did realize that it was a low point salvage operation, you never really cared. You had completely "adopted" that wreck at that point, so it was in your best interest to salvage it anyway, low points be damned.

And so, in the end, it felt like the wrecks were just handing out random points, even though there was a lot of effort built in to the game to make it not random.

Therefore, the game was just running around, finding wrecks, and getting random points. Pretty much like what I imagine real shipwreck hunting and salvaging is sort of like. I've gone through 3 different versions of this, with handling the point system in different ways. With all the same results; while the clue hunting is fun and sound, the game around that aspect isn't.

Recently, I decided that what was wrong with the game is the focus of it; the ultimate goal of how to win at it. The ride was fun, but the destination wasn't. As it was, I had still not developed a good way to end the game, aside from "after 12 shipwrecks have been found." I've never liked this kind of arbitrary kind of ending in a game to begin with. I'd much have a more organic way to end the game (whatever that means), than some simply stated fact. There's nothing really building towards that finish. It's not like players are building an empire from some small cogs. Your salvage operation is always the same operation throughout the game. Puerto Rico doesn't end after XX rounds,there are hard component limitations that end the game, things that the players can control, or at least feel like they can. Or at least point to how it happened.

Not, "just because the rules said so."

So I've turned the game much more into an Indiana Jones/DaVinci Code affair. Which has brought a lot of the mechanical concepts of how the game works into a much more sharper focus, and has even brought the theme out some more. And it has gotten rid of the entire pesky points awarding system. It goes like this now:

The game is the first player to discover one of the 3 Gates of Atlantis at the bottom of the bay. To do this, players combine artifacts together which reveal clues as to where those gates are. However, those artifacts are also lost in the bay, hidden amongst the many shipwrecks. So, the player first travel from city to city, finding the clues that eventually lead the players to discover which shipwreck each artifact is hidden on, then the players must discover the locations of those shipwrecks, dive down to recover the artifacts and then use the artifacts to discover the location of one gate.

This is a much stronger narrative theme to impose on the players, as it gives them a call to action. The game now has a drive behind all of it's clue-hunting mechanical nonsense. And like any good "race for the artifact story," the game no thematically allows for stealing things from other players, leading to more direct confrontations, which I think should play out well.

//Well, of course, until it doesn't play out well, then back to the drawing board. The life of a prototype game is never complete.

Labels: , , ,

Monday, March 03, 2008

The Hook

In a recent discussion on the BGDF chat forum, I’ve found that some people may, or may not, know about this little trick in the game design world known as…The Hook. Since I haven’t been feeling rather design-y recently, The Hook might be a nice little discussion point worth posting about.

The Hook is a general term that we use around the office that describes the one most singular thing that makes the game compelling to the user. This is not a game mechanic or theme, or full “pitch” sentence that describes what the game is about. In fact, it is frequently under 8 words, at most, that simply answers the question:

“So, what is the hook of this game?”

Again, it is important to realize that this is NOT really what the game is about (even though, in some cases it can overlap). This is the one simple thing that a player can grasp that “reels them in” into further play, or even the interest of playing the game. This is important because, if you cannot identify The Hook, then there is a good case to be made that the game itself is pretty bland, and there is nothing much more you can do to fix it.

Conversely, if you CAN indentify The Hook, you will understand that almost all functions and systems of the game hang off of it and support it, making a much stronger game in the process. If you feel that the game is “too heavy,” it is probably because there’s a rule or mechanism in there that doesn’t support The Hook, and can easily be removed, often improving the game.

And now, the examples.

Puerto Rico’s hook is “building the most efficient machine.” That’s it. Note that there is nothing in The Hook that describes it’s theme, or it’s somewhat unique role-selection mechanism (and yes, I know there have been role-selection games before hand).

In fact, PR's hook itself is not that innovative, as many games can be thought of as “building the most efficient machine.” But this is the thing that gets player to come back and play it again; with each play, the player picks up a better understanding of the various interplay between the buildings (and to a lesser effect, the way the worker resources energize the buildings and plantations) in determining how to avoid the inefficiencies of previous games.

Some games are often harder to find The Hook in them, or have multiple relational Hooks. The Princes of Florence, while it, too is a “efficiency builder” has an additional relational Hook, which I think is the bigger Hook for a new player in the game. The big hook for PoF players is "play Tetris in a board game". Remove this element, and while you may have a nice game there, but there'd be nothing remarkable about it. In this case, the hook defines a fairly unique application of how the game works. I suppose I should note that you aren't REALLY playing Teris, but the whole puzzle solving aspect of packing in various oddly shaped pieces matches well with that description.

It should be noted that in the two above examples, there really isn't much thought given to the theme of those games, especially with regards to their Hooks. The games, themselves are fairly themeless once you remove various typefaces and graphics. I've always found it amusing that in PoF you are supposedly attracting artisan's to your little art clubhouse and having them produce their wares, but you never actually SEE or feel an artist, and their supposed "art" they are producing is merely a card with a lot of stats on it. These are effectively themeless games, with a theme attached to them.

As an opposite example from above, I present Ticket to Ride, which has a hook that is very similar to it's game description: play sets of cards to complete tracks. The Hook here is "Building a track layout to complete city connections through simple card play." As much as I tried to keep the word count down to a minimum here, I felt that the card play aspect of the game is the thing that really carries it; there are plenty of other train games out there, but TtR is the game that I think solves the solution simply for the average player "to get," and to pick up and play often enough. And in this case, some allusion to the theme is appropriate...slapping a non-train theme on to this game is most likely inappropriate.

Of course, I've applied The Hook to three Euro Designer games, but it can be applied really to any other game. In some respect, The Hooks of various games are defined by the family in which they keep.

"Trick taking/avoiding game" all share the same hook, as described by their family trait, with maybe an additional comment with regards to what defines the trick. Wargames are somewhat all similar, given that thety can be block-styled, or card driven, or action point driven, or what have you.

The important thing, however, to take from this is that once you have found a Hook, it is important to make sure this is the heart of the game, and all other mechanics "tendril out" from it and support it. Otherwise, it gets lost, and the game will be confusing at worse, or just meandering, at the least.

Labels: , , , ,

Tuesday, May 01, 2007

Motivators

When I get the chance, I've been play-testing a basic version of Leviathan a bit, tweaking some values and such, and putting the rules into some kind of understandable form. As a recap, this is a general overview of how things currently work, based on what I've fleshed out so far.

Tales:
The object is to get as many Tales in each Port as possible. Your final score is based on the 2 Ports with the lowest Tale count.

Strength:
When a player runs out of Strength, the game is over. A player gains Strtength by taking down ships (eating the sailors). But a player also loses Strength when doing this, and due to weather events.

Game Play:
The player first decides how much Strength to apply to an "At Ready" Strength. This is the amount of Strength he expects to expend during this round. All unused At Ready Strength is discarded at the end of the round. However, if the player did not assign enough At Ready Strength to cover "losses" during the round, he must cover start sucking up his Strength reserve with a penaltly of using 3 Strength for each Strength that is required to be paid.

The player may move to a new location.

The player checks out what he has discovered at this location.

If he finds a Fleet, he Battles them, using up Strength in the process, or attempt to run away.

Strength and Tales are awarded for sunk ships.

And then round finishes, all excess At Ready Strength is discarded.

**************

Playtesting at this stage, I'm currently smoothing out the Battle system, and getting a feel for how the balance between using up Strength and awarding Tales feels.

And without the Evolution system, the game feels fairly dry. It's completely playable for sure. The game as it stands right now, is basically the player making decisions pretty much based on making decisions based on Strength/Tale conversions. And that's essentially the sole "motivator" right now.

Most motivations that move a game along are pretty simple, and they are typically all tied to "Winning the Game." Whether that means the most points, or getting rid of your cards first, or first across the finish line, or whatever, it's pretty much all tied to winning.

Usually, though, there are a lot of secondary motivations you can find in games. These things are a bit more varied, but they usually more exploratory in nature. These things are usually along the lines of finding the best strategy in order to win, but they can also be more about just trying to mess around with the game's systems and see what becomes of it if you don't follow the obvious path, like attempting to go the 100% corn producer path in Puerto Rico, or playing Princes of Florence without building ANY buildings. Or playing Tikal solely for chasing the masks and idols. A big part of the CCG allure in is this; often, it's not so much as winning the game as it is trying to get all of the cogs of some infernal machine together to come out of your deck just right.

Anyway, in my experience with PocketCiv (and really with games in general), you really need to have something more than a design that is simply "best points win." Or in the case of a solitaire game, just a running total of points. Sure, you can "beat the game," but the flexibility of the PocketCiv turned out to be much larger than I thought; there's a lot of things to explore in there.

Which leads me to Leviathan, which, in it's current form, doesn't have the same amount of flexibility. As a game design, it's pretty static, and the player has only a few real choices; these things I are Player Movement, Player Battle Decisions (which includes the At Ready/Reserve mechanic), and a player's decision to keep fighting or to run away after each sunken ship. There really isn't that much to explore.

And so, my next step is introducing the Evolution system into the mix.

Generally, the concept is this: When a player sinks a "good" ship (one that has a certain value), the player is awarded with a power-up (he Evolves). However, the fly in the ointment here is that giving the player an option of what he wants will most likely allow him to beat the game easily. PocketCiv controls this aspect by it's costing structure: more interesting or powerful technologies simply cost more, or have preresiquites before you can obtain them. Additionally, I need to have some control over the Evolution to keep the player coming back to explore new routes.

I don't really want the player to "target" a certain power-up, I would like him to discover it somehow. So if a player wants to follow a certain Evolutionary path he hasn't been down before, he can find something new.

Of course, this sort of relies on a certain amount of trust in the player in that he simply doesn't just read the entire menu before he plays the game. On my end, I sort of have to hide the power-ups as best as I can, so the player can't just happen along something cool that he isn't supposed to get.

In a nutshell, that is the design issue I'm out to solve, and here's the first pass. I think it will work out well, with the exception that I note after the description. The Evolution system requires the need for two additional grids (on one or two boards), and a book or manual for the "Captain's Log."

Ships come in two classes for the purpose of Evolving. Once a ship is sunk, the next Battle Card is turned over, and based on the Ship Type (of the defeated ship), the player can determine if the ship is "Named" (a cool ship, one worthy of songs to be sung by sailors), or "Unnamed". If a ship is Named, you are awarded a icon; there will only be 4 different icons a player can collect. Additionally, a player can only have one of a particular icon at a given time; so if a player collects a "spyglass," and he already has a spyglass, then too bad, he doesn't get an additional one.

I would've liked there to be more of a theme to "naming ships," but at this point, I'm going to attempt a simple route to keep the current, overly large component count down a bit.

Anyway, evolving is based essentially on a probability tree. A player starts a pawn on the bottom of the tree, he may spend on icon to move on a branch to the next space up on a branch, provided he has the current icon to move there. At the new space, there will be an entry number of a Captain's Log that the player will be required to read.

The Captain's Log contains two types of articles. First, a Captain's graphic description of the sea monster that attacked his ship, which will end with another pointer to entry somewhere else in the book. This entry contains the power-up rules description; the new rules that appply to the player now that he has Evolved.

Ultimately, the Captain's description is fluff, but important fluff it is! It is the link that hides the misdirection between the entry number on the Evolution Tree (which can be seen by the player) and the eventual reward of the power-up (the entry that the Captain's description points to). So while a player may glance and read about a potential rules change; he will most likely not know how to get there, short of scanning and remembering other Captain's descriptions.

So, let's break this down a little bit more, in terms of a player's choice.

The player now has fairly limited control over exactly how he will evolve. He has enough control where he can decide to wait and spend his icon (in this example, the "spyglass") on whatever the next "spyglass" Evolution will be. Now, if he has played the game enough times, and decides that he has seen the "spyglass" Evolution choice enough at the start of the game, he may wait and use it further up the tree in the hopes of exploring a new branch on the tree, and finding a new "spyglass" Evolution that he hasn't played yet.

However, this comes at a possible price, as getting another "spyglass" is essentially a useless endeavor, since you can't carry spares. "Collecting" a second "spyglass" is giving up one Evolution. So, there's a bit of fun risk/reward in this. You can collect the known Evolution now, or you can wait, and try for a different one, in the hopes of spending it on a new, unplayed Evolution later.

While conceptually, I think the basic design is strong, the hard part on my end is this: I need to somehow come up with a rather large list off power-ups to make this a useful and interesting feature. And they need to be fairly unique, especially the ones further up the tree, as these will not be seen very often. They need to have a certain "hey that's cool!" about them, so the first time a player experiences something neat 5 levels into the tree, he'll want to come back and try a different branching route in the tree to see what else is at level 5.

I'm somewhat concerned that the "base game" isn't robust enough to really pull this off. Or at least, pull it off to the point of making the player's choice meaningful with the Evolution Tree. Here are the current "systems" I can power-up:
  • Player movement
  • strength/healing
  • Battle options
  • Awarding of Tales
  • Weather effects
And so, that's the plan of the moment. We'll have to see how it all comes out.

Labels: , , , , , ,