Introduction

With years, I've learned a lot about Level Design, and I've also learned that when facing the complex challenge of creating a level, one can sometimes forget the basics :)

That's why I'm often using checklists, just to make sure that I didn't forget anything important and sometimes bounce on some concept that could fit in and enhance the level.

Reading the following posts, you'll probably think "oh yeah...I already know this, it's obvious", and you'll also probably think " yeah...sure...but this isn't mandatory" and you'll be right :)
The following posts are not supposed to be THE rules of LD.
They are just key learnings and references to be used to avoid mistakes and boost design creativity.

Have fun!

GamePlay Space

This is not about Level Design but I wanted to share the information about this fantastic place indie devs can rent to develop their games.

>> http://gameplayspace.com/

It's built for video game dev so you'll find high speed internet connexion, kitchen, meeting rooms and even enough place to organize events.

What makes it even cooler is that it gives you the opportunity to meet other indie devs, share information and ideas, do playtests and get access to Execution Labs mentors and talks.

It's located in downtown Montreal and share the same space as Execution Labs.

Teaching the player

LEARNING IS FUN!

Even if you've never been a great school fan ;) , I'm pretty sure you'll agree with me when I say that in games, learning is fun !

In fact, learning is at the core of any game, and it's definitely the most fun part of it.

• Learning your abilities and how to use them
• Learning the world and how it works.
• Learning your enemies, the challenges and how you can end up victorious.
• Learning new tactics, getting better at what you do.

Level Design is the main artisan of this teaching/learning and it's an important part of any game.

Finally, learning and mastering something is gratifying and you should never miss the opportunity for the player to feel smart from have learned something new.

THE "IDEAL" TEACHING STRUCTURE

Presentation / Learning : show and explain the player.

Present the new mechanic, the new element and how it works

i.e. Grapple Hook example (part 1 /3

The player is chasing an enemy through a military base when he escapes right in front him by using a grapple hook to jump over a chasm.

The HQ tells the player through radio that those grapple hook devices the enemy used are probably compatible with his gear and that he can grab one in the nearby crate and use it for himself. 

Objective = Get a Grapple Hook Device.

• Show : The NPC shows you the device, how it works and what it does.
• No text : UI is pointing at the crate, voice tells you what to do. Clear game objective : grab the grapple hook device.

Training : time for practice.

Provide a setup where the player can safely use his new technic / ability and train as much as he wants.

i.e. Grapple Hook example (part 2 /3)

The crate of Grapple Hooks devices is on a platform a few meters above ground.

The player can climb there with a ladder and once equiped with the device, the HQ voice tells him how to do it (i.e. Aim for a wood surface and press "Right Bumper").
Next objective = try the device.
The UI objective marker is on a nearby platform only reachable with the grapple hook.

There's more than one platform and the player can can easily spots nearby places with bonuses on it (ammo, health, coins, etc) only reachable with the grapple hook.

• Training Ground : Multiple platforms at various distances and height so the player can train and see how his new toy works :)
• Safety : no risk to die there. (platforms might be above water) You can try as long as you want.

Trial : making sure it's understood.

A challenge to make sure the player has learned.

This part is especially important if it's a chore mechanic that you want the player to have understood : you don't want your player to miss a key part of the gamegplay.

i.e. Grapple Hook example (part 3 /3)

After reaching the distant platform, the objective changes to "Use the Grapple Hook to cross the chasm".

The only way to continue is to follow the path of the escaped NPC and jump over the chasm.

This is trial in the sense that if the player has not understood how it works, he won't be able to pass.

If it takes too long for him (i.e. the player has the grapple hook and he has been down on the ground for 30s) you might want a HQ radio msg to remind him what to do + some extra UI pointing at a piece of wood on the other side if he doesn't progress.

GENERAL THOUGHTS

I won't go into tons of details but generally speaking you should pay attention to

• Learning = Playing. You should never give up on fun for the sake of teaching the player.
  Chances are good that something boring to teach will end up being boring to play...
