December 27, 2008

Mini Game Design: Poker Panic

For 3-7 players.  Uses a standard 52-card deck.

  1. Shuffle, deal 7 cards to each player.
  2. Players trade cards amongst themselves.
  3. After a while (time limit?) trading ends.
  4. Each player uses the cards they have to construct the highest-scoring poker hand they can.
  5. Highest hand wins.

The information problem

Notice I’ve said nothing about what sort of information is allowed to be passed.  How do you know the other person will stick to their deal?  Do you have to reveal the cards before trading them?  What happens if you trade cards and suddenly someone says “Wait, you said it was a heart, but this is only a 3 of hearts!  I don’t want this, give me back my card!”.  Also, is it difficult to make deals with someone sitting across the table from you?

Playing on a computer solves many of these problems.  Any decent chatroom interface allows the players to chat with each other both publically and privately.  Also, I can envision a trading interface that would make things easy.  The trading interface would look something like this:

  1. You choose a card(s) to offer.
  2. You choose how to present those card(s).  If you were trading the 7 of hearts, there would be options for calling it “One 7″, “One H”, “One Red”, “7H”.
  3. When both players are finished with the trade, they see the details of the trade and can examine it.  (”Trading One 7 For One D”)
  4. If both players confirm, the trade is executed.  If either player cancels, the trade is cancelled.

This solves the problem of not getting what you expected by making it part of the game.  Yes, you might have gotten a 2H, but you saw that you were getting “One H” and you pressed “Confirm”–it’s your fault!

Notes

You may trade unequal numbers of cards.  Is a hand with four cards a legal hand?  I would say for this game it should be.  If you trade away all but four cards, but those four cards are four kings, you deserve to win!

Obviously there’s room for variation; giving the players fewer cards to start with would probably restrict their freedom, but giving them too many would shift the emphasis more toward simply arranging the cards you already had.  Playtesting is certainly a good idea here.  One thing that might be fun would be to shuffle two decks together; that way things become more uncertain and random.

Comments Comments | Categories: Card Games, Game Design | Autor: JohnEvans




December 14, 2008

AS3 and images; Aching Dreams 2

I upgraded to Flash CS4, and I’ve been working on Aching Dreams 2, as well as simply learning ActionScript 3.0. So far I’m just working on the programming framework; the story, gameplay and characters are still being, ah, fleshed out.

Here’s something interesting I’ve discovered:

When you add an image to a Flash file in the library, it becomes an “embedded asset”. In AS3, you can use the getDefinitionByName() function to find the embedded asset class based on its filename (well, its linkage name, which is by default its filename). Then you can instantiate the class and get a BitmapData class; you can use this to construct a Bitmap class, then use addChild or addChildAt to display it. The really interesting thing is that the documentation says the BitmapData constructor takes a height and width…but this doesn’t seem to matter in the case of embedded assets. Pass the constructor anything you want, even 0,0, and it should still instantiate and display correctly.

Comments Comments | Categories: Adult Games, Flash Games | Autor: JohnEvans




November 30, 2008

NecroFodder!

As hinted at in an earlier post, I’ve created a new web-based game: NecroFodder!  It’s intended to be quick-playing but with some strategy involved as well.  Go check it out!  (It was created for the TIGSource Commonplace Book Competition.)

In other news…I’ve been getting a huge number of spam comments on this blog.  Fortunately, the WordPress software makes it easy to deal with them, so you guys never see them…But it still greatly puzzles me. O_o

Comments Comments | Categories: Game Design, PHP, Web-Based Games | Autor: JohnEvans




November 25, 2008

Character power tests: Some thoughts, and an avenue for exploration

Recently I had an interesting insight, but I need some background to explain it.

First, let’s think about games. Single player games, for now. One of the definitions of games given in Rules of Play is that game players deal with unnecessary obstacles. Imagine Super Mario Bros., for example; there are all sorts of obstacles in the path to the Princess at the end. In a sense, there is no reason why these obstacles are there; one could easily imagine a version of SMB that lets you just walk a flat, enemy-less path to the end. But the obstacles make it a game. (I highly recommend reading the book, because it’s much better written than my fumbling summary.)

So, SMB contains obstacles. We can think of these obstacles as skill tests. If you fail at a skill test–that is, if you miss a jump or can’t dodge an enemy–you are sent back to your most recent checkpoint. You have a certain number of chances, and if you use up all yoru chances, the game is over. So, SMB is focused on skill tests.

