Experimental Game Dev Interviews — The First Game Dev Podcast Ever
RSS icon Home icon
  • Guest Post: Gameplay and Story

    Posted on October 19th, 2010 IndieGamePod No comments

    What are games? This is the sole question to begin to understand how games work. We are going to discuss the very basic design of video games. If you are new to video game design, this is where you should start.

    Video games, at their most basic, are divided into two sections based on their design: story and gameplay. In the very best games, these two work together to make a masterpiece. Gameplay should complement story, and story should complement gameplay (you’ll see what I mean in a moment). People discuss story-driven games and gameplay-driven games, but to make a game the best it can be, they should really be the same caliber. It’s time to stop thinking about gameplay and story, and time to start thinking of them as story-gameplay (no, I did not get this idea from Einstein).

    Gameplay is, well, you actually playing the game – how you are allowed to interact with the Metal Gearworld. This gameplay is also divided into two sections: actions and challenges. In Halo, the actions are running, shooting, jumping, crouching, reloading, etc. These actions are referred to as game mechanics, and you are able to do each one in the virtual world by doing something in the real world with the control. Often, each mechanic has its own button. You use these mechanics to complete challenges.

    A challenge in Halo is often a hoard of enemies. Challenges are often interwoven throughout the game. For example, let’s say your challenge is to rescue the princess. To do that, you need to get the sword, a subchallenge. To get the sword though, you need to kill the sword’s guardian, a subchallenge of a subchallenge. You accomplish these challenges throughout the game by using the mechanics. The relationship between the mechanics and challenges is what’s known as gameplay. That is pretty much the outline of every game: a series of challenges, or problems, which the player must complete.

    The second part of a video game is the story, which includes the story (the events that occur in the game), atmosphere, sounds, characters, and all things that either make the virtual world more immersive or gives weight to the challenges. Let’s say we’re designing a video game, and the player’s overlying challenge is to save the princess. But how does the designer make that the challenge? Do we just say in text, “You’re challenge is to save the princess.”? No! We let thegta mechanics and story story give you that objective organically. We can show a cutscene of you and the princess, when she is kidnapped and you are knocked unconscious. Characters of the village can be sobbing about their loss to you; the town may go into disarray, etc. The point is, you, through the character you play in the game, know that you have save the princess. If we just told you in text what your challenge was, you would feel no obligation to complete the challenge. The game wouldn’t be fun, because the game of interweaved challenges has turned into a list of things you have to do. Go from point A to point B, and you win the game. Nobody would ever go to point B just because you told them to. Through story, challenges should be organically produced and given to the player, who now has a reason to complete the challenges. He/she now wants to complete to the challenge because of the story – you’ve become attached to the characters, you want to save this interesting new world, you want to know what happens next or the answers to your questions about the story or world. The feelings the game gives you is also important – you want to continue to feel the power, achievement, etc. You also want to keep playing because the gameplay and process your mind plays in completing challenges, but the story on top of fun gameplay takes the game to a whole new level (no pun intended).

    So now about how gameplay and story complement each other. Basically, gameplay should progress the story. By accomplishing your goal, you are rewarded with story. By using the game alan wake gameplay and storymechanics to accomplish the challenge of saving the mayor who is inside a burning building, he may reward you, in the story, with a weapon, information, or something to get you closer to your larger challenges, like saving the princess. The weapons means new, fresh gameplay for you to enjoy, completion of the challenge makes you feel great, and you get to progress through the story which you’ve been immersed into.

    So, wrapping up, story and gameplay make up video games. Gameplay is the actions, goals, and how the two go together, and story is what gives weight to the goals. Gameplay opens up story, as story serves as a reward for gameplay. Story also gives reason for the games, so without story, the gameplay is not as fun or logical.

    I could go on forever, but I’ll stop there. It is a lot to process if you are new to game design, so for practice, go play your favorite game (action, action-adventure, or adventure game, although there are many more which use this formula), and examine the challenge structure at any point (know your main goal and all of the subgoals at any point in the game after the introduction). Also figure out what the mechanics are. Also, if you’re in for a challenge, try to figure out why you are playing the game and completing the challenges. What is it about the game that makes playing it so much fun? We’ll cover that someday.

    Have fun, and come back later for part 2.

    Dylan Woodbury lives with his family in Southern California. He runs http://dtwgames.com, a game design website that posts intriguing new articles every week, both beginner’s tutorials and theoretical ideas. He also has an interest in writing, and is planning his first novel. His primary goal is to change the world through video games.

  • Author of Lost Garden Blog Discusses Future Opportunities in Game Design

    Posted on October 18th, 2010 IndieGamePod No comments

    Daniel, author of LostGarden.com, discusses current and emerging game design opportunities

    You can download the podcast here…
    http://www.indiegamepod.com/podcasts/cc-lostgarden.mp3

    Or listen to it here…

    Read the rest of this entry »

  • Using Instant Action to Develop Games

    Posted on October 15th, 2010 IndieGamePod 1 comment

    Donald, from Instant Action, talks about using their middleware to accelerate your game development

    You can download the podcast here…
    http://www.indiegamepod.com/podcasts/cc-instant-action.mp3

    Or listen to it here…

    [wp_youtube]yV7yRjgUGqk[/wp_youtube]

    Read the rest of this entry »

  • Indie Flash Developer Discusses Making Online Games

    Posted on October 14th, 2010 IndieGamePod No comments

    Rob discusses getting into developing web games

    You can download the podcast here…
    http://www.indiegamepod.com/podcasts/cc-indie-flash.mp3

    Or listen to it here…

    Read the rest of this entry »

  • IndiePub Best Game Design Winner: Vanessa Saint-Pierre Delacroix & Her Nightmare

    Posted on October 13th, 2010 IndieGamePod No comments

    Hey folks,

    As a follow on to the guest post about game usability, here’s an interview with the founder of Bad Pilcrow Studio about the development and design of Vanessa Saint-Pierre Delacroix & Her Nightmare

    You can download the podcast here…
    http://www.indiegamepod.com/podcasts/gdco-bad-pilcrow.mp3

    Or listen to it here…

    [wp_youtube]twOBUIhi55k[/wp_youtube]

    Enjoy 🙂

  • Guest Post: Game Usability Lessons from Vanessa Saint-Pierre Delacroix & Her Nightmare

    Posted on October 11th, 2010 IndieGamePod 1 comment

    Introduction

    My studio’s latest game, Vanessa Saint-Pierre Delacroix & Her Nightmare, recently earned a Best Design award in indiePub’s 3rd Independent Game Developers Contest.  Our team believes that the graceful usability of Vanessa was a contributing factor to our success.  This brief article outlines some of the best practices from our development process.

    Before diving into the lessons we learned, an explanation of our game is in order.  Vanessa Saint-Pierre Delacroix & Her Nightmare is a 2D puzzle and platform game mapped to a 3D cube.  In each level, players must guide the titular character to an exit.  In order to do so, they must use Vanessa’s ability to rotate any face of the cube she occupies.  In a way, Vanessa Saint-Pierre Delacroix & Her Nightmare borrows from the best parts of Super Mario Bros. and Rubik’s Cube.

    [wp_youtube]twOBUIhi55k[/wp_youtube]

    Why does Vanessa play so effortlessly?  I have identified three key components of the game’s design which I believe contribute to its usability.  They are: a subtractive approach, polished difficulty, and a focus on early testing.

    A Subtractive Approach

    In The Elements of Style, E. B. White writes, “A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts.”  This philosophy applies to game design.  Vanessa works well in part due to the subtractive approach taken during development.  Any element out of place was cut.  Those that remained created a strong, central core for players to enjoy; they are unburdened by clutter.

    For example, early versions of Vanessa included functionality for manually rotating the game’s camera.  By controlling the camera, players could adjust Vanessa’s puzzle cube to see each face.  As a result, our testers became fixated on trying to solve every puzzle before making any moves.  They grew frustrated, and for good reason: studying isn’t fun.  So, the manual camera was cut, forcing players to explore the cube in order to find a solution.  Exploration is far more satisfying than planning, and it better reflects the nature of our game.

    Subtractive design provides developers with an added benefit: it simplifies a game’s controls.  As I write, an Xbox 360 gamepad sits in front of me.  It has thirteen buttons and three different ways of indicating direction.  Feel free to use as few of these options as possible when designing your games.  Your users will appreciate the ease with which your project operates.

    Vanessa requires five buttons and one thumbstick – the bare minimum specified by the game’s mechanics.  Overwhelmingly, players have noted that Vanessa is an easy game to pick up and play.  A manual camera, weapons system, or any other unnecessary mechanic would have required more buttons, more training, and more cognitive resources.  In short, it would have been less usable.

    Difficulty

    Most players (and many developers) view difficulty as a linear path from easy to hard.  This model is incomplete, and incompatible with good design.  In general, difficulty should increase slowly at the beginning of a game, rise significantly once the mechanics have been established, and taper off towards the end (well before challenges become punishing).  Along the way, modest dips in difficulty should be included, to allow the player time to demonstrate their mastery of the system.

    I recommend introducing new mechanics or challenges individually.  Give the player time to acclimate.  Vanessa Saint-Pierre Delacroix & Her Nightmare features thirty-six levels, and new mechanics are launched in levels 1, 2, 3, 7, 10, 12, 15, 19, and 26.  Notice how, after the initial tutorial levels (1-3) play out, there is increasingly ample space between additions to the game’s complexity.  In those levels, difficulty increases modestly, and occasionally drops.

    Why should difficulty decrease every once in a while?  The idea is simple: games should be fun.   Once players have figured out how a mechanic works, they need opportunities to revel in their mastery of the system.  So, if your game is about destroying vampires, introduce your player to a single vampire, then force them to battle two vampires at once, then three.  After that, let them go to town on a single vampire again.  After the challenge of defeating three bloodsuckers at once, the slight reprieve will be a welcome break for the player.  Likewise, the player will compare and contrast their first encounter with a single vampire to their most recent encounter.  How will they measure up?  A good designer will want their players to feel satisfied and empowered, not unfairly punished.

    Of course, what works on paper rarely works in practice.  There is no substitute for thorough testing.  Developers should listen carefully to feedback from players, and – here’s the kicker – suppress their egos.  When someone criticizes your work, it’s easy to dismiss that point of view as uninformed, incomplete, or just plain wrong.  But by protecting your ego and clinging to your own opinions, you may be dismissing information that could improve your game.

    Developer as Tester

    I firmly believe that a game’s developer should be its first and best tester.  During production, no one will play your game more than you will.  This has both advantages and disadvantages.  On the one hand, you will become intimately familiar with every facet of your game.  On the other hand, you may fall into testing patterns or become comfortable with certain idiosyncrasies.  Remember, just because you know the critical path through a level doesn’t mean you should take it every time.  Be thorough, and make every effort to break your game.

    I never release a game for testing unless I have exhausted my bug list.  If I can no longer find errors, then I need more people looking for them.  After submitting the Beta version of Vanessa to indiePub’s 3rd Independent Game Developers Contest, only one critical bug surfaced: in some countries, decimals are stored as commas instead of periods.  This formatting issue prevented some foreign gamers from fully enjoying our game.  The bug itself was easy to fix, but it demonstrates the need to conduct deep and thorough tests of your game.

    Final Notes

    If you are unfamiliar with interface design, I highly recommend studying Jakob Nielsen’s Ten Usability Heuristics, available from his website, useit.com.   These ten practical suggestions will help ensure that your game offers a more satisfying experience for players.  For example, Nielsen suggests that “every extra unit of information… competes with the relevant units of information and diminishes their relative visibility.”  For this reason, Vanessa’s in-game interface consists of only the most important information: a level number, the number of rotations the player has triggered, and the amount of time that has elapsed since the level began.

    Conclusion

    The ideas expressed in this article worked for Vanessa.  However, every game is different, and independent developers should never cling too tightly to a single design philosophy.  However, by carefully considering these concepts, you are bound to think more critically about your own games, and arrive at an approach that best suits the project at hand.

    David J. Sushil is a professor of Game and Simulation Programming at DeVry University.  He is also the owner of Bad Pilcrow, an independent game studio in Orlando, Florida.  His most recent game, Vanessa Saint-Pierre Delacroix & Her Nightmare, was awarded Best Design in indiePub’s 3rd Independent Game Developers Competition.

  • The Design and Opportunities of Skill-Based Games

    Posted on October 9th, 2010 IndieGamePod 2 comments

    Davin, VP of Social Games for the Game Show Network, talks about the opportunities of skill-based games

    You can download the podcast here…
    http://www.indiegamepod.com/podcasts/cc-gsn.mp3

    Or listen to it here…

    Read the rest of this entry »

  • Social Game Flash Engine Tutorial, Part 4: Adding in a special IsoItem

    Posted on October 8th, 2010 IndieGamePod 1 comment

    Hi,

    This is the next part in the tutorial to build your own Social Flash Game MMO based on the Free Social Game Flash Engine

    You can read part 1 here…

    You can read part 2 here…

    You can read part 3 here…

    Special items such as animals are handled in a particular way. Animals in the game follow the same standard of set up that normal items do, however in order to control the seperate animation behaviour they were given a slightly extended set up. First of all our animal must exist on one frame and be given the instance name “animal” as shown:

    As you can see, the elephant is a 2×2 IsoItem, and is positioned exactly the same way an item is. Now, if we dive into our “animal” movieclip and see how the animation is set up on the timeline:

    We can see the three main frame labels we’re looking to have, “standing”, “moving” and “eating”. These three frame labels will get called at the appropriate time for the animal. The rest of the process is exactly the same as adding an item, except that it should be placed in the storeanimals.xml file.

  • Social Game Flash Engine Tutorial, Part 3 – Working with a Store

    Posted on October 7th, 2010 IndieGamePod 1 comment

    Hi,

    This is the next part in the tutorial to build your own Social Flash Game MMO based on the Free Social Game Flash Engine

    You can read part 1 here…

    You can read part 2 here…

    Part 3…

    VetRanch allows the player to purchase items. These can take the form of animals, decor, buildings, or even some extra land. Persistent data is becoming a growing trend in flash games, giving the player an in-game currency and allowing them the ability to purchase items and have them still there when they come back to play again the next day. It’s little things like this that increase the fun and replayability of the game.

    The store in VetRanch offers the player extra experience when they purchase the item, this is one of the ways that the player can help raise their level in the game.

    To trigger the building of an item in the store, we use the following IsoMap function:

    setCurrentBuilding(ref:int, type:String, cost:int)

    The reference is the unique id found in the itemlist.xml file talked about earlier, the cost is obviously how much should be deducted for building the item once it has succesfully been built. The type variable is what we’re interested in, this is what we use to determine how the item should behave.

    For instance, if we set the type to “item” then it will behave exactly like a static item as we would expect. However, if we set the type to be “zoo” then it will take on the characteristics of an animal.

    Placing an Item in the Store

    Once we have inserted a new item into the game, we need a way to add it into the store so it can be purchased and placed on the players map.

    The store currently loads the decoration information from the storedecorations.xml, which has a typical format of:

    <items c=’decorations’>
    <item fl=’3′ f=’5′ p=’500′ i=’isopics/statue1.jpg’ uid=’31’ box=’0′ xp=’1′ pt=” t1=’0′ t2=’0′ >Statue 1</item>
    <item fl=’10’ f=’5′ p=’500′ i=’isopics/statue2.jpg’ uid=’32’ box=’0′ xp=’1′ pt=” t1=’0′ t2=’0′ >Statue 2</item>
    <item fl=’1′ f=’0′ p=’10000′ i=’isopics/pool.jpg’ uid=’30’ box=’0′ xp=’1′ pt=” t1=’0′ t2=’0′ >Pool</item>
    <item fl=’10’ f=’25’ p=’250000′ i=’isopics/mediumhouse.jpg’ uid=’43’ box=’0′ xp=’1′ pt=” t1=’0′ t2=’0′ >Medium House</item>
    </items>

    The two important attributes we’re interested in here are the “uid” field, which links directly back to the uid specified in the itemlist.xml file earlier, and the “i” attribute which links to a thumbnail image of our statue. “p” is also of importance, and refers to the price that the item will be sold for.

    To add in our large statue, we could place something along these lines in the .xml file:

    <item fl=’3′ f=’5′ p=’500′ i=’our_statue.jpg’ uid=’4′ box=’0′ xp=’1′ pt=” t1=’0′ t2=’0′ >Our Statue</item>

    Now our item should appear in the decoration tab in the store, and can be purchased and placed into the game with no additional compilation of the main game needed.

    Clothing Store

    The game also comes with a clothes store to give the player compete customisation over their appearance in the game. Feel like dressing your character in the style of a certain adventurous archaeologist? No problem.

    By letting the player dress their character any way they please gives them the much needed ability to express themselves and this helps them to truly get hooked into the game. All of the characters clothing can be externally loaded, this means we can add hundreds of costumes into the game, giving the player no end to the possibile combinations to choose from.

    The clothing store is fairly self-contained, and can be shown or hidden by calling the following two functions Main.as.

    gotoClothingShop()
    hideClothingStore()

    If you’re wanting to play around with how the clothing store works, open up AvatarShop.as, this is also where we can set the prices of the various hair styles, tops, bottoms and shoes along with various other details.

  • Using Google Chrome To Distribute and Promote Your Games

    Posted on October 6th, 2010 IndieGamePod 1 comment

    Mark and Mike, from Google, talk about the Chrome Web Store and the opportunities for indie game developers

    You can download the podcast here…
    http://www.indiegamepod.com/podcasts/cc-google.mp3

    Or listen to it here…

    Read the rest of this entry »