• Make it fit into the universe : as much as possible make the teaching sequences feel natural and logical in the game flow (narrative, action).
• Playtests is your best friend. When dealing with teaching and tutorial, playtests are invaluable. That's where you'll make sure 100% of players understand what they should.
• Don't overdo it. I mean you don't need to teach players that pressing the left mouse button will shoot the weapon in a FPS. The lighter the tutorials, the better.
  Playtests will help you validate the list of what you need to teach, and what is obvious for players.
• Backward Teaching (?) (hehe...not sure how I must call it ^^)
  So, I just said you don't want to overdo it, but at the same time, you must make sure players have understood and get ready for a reminder in case they've not. i.e. The player keeps shooting his grapple hook at everything. After a few bad attempts, have the HQ radio voice remind him that the device only works on wooden structure + highlight a valid hook point with some UI
• No Text : try to use voice and acting NPC and limit the text to the minimum. I know, I know, sometimes budget and timing force you to go the the cheap text tutorial. But try to avoid it ;)
• Having Fun with what you learned : it's super important that the player can spend time playing with what he just learned. It would be a mistake to chain tutorial elements without any "meaty" chunks of gameplay based on it in between.

BUILDING UP COMPLEXITY STEP BY STEP

Teaching is not just about a new abilities or equipment.

To not overwhelm the player, it's usually a good idea to teach him new concepts, make sure he understood what he has to do before adding some challenge on top of it.

i.e. Player's goal is to re activate the Generators of an outpost to power up the defense systeme.

• Left wing is easy and clean.
  The player learns what he must do activate the generator (i.e. Activate fuel pump, fix a broken valve, manually start the generator)
• Right wing adds challenge on top it.
  The player must do the exact same thing but this time, there are enemies attacking.

THE FIRST LEVELS

Although learning is an ongoing process in any game (learning new tactics, new enemies, new environment, new challenges), the first levels are usually pretty heavy on this side.
And to make things even more complicated, on top of acting as "The game school", those first levels need to be super engaging.

Temptation is great to start building the game with those (they are the beginning of the game after all :) ) but although you should definitely prototype them early, you should not rush on raising the quality too much...or expect to loose a lot of time on it.

• Build them early and playtest, again...and again...
• Keep it in a "prototype" phase so it's easy to adjust and react to player feedback.
• Did you train everything needed for the player to enjoy the game ?
• Is the order good ?
• Maybe you teached too much, too fast...or too early...
• Is the pacing engaging and the experience fun ? Does the learning fit with the narative / game experience ? (i.e. Half Life 1 & 2 first minutes)
• Make sure the player can have fun playing with what he just learned before learning something new. (i.e. just got a jetpack? the rest of the level should be built on that)
• Pacing is critical : you want the player to get hooked and want more.
• ...but finish them last.
• You'll probably need to throw them away + rebuild 10 times...the simpler, the faster.
• You'll have learned from building all the other levels, and you'll be able to use this experience to make those early levels better.
• Gameplay will change...what' was thought important at the end of preprod might have shifted to something else, the story might have evolved...
• Keep in mind that those early levels are probably the most complicated to pull out (everyone want to put its best stuff into it!) You'll have learned how to do it from other levels.

Listen to the players

A quick one today about the importance of player feedback and play-tests.
When I say "player feedback" it's basically anyone but you, including your colleagues or friends :)

Levels are complex structures mixing art, gameplay and narrative, and it would be foolish to think that you can build the perfect one from scratch.
You need to show it to other, and the sooner the better as long as you follow a few guidelines...

WHAT DO YOU WANT TO TEST ?

Whatever the advancement of your work, you should always be clear with the following points

• What do you want to learn from presenting your work?
• Does your current level has what it takes for the player to give you valid answers?

The second point is important : you can't wait for the level to be 100% finish to get some feedback, but you'll usually need enough so it's possible for someone to give you interesting answers.

