Game Design with Kodu Game Lab

Updates from richard RSS Toggle Comment Threads | Keyboard Shortcuts

• 

  richard 6:55 am on March 15, 2010 Permalink | Log in to leave a Comment  

  Objects, Attributes, and States 

  In looking at game mechanics, we are specifically looking at the objects that make up the game. Anything that can be controlled, that reacts to an event, has a position are objects.

  In Kodu Game Lab, objects and bots and objects and are added to the game using the object tool. Objects are assigned a starting position upon creation.

  Attributes are the settings or information about an object, these may include the colour, size and speed.

  In Kodu Game Lab, settings can be set by the game designer but can’t be altered during the game.  Some attributes like speed (eg fast, fast) can be altered programmably during the game but not to the extent that they can be by using their settings. An option is to make multiple objects with different settings as creatable objects and then create instances of the object as they are needed during the game.

  Objects can be static, in that they don’t change during the game or they can have multiple states. Kodu Game Lab only allows an object to have states whereas other platforms may allow each attribute of an object to have various states.

  Pages are the metaphor used by Kodu Game Lab to represent the various states of an object with an action triggering a change from one page to another. Object states are also determined by current circumstances of the object such as seeing, hearing or being close to another object. Sometimes it is appropriate to notify the player that the state of an object has changed by changing the colour of the object or by playing a sound but on other occasions it is not necessary to signal this to the player. Notifying the player of too many changes to the states of the objects may not always be desirable as it may lead to confusion or the feeling of being overwhelmed.

  When  planning the mechanics of a game be aware of:

  The objects of your game.

  The various attributes of the objects.

  The various states of each object. Is the player to be notified when an object changes states?

  Game play is determined by the mechanics of the game. Thinking about the objects and their attributes and states and how they influence each other is the most important part of a game.

  Using The HTML Properties Inspector In Dreamweaver CS4 | Free Babelfish Download is discussing. Toggle Comments

   

  Reply Click here to cancel reply.

  You must be logged in to post a comment.

• 

  richard 6:55 am on March 15, 2010 Permalink | Log in to leave a Comment  

  Actions 

  The reason that games are often uninspiring and appear to be too similar to other games is due to the actions being unoriginal or derivative. Actions define what a player can do, how they control the objects in the game and how they can respond to happenings in the game.

  The actions emerge as a result of what is happening during the game and the less predictable and wider in scope that the actions can be, result in a generally more playable game.

  Ways in which actions can be used to increase playability:

  1. Add more actions.

  If your characters can only perform one action eg jump or shoot consider adding more actions to increase the variety in the game play. By adding multiple actions you increase the options available to the player, of course it is possible to overwhelm or add actions that serve little or no purpose.

  2. Allow actions to apply to more objects in different ways.

  If actions apply equally and the same way to all objects a game can quickly become repetitive and boring. Can the action that an object performs be used in a variety of ways? Games that focus on discovery or problem solving will particularly benefit from this approach.

  3. Add more objects

  Some games allow the player to control multiple objects either concurrently or by switching between them. Some game allow multiple players to work together to achieve the game’s goals, goals which are not able to be completed without cooperation. Of course, adding more objects to a game may add complexity that is not needed and will distract from the game.

  4. Modify the effect of the action

  When an action is performed it has some effect on other objects in the game. Modifying the effect of an action will most likely increase the interest for the player. Whether the player is notified about the variable impact of certain actions is also worth considering and assessing how this will effect the game.

  Questions to ask.

  How many actions can the player perform?

  How many objects can the player control?

  What attributes determine the playability of the game?

  What are the various states of each object?

  How do the effects of the various actions change during the game?

   
