Iron Chef Carnage

I loved Maniac Mansion, and that was a game that didn't think twice about completely screwing the player hours after they messed up by making the game impossible to beat due to a bad decision.  Heck, you could walk away from the character selection screen and already be totally boned, and nobody would tell you.  Even though there was 0% chance of success, you were allowed to flail around and try to solve puzzles that were absolutely insoluble.  Is that good design?  Maybe.

I'm assuming that gear with determine abilities, like you can't whittle a point on a stick unless you have a cutting tool, so starting with a knife will save you the hassle of knapping a stone into a crude blade (or an awesome blade, if the PBS documentaries I watch know anything about master-level stone tools).

 

You say there will be perma-death, but will the client/account/whatever track achievements in the past?  Just like the new Starcraft automatically sends your workers to mine, maybe a thousand repetitions of the first twelve seconds of the game would allow you to skip those chores.  Say I spawn in with just the clothes on my back.  After fifty tries or so, I'm going to have certain elements locked down, like finding tinder or a walking stick.  Have a tracker for the number of times mundane tasks have been completed--"Made a walking stick within five minutes of spawn:  23/50"--and when the criterion is met, just let the guy spawn in with a walking stick.  You know he's able to get one, why waste his time?  He'll never not be able to get one.

 

Of course, you have to qualify it, so a super-dedicated player can't spawn with an Iron Man suit and a Ferrari, but taking away some of the entry-level chores and letting a player get back to work being awesome (or catching Cholera, whatever) would be a nice reward for past successes and take some of the sting out of permadeath.

 

You could even balance it further by employing a "point" system.  Like Waterlimon said, a character who had time to prepare would have a wildly different kit than one who was caught with his pants down.  How about a system that lets players pick a few items from a list, spending points to build their kit.  A book of paper matches is cheaper than a butane lighter, a box cutter is cheaper than a survival knife, and if you want that survival knife you have to accrue credit through in-game effort, since not everyone has a freaking Rambo knife laying around.  I might spend my points on some spam and a canteen (old Dasani bottle if I want to save a couple points) and mandals, but once I've got my act together and know how to get food, I can stop bringing the spam and spend those point to upgrade my footwear to a closed-toe hiking shoe.  Once you get awesome at survival, you can spend all your points to start with an unlockable canoe and play the game in a totally different way, hard-mode with water travel.

 

You could even use the unlock system as an incentive to the players.  Say you can only get certain unlocks if you start in a more austere way.  Yeah, you can spawn with a .22 rifle and fifty rimfire cartridges, but just like playing GoldenEye with cheats enabled, you won't get any credit toward further unlocks while you're in easy mode.  If you start naked, you get a difficulty bonus and mad props for being a true woodsman.  If you split the difference and start with a cargo vest and a hatchet, then you can accrue credit towards achievements in a normal way.

 

I really like your idea, and I'm hoping the project moves forward so I can hear more about it.  Have you given any thought to the tools and restrictions regarding inter-player communication?  It's been a worm in my brain lately, and I'm on the lookout for views.

A state diagram is a good place to start.  Make sure you can make a game out of it before you invest the considerable resources required to represent it to the player.

 

I'm going to call this an impossible task, because of the proliferation of options.  Even assuming that you got the system and interface perfectly modeled and intuitive to the player, asking someone to play such a game would require them to get good at the actual grappling contest, making your game (this subsection of it, even) as opaque and intimidating as a top level flight simulator.  Maybe Royce Gracie could play and enjoy the game, but your average audience member is going to feel like a ten-year-old playing career mode in Madden:  He'll be bad at the 10% he can make sense of, and just be pushing buttons at random for the other 90%.

 