Now let’s think about another game, Knights of the Old Republic. If you haven’t played KotOR, it’s the type of computer game called an “RPG”, set in the Star Wars continuity. (”RPG” in this case is kind of a misnomer, but I’m not going to address that in this post.) KotOR is a fun game and I highly recommend it. If you’ve ever played any of the “main” Final Fantasy games, as well as Dragon Warrior/Dragon Quest, Atelier Iris or any of a thousand other RPGs…then you know the basic flow of the game. But let’s go over it to refresh our memories…

Knights of the Old Republic also has obstacles and skill tests, but its structure is slightly more complex. During most of the game you have the option to explore various areas at whatever pace you wish, and while there is always someplace to go (often many places), the game doesn’t force you along as much as SMB’s screen that only scrolls to the right. In KotOR you can take time to explore areas and increase the power of your party. This is important because the skill tests in KotOR are dependent on how powerful your party is, and to a lesser extent your strategy; you really need to spend time increasing the in-game power of your characters. Practicing–that is, developing your own skills–won’t get you far. Of course, this in-game power-up process isn’t too onerous, because mere exploration and moving from place to place will provide some of it. The game is pretty well “balanced” in that respect.

Let me take a moment to explain that last statement. “Balanced” is a term that can have several meanings. In the context of single-player games, like I’m using it, it usually means “not too difficult and not too easy”. In other words, the game provides you with a challenge that’s appropriate to your skill level; it’s fun. As I’ve said, most of the “skill” tests in KotOR deal with your characters’ in-game power, but the game includes a lot of exploration and questing that will increase that power. In other words, things that you were already expecting to do–exploration and questing–increase your in-game power enough to pass the “power tests”. Therefore, it doesn’t seem like you have to do anything “special” to pass these tests.

My point is that there are things people expect to do in games and things they don’t really want to do. Playing an RPG like KotOR, people expect to spend time exploring vast areas, fighting monsters along the way, solving problems for NPCs…those are things that players usually think are fun. However, in some games you can reach a point where your characters are just not powerful enough to pass the power test; in this case you have to do something to increase your characters’ in-game power. You have to take time out from the fun stuff you were doing and, say, go kill monsters for a while. Often this is referred to as “grinding”, a word that wonderfully evokes the mindless, fun-less nature of the task. RPG players aren’t exactly surprised when they have to do this, but the more grinding is necessary, the less balanced the game seems to be.

(I realize that I’m making sweeping generalizations about what players find “fun”. Different players find different sorts of fun in games–that’s something that’s been hammered into me over the years, no question. But it’s all in service to my points!)

So, the point is–Ideally, when players play games, they don’t have to spend any time on tasks that aren’t fun. Assuming players enjoy exploring and questing more than they do wandering around finding monsters to kill–a truly “balanced” game shouldn’t require any monster-kill grinding. Sure, without obstacles it wouldn’t be a game, but what we’re looking for is that line that separates “obstacles the player enjoys overcoming” and “tasks the player feels forced to accomplish in order to get back to the fun”. That, to me, is what every game designer searches for (even if they don’t consciously realize they’re doing so).

Okay, that’s cool. But let’s back up a bit. Let’s think about KotOR again and its “power tests”. When I talk about these tests, I’m usually thinking of bosses. These are in-game characters or creatures that the player must defeat in battle to advance to the next stage of the game. The player’s in-game power must be powerful enough to defeat the boss; therefore, to reduce the boss to its most simple form, it’s a test of the player’s in-game power.

So what happens when you go through this test? There are usually two options:

  • Pass the test–Go on to the next stage of the game.
  • Fail the test–Game over. Start over from your last saved game or some other checkpoint.

But wait–This reminds me of something. It reminds me of a post or article over on The Forge, although I wasn’t able to find the specific reference. I bet it was something posted by Ron Edwards; I’ll try to recreate the argument as best I can.

Now we’re moving away from computer games and talking about pen-and-paper roleplaying games–Dungeons & Dragons being the most famous example. For those not aware, Ron Edwards has spent a lot of time thinking and writing about RPGs, coming up with new models for what they actually include. Of course there’s debate, but here’s one basic point that he (and many other people) agree on: A lot of published RPG rule systems do the same basic stuff because “that’s how everyone does it”, but there are other ways to do things that are worth exploring. Hence, a site about “indie” RPGs, where people who are interested in non-mainstream stuff (or, to put it another way, bored with mainstream stuff) congregate.

Here’s one example of a different way to do things in RPGs. Let’s imagine there’s a character with a “Pick Locks” skill. They sneak into an enemy compound in order to steal some documents. They come upon a door they need to get through to advance further; the door is locked. So, they do a power test–they roll some dice and look at their Pick Locks skill.

Let’s say they fail the roll.