• 

  richard 6:55 am on March 15, 2010 Permalink | Log in to leave a Comment  

  Rules, Objectives and Goals 

  Games have rules and the most important rule is the objective of the game, what the player must achieve in order to win the game. Rules define where players can go, what they can do, and how they interact with other objects and characters in the game. It is critically important that the player clearly understands the objective of the game, a game whose objective is unclear will never be a good game.

  It is also important to include short term goals in your game, that give the player a sense of progress and accomplishment.

  Rules also must be fair, that is, all players should have the same chance of success, if the fairness of the game changes or is different for different players then this must be clear in the rules of the game.

  Rules should generally be clearly communicated so that players know what they have to do to win and why they may lose. In Kodu Game Lab, rules can be conveyed in the description of the game or they can be communicated using in game dialogs. For some games, the rules may be obvious for other games the rules will not be obvious at all.

  Games can have different modes, where rules that apply in one mode do not apply in another. Usually these modes are time limited but can also be triggered by location or by certain events.

  Good rules are:

  1. Clear.

  2. Achievable

  3. Satisfying

  Questions to ask:
  What are the rules of my game?

  Are the goals clear to the player?

  Are there short term goals which build interest in the game?

  Is the player able to choose their own goals?

   
• 

  richard 6:54 am on March 15, 2010 Permalink | Log in to leave a Comment  

  Task 3 

  This week’s task is to look at a game in light of Marc LeBanc’s 8 kinds of fun, it is simple task given many of you will be working on your own Kodu games.

  Choose a Kodu Game Lab game, either one you have made or one someone else has made, and identify the kinds of fun the game aims for. Assess whether you think the game is successful in this.

  nikwing, and devra29 are discussing. Toggle Comments

   
  • 

    devra29 9:12 am on March 21, 2010 Permalink | Log in to Reply

    I tend to be extremely task orientated, so looking at something from the “fun” aspect is very different for me. I looked at my week 2 redo “Disappearing Trees 2″ I have a lot of work to do on the fun aspect. I made the game to mainly build my skills and give me practice in maneuvering my Kudo around the game board. The only fun criteria I had was #4 “Challenge”but for someone with high skills wouldn’t necessarily find it challenging.

  • 

    nikwing 12:29 pm on March 29, 2010 Permalink | Log in to Reply

    http://planetkodu.com/transtone-v04/1048

    a review/ any advice on the “fun” is welcome

• 

  richard 9:09 am on March 11, 2010 Permalink | Log in to leave a Comment  

  New Kodu Version is now available for download 

  You can download the new Kodu version from http://www.microsoft.com/downloads/details.aspx?FamilyID=57a23884-9ecd-4c8a-9561-64bfd4fa2d3d&displaylang=en or via http://fuse.microsoft.com

  Information about this update is available on the Kodu blog: http://community.research.microsoft.com/blogs/kodu/archive/2010/03/10/new-kodu-build.aspx

   
• 

  richard 8:03 am on March 8, 2010 Permalink | Log in to leave a Comment  

  Week 2 content available 

  The content for week 2 is now available.

   
• 

  richard 7:59 am on March 8, 2010 Permalink | Log in to leave a Comment  

  Video: Game Design Process 

  In part 2 of our interview with Charles Howell, we discuss the process of making great games with games, specifically the process that Charles himself uses.

  
  Download Video

   