i.e. To test orientation in your level, you'll need at least some evolved grey box version with early texturing (just so it's not all flat color from ground to rooftops) , shaping, lighting, and the landmarks + key orientation elements (props, etc). You'll probably also want objectives place holders to be functional.

One last point : don't be afraid to disclaim what is NOT there and should therefore not be commented.

LISTEN TO THE PLAYERS

There's Always a good reason...
When players complain, there's ALWAYS a reason for it, so you should always pay attention.

But finding the right problem/solution is the difficult part
The key is to evaluate the source of the problem, and I suggest you'd be cautious with direct play-testers feedback.
I'll give you a quick example : In versus mode multi-player games, players could complain that they are not moving fast enough. They constantly want to sprint and they'd like to run twice faster.
What you must understand is not "Let's make the player run faster" (changing this would affect combat, aiming, lag effect, GD balance + LD scale) but asking why they'd like to run faster?
Maybe it's because the map is too big? Or maybe the time to capture an objective is so fast that you feel like you don't have time to reach it and do anything about it? or it can be because the map structure is chaotic and you feel like you are having trouble finding a sustained stream of interesting PVP action?

And check your play-tester's profile
I mean, if a hardcore multiplayer Call of duty player finds your stealth level boring, it might just be because he doesn't like stealth games ^^

But there's always something behind it
Players never complain for nothing...

THE PATH OF LEAST LD RESISTANCE

Sometimes what you thought would be obvious is not and the majority of players go in the wrong direction or don't understand an objective.

I've seen some LDs deploying tons of efforts to guide the players where they wanted them to go, while sometimes, it's easier to simply follow the player's "natural path".

i.e. You placed the dynamites needed to blow up the bridge clearly visible in front of the commander's tent but  the majority of players tend to go directly to the truck, and it takes them time (and frustration) to finally find the explosives back at the tent. Unless there's some special super important reason, you'd better just move your dynamites next to the truck as it's where players seems to be looking for it :)

PLAY-TESTS ARE INVALUABLE

Play-tests are key to design good levels, not only because it helps you build a better version of the level you are currently working on, but also because it helps you understand others and how they play.

I recommend play-testing your level as soon as possible (start with colleagues) so you can iterate violently if needed ^^ (the very first thing to play-test is accessibility and orientation)

On top of that, there's nothing more satisfying than watching others having fun in the level you specifically crafted for this very reason, so don't be shy :)

To sum it up I'd say

• Never forget the intention / goal of your level
• Know what you want to learn from the playtest
• Listen to player's feedback...
• ...but be the judge regarding what and how to fix problems.
  (ultimately, you know why things are this way and how much it costs to change it)

Puzzles & Level Design

Hi everyone!

Today I've decided to talk about puzzles and how to make correct LD integration of them.

The best thing you can do to understand how to build good puzzles is watch the fantastic Randy Smith's talk from GDC 09 :)
>> http://www.gdcvault.com/play/1333/Helping-Your-Players-Feel-Smart

Please, do yourself a favor and watch the above presentation before going further.

For easy use, here is a quick "recap list" of key points from Randy Smith's talk.

USER INTERFACE

Visibility

• Does the player see / understand the goal and steps to succeed ?
  i.e. I need to place the missing gears into the mechanism to open the doors.
• Does the player see / understand what he can interact with ?
  i.e. I see some gears I can pick up and place on a pannel, I see a lever to activate the mechanism, I see the door that are supposed to open.
• Are the states of the different puzzle parts/steps clear ?
  i.e. Switch is ON/OFF, There's a missing gear, This part is OK, this part is Not OK
• Use Motion, Sound, Lighting, VFX, to catch attention.

Affordances

• What are the logical functions of your puzzle ingredients and are they clearly presented / easy to guess ?
  i.e. A pressure plate. You understand that you can step on it, or drop some weight on it.