So…Now what? The character is stuck. They can’t advance until they succeed at their roll. Just like KotOR–back to the last saved game.

Now, in a real RPG session you usually have a GM who is there to improvise in some way. One simple way to deal with this problem is to let the character break down the door–but this might attract the attention of guards, making the character’s situation stickier.

Some RPG systems tackle this problem by developing the notion of “stakes” more. In the original scenario, the stakes were simple:

  • If you win this test, the door is open and you can advance.
  • If you lose, you cannot advance.

But there are other ways to do this. Let’s imagine the stakes of the conflict were set as follows:

  • If you win this test, the door is open and you can advance.
  • If you lose, you get the door open, but you make so much noise that guards are attracted.

In a sense, all we’ve done is fold some improvisation into the conflict. (RPG theorists often refer to these “tests” as “conflicts”.) We’ve made more explicit the idea that this test doesn’t put a halt to the game; instead, failure puts more pressure on the character and makes the story more interesting. The focus is not as much on the mechanics of the in-game power; the focus is more on how the story will develop and what (hopefully interesting) things will happen to the character next.

So, going back to KotOR’s power tests, now they look a bit limiting. Basically a KotOR boss can be summarized as follows:

  • If you win, you advance.
  • If you lose, reload your save and grind until you think you can try again.

So, do we have to do it like this? We can take a page from the indie RPGs and create different stakes than something “win/retry”. But now we’re getting into a branching storyline and exponential growth of content. In other words, if you want a “lose” option, you have to write and develop it; that could be hard.

Perhaps there are ways to more easily develop branching and adaptive storylines. But that’s a post for another day…

Comments Comments | Categories: Game Design, Role-Playing Games | Autor: JohnEvans




November 10, 2008

JavaScript

Today I looked into learning JavaScript.  Basically it’s a weakly-typed declarative/functional language with a couple object-oriented features for good measure, much in the line of PHP or Perl.  The interesting part, though, is the “HTML DOM”, a set of objects that allows JavaScript to access and manipulate the web page it’s a part of.  I went into this project looking to learn automatic form validation, and I’ve figured that out.  Even that much may allow me to add new features to my web-based games.

Speaking of web-based games, I had an idea for another little project for the TIGSource Commonplace Book Competition.  I’m calling it “NecroFodder”.  We’ll see if anything comes of it.

Comments Comments | Categories: Events, Game Design, PHP, Web-Based Games | Autor: JohnEvans




November 6, 2008

A review and a new project!

First, Greg Costikyan (yes, that Greg Costikyan) has given Aching Dreams a favorable review.  Not intense praise or accolades by any means, but for what the game is, I’m very pleased with what he said.  And there’s an interesting conversation going on in the comments, too.  Really, this is kind of an amazing feeling for me; obviously Cook did a lot of work on the project (more than just art), but I’m the one who had responsibility for programming, UI design, fixing bugs, not to mention building and “shipping” the finished product.  So I feel rather…validated!

Also, I’ve started on an interactive fiction game called “The Duel” for TIGSource’s Commonplace Book Competition (horror-themed for the Halloween season!).  Check it out and make suggestions!

Comments Comments | Categories: Adult Games, Events, Flash Games, Game Design | Autor: JohnEvans




October 27, 2008

Recent Project Work

So, recently I completed writing a long…well, I guess you’d call it a short story, or maybe even a chapter of a novella. And now that that’s out of the way, I can get on with doing other cool stuff. (It had sort of been weighing on my mind for a while.)

I’m doing more PHP work on secret projects, and I’m also working in Inform on a project for the TIGSource Commonplace Book Competition. (I’m actually working in Inform 6; it’s more programmer-oriented than Inform 7, but hey, I’m a programmer! And it’s what I learned. Maybe someday I’ll learn 7.) I bet I’ll even be able to finish this one for Halloween.

Oh, yes, Halloween. I always want to have something…special happen for Halloween. We’ll see what I can *ahem* dig up.

Comments Comments | Categories: Events, Fiction Writing, Game Design, PHP, Secret Projects | Autor: JohnEvans




September 24, 2008

Difficulty and game skills

I’ve noticed that I haven’t really been enjoying “twitch” games, that is, games that have action and focus on manual dexterity and/or timing.  I’ve especially been frustrated by those that are difficult.  Today I started thinking about why that might be the case.  (Brought on by playing Mega Man 9.)

The thing about action games is that they expect you to play them over and over, to practice, and thus to develop the skill of playing the game.  Then, once you finally master the skill and pass the game, you’re supposed to feel a sense of accomplishment.  And that’s good, if that’s what you want.