• 

  richard 7:58 am on March 8, 2010 Permalink | Log in to leave a Comment  

  Identifying Risks 

  When attempting to create any game it is important to consider the design risks and this is especially important when creating games with Kodu Game Lab? Is this game technically possible to make with Kodu Game Lab?

  Is there any aspect of the planned game that is not possible to make with Kodu Game Lab?

  Can the resources required be kept to size and level of complexity to make it playable with Kodu?

  Can the object or bot be programmed to act in a required way?

  Can a world be created to in the required form?

  When generating ideas for your games it is useful not to be concerned with reality but at some stage it needs to determined if it is actually possible to make the desired game with Kodu. Obviously, for some game ideas that are variations of other Kodu it will be relatively safe to assume that the game will be possible to make. Other ideas, say, creating Second Life with Kodu, will obviously be impossible. So what can we do to minimize design and technical risks?

  The Process

  1. Identity the major technical and design risks of your design

  Once you have decided on the game that you plan to create is important to identify the parts of the game that might not be possible.

  2. Build a prototype of the risks

  Start by building the parts (the risks) of the game that you feel might not be possible. It is not necessary to build a complete game at this stage or get this part of the game exactly right. This stage is all about determining if this risk is real or not. With Kodu it is not only necessary to determine if it actually possible but also necessary to determine how many resources this part of the game uses.

  3. Test

  Play testing is the most important part. Testing at this stage only tests the specific identified risks.

  4. Modify (or abandon) as needed

  Once you have evaluated the risks and determined what is possible, you can either proceed as planned, modify your design with regard to the discovered limitations or abandon the project.

  Spending time identifying the risks in your game design will save both time and frustration when making larger and more complex games with Kodu Game Lab.

   
• 

  richard 7:58 am on March 8, 2010 Permalink | Log in to leave a Comment  

  The 400 Project is attempting to find and list 400 (just a rough number) rules that apply to Game Design. The project began in 2003 and so far has compiled a list of 112 rules.  The project is managed by Hal Barwood and Noah Falstein. Most of the rules have been written by Noah Falstein, although anyone can submit a rule.

  Each rule has a name, a statement (description) and a domain to which the rule belongs. Each rule has an example or two from well known games as well as counter-examples that show the consequence of not following the rule.

  For example,

  Provide Clear Short-Term Goals

  Always make it clear to the player what their short-term objectives are.  This can be done explicitly by telling them directly, or implicitly by leading them towards those goals through environmental cues.  This avoids the frustration of uncertainty and gives player’s confidence that they are making forward progress.

  Noah suggests that rules are useful when you are stuck with your game design or evaluating the game you are making against each rule in the list.

  Good Game, a TV program in Australia, ran a short story on the 400 Project, last year and the clip is available on YouTube.

  
  YouTube

  During the coming weeks we’ll look at some of these rules and how they apply to the game experience. We would love to hear your thoughts on these rules.

   
• 

  richard 7:57 am on March 8, 2010 Permalink | Log in to leave a Comment  

  Design Patterns in Games 

  Patterns are used by designers to solve problems using specific known solutions and that have been previously proven to work. In 1977, Christopher Alexander’s wrote the book “a pattern language” that outlined how patterns could be used in architecture to enable anyone to design buildings. Design patterns were popularised by the Gang of Four for use to solve common object oriented programming problems.

  Design patterns:

  • give a general solution to common problems
  • are universal to any programming language/environment / framework
  • outline the reasons why the pattern is appropriate
  • create a shared language and understanding

  Staffan Björk & Jussi Holopainen have detailed about 300 game design patterns on their website and in their book.  The website only has a basic description, an example and the relations for each pattern but it is still very useful.

  Example from the website

  Boss Monsters

  A more powerful enemy the players have to overcome to reach certain goals in the game.

  Sometimes defeating the Boss Monster can be a goal in itself, but usually Boss Monsters are used as subgoals in the game and the high-level goal is of another type of goal. Boss Monsters are almost always used to structure the progress of the game.

  Instantiated by Eliminate

  Instantiates Overcome Tension Higher-Level Closures as Gameplay Progresses

  Modulated by Achilles’ Heels

  Modulates Rescue Levels

  Game Design Patterns can positively influence the design choices of game designers by enabling the games to have “authentic game experiences”. In particularly investigating the patterns for narrative structures, predictability and immersion, such as tension or planned character development, may be useful in generating ideas for your games.

  Many of the patterns and descriptions may seem obvious and some of the patterns may not be applicable to Kodu Game Lab however a deeper knowledge of the design patterns in games will undoubtedly help you create better games.

  In weeks 3, 4 and 5 of this course we will unpack some of these design patterns in greater detail looking at how they can be used to build the game experience.