• Be careful with hidden affordances >> player logically thinking an object is supposed to do something that isn't working in your game.
  If we take the example of  a crate. You could think you might be able to carry it, stand on it, drop it, open it, break it, push it, hide/take cover behind it, etc.
  Make the functions you need obvious, and provide signs and feebdack so it's clear for the player that those you don't need won't work.
  i.e. You can't destroy it >> It's made of steel.
• Beware of affordances cluttering in scenes where too many visually appealing elements could create noise >> do the important parts clearly stand out or are they lost in the scenery ?

Visual Language

• Avoid any confusing shape / size. If your player can jump 1,5m high max, any steps should be lower than 1,5m --> I can jump on it or greater than 2.5m --> it's clear I can't jump on it. 
• You can use colors, shapes and visual materials to highlight key elements properties.
  i.e. I can destroy wooden crates, I can't destroy metal crate. In some cases UI might be part of the solution. i.e. red interdiction sign if you are trying to shoot a friend.

Feedback

• Make sure there's positive feedback when the player does something good
• ...and negative feedback if you are using elements incorrectly (as important!)

Mapping

• Make hidden connections visible to the player
• Create a direct physical link.
  i.e. A valve triggers a mechanism --> a pipe visually connects the valves and the mechanism.
• Abstract Connection / Similar Design
  So the player can make a mental connection.
  i.e. A blue ball in the middle of 10 yellow balls might be the one going into the blue hole --> here, the color code create the mapping.
  i.e. Left switch command the left door, right switch the right door.

PUZZLE STRUCTURE

• Write down the steps the player has to go through to solve the puzzle
• For each step, identify the things the player needs to know
  i.e. Step = put a crate on a pressure plate (to further open a door) : does the crate exist? Can I move it? Is it heavy enough to trigger the plate? where is the pressure plate?
• Try to work on the UI principles so they are OK for this step
• Adjust according to playtests.
  i.e. players don't understand the door opens when they drop the crate on the pressure plate. Solution, make sure Plate>Door mapping is visible + Increase positive feedback when the pressure plate activates.

REUSE FAMILIAR STEPS

• Basic chunks of puzzle that are enhanced by extra steps / mixed with other chunks.
  i.e. Puzzle 1 = Put crate on pressure plate to open the door >> Puzzle 2 = same but you need to find a way to reach the crate.

End of Randy Smith tribute :)


-----------


Now, on top of this, I'd like to add a few extra points that can help when you integrate puzzles in your games.

I won't talk this much about game where puzzle is the main focus.
In this case, the "puzzle LD job" is mostly about breaking down the various puzzle systems / complexity, combination and think about when and how each new element should be introduced, if possible in a clever and exciting way ;)

Puzzle are usually more problematic when they appear as exotic system in other gameplay based games. (i.e. FPS, RPG, etc)

MAKE IT FIT INTO THE WORLD

A mission is often about living an experience, about being immersed into the game world.
So, even if a puzzle perfectly fits at a certain point in your macro LD excel sheet in terms of timing / pacing, think twice before forcing a puzzle into a place it doesn't belong / make sense ^^

TIPS TO DEFINE PROGRESSION STEPS
From the initial/basic puzzle design, you'll want to build up variations and complexity.
It usually starts by breaking down what mechanics you want to teach, and then removing some of the key needed functionality.
I've found the following to be recuring elements you'll want to play with.

• Player Mobility / Puzzle ingredients accessibility
  What if I restraint player's mobility? What if he can't move freely around to solve the puzzle?
  i.e. I need to push a crate on a pressure plate...but the crate is on one side of a river while the plate is on the other >> extra step = lower the bridge.

• Line of Sight / Visibility
  I need to see one of the puzzle element to solve it (shotting at trigger, or activating device at the right time) but there's something blocking my visibility, or I can't see my target (no light)
  i.e. I have to shoot a timed trigger when I'm next to the switch but wood planks are blocking my line of sight when I'm standing near the switch. >> extra step = Blow up the planks 1st.

