Archive for the ‘Game Design’ Category

h1

Early Wizorb Design Sketches

May 3, 2012

These are the very first ideas set down on paper for Wizorb. Mostly scribbles in Frenglish. Lots of this have changed throughout the development of the game.

h1

Level Design In 11 Points

May 5, 2011

It’s been a while since I’ve written something about game design. So, I decided to write an article describing how I proceeded when I made the levels of Ninja Senki.

  1. I played many MANY platformers and studied how their levels were built. Doing that kind of research is enlightening and fun ^_^.
  2. I designed a bunch of micro situations to test extreme possibilities and various combinations of situations in small rooms prior to designing the actual levels. Ex: Maximum height and distance that the player can jump. Then, I saved these combinations and I ordered them from the easiest to the hardest. In the end, I discarded the uninteresting ones. This gave me a grasp of what I could do with the game system.
  3. I designed the macro architecture of the levels for the whole game by defining the general shape and orientation of each level (vertical up/down, horizontal, stairs, open area, L shaped, Z shaped, etc.). The shape of a level should also match the visual theme as much as possible.
  4. I planned the sequencing of the ambiances of the game. I gauged dark and bright levels. The idea was to make the player travel. Example: I tried to avoid making a sequence like this: cave, dungeon, and then house interiors… But it could have been a good idea if I wanted the player to feel claustrophobic.
  5. I tried to use level design as a means to tell a story. I believe that thematic progression inside each level is crucial. So, I segmented the architecture of each level in 3-4 parts. For example, for the second rooftop level (Scene 14), I divided it in 3 parts: the first part is some kind of gateway guarded by riflemen, the second part is a tower, where you have to climb up, and the last part is balcony where you have gaps to cross and jumping ninjas to defeat. If this progression is planned in the visuals of the backgrounds as well, this can make a level very memorable and engaging.
             
  6. I chose a limited amount of ingredients for each level (my test rooms mentioned at Point 2 were useful to help me choose what ingredients I wanted). I didn’t want to spoil all of the ingredients in the first level. That would have made the first level overwhelming and the rest of the game irrelevant. I chose only 3-4 enemies and obstacles for each level and then I created a progression by introducing them alone first, and then by combining them in more and more complex manners, thus creating a nice difficulty/learning curve.
  7. I used level design situations to teach the systems of the game. For example, I created some situations where the player had low chance of dying, but had to use a specific ability to progress. This can save a lot of explaining in texts and tutorials.
  8. I used enemies, walls or pickup items placement to hint how the player should solve a situation. For example, I put some pickup items to hint the position where the player should jump to successfully cross a gap. Or I placed a step, a solid object or a groove in the ground to hint where the player should stand to be safe from an attack.
  9. I restrained the height or width of some sub-levels to the height or width of the camera in order to allow the player to see further. Because, when the camera is centred on the player, the maximum distance that he can see is only half the size of the screen. Locking the camera to the level can give more possibilities for platform and enemy placement.
        
  10. I tried to let the player breathes sometimes. The difficulty shouldn’t be constantly climbing up. From time to time, I intentionally put some easier situations during a level to relieve the tension a bit.
  11. I kept levels short or checkpoints not too far from one another, especially if the difficulty was high. I like to keep playtime below 5 minutes between each checkpoint. It helps keep away the frustration.
h1

Satisfaction Guaranteed!

March 31, 2010

As a game developer I always ask myself what makes a game fun. The “fun” word sounds so abstract and is so subjective from one person to another. A lot of things can be fun in a videogame: exotic environments, impressive sound effects, entertaining story, funny characters, particle effects, and so on. However, some games have all of that and can still be not that fun. So what exactly makes a game satisfying? Where does the SATISFACTION come from?

I’m sure everyone has a different vision of this. That being said, my idea of the source of satisfaction in games is not abstract at all. I think that a lot of game developers have this conception too but they simply never put it into words. Here it goes.

To be satisfying, a game has to make the player go through this “achievement loop”:

  1. Challenge: The player is facing an obstacle and he has limited means to overcome it.
  2. Trial and error: This is the hard work (making the player suffer a bit is very important). The player tries to overcome the obstacle in various ways with the tools he has.
  3. Learning: Having tried his tools, and probably failed while trying, the player learned to use them.
  4. Success: The player overcomes the challenge. He feels that he accomplished something and that hard work paid off. This is the moment when the player is having fun, he feels satisfaction. The player thinks: “Yeah! I’m good at this game!”
  5. Loop back to point 1 with a gameplay situation of increased complexity/difficulty.

This looks like a recipe, but it’s not. It can be applied in many ways in any kind of games, but it’s not necessarily easy to do well.

This loop can be found in micro situations of any classic game. Let’s apply this loop to the very first gameplay situation of Super Mario Bros:

  1. Challenge: Mario encounters a Goomba slowly walking towards him.
  2. Trial and error: Mario tries various strategies. He walks straight through the Goomba and dies or he clumsily jumps too early and dies again.
  3. Learning: Mario now understands better how to move and jump.
  4. Success: Mario jumps successfully on the Goomba and crushes his ugly shitake face. He is victorious!
  5. Loop back: Mario will now face a greater challenge.

However, when the game has nothing new to teach to the player, it can no longer loop and therefore it becomes repetitive and eventually boring.

In my opinion, a lot of current generation games have problems keeping the player interested because they try to create satisfaction in an artificial manner. The typical game features an overpowered character facing ridiculously simple gameplay situations (because Gameindustryasshole thinks that people only like easy stuff). So what happens is that when playing the game for the first few minutes, you feel like a God, you’re blown away by your own level of badassness. But not long after, when you realize that the game has nothing new to teach, it starts feeling tedious. And worst, when you fail in that game you don’t learn anything and you feel like an idiot because you weren’t supposed to fail.

This loop can also explain the classic or cliché videogame principle tagged to a lot of addicting games: “Easy to learn, hard to master.” Because the hardest a game is to master, the longer the “achievement loop” can go on and still be fun.

I’ve read the book “A Theory of Fun for Game Design” by Raph Koster a while ago. It most certainly influenced this post, so I encourage anyone to read it.

h1

Storytelling

October 11, 2009

ninjagai-12During the past 8 years, I’ve worked on various kind of video games and I’ve realized that storytelling is very often a major weak point. The main problem is that game developers often tend to forget that video game is a very different medium than cinema even if they share some similarities. By wanting to convey a “great” story, game developers/scriptwriters often end up with a story shoehorned in that breaks the flow of the game.

Cinema is a passive medium that solely focus on conveying a story, while video game is an active medium that requires the input of the player in order to progress (interactivity). The purpose of this post is simply to share what I think works well when telling a story in a game (in action games, to be more precise). I’m no scriptwriter, so my point of view is of a game designer. Here are my thoughts:

  • Showing is stronger than telling (with simple actions).
  • Let the player guess (providing the satisfaction of understanding) rather than explain everything to him. Tell less and hint more – show only glimpses (imagination of the player fills the blanks, it makes him perceive a bigger world than what is actually hinted – if too much is explained, incongruity can become easy to notice, which leads to an unconvincing/not credible world).
  • The story must flow on its own – if the player needs to press a button to scroll text he’s going to skip it (or be frustrated to have the ‘homework’ of reading through it).
  • The purpose of the story is only to set a context and a goal, more than that is superficial and can get in the way of the game – the real story of the game should be what the player experiences when playing through the game.

In conclusion, Heather Campbell nailed this principle in her excellent review of Super Paper Mario in issue 64 of Play Magazine: “Think back to Super Mario 3. There’s a story in that game, but it’s never told to us – we experience it with Mario, by adventuring through levels with him.”