However, I play games a little differently.  Personally, I don’t really enjoy developing a skill to play a game; if I have trouble passing something and finally get through it, I feel relief more than accomplishment.  I’m not looking to develop and exercise skills in “simple” play of a game.

What I’m looking for is more in the line of experiencing the game.  I want to explore the environments, learn the information about the game world, hear the story, see the ending.  If I have to go back and repeat something until I get it right…well, that’s just interfering with my true enjoyment of the game!

You might be thinking that this implies I never replay a game.  However, this isn’t true.  There are games with multiple endings, of course, but what I really enjoy are games with multiple strategies.  My favorite type of games are the strategy/builder type games; Civilization, Master of Magic, Galactic Civilizations, Master of Orion.  (Why do I feel like there should be a game entitled “Master of Civilizations”?  Well, anyway…)  Once you finish one game of Galactic Civilizations 2, you can play another as a different race.  Or with a different galaxy size.  Or different distribution of planets, combination of opponents in the game, research speed, opponent intelligence (difficulty level)…And that’s not even considering the different ways you can play the game, conquering through military force or seducing planets through influence, etc., etc..

Therefore, while action games can certainly be fun, they don’t hold my attention like strategy games.

(This is all, of course, completely subjective; I’m well aware that everyone plays games for their own reasons!)

Comments Comments | Categories: Game Critique | Autor: JohnEvans




August 27, 2008

Dividing up large amounts of loot

Over in my LiveJournal I posted an idea about dividing up valuable loot between a group of people completing a “dungeon run” of some kind. It sparked some interesting discussion in the comments! I suppose I should do that sort of thing in this blog, although I’m not sure anyone even reads it…

Comments Comments | Categories: Game Design | Autor: JohnEvans




August 10, 2008

Hypership, a collaborative writing game

The idea of this game is that we create a starship put together from materials obtained from different worlds (or even dimensions). Each player thinks up a quick description of a civilization (”When climate change made their seas drop, these fish-people became amphibians; they are masters of chemistry and growing structures out of organisms like coral”). Then, they are assigned a Component Type by the referee (”Life Support”) and figure out how their civilization would make that component (”Photosynthetic coral reefs exchange gases and absorb wastes; Membranes let the gases through while keeping the air in the rest of the ship from being too humid”). And then, everyone’s components get put together into one amazing ship!

Here are the rules in all their tedious detail!

One player should act as a referee, and that player probably shouldn’t contribute. (That player should be someone who isn’t really disappointed in not being able to play…refereeing for this game isn’t that hard. Heck, it could all be done by a computer program, now that I think about it…)

1. Each player secretly chooses a Technology Level. This level can range from 1 (you can build a castle) to 5 (you can colonize other star systems). (Obviously, this portion of the game needs to be expanded, and probably the numbers changed; for now, let’s go with this.)

2. Everyone tells the referee their Technology Level. (Again, secretly, so only the referee knows all the levels.)

3. The referee judges the suitability of the Technology Levels. If it’s invalid, the referee says so (”we need one more person of at least Technology 4″); then, go back to step 2. If the Levels are valid, continue to step 4.

4. Each player writes a description of a civilization that exists at their chosen Technology Level. When I say “Technology”, it could be something fantastic like magic.

4b. This is a step I’m not sure if I should include or not. For now, consider it an optional variant: Each player passes the civilization they’ve written to the player on their left. (Left is an arbitrary choice; as long as each player gets a new civilization, it’s fine.) Then the players have to inform the referee of the Technology Level of the civilization they currently have. From now on, for each player, the new civilization is considered to “their” civilization (with associated Technology Level).

5. The referee secretly assigns each player a Component Type, based on their civilization’s Technology Level. If there are less than five players, assign more than one Component Type to each player. Some Component Types are “optional”, to be assigned if there are more than five players. Or the referee can simply assign the same Component Type to more than one player. Consult the following list:

  • Structure - Minimum TL 1
  • Life Support - Minimum TL 2
  • Wiring - Minimum TL 2 (optional)
  • Engines - Minimum TL 3 (optional)
  • Computer - Minimum TL 3
  • Power Supply - Minimum TL 4
  • Hyperdrive - Minimum TL 5

6. Each player writes a description of a component, of their assigned Component Type, that could be created by their civilization.

7. When everyone’s done, dimensional travelers assemble all the components into a starship and explore the galaxy!

This game just sort of popped into my head, so I thought I’d write it down. Obviously, the framework could be adapted to many other things besides starships. And the basic component list could probably be improved as well.

Creative Commons License
This blog post and the game “Hypership” is licensed under a Creative Commons Attribution 3.0 United States License.

Comments Comments | Categories: Game Design | Autor: JohnEvans