• Sequence and Anticipation
  What's the puzzle sequence? What's the correct order to do things?
  i.e. Step 1 = I clearly see the switch, I activate it, the platform moves but...that's it. Step 2 = I shoot a trigger and a crate falls in the river... Oh! I see I must first activate the switch (step 1) then shoot the trigger (step 2) so the crate falls on the moving platform.

You can also use action gameplay fundamentals if it fits in the game you are creating.

• Synchro : you must do something at the right time. It's about rhythm and catching the frame.

• Precision : you must be precise with your controller. Aim carefully, do a precision jump, etc. Time doesn't matter, just be precise.

• Speed : you must react quickly and possibly learn how to chain multiple action in a way efficient enough to succeed.

And of course, all those can be mixed for extra complexity/difficulty


CONFINED SPACE
It's usually a good idea to constraint the player into the smallest viable area (smallest being a special screen :) ) to solve the puzzle so he knows the solution is there and he didn't miss any key elements before in case he gets stuck.


QUIET PLACE
It's usually a good idea to avoid any fighting or other mind disturbing gameplay while in a puzzle area so the player can focus on what he has to do.
I say this, but of course, it can be cool to present the exact same puzzle configuration a second time, but this time, there's the extra challenge of dealing with disturbing gameplay elements at the same time :) (but at least, the player knows what to do)


EMBEDDED SOLUTION 

Puzzles usually have this annoying problem that they are not open in nature : as a player, you fix the puzzle the way it has been designed...or remain stuck.
As a designer, you don't want to give the solution to the player, but you can find a way to provide hints directly in your level.
If the player is good enough : he won't need this optional extra challenge.
If the player is struggling with the puzzle, he 'll just need to do some "extra effort" that are not related to the puzzle and be rewarded with a hint.
I.e. Fix the pipe network to bring steam pressure to the cooker...and optionally, you can search the local desks and cabinets around to find "maintenance clues" left by the workers.
Always better than having to search the internet...or worse, give up the game because you are stuck there.


THE SPECIAL FLAVOUR IN YOUR LEVEL
It can be cool to introduce a simple "Puzzle element" concept in your level and then use it with incremental difficulty 4 or 5 times.

• It gives a special flavour to your mission
• It feels good for players to fix the "easy" puzzle at each step.
• Feels more integrated in the mission flow and less like "that's the puzzle room".
• Forces you to better think about the puzzle integration in your mission logic (rather than an one timer puzzle artificial plugged somewhere where it doesn't necessarily make a lot of sense)
• Make sense on the production side : the system has been developed and tested >> better use it more than once !

i.e. High security building. Some doors only open when the scanner next to it is presented a valid magnetic key. Gates open when you stand in front of scanner, and close when you leave.

• Step 1 : Learning : the scanner is right next to the gate. Just stand in front, and rush through the gate. 
• Step 2 : This time the scanner is further from the gate...too far to rush.
  But patrolling robots are passing next to the scanner every 10s, triggering the opening of the door for you. Just wait and pass through.
• Step 3 : No visible scanner next to the gate, but going on a platform slightly above you find a security console with a scanner. Player needs to walk up there and jump down / rush through the gate when it opens.
• Step 4 : Scanner too far from the door and robot path to the scanner is stuck. Clean the robot path so it activates the scanner.
• etc.

PUZZLE AS "ON DEMAND" CHALLENGE
I mentioned it in my Challenge on demand article, but due to their exotic nature, puzzles are good candidates to gameplay on demand / optional side content.
If the player doesn't like it (i.e. Your game is an FPS, and as a player you might just want to blow things out, not solve puzzles) he can skip it, and it's less of a problem if it's too hard.


AESTHETIC BEFORE COMPLEXITY

If your game is not about puzzle and they are the "exotic part", you should focus on keeping your puzzle easy but making them look super cool and having surprising / impressive effects on completion.
It will then provide this "breath of fresh air" + "Feeling smart" feeling you want without risking to block the player.


ANALOGUE SUCCESS vs 100% EXACT PUZZLE

Puzzles don't have to be 100% scripted in one single way to complete it.
You can measure success through some analogue meter (pressure, data transfer, energy level, etc) so there are more ways to solve the puzzle than needed.
i.e. Raise pressure level in a system to the green area (60% pressure min) by opening / closing valves.
In this kind of puzzle there can easilly be more than one solution to the problem. There might be a 100%  pressure solution (and the player should probably gain a bonus from finding it) but 60% is enough to pass.


PUZZLES = EXOTIC GAMEPLAY = $$$
Unless your game is about puzzle solving, be aware that puzzle are kind of "Exotic Gameplay" and therefore require extra mechanics, UI, scripting, etc...
Puzzle also require some extra QA and play testing.
All this doesn't come free :)

About Coop - Part 3

COOP DYNAMIC = PING PONG
As always in level design, pacing is a critical part, and on top of the standard action curve + attention to contrast + following the blueprint, you'll want to pay some special attention to the coop dynamic.

• Ping Pong
  Think of coop missions as a ping-pong game where players are constantly sending the ball to each other. Each player must be the key progression element on a short regular basis.
  i.e. "One pulls the lever to keep the door open, the other steps in, and moves a crate to prevent the door to shut down completely, and so on and so forth..."
  The last thing you want is one player constantly being the centre piece to any action.

• Breaking the team......temporarily ;)
  It can be interesting to setup "one time" single player traps to spice up the action.
  As one player is struggling with the trap, the other can help and save the day >> good for the team emotional bond.
  i.e. first player falls through the floor. The other has to help him while he is being attack + throw down a rope to help him out.