Try to boil the contest down to some rudimentary elements.  Whip up that state diagram and try to limit the actions in each state to a handful, so your players don't have to think about the exact positioning of all their limbs at all times.  Maybe the dominant fighter has options to press his advantage with some direct attacks, to protect his advantage with some control moves and to disengage and transition to a striking fight.  The dominated player can defend against attacks, attempt to take control by shifting to a state where he's dominant, or escape and transition to a striking fight.  In terms of basic game dynamics, it would wind up looking like a blend of rock/paper/scissors with dice rolls and a tug-of-war, where you're competing for the resource of dominance and then spending that dominance to play out the larger contest of attrition.

 

So if my fighter has good reach and is long-winded, I'll prefer to keep my feet and stay mobile, while a stockier combatant might prefer to take the fight to the ground and keep it there as much as possible.  I'd be willing to absorb a few hits or spend some stamina to disentangle myself and get back to where I can land punches, while he'd be willing to charge through my attacks and grapple with me.  If he puts me on the ground, I might not even try to compete with him, and instead direct my efforts toward getting away, accepting that he'll get some good shots in while I worm my way out of the situation.  If he sees me trying that, he'll devote some of his time and energy to delaying my escape, allowing him to do more damage before I resume kicking him in the teeth.

 

Balancing will, of course, be a nightmare, and you'll have to ensure that the choices a player makes are numerous and varied enough to allow for strategy, without becoming so myriad that it turns into a guessing game.  Turn-based is a good idea, and I love your idea of having the turns themselves change length based on the situation, giving another incentive for a player to keep control of the bout.  I think a lot can be done with that idea.

You should think about whether you're making the ores as a means to regulate acquisition of materials or as a part of the world.  In Anno or Civ or whatever, you are basically making an "Iron Farm" and just jumping through the appropriate hoops to get the material you need.  Calling it "Iron Ore" is fine, and you can just stick it around the map to make hotspots for control and development.

 

In the Dwarf Fortress example, if you want Iron, you have to harvest either Magnetite, Hematite or Limonite, all of which can be used as rocks for building and crafting, and which can be processed at a smelter to produce iron bars.  Some ores, like Galena, are more complex, since smelting that produces a bar of lead and half a bar of silver, but you can use the ore with gold nuggets to make electrum, complicating the tech tree even further.

 

I'd never suggest that anyone make a mineral tech tree as complex as DF's, unless you're a sadist or are making a game about geology, but the "list of ores" question can be answered with the wiki links above, so you need to focus a bit more on the uses of ore in your game before you can decide what you need.

I'm definitely a fan of having different types of locks. Picking a deadbolt isn't the same as picking a set of handcuffs, after all. Making it abstract will work well if the game is otherworldly, like a futuristic sci-fi lock or a magical dwarven lock or something, but having a block-sliding minigame to see if I can pick a conventional tumbler lock would feel very strange indeed. I don't think I'd like that. I'd rather just have a progress bar.

One thing I've been thinking about for a lockpicking minigame is a tree system. It's like a brute-force combination breaking system, but dressed up a little bit. Here's the naked mechanic:

Have the combination for opening the lock consist of four digits between one and three. That's 81 different possibilities, so it'll take a long time to get through them all. Players can get good at mashing the buttons to speed things along, and character skill can help out by verifying a correct choice on one of the numbers, effectively reducing the complexity of the puzzle by 2/3 for every level in the skill. So you put in 1-1-1-1, 1-1-1-2, 1-1-1-3, 1-1-2-1, and on and on and on until it pops open. When you get better, you can test the first digit individually, so you'll get it in three tries max, leaving you with no more than 12 tries for a lock, instead of 81. Here's how you dress it up:

Your guy kneels down by the keyhole, stick his picks in there and you've got three buttons to hit. One is a sort of prodding motion, one is a twist, one is a rake. You flail wildly against these buttons until the thing opens. With character skill, you'll be able to "feel out" a given tumbler and solve it before moving on, so your picking will become more deliberate and efficient. You don't need a little window to come up showing the lock's innards, you don't need an on-screen prompt, just a character animation and a few different sound effects to convey the needed information to the player.