1 / 70

What is an Ontology?

What is an Ontology?. An ontology for a domain is the explicit formal specification of the terms in the domain and relations among them. What is an Ontology. Defines a common vocabulary for a group of professionals who need to share information in a given domain.

sstringer
Download Presentation

What is an Ontology?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. What is an Ontology? An ontology for a domain is the explicit formal specification of the terms in the domain and relations among them.

  2. What is an Ontology ... • Defines a common vocabulary for a group of professionals who need to share information in a given domain. • Includes machine-interpretable definitions of basic concepts in the domain and relations among them.

  3. Share a Common Understanding • Several different Web sites contain medical information or provide medical e-commerce services. • They share the same underlying ontology. • Enables computer agents to extract and aggregate information from different sites. • Common Digital Entertainment ontology. • Medium for discussing and sharing ideas among designers. • Foundation for analysis and critiquing.

  4. Enable Reuse of Domain Knowledge • Notions of Time • Time intervals • Points in time • Relative measures of time. • Notions of Space • Spatial relations • Navigation around obstacles. • Emotions • Applicable over a broad range of applications.

  5. Make Domain Assumptions Explicit • Makes it easier to change underlying domain assumptions. • Hard coding assumptions about the world makes it hard to • Find and understand assumptions • Change assumptions • Explicit specifications are useful for new users who must learn what terms in the domain mean.

  6. Separate Domain from Operational Knowledge • Describe a task of configuring a product from components according to a required specification. • Develop a program that is independent of the specific products and components themselves • Same program can configure • PCs • Elevators • Video Game Consoles

  7. Description Logic

  8. Description Logic

  9. Family Ontology o.1 Man := (hasGender = 1) ∩ (hasGender з Male) o.2 Woman := (hasGender = 1) ∩ (hasGender з Female) o.3 (hasChild)-1 = hasParent o.4 Person := Man U Woman o.5 Parent := Person ∩ (hasChild ≥ 1) o.6 Father := Parent ∩ Man o.7 Mother := Parent ∩ Woman

  10. Family Ontology Relations Relations: hasGender(Person,String) hasParent(Person,Person) hasChild(Person,Person) hasConsort(Person,Person) Rule: r.1 hasParent(?x1, ?x2) Λ hasConsort(?x2, ?x3) => hasParent(?x1, ?x3)

  11. Family Ontology Example Person Instances: m1, f1, f2 Relation Instances: hasGender(m1, Male) hasChild(m1, f2) hasGender(f1, Female) hasConsort(m1, f1) Conclude:Mother(f1)

  12. Family Ontology Example d.1 hasGender(f1, Female)  Woman(f1) [o.2] d.2 Woman(f1)  Person(f1) [o.4] d.3 hasChild(m1, m2)  hasParent(m2, m1) [o.3] d.4 hasParent(m2, m1) Λ hasConsort(m1, f1)  hasParent(m2, f1) [r.1] d.5 hasParent(m2, f1)  hasChild(f1, m2) [o.3] d.6 Person(f1) Λ hasChild(f1, m2)  Parent(f1) [o.5] d.7 Parent(f1) Λ Woman(f1)  Mother(f1) [o.7]

  13. Family Ontology Example • Steps d.1 – d.3 performed by description logic ontology reasoner. • Step d.4 performed by deductive rule engine. • d.5 – d.7 performed by the ontology reasoner using the necessary relation instance concluded by the deductive rule engine in d.4. • Neither ontology reasoner nor deductive rule engine alone is sufficient.

  14. Game Ontology Project • Michael Mateas et al, Georgia Tech • Identify the important ”parts” of games. • Rules • Player activities • Presentation and input • Player goals • Entitities in the game world • Etc. • Identify relations between the parts.

  15. Game Ontology Project • Capture the discrete decisions that must be made in a game design. • Describe how effects of decisions propagate throughout rest of design. • Via constraints and tradeoffs between elements. • Show how various elements contribute to the overall design. • Important for game analysis. • Help clarify design choices. • Important to game designer.

  16. Top Level Elements • Interface • Mapping between the embodied reactions of the player and the manipulation of game entities. • Rules • Constrain what can and can’t be done in a game. • Determine the basic interactions that can take place within the game. • Goals • Objectives or conditions that define success in the game.

  17. Top Level Elements • Entities • Objects in the game that the player • Manages • Modifies • Interacts with at some level • Entity manipulation • Alteration of the game made by player or in-game entity. • Actions or verbs that can be performed by the player or in-game entity.

  18. Ontology Entries • Name • Description • Parent • Captures the notion of a subtype • Child elements are more specific or specialized conepts than the parent • Child • Part elements • Elements related by the part-of relation • Captures the notion of compound elements • Strong Examples • Weak Examples

  19. Ontology Extracts PresentationCardinality of gameworld1-Dimensional gameworld2-Dimensional gameworldPresentation hardwareAudio display hardwareHaptic displayVisual display hardwareVideo monitorVR goggles

  20. Ontology Extracts RulesRules SynergiesDominant StrategyDynamic Difficulty AdjustmentGameplay RulesCardinality of Gamepay0-Dimension Gameplay1-Dimensional Gameplay2-Dimensional GameplayGame EndsEvaluation of EndingResource Exhaustion

  21. Cardinality of Gameworld Cardinality of gameworld Many games are spatially-based in the sense that a player must interact with a game world that is defined and presented as having spatial properties. Usually, this means that a player is granted a view of a world that affords its perception as a 2 or 3 dimensional place. For example, if playing a game of chess, the player may be afforded a 2 dimensional representation of a chess board versus a 3D representation where the board is viewed at an angle and the chess pieces are rendered in 3D. For the former case, the game world's cardinality of space is 2D while the latter is 3D.In other cases, while the player may have the perception of a world, the actual dimensions of this may be unclear or undefined. This is commonly seen in text-based adventure games where the locations that the character visits may not follow normal rules of logic. For example, typing "North" to exit a location and then typing "South" may not lead the character back to the original location despite the logical assumption that moving "North" is the inverse to "South."

  22. Cardinality of Gameworld Also, in many games there is certain confusion caused by changes in representation between levels or episodes of the game. In fact, the mere existence of various levels makes this distinction more confusing. In a game such as Donkey Kong, where there are 3 distinct 2D levels, do we consider each level a place that is connected to the previous ones? Would that make Donkey Kong's game world 3D? For simplicity, we refer to the cardinality of space in terms of what is represented in a level or episode. Thus, for the case of Donkey Kong, we would maintain that it takes place in a 2D game world.We note that the cardinality of space refers to the perception of the game world by the player and not to the actual degrees of freedom the player is allowed within the game world. To account for this, please refer to Cardinality of Gameplay.See also   Cardinality of GameplayParents:PresentationChildren:1-Dimensional gameworld , 2-Dimensional gameworld , 3-Dimensional gameworld , Undefined gameworld cardinality

  23. 2-Dimensional Gameworld 2-Dimensional gameworld 2-Dimensional game worlds, as the name implies, are spaces that have 2 degrees of freedom. Without getting into any of the specific mathematics, we can think of them as spaces that have length and width (or width and height) but lack depth. Most older video games have 2-dimensional game worlds. A few examples of these include Pac-Man, Tetris and Asteroids.See also   Cardinality of GameplayParents:Cardinality of gameworld

  24. Cardinality of Gameplay Cardinality of Gamepay The cardinality of gameplay refers to the degrees of freedom the player has with respects to movement (or the control of movement) in a certain game. For example, the player may control a character that moves left and right or have to place tokens on a 2-dimensional board. Other games, allow the player to control movement in 3 dimensions.It is important to note that the cardinality of gameplay is related, but not necessarily the same as the cardinality of the gameworld. For example, while the classic game of Monopoly is played on a two-dimensional board, the players tokens are limited to move along one dimension and always in the same direction. In this example, the cardinality of gameplay is 1D.

  25. Cardinality of Gameplay We also note that the cardinality is only with respect to the movement the player can perform and this is independent of other actions, or that the effects of those actions may occur in some other dimension. For example, in Space Invaders the player controls a ship that can move from left to right along the bottom of the screen. The players ship can also fire shots that travel upwards along the screen. In this case, the cardinality of gameplay is 1D, despite the fact that the gameworld is 2D and that the players shots have effects outside of the limits of the players movements.Parents:Gameplay RulesChildren:0-Dimension Gameplay , 1-Dimensional Gameplay , 2-Dimensional Gameplay , 3-Dimensional Gameplay , Undefined Cardinality of Gameplay

  26. 1-Dimensional Gameplay 1-Dimensional Gameplay Games that have a cardinality of gameplay that is 1D restrict movement to only one axis. This means that movement can only be controlled in one direction and the exact opposite of the direction. For example, up/down or left/right. Strong Example:In Space Invaders, the player controls a ship that can move from left to right across the bottom of the screen. The objective is to fire at the enemy invaders that are slowly moving downwards. Strong Example:In Pong, the player controls a raquet that moves vertically on the across the side of the screen. The object of the game is to position the raquet so that the ball hits it. Parents:Cardinality of Gamepay

  27. Application of Ontology Concepts • Space Invaders • 2-Dimensional Gameworld • Invaders march across the screen from left to right and down towards players • 1-Dimensional Gameplay • Player can only move his spaceship from side to side.

  28. Design Patterns “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” Alexander, C. et al. (1977): A Pattern Language: Towns, Buildings, Construction. Oxford University Press.

  29. Game Design Patterns: a definition “Game design patterns are general descriptions of interaction which occur in games. The patterns are semi-formalized interrelated tools that can be applied in situations to generate context-dependent solutions. Game design patterns are usually identified from existing games where the interaction pattern may or may not have been intentionally been promoted by the game designers.” (Björk, 2003-05-13)

  30. Game design patterns I • A method for talking about games in order to: • Describe them • Analyze them • Compare them • Create them • Based on design patterns

  31. Game design patterns II • A way to describe design choices (or emergent features) that reoccur in many games • Offers possible explanations to why these design choices have been made • A guide to how to make similar design choices in game projects • What is required to make the pattern emerge • What consequences can the pattern have on game play? • Motivation • Need a vocabulary for talking about games • Need to discuss and do game designs in a structured fashion • Provide a tool for, especially experimental, game design

  32. Game Design Patterns III • Semi interdependent descriptions of commonly reoccurring parts of the design of a game that concern gameplay.

  33. Component Framework • A activity-based model of game interaction • Fundamental feature of games is making changes in quantitative game states. • Describe games in terms of activities players perform. • Provides concepts for talking about the first order of game design. • Includes many of the traditional concepts used to describe games • Player, rule, goal, etc. • Physical and logical components that make game play possible. • Basic components then be used to describe second order concepts. • Game design patterns. • Lays out the details of how games are constructed • Describe, analyze and compare games • Game state • Playing the game is making changes in the game state!

  34. Component Framework

  35. Component Categories • Reflect four basic ways of viewing the activity of playing a game. • Holistic • Determine how the activity of playing the game is divided • Boundary • Limit the player activities by allowing certain actions and making some activities more rewarding • Temporal • Describe the flow of the game play and define the changes in the game state • Structural • Define the parts of the game which are manipulated by the players and the game system

  36. Holistic – Game Instance • The components, actions, and events that describe the specific play of a single game. • Setup • All the actions of participating players • Ending the game • Determination of the final outcome • Any activities required to restore the game state before the next setup. • Game stays the same, but every instance is unique.

  37. Game Instance Examples • Game instance of chess includes • Players • Game boards • Pieces • Game instance of Asteroids • Starts when players insert coins and select number of players • Continues until all players have run out of lives • If they played well they get to choose a handle and their score is displayed on the high score list. • Game instance of MMORPG (Massively Multiplayer Online Roleplaying Game, e.g., Ultima Online) • Includes entire history of that persistent world. • From initiation of the server to final server shutdown.

  38. Holistic – Game Session • Complete activity of a single player • From start of actual gameplay to last actions considered part of the game. • E.g., a single game instance of chess consists of two game sessions • One for each player. • Not so interesting in a game with only one player. • Very interesting for MMORPGs • Players start playing the game independently of each other. • Specific player sessions may never overlap at all.

  39. Holistic – Play Session • Applies to individual player. • Time actually spent playing might be divided into several different occasions. • Each occasion called a play session. • A game session consists of one or more play sessions.

  40. Holistic – Setup Session • Could be very simple. • Choose color of a car in a rally game. • Provide players with ways to determine their play experience. • Set personal goals. • Insert player’s own material into the game. • Setting mutators in Unreal Tournament. • Choosing and modifying characters in MMORPGs.

  41. Holistic – Set-Down Session • Usually uninteresting from a game experience perspective. • However, can allow the individual to do administrative or planning activities. • Compare current game instance with previous instances. • Essential in games that can’t be won. • Measure success relative to other game instances. • Raising or gaining skills in RPGs.

  42. Boundary Components • Limit the player activities by allowing certain actions and making some activities more rewarding. • Rules: dictate how everything works! • Modes of Play: states where the player can perform different actions. • Goals and subgoals: motivation for playing the game in certain ways. Game states that the players should try to achieve.

  43. Rules - Example • Europa Universalis II real-time strategy game. • Describe dependency between a country’s • Leaders, provinces, research, international status, religion, and military forces. • Describe trade, vassals, loans, and alliances between countries. • Tutorial supplies basic concepts and fundamental relationships but • Players must learn the detailed rules unaided. • Game mastery heavily depends on understanding what the rules are and how to take advantage of them. • Nomic is a game based on changing rules. • Goal is either • Get 100 points. • Prove that gameplay can’t continue due to two contradictory rules.

  44. Temporal Components • Describe the flow of the game play and define the changes in the game state • Actions: what the player can do • Events: what are the game state changes • Closures: meaningful game state changes • End conditions: determine changes of mode of play and closures • Evaluation functions: determine the outcome of an end condition

  45. Structural Components • Define the parts of the game which are manipulated by the players and the game system • Interface: provides players information about the game state and possible actions • Game Elements: components that contain the game state • Players: entities that try to achieve their own goals within the game • Game Facilitator: synchronizes the game state

  46. Examples of Game Design Patterns Examples • Power-Ups • Boss Monster • Paper-Rock-Scissor • Cut Scenes • Role Reversal • Parallel Lives • Orthogonal Unit Differentiation • Stimulated Social Interaction

  47. Characteristics of Game Design Patterns • Three main characteristics • Recurring game mechanics or elements of interaction in games • Semi-formal inter-dependent descriptions • Can be intentional or emergent in game designs • No canonical definition • Many are possible • Not only a collection of patterns • The methods in which they can be used

  48. Pattern template • Name • Description • Core Definition • General Description • Examples • Using the pattern • Consequences • Relations • References • Based on the component framework (game sessions, rules, players, actions, closures, information structures, control structures, etc.)

  49. Pattern template, cont. • Name • Preferable short, specific, and idiomatic • Description • Concise description of the pattern • Description of how it affects the structural framework (if it does) • Examples of games in which the pattern is found

  50. Pattern template, cont. • Consequences • What effects the game pattern has on game play • What superior patterns the pattern supports • Potentially conflicting patterns and why • Using the pattern • What components from the structural framework are required to use the game • Subpatterns that can be used to instantiate the pattern • Common choices a designer is faced with when trying to apply a pattern

More Related