• Track Archetype vs World interactions How each player / archetype can interact with the world and make the mission progress, where are specific ammo/resources placed. Unless intentional, you don't want one player/archetype to get all the fun and attention.

• Player Exchanges
  if your game allows for direct player interaction (sharing ammo, reviving or healing friends, Skills synergy, etc) try to build situations highlighting them. They build up the team feeling.

COOP PATHS = I SEE YOU

• Together
  80% of the time if not more, players should share the same space / action.
  Then, you'll sometimes want to destabilize your players by forcing them away from each other.  If you've created an efficient coop setup this separation should be lived as a moment of stress (remember players should feel that they can't make it alone)

• Parallel

• Playing together in the same space doesn't mean you have to step on each others toes.
  I strongly suggest you open up some space by building parallel paths where each player can see each other.
  i.e. facades/rooftops on each side of a street, cliff paths separated by a torrent, etc.
  This way...
• Players aren't stuck on the same rail
• They still follow each other / see each other
• Clear mapping / good control of "who does what" (if you are on path A, you'll deal with actions related to it)
• Opportunities to provide different view angles on the situation >> reinforcing player communication

OPEN SITUATIONS

Opening the playground in coop action means you must pay some special attention to a few points.
You don't want players to just feel like they are "in the same world", you want them to be part of the same team.

• Don't break the unity
  One of the risk is to break the team momentum by having 2 players aiming for 2 different goals. i.e. While player A needs player B to solve his current pb, B on his side is waiting for A to progress. Who should move and join the other?
  Try to avoid that ;)
• Strong accessibility needed As soon as people aren't together, you must make sure it's easy for them to catch up, with strong landmarks and clear paths.
  Nothing worse than having 1 player waiting for the other because he lost his way :-/

• Make it a dangerous place
  One way to solve the problem is to have a place too dangerous to be explored alone. Players have the freedom...as a team.

• Coop Gates
  Another solution is to use Coop Gates : player can explore and move around solo, but they'll soon find a "coop gate" requiring the team to be passed.
• i.e. Objective = Find X batteries to power the door system.
  Both player can spread and gather the batteries, but they'll soon have to regroup to 1) grabb some batteries they can't reach alone 2) complete the objective as 1 player protect the other while he links the batteries.
