Switch Theme:

Rules Design Discussion- Genre Driven Design  [RSS] Share on facebook Share on Twitter Submit to Reddit
»
Author Message
Advert


Forum adverts like this one are shown to any user who is not logged in. Join us by filling out a tiny 3 field form and you will get your own, free, dakka user account which gives a good range of benefits to you:
  • No adverts like this in the forums anymore.
  • Times and dates in your local timezone.
  • Full tracking of what you have read so you can skip to your first unread post, easily see what has changed since you last logged in, and easily see what is new at a glance.
  • Email notifications for threads you want to watch closely.
  • Being a part of the oldest wargaming community on the net.
If you are already a member then feel free to login now.




Made in us
Battlefield Tourist




MN (Currently in WY)

Greetings Designers,

I don;t have a fully fleshed out topic for discussion this time, but I wanted to get us back into a regular cadence of design discussion in the design discussion board. So there you go...

Let's talk about the sequence in which you design the game processes. Most of us are not trying to design generic game systems, but are instead focusing on a specific time-period, genre, "feel' for a game. Therefore, how do you approach the game design process differently based on genre? Do you start with the basic core concepts and then build the chrome, do you think about units and build on how they should interact, or do you start with fluff and try to build from there? Do you start with the end result of an interaction in mind and fit the genre to the mechanics?

Clearly, there is no "wrong" answer to this but instead to get us to reflect on our design processes and to appreciate differences of approach. I will share some of my thoughts in a few posts.

Please discuss.


Support Blood and Spectacles Publishing:
https://www.patreon.com/Bloodandspectaclespublishing 
   
Made in gr
Thermo-Optical Spekter





Greece

At the moment I am working on an odd sequence, I have the gender and the big picture set and now working on the rules so I can work the IP details according to how the rules are set.
   
Made in us
Incorporating Wet-Blending





Houston, TX

Gender? As in the game's gender? Please explain.

I generally start by trying to outline broad goals. Usually this will relate to player expectations (IE this is a tactical skirmish game designed for 2-4 players fielding 3-12 models per player and with each game lasting no more than an hour or this is a grand fleet simulator designed for any number of players and 1 referee to be played over several days). I think you really have to look at the scope of the game in terms of time, players, and pacing before you can hope to start making coherent decisions. If you know you want a fast playing game that keeps multiple players engaged, for example, speed and simplicity will be paramount. If the game is about commanding armies to seize provinces, you probably don't need to worry about man to man combat and should focus on rules reflecting effective movement and supply of larger bodies of troops.

-James
 
   
Made in gr
Thermo-Optical Spekter





Greece

Genre not gender.
   
Made in us
Battlefield Tourist




MN (Currently in WY)

 jmurph wrote:
Gender? As in the game's gender? Please explain.

I generally start by trying to outline broad goals. Usually this will relate to player expectations (IE this is a tactical skirmish game designed for 2-4 players fielding 3-12 models per player and with each game lasting no more than an hour or this is a grand fleet simulator designed for any number of players and 1 referee to be played over several days). I think you really have to look at the scope of the game in terms of time, players, and pacing before you can hope to start making coherent decisions. If you know you want a fast playing game that keeps multiple players engaged, for example, speed and simplicity will be paramount. If the game is about commanding armies to seize provinces, you probably don't need to worry about man to man combat and should focus on rules reflecting effective movement and supply of larger bodies of troops.


I agree, ideally this is what you want.

However, I find that I frequently start by thinking about what units I want in the game first and then start to work backwards. This tends to help me think about the scale i need and the speed of play.

Support Blood and Spectacles Publishing:
https://www.patreon.com/Bloodandspectaclespublishing 
   
Made in us
Decrepit Dakkanaut






SoCal, USA!

When I'm creating a game, I usually start with some kind of statement of what I want to do, what my goals and objectives are. KOG light was created as a simple way to use a certain set of miniatures, and deliberately ignored genre until I shoehorned a background for it as its own game.

Since then, I've started working on a different game, a racing game. Genre-wise, I'm aware of how Car Wars and other driving games work, and I'm breaking with a number of conventions. Instead, things are structured around a much more detailed requirements statement. I have a fairly-detailed technology background that clarifies about what is possible. I also have numerical data that I'm using to drive target results for verisimiltude, in terms of how the vehicles should behave as they move.

So, to answer the questions:
- Yes, I'm starting with core concepts and will be building in necessary chrome later.
- Yes, I've got a clear concept of what my units are, and how they should interact.
- Yes, I've got a clear background piece that I'm building from.
- Yes, I've got some idea of gameplay and have tweaked background elements accordingly.
"All of the above."

It's an iterative process of successive refinement, where I address various elements, fleshing them out one by one, bit by bit.

   
Made in ca
Posts with Authority




