How "Deep" into my Mechanics should I go for Prototyping?

I have created a set of highly extensible mechanics, and in order to avoid feature creep, I only want to expand them only as much as necessary.

What I have

• Nested HitBoxes
• Injury System
• Bullet Penetration
• Player Stats handling and processing
• Base Unity FPS Movement
• Behavior Tree driven AI
• NodeGraph Editor window for Behavior Tree creation

What I don't have

• Item System (can import from another project)
• Weapon System (can import from another project)
• Inventory System (can import from another project)
• Inventory UI
• Enemies
• Prototype Art
• Any kind of Prototype game world
• Building Generation System
• Crafting System
• Medical System

Still a lot of stuff to Develop, and I want to move into a prototyping stage as fast as possible. How far should I take my mechanics? Can anybody give me a little nudge in the right direction for rapid prototyping of more complex game design?

 

Not sure if this should go to the game design forums or not.

My prototyping stage usually includes at least some rendition of my game's most important or prominent features. If you're making a survival FPS, that would be gun play, crafting, and the survival mechanics themselves. If enemy AI plays an important role, or is particularly complex, then that should be prototyped as well. The other listed systems, like the inventory and UI, need only be implemented enough so that the main features function in the prototyping stage. Once you're comfortable with your main systems, you can expand into the others.

You should diagram out each feature in a chart, connecting dependent features. That way you can visually determine which features should be prototyped first, and which ones need only a simple implementation.

 

Get to a point you feel comfortable, play it, evaluate it, then decide to continue developing it or scrap it.

 

I think that you should do some enemies and then make a test world. Play it and see if it's even fun. You really don't need that much extra to prototype. But after you finish that, import those things from the other project and refine/optimize for your project. Then keep building the most important / large features and keep testing as you go.

 

What you listed seem like a typical FPS survival game, what's so new that you need to prototype?
The answer to that question will tell you how much you need to prototype.

 

I tend to prototype my games into existence. Each version is built on the fratures of the previous one. From this point of view the prototype is only done when the game is shipped. It works for small projects.

On larger projects a common technique I've seen is to build a vertical slice. Basically include one of every type of content that will occur in your game.

 

That's not really a prototype in my eyes, though. To me a prototype is used to test something. "Does X work?" "Is Y fun?" "Can Z be controlled comfortably?" "Can W be balanced?" You do the minimum work to answer that question. A vertical slice strikes me as more of a show piece, something you use to show a design you think is already working to attract funding or team members so you can bulk it out into a whole game.

 

What do you not know about your design? Can you form it into a testable question? How can you answer those questions with the minimum effort?

For what it's worth, I wouldn't call the things you've listed there "mechanics". They're "features". A mechanic is something that influences player behaviour. The stuff you've listed provides for forms of player interaction. They're related, but not the same.

 

Different damage model, medical system, stats model, and more elaborate enemy AI...that's actually what I've spent most of my time on as well. Haha thanks.

I have never thought about the differences between mechanics and features. Good info. I am going more for environmental immersion and (eventually) player interaction. I am focusing first and foremost on a single player experience, but I am considering doing an instanced seamless multiplayer system as well. I think it would be cool if players could be brought into other players game without knowing. In this manner, I can dictate how often player interaction occurs.

Can you give me some examples of Features vs Mechanics?

 

Let's say that you have a hunger system. And the environment provides food in some way. The interplay between the player generating food from the environment to solve the 'hunger problem' would be "the hunger mechanic". It's an aspect of gameplay.

The features would be:
- an inventory system to store food items and tools.
- the environmental objects and routines that generate food.
- the ability to use a tool on an object to interact with it.

You can sort of think of mechanics as the meaningful decisions from player's perspective (or how the environment responds to player action to provide challenge) and features as the plumbing required to expose that experience to the user.

Although I could be wrong about the nomenclature.

 

I see. A lot of my mechanics are linked between features it seems. For example-
-Injuries stack modifying a pain variable on character
-higher pain creates more "noise" on player action or passive noise if too high
-noise attracts enemies

So I am still fleshing out the linked features before I can polish mechanics.

 

What specifically is the essential experience (to use Schell's term in Art of Game Design) that you want to give the player? Bethesda's Fallout 3 and BioWare's Mass Effect mostly have the same mechanics: shoot, loot, talk with NPCs, complete missions. Bethesda's team was heavily influenced by McCarthy's The Road, and they did a great job of conveying the bleakness of the world, whereas the BioWare team did just as good a job making the player feel like the hero of an over-the-top space opera. Go as deep into your mechanics as you need to convey the essential experience, and save the rest for later.

 

I don't actually consider the prototype a separate entity. It's basically called a prototype if we're not sure about it. The moment we're sure about it, it's called an alpha.

 

When I'm prototyping I separate things as much as I can and put them into modules that could be used in any project. See how you are considering importing item and weapon systems from another project? You can apply that to crafting and building systems (and more on that list) also as standalone projects that you import into your project as modules

 

I think that's backwards. Work out the mechanics you want, then design features that provide and support those mechanics.

As for what a "mechanic" is, I don't know of any standard definition but I've always thought of them as being the aspects of a game that players need to balance to reach their goal. Eg: if a player has to manage their ammo in a game then that's a mechanic. It effects their behaviour because at the simplest level it limits how much they can shoot, and on more complex levels it can encourage them to explore (find more/different ammo), influence what combat they take part in (to conserve ammo or spend it to get different resources), and so on and so forth. So the ammo counter, being able to pick up ammo, etc. are features, but their combined effect on how the player achieves their goals is a mechanic. That's how I think about it, at any rate.

 

This is what I was tryin to say earlier.

 

The English and their superior linguistic skills strike again.

I don't think they clearly defined it for us in school either. We had to propose several mechanics when coming up with our game idea and the teacher had to say which counted as a unique mechanic.

 

When I started, I always worked on features first. Now I've started to learn to focus on the mechanics and work out the right set of meaningful features required to build the mechanic. It's a subtle difference, but a really, really important one I think.

I think that when games edge closer and closer to simulations, the separation of game mechanics and feature implementation really starts to blur more.

I also think that as gamers, we are so accustomed to looking at really polished mechanics that we start to think that it's a given that they'll just emerge once we've built in all the functionality - but it's just really not true. There's so much more that goes into building an engaging experience than we think at first.

 

Sounds like any software development, right? When people start out they're focus is on how to make things, and you think a lot about features. Once you're good at that you start shifting focus towards what to make, and start thinking more about the overall design.

So, I guess, don't let "mechanics" or any other fancy label or terminology distract you. Like with any other software, first design the experience you want, then figure out how to build that experience. The alternative is to build some pieces and then figure out how to mash them together in a way that makes a good experience - that can certainly be done and has worked for plenty of people in the past, though I suspect it's a far more roundabout way of getting results.