• Game Design needed = Communicate + Interact
  Being physically together is not the only solution :)
  What's important to the coop feeling is player interaction + feeling like you are part of a team.
  With the right systems + rules allowing player to both communicate + Interact, Game Design can help building a strong coop experience fitting in a true open world.
  i.e. Player A in the corridors needs player B in the control room to hack the door so he can progress, while Player C triggers orbital strikes to protect and help his friends.
  Just make sure the roles are clearly defined.

COOP TACTICS

• Win or Loose together
  As much as possible, try to build your levels so understanding tactics and coop actions > pure skill.
  This is to limit the cases where one player would blame the other for inefficiency, or carry the game because he is too strong and the other one feels useless.
  Ultimately, you want the team to figure out the solution together, and to win together, rather than pointing the finger at one particular player.

OUR DEAR STREAMING FRIEND :)

• Careful with streaming : usually, for the sake of simplicity, you'll want both players in the same loaded area. >> Use a simultaneous coop action + cut scene to synch all players
  i.e. Everyone must push the truck...and when the bridge falls under its weight, a short cut scene makes all players stand on the same side of the broken bridge with no way to backtrack.

ROLE SETUP MUST BE SUPER CLEAR

• If there are any key position / role to be filled in your setup, it must be highlighted and super visible to the player that there's conceptually a Seat A and a Seat B.
  It helps organize things naturally between players + everyone has a key role.(I feel special!)
  Use lighting, colors, animated elements, UI, etc. Anything to put emphasis on the key roles / positions.

COMBAT TIPS

• Enemies Facing = front
  I know, one would think that 2 players can easily cover 2 different sides, but it's never easy in a video game (lack of communication, you don't understand what your friend is doing, etc), and this should be reserved to special setups.
  After all, you'll never feel more in a coop game than if you see enemies you haven't shot fall in front of you :)

• Enemies facing = Larger
  If being attacked in the back isn't recommended, enlarging the battle front compared to single player is a good idea so both players aren't shooting the exact same spot.
  Try to make it so each danger zone is visible to the side of the other player field of view.
  Vertical depth is especially good as the result of what happens above can fall down and be naturally visible below.

• Short Delayed Threat = Simple Team Communication Opportunities
  Any situation where a player can warn the other (about some threat or opportunity) is good to strengthen the bond and create a connection between players. i.e. "Grenade!"
  Just make sure that the delay is long enough : it's more a matter of making players communicate than forcing them to react in a millisecond.

• Not everyone doing the same thing (people love being special)
  Think of tactical setups requiring different player roles
• Snipe + Melee
• Above + Down
• 1 player lures the bad guy, the other shoot him in the back.
• One must do something while the other covers him
• Present the setup once without enemy (learning) before introducing enemies.
  i.e. Doors are locked and must be hacked. One player will hack the door, the other will defend.
  The concept of "I must hack the door" should be presented and completed once right before the combat aspect jump into it.

PUZZLE = STEP BY STEP & SIMPLE

Don't forget that coop puzzle require some intense communication between players (voice, laser pointers, UI, etc) and although 2 brains are better than 1 to solve a problem, there's a serious risk that only one of the players finds the solution and have fun, leaving the other one behind and a bit frustrated.

• Step by Step
  By building a step by step puzzle progression is important. This way, you make sure that both players are working on the same problem at the same time. (part of a team)
• Parrallel paths and Visibility as a coop tool
  Work on visibility to make the solution easier to find for the player on the path not directly related to it.
  Again, it's not as much about personal skill and more about team cooperation.

• Archetypes abilities as Puzzle Keys
  It's always better if players can use their specificities as key to unlock the puzzle gates.
  It naturally organize things and highlight players specificities.

Oops!
I just realize this took much longer than expected, and I only mentioned a few key points and pitfalls to  be avoided. At least I hope it helps starting in the right direction :)

Merry christmass

I won't be around for the next weeks, so new articles might become rare.

Meanwhile, I wish you all a merry Christmas and a happy new year full of gaming fun :)
(I hope Santa won't have forgotten my Elite Dangerous copy :P)

Cheers!