I'm from the future. The future of space

My sequence and design propaganda:

1) Identify what elements I want to represent. Say, for example, I'm doing a Gundam game (big space robots that fight) and I've made a list of scenes in the tv series that I want to have happen on the table top. If it's a historical game, then it will be a statement about history. An interpretation. Like "on the modern battlefield, if you can see something, you can destroy it." There will be more than one element, so it's brain storming time and then ranking in terms of priority.

2) Figure out everything that is needed to model the chosen elements. These get priority. And figure out everything that is needed for the things that get priority but are themselves not a priority. I do not try to make a framework for modelling reality. I don't want to model everything, that's silly. I want to model the elements I have selected to be priorities. This can be really hard work and can involve long lists of things. Take the Gundam example. I've got movement relative to one another. Common ranges at which scenes in the TV show are framed. All sorts of weapons to model. Beam sabres and close combat and how combatants shift between the archetypal ranges as shown in the animation. The main reason you don't want to model everything will become quite clear as modeling even a few elements will bring to mind tons of things you need to consider.

An aside on simulation:

Ask any actual professional simulation designer and they'll tell you good simulation is about only representing the elements in the environment that matter to you, and most certainly not about representing everything. As well, this is a good point to take the time to forget useless definitions of words like simulation that are based on pop culture ideas rather than on what actual simulation designers do.

Actually taking a moment to jettison baggage about representing or modeling elements that might limit design is a good idea. The most likely example is some conflation with simulation and complexity. Real simulation designers try to limit complexity, not multiply it. Pop culture notions of simulation = complex are not held by people working in the industry (be they industrial, education, military or any other branch of simulation and modeling). Simulation games are also very well explored by these people as they know that the best simulations are engaging and interesting.

This is also a good time to forget about limiting ideas like "wargames can't be historical" or "it's just pushing toy soldiers around on a table, so don't worry about getting it right."
*Do* worry about getting it right. Getting it right is what the game design process is all about: allowing people to make meaningful decisions rather than meaningless ones. Identifying elements and then representing them rather than claiming from the get go that such representation is impossible. You likely won't ever accomplish what you believe to be impossible.

On the flip side, don't ever see your game as anything other than a representation of the chosen elements through abstraction. And that's good enough. It's good enough to call it accurate. If my Gundam game recreates the types of things that happen in the fights in the TV shows, it works, but it is not a TV show. Representation to allow interesting decision making is fun and is a re-presentation of the chosen elements. Acknowledge that by choosing elements to model you are failing to chose other elements. Elements that may or may not have had an impact in your source material. It's okay to skip over an element that had an impact because you are more interested in a different element. You can't represent everything so choose your priorities.

People have used claims to realism and "accurate simulation" to beat other people over the head, so don't do that in your rules document. Making claims about what your rules do is *marketing*, not game design. Stick to design during the design process.

3) Imagine the decision making of the player as they play. And what they actually do physically in terms of moving models, measuring, rolling dice. Basically what the actual people playing will do, say and think while playing. And what actual physical objects will be on the table top (and the size of the table top). Basically all the real world stuff.

4) Make sure the elements in 2) mesh with both 1) and 3). Make sure that no element has crept in priority to the point where the decision making has shifted onto something I don't actually care about and ensure that the representation has stayed on my chosen element and not drifted onto something else.

5) Make a list of everything that has to happen on the table top. Use this to make a turn structure. I happen to favor games where not everything on a given side acts in a single turn and players just prioritize things. As long as everything that has to happen can have a place, go forward with it. I also prefer games with little wait time while the other player does stuff, so I try to find ways of having back and forth. Reactions are likely to be on the list of things that will have to occur.

5) Make a list of results for each operation of the game procedures (the stuff that has to happen). And lists of factors that might enable additional results or prevent certain outcomes from occurring.

6) Play without a randomizer and just go through different outcomes and see how they feel to the participants. For example, the recon vehicle goes turret down and takes a peak while the player also gets a report from an overhead gunship. No contacts, play it out a bit. Reset, contacts found this time. Play it out a bit. The gunship fires on something. Does it hit, does it destroy? What results might happen? Try them out. Don't worry about dice or odds right now.

7) Devise a means that the player can take the factors and make meaningful decisions about what to do. In the historical example, the player might have to consider what optics their recon vehicle has or how far away the terrain they want to scope out is (measuring range happens at some point, for example). Or know how the terrain works so they can go turret down and just peak over a ridge. Or the player might take into consideration what a satellite or a high flying aircraft has spotted.

A more simple example might be whether or not the gun in a given tank turret is up to the task of taking out a given enemy tank.

8) Come up with stats and randomizers. While many people think of this as the meat of the game, I actually see it as almost an after thought. It's a means to an end. Stats and randomizers just need to not become problems. As long as they resolve what needs to be resolved without causing procedural problems (as in, problems with what the participants are actually doing or how decisions are being made) then that's probably good enough.

For example, a convoluted procedure with lots of steps might cause a problem in terms of the procedures being too slow or causing decision making paralysis because there are too many factors to consider. Or the players might start making decisions based on the procedures of the rules rather than the disposition and capabilities of the soldiers on the table top. This can be desirable, but I think it's best to keep it at most a step or two removed. If a rules procedure is based on the table top and people make decisions based on that, that's probably fine, but if there's another procedure based on the the first procedure, I think the representation might be in danger of breaking down. The way to have nested procedures (if you are going to have them) is to have points where you refer back to the table top. The situation you are actually trying to resolve. A classic example of this is finishing the shooting procedure with cover saves. You actually have to refer back to the table top and at this point the procedure can be reconnected with the miniatures on the table..

Or an opportunity to violate the basic premise of the game (item 1). If I'm trying to express that being seen on the battlefield is dangerous but create a quirk in the rules that makes being in the open better than being obscured in terms of a dice roll needed for something to happen, I've got a problem.

9) The design goals need to be used as a guide to double check the system. If I want a game where the tanks of one side can only be likely damaged at very close range (say Kursk, 1943, the Soviet T-34's gun vs the new German Tiger tank) but I don't have something that takes range into consideration when it comes to determining if the armour is defeated by an attack, I've missed the design brief. If I say X matters, I need to check to make sure it does.

10) Commence playtesting. During which concentrate on variable isolation. If you're testing the core system of moving and shooting with soldiers with rifles, a tank doesn't need to be on the table. You'll get to playtesting with all the different elements at once in time.




Automatically Appended Next Post:
Another thought on genre. Genre is about expectation. If someone goes into a movie thinking it is a certain genre then they are expecting things to be there and other things not to be there. Boundries can be pushed and rules bent, but if you shatter expectations you'll lose touch with the genre you are interested in. So if I were to go through my design sequence with expectations of the participants in mind given the subject matter, it would probably be part of 1) where I choose the elements I'm going to include.

I also don't think settings or historical epochs are genres. You can have stories of wildly differing genres set in the same historical period or fictional setting. A gritty investigation into a resistance cell in Paris in 1942 can be very different than an action movie based on the some conflict. In first the entire movie could take place inside an interrogation chamber while the 2nd might have big explosions, leaping from trains and cabaret dancers with unknown loyalties.

This message was edited 8 times. Last update was at 2017/02/23 17:10:02


Balance in pick up games? Two people, each with their own goals for the game, design half a board game on their own without knowing the layout of the board and hope it all works out. Good luck with that. The faster you can find like minded individuals who want the same things from the game as you, the better. 
   
Made in gb
Longtime Dakkanaut






Cheltenham, UK

I start from the player experience. How long do I want them at the table for this game? How much time should they need to spend prepping before play? How much time should be spent on book-keeping between turns?

I tend to prefer as stripped-down an experience as possible, myself, but some people really do love that whole "pouring over a codex" thing. Similarly, I like tidy battlefield with a minimum of counters and markers but, again, some people love that stuff.

Once I've got a clear idea of what I expect the player experience to be like, I then create a narrative in my head of how a typical game would play out. What sort of tactical and strategic challenges should a player face? What parts of the game will go quickly and what parts will go slowly? What sort of story will the game tell? How will they know who's won? What will tell them the game is over?

Only once I've got these things in my mind do I turn to imagery for the game.

I create Pinterest "mood boards" for all of my games, bringing in art, miniatures and videos that all inspire some aspect of the game. Perhaps a character who ought to be possible, or a piece of equipment that should be included, or even an example of a combat or activity that the game should capture (such as an impressive piece of parkouring, or a catastrophically exploding tank).

Only then do I start the actual process of writing mechanics. And I typically find that the core mechanics are done and dusted within a couple of hours if all of the above is already in place. After that, it's just admin: pulling together the strands of imagination and tweaking in response to play-testing.

I spend a surprising amount of time rolling dice and staring into space.

   
Made in us
Widowmaker




Somewhere in the Ginnungagap

Generally speaking I would begin with a problem statement. That problem statement would help inform me if I should start with theme or mechanics. Here are two examples of what I'm talking about from designer Antoine Bauza. For 7 Wonders Bauza started with the problem statement "What if a game played well with seven players?" (mechanics driven) where as with Terror in Meeple City started with how can you make a game that captures the feel of the classic arcade game Rampage? (Theme driven). From there I would normally implement an Agile workflow like Scrum other wise you might run into the scope monster.
   
 
Forum Index » Game Design
Go to: