TDT71: Game Development
This compendium is the 2015 version of TDT71
List of syllabus articles:
- A Brief History of Computer Games Presentation
- Pervasive Games
- MMORPG: Past, present and future Part 2
- Wear Out Effect of a Game-based Student Response System Presentation
- What makes things fun to learn? Heuristics for designing instructional computer games Presentation
- GameFlow: A model for evaulating player enjoyment in games Presentation
- Game development is harder than you think
- From visual simulation to VR to Games Presentation
- Requirement engineering and creative process in video gaming Presentation
- Evaluation of object-oriented design patterns in game development Presentation
- Scripting versus Emergence: Issues for Game Developers and Players in Game Environment Design Presentation
A Brief History of Computer Games
Changes in games
- Hardware: Better design, internet, saving games
- Interaction devices: Controllers, movement interaction (Kinect, Wii controllers), touch screens
- Software development tools: Game engines creates abstractions for programmers, making development more efficient
- Business: Teams instead of individuals, larger budgets, education towards the right skill set, ads and in-game purchases
- Diversification: Able to play on all kinds of devices today
The availability has improved drastically after more devices were introduced, especially the ability to play on devices not designed for games, such as PCs and mobile phones. This had a huge impact on the gaming demographics. Being able to save games enabled game developers to create stories, and gamers to experience progress on another level. Internet also provided with interactivity that revolutionized gaming.
Some major events:
- 50-59: First game in 52 (tic-tac-toe), and the first interactive game (tennis)
- 60-69: Movement towards commercial games, electro-mechanical arcade machine
- 70-79: Arcade "golden age" with Pong in 72 and Space Invaders in 78 (first colorized game). Game consoles
- 80-89: Poor quality games on console, before "comeback" in 85. PC games
- 90-99: Larger budgets, more power and 3D graphics, keyboard + mouse = new types of games, DirectX, handheld devices
- 00-09: Pirating, different requirements for different target audiences (e.g. graphics vs game dynamics)
- 10-11: 3D screens, pervasive games, more smart phone games
Pervasive games are games where virtual and real game elements are used together. There are many different types of pervasive games. Examples of these are smart toys, affective games, tabletop games, location-aware games and augmented reality games.
Most current smart toys are traditional toys equipped with simple sensing technology linked to computer logic. Based on how the toy is used, sounds can be played or graphical information can be displayed. Smart toys are excellent for pervasive games because the toy design suggests interaction method, and parents are not so reluctant to let the kids use smart toys as spending time in front of a monitor.
An example of what a smart toy can be used for is digital storytelling, encouraging children to use the toy in a specific way.
The goal of affective gaming is to capture how a player is feeling at any given moment and use it to enhance the game experience. This can for instance be done by using sensors to detect how the body is responding, voice analysis, or facial expression analysis.
An example of this is a two-player game where each player tries to move a physical ball which moves based on how relax the players are. Another example is making a player’s character jump when the physical player jumps from being startled.
Location-aware games work by using technology to track and identify players and objects, and turn the real world into a game board. This can be done with GPS, WiFi, infrared beacons, RFID or other signals. Games like these allow the players to walk around in the real world and use technology for virtual objectives. There are issues with this, like the uncertainty of sensing and wireless communication.
An example of this is a game where players can walk around outside and collect treasure, or accept objectives that shows up only on their smartphones
Augmented reality games
Augmented reality games are done by drawing virtual reality objects into a real-world environment. Users see their view augmented with 3D objects so they appear to exist in real space. This concept fits well with Stapleton's Mixed Fantasy Triad, which says that the ideal entertainment experience provides a combination of physical experience and virtual content, which stimulates the player such that they use their imagination to fill the gaps.
The three general approaches are:
- Head-mounted display: Users see virtual objects along with video of the real world taken from a camera mounted on their heads.
- Projecting images on real-world surfaces: Difficult to do, and interaction spoils the effect.
- Using handheld devices: A lightweight display device with camera can be used as a window into augmented space.
Most of the augmented reality games seen so far have required specialized hardware and controlled environments, which makes the games less convenient. Additionally, finding good interaction methods have been difficult.
MMORPG: Past, Present and Future
- PvP: Player vs Player
- PvE: Player vs Environment
- Griefing: The act of irritating and angering people in video games through the use of destruction, construction, or social engineering
- NPC: NonPlayer Character, i.e. a character controlled by the computer
- RPG: Role-Playing Game
- MMO: Massively Multiplayer Online
Background (part 1)
Precursors to MMORPG
Inspirations for MMORPG
Dungeons & Dragons (D&D)
Table-top game where the good tries to destroy the evil, inspired by The Lord of the Rings and containing similar types of races. Leading a character through an environment, and according to a set of rules and instructions perform tasks that progress their journey.
MUD1 was a text-based, multiuser dungeon computer game released in 1978. Gameplay was similar to D&D.
Single-player computer RPGs
Introduced real-time mechanics, several possible ways of completing tasks, and graphics so that players did not need to rely (that much) on their fantasy to play.
Multiplayer computer RPGs
Only for a small number of players, and could usually be played both alone or with others over LAN or internet. Some had player impact on the world and randomly generated content.
History of MMORPG
Meridian 59, which was released in 1996, is often credited to be the first MMORPG (this is disputed). Had mini-map, chat (with event logging), and player interaction. It was also the first to adopt the monthly fee as opposed to hourly rate. Some more MMORPGs:
- Ultima Online: First commercial success. Heavy on PvP
- EverQuest: Introduced the idea of raids
- Asheron's Call: Custom interface
Improvements to the graphics and interface (learned from first-generation), as well as Realm vs Realm combat, instances, player economy, crafting, and highly customizable characters. Some MMORPGs from this period:
- Dark Age of Camelot: Realm vs Realm
- Anarchy Online: Instances
- Final Fantasy XI: Cross Platform
- Eve Online: All on one server
- Star Wars Galaxies: Crafting
- The City of Heroes: Highly custom characters
- EverQuest II: Polished from experience
- World of Warcraft: Accessible
Survey results (part 2)
122 people participated, where the first part were a quantitative questionnaire, while the second was qualitative.
Most wanted settings:
- Other setting
- Post apocalyptic
- Outer space
Top 5 best liked features:
- Class/skill options
- Graphics and effects
- Large world to explore
Bottom 5 least liked features (5 is the least liked):
- Extensive story telling
- Low latency
- Raid content
- Low system requirements
Top 5 issues:
- Exploits and cheats
- Running out of content
- Player griefing
- Real-world services
- Camping rare items/spawns
Note: Running out of content was reported as the second largest issue, but "lots of content" was only the 6th most wanted feature.
Most wanted character development systems:
- Combination of class and skill : 41.4
- Skill : 40.6
- Class : 9.8
Improving existing features
- PvP combat: More balanced between classes (usually follows a "rock, paper, scissors" format)
- The (level) grind: Do repetitive actions in order to advance should be improved/hidden by giving it a purpose
- Story line (quests): Better distinguished from grinding; quests should be meaningful and drive the story
- Graphics and effects: Better graphics, but without new hardware. Exactly which improvements? Most could not pinpoint a specific improvement
- Content and updates: Response time on bugs; the need to utilize the variety of a raid party
- Classes and skills: Not balanced for all types of gameplay (e.g. PvP vs PvE); disputes about skill/class progression
- Technical enhancements: Better AI for better immersion
- Item crafting and economy: Needs more meaningful crafting; balance between worth before and after crafting
- Combat and skill: Too repetitive and/or easy combats
- Downtime: Time wasted finding party, travelling, and preparing for combat should be reduced
- Player impact on the world: "How can thousands of subscribers all feel like the hero?"
- Player-created content: More content and quests, made by the users. The problem is to limit the amount
- Technical enhancements: Adding voice chat
- Mini-games: Increase amount of variety and content with mini-games unrelated to the storyline
- Item crafting and economy: Make it more significant by limiting drops; specialized crafting skills, with trading/buying from eachother
- Player-aging and death: Debated, because it would raise the stakes, but at the same time be a huge loss to a committed player when it happens
- Dynamic environments: Flood, fire, weather, day and night; greater immersion if the environment changes
- Dynamic content and quests: Generate content based on player decisions for a personalized experience, and better "replayability"
- Realtime combat and damage: Targeting and then executing attack seems unnatural, they want a more fluid experience
- NPC interaction: They are too static, does not seem real. Should go and live a normal life when you don't need them
- Evolution: Biological and technological evolution according to a timeline
Wear Out Effect of a Game-Based Student Response System
Presentation How is the classroom dynamics, students' engangement, motivation, and perceived learning affected by GSRS short time vs long time? And finally, do they want to continue using it afterwards?
- SRS: Student Response System
- GSRS: Game-based Student Response System
- BYOD: Bring Your Own Device
SRS opened for new ways of teaching in the classrom by offering interactivity and new ways of learning for the students. It also provides benefits to teachers, as it allows them to receive real-time feedback on the learning progress of their students, as well as feedback on the quality of their lectures. The only problem was that some additional device was required in order to participate, which the wave of BYOD solved.
Some other benefits mentioned in the article (some assuming a "promised" quiz at the end of the lecture, so that students have that in mind when working):
- Higher attendance
- More focus throughout the entire lecture
- More work done by the students during class
- Most students and lecturers were positive to SRS
- Anonymous participation (shy students have benefitted immensely from this, in both learning and showing knowledge)
- Peer cooperation (discussing misconceptions)
- Make students the teacher by letting them create a quiz
There are also reported challenges:
- Time to learn and set up
- Create effective questions
- Adequate coverage of material
- The ability to adapt to instant student feedback
- Unreliable technology, such as browser compatibility and wireless
Compared to a SRS, a game-based SRS has more emphasis on engaging and motivating students by gamifying the response experience. The idea that fun and engagement provided through games help students learn topics, without realizing it is "work". According to the article, no documented effect on the use of GSRS was found.
The test was performed on Kahoot!, Alf Inge Wang's own creation, by Alf Inge. Some hundred students were given a questionaire with questions concerning their subjective experience of the use of Kahoot!, with the summarized results here:
- Classroom dynamics: Small wear out
- Engagement: Minimal wear out
- Motivation: Minimal wear out
- Perceived learning: No wear out
- Reusability: 94% wanted to use Kahoot! once a week or more
Specific experiences from the students (negative/neutral/positive):
- Easy to use
- Mixed response on reducing amount of talking
- Fun to compete
- Fun to play in the same room
- Better concentration
- More engaged
- Mixed response on emotional engagement
- Fun to play
- Wished Kahoot! was used more
- Neutral to positive response on topic motivation
- Learned from playing
What Makes Things Fun to Learn? Heuristics for Designing Instructional Computer Games
The main goal is to provide game developers with some heuristics for making games more fun to play.
The principles presented in the article can generally be categorized as part of either
Note that not all principles can be, nor should be, applied to every game. The best games do incorporate elements from all categories though, in a clever way.
In order for a computer game to be challenging, it must provide an attainable goal. Without an objective of the game, people have less motivation to progress. A goal should be/have:
- Appropriate difficulty (according to the players current skill)
- Performance feedback
A goal can be made obvious and compelling by the use of visual effect and fantasy. Finding a specific target on a map is not very compelling by itself, but by adding a hero that has to travel there in order to save humanity, the player suddenly have a compelling motivation for completing the goal.
A game is boring if a player is certain to win, or lose. Ways to make a game more uncertain:
- Variable difficulty level
- Multiple level goals (e.g. easily attainable main goal to drive the story, and a couple of difficult alternative goals to challenge good players)
- Hidden info
As to variable difficulty level, the difficulty can be automatically decided based on the player's performance, or chosen by the player. An important thing to notice is the player's self-esteem as a factor of the player's perceived success. In order to have success the challenges need to have an appropriate difficulty level, and in order for the player to understand their success, they need feedback and improve their skill. Variations of multiple goal levels include score-keeping and speeded completion. Hidden information can motivate the player to explore and understand his abilities, while randomness can increase the difficulty in achieving a goal.
Fantasies makes games more interesting to the player, and can make them more compelling or be used as a means of challenge (requiring the player to use his fantasy in order to complete a challenge). Not all fantasies are compelling to all types of people, and need to be carefully considered according to the target audience.
It augments the game, by helping the player visualize the challenge and receive feedback.
The player is required to use his fantasy to complete the game, e.g. shooting darts where distance and angle of the throw needs to be calculated (read: Fantasized) in order to succeed.
A difficult element to incorporate in a game, but very powerful: If a player has empathy with the character, the character's goal seems more compelling, and the feedback received resonates stronger with the player; associating a game with a certain emotion has a strong impact on the overall impression of the game. But different players are enticed by different emotions, and as such there is no "one fits all". A common example is horror games: Some people just love it, and some people cannot stand it.
"Curiosity killed the cat, but satisfaction brought it back"
A player's curiosity can be evoked by having just enough informational complexity, that is, some uncertainty in the information provided, while the situation is still comprehensible to the player. In order for the player to feel in control and have fun, the curiosity should be satisfied at some point.
Note that this differs from uncertainty in the challenge: A challenge refers to what the player can do, and complexity to what the player can understand.
Capturing the attention of the player by sensory cues, such as changing visuals or sound, makes a player at some level curious about the change and moves their attention to the source. Some ways of using these effects:
- As decoration
- Enhance fantasy
- As reward
- As a representation system: E.g. boring battle stats can be quite enticing with the right sensory tools
When a person is "missing" some information, they feel a need to attain this information to feel completeness and consistency. In order for the informative feedback to be the most engaging, it should be surprising and/or constructive as to motivate further progress.
GameFlow: A Model for Evaluating Player Enjoyment in Games
Inspired by the psychological concept of Flow, this articles formulate an equivalent model for evaluating enjoyment in games, and evaluates its usefulness.
Invented by Mihaly Csikszentmihalyi ("Me-high Cheek-sent-me-high"), Flow denotes the mental state of operation in which a person is fully immersed and time seems to "fly by". The concepts apply to all types of activities, and is relatable to all humans in all cultures around the world. Although there are no precise definition of the requirements, the general elements can be defined as this:
- Task that can be completed
- Task has clear goals
- Control over actions
- Immediate feedback
- Ability to concentrate
- No concerns, stronger sense of self afterwards
- Sense of time is altered
The article redefines the previously mentioned elements to specialize it towards games, as described in the following subsections. The examples are taken from the games and may not fit a general context.
A requirement for being absorbed in the game is having full concentration on the game and solving the task at hand. In order to do this the tasks should be meaningful, have an appropriate workload, and minimize non-related interactions (e.g. settings or other screen elements).
Example: Detailed world elements, compelling narrative, simple gameplay and interface, and numerous tasks and objects to monitor.
A challenge should match the player's skill level and provide different levels of difficulty for players of different skill level, in order to feel neither bored nor anxious. The level of satisfaction of completing a challenge depends on the perceived level of accomplishment, and is a form of intrinsic reward. Pace is said to be an important element, because too many challenges (although at a fitting difficulty level) can be tiring.
Example: Difficulty of AI, mission variation, mastering different races, balance between races.
The player should improve their skills during the game, and the learning should feel like a part of the game (which can make creating tutorials a challenge). Hints and tips during gameplay, or create real-world analogies, can be effective tools to help the player without interrupting the game. Learned skills should be useful for future challenges, and rewarded appropriately compared with the level of progression.
Example: Tool tips, online help, optional tutorial that fits story, RTS conventions, sensory cues, gradual introduction of elements, ability/skill/story rewards.
Players should be able to translate their intentions into in-game behaviour, and facilitate different styles of playing by allowing customization of controls. The control system (whether menues or actions) should be as effortless as possible to use. Actions should have an impact on the world, and let the player solve the problem the way they want (e.g. a multiple choice list of actions will restrict control). There should not be a single optimal strategy when facing a challenge, or the player will feel like being played.
Example: Pathfinding, adjust unit aggression and formations, hotkeys, different play styles for different races.
Goals should be easy to understand and presented at appropriate times (if there is a story, an overall goal should drive the player from start to finish). Each level should have multiple goals that test players in different skills and levels of difficulty.
Example: Introduction to story/world, in-game cutscenes, mission objectives.
Feedback should guide the player, both when winning and losing, and provide motivation to continue. In this respect, feedback is essential for maintaining concentration. Both actions and status/score should inform players of their success.
Example: Notification of mission success or failure, mission log, status, score and summary at end of mission, sensory feedback on actions and events.
Games should provide deep and effortless involvement, be emotionally engaging, and provide an "escape" from daily life (most games provide an experience that is unavailable to the player in real life). To do this, the interface should be transparent to the player's perception, the story/background relatable, and the game should affect the players senses in an appropriate way.
Example: Concentration, connection to heroes and story, no waiting.
Validation of GameFlow
The games were scored on a scale from 0-5 in each element from GameFlow. The games tested are very similar, but differed significantly in their ratings and economical success (Hint: Warcraft 3 was the successful one). These scores where averaged and compared with their ratings from GameRankings, in order to show if GameFlow can approximate how fun a game is:
- Game: GameFlow vs GameRankings score
- Warcraft 3: 96% vs 94%
- Lords of EverQuest: 48% vs 61%
The scores are similar, and thus the GameFlow model seem to be correlated with the fun of a game.
One important aspect of GameFlow, and Flow generally, is that the importance of each flow element is different for different types of games/activities. There is no "one fits all" solution, and one needs to find a clever balance between elements where they complement each other in the current context.
Another thing worth mentioning is the qualitative aspect of this review: All elements are subjective, and most requires extended observation of a player to evaluate properly, and are thus difficult to measure objectively. Tools for evaluating games more accurately and efficiently needs to be developed, as well as design models and tools for guiding creation of new games. An important observation was made in this regard: It was easier to identify shortcomings than what a game did well, and several well-done elements of Warcraft 3 was not noticed before its corresponding defects were noticed in Lords of EverQuest.
Game Development: Harder Than You Think
In the early years of game development, the primary concern of the programmers were to optimize the code on a low level in order for the game to run quickly. Now, its a challenge just to produce the desired end result, especially if multiplatform support are of concern. The first section introduce problems related to the size and complexity of game development as a software system, the next more directed at game-related problems.
Project size & complexity
The game development community have received little attention regarding development of tools to use. Console producers usually ship some development tools, but since the life span of a console is around 5 years, the tools are only updated for 4 years, tops, and learning to use each tool takes time. 3D-modeling tools are available, but usually directed towards animators and not games. This resuls in game developers creating their own tools, at least when innovating in technology or game design. Lately better asset management tools have been made available, but the article states it is not optimal.
The most common programming language to use is C++, mainly because it is fast, but it is not made to compile game code fast, and no development environments has been created for working with game development.
Compiling games takes a long time, as well as debugging, and loading of data (usually not optimized early in development process). When you have to debug for multiple platforms problems are bound to occur often, which requires compiling and loading between each fix for each platform. Some dynamic loading of content and code has been employed successfully. Distributed compilation have also been used, but is no cure-all solution. Refactoring is often performed to improve the compile time, but this sometimes happens at the cost of runtime speed.
Prone to errors when developing for several platforms, and lots of restructuring of code is required. With a team of several programmers, code should ideally be merged often, but since the workflow is slow and you don't want to introduce errors which hinders other developers from working, merges are often performed rarely.
Some components have good reusability, some not. An overview of reusable components, according to success:
- Very successful:
- Audio low-level
- Rendering low-level
- Skeletal animation and morph targets
- Slightly successful:
- Collision detection and physics (hard to create though)
- Networking low-level
- Mixed success:
- Scene management
- Persistent object storage
- Scripting languages
- AI functionality
In general, most of 3rd-party components are difficult to use, and requries good insight into the low-level functionality to use properly. Some also requires a specific structure of the data and components, which impose contrainst on the rest of the system. In the end the usefulness of buying versus creating their own components needs to be done for each component.
There are some game engines available, such as Unreal Engine, which offers a full game development environment. Sometimes they are perfect for a development team, but they are expensive, technically conservative (i.e. cannot innovate gaming industry with them), and has limited applicability in types of games.
Highly domain-specific requirements
Creating engine code requires the programmer to be knowledgeable in multiple areas, including mathematics and algorithms. Typical mathematical problems in game development include linear algebra and signal processing, and algorithmic problems 3D problems such as spatial partitioning, intersections, and clipping. There has been done a lot of research in the area, but usually for offline systems that can be adjusted between runs in order to get the wanted behaviour.
Many problems have good solutions, in isolation. Making them work together in a harmonious way is harder to do, and in game development there are complex system structures and algorithms that need to be designed to work together.
Depth of simulation
When dealing with realtime graphics, most of the numerical data needs to be integrable over time, which presents many problems in the discrete world of programming (integrate if/then/else-like statements?). Additionally, problems like stiffness (changing parameters results in failure) and tunneling (objects moving through each other when they should collide) occur due to the continuous nature of physics in game worlds.
Profiling is a hardware optimization technique that analyze computational requirements and assign computations accordingly to utilize most of the hardware capabilities. The problem in game development is that the bottlenecks are constantly moving from one part of the system/code to another, which means that commercial tools for profiling (using averages for distributing workload) often fails to optimize anything, and vendor-specific profiling tools too general/insufficient for high optimization.
Game developers are constantly under pressure to deliver something new. This requires using new technology and game design, which introduce uncertainty in both development and end result.
From Visual Simulation to Virtual Reality to Games
Serious games denotes the categories of games that are extended by pedagogy or instructional content. In order for a serious game to be successful the pedagogy part should be subordinate to the entertainment, or else the positiv effect of entertainment will be gone. This is what is called collateral learning, where the learning is a "side effect" of other activites that cannot be viewed as traditional teaching.
One of the issues, then, is incorporating pedagogy into games in a way that the player does not realize it. This requires people from all relevant domains, i.e. game designers, educators, and subject experts.
A research group dedicated towards developing methodology (principles, processes, and procedures) and tools for creating serious games, in order to shorten development time and improve the quality of such games. The group includes researchers and students from several universities and fields of study.
Game production challenges
Some of the problems experienced in game production environments:
- Dissolution of team after completing a game
- Increasing learning time for tools
- Increasing production time
- Less reuse of components
- Higher demands for portability
These areas are of special interest when researching serious games:
MMOGs have pushed the limits of research in areas that are useful in serious games, such as large, networked simulations. But this work has not provided dynamical systems fitting a variety of serious games, which will need to be developed in order to achieve reusability. Current game development engines have limitations, such as size of game areas, and are usually really expensive. The ability of streaming large amounts of data will also need some attention in order to facilitate future requirements.
Cognitive game design
To create a realistic simulation, better human and organizational behaviour needs to be developed, that can run a large number of entities simulaneously. Also, to provide flexibility, a way of creating compelling computer-generated stories should be deviced, which supports player immersion. Usually such tasks have been done by a human monitor, but this is not a viable solution in the long run.
Further development in graphics, sound, and haptic feedback is required to create more realistic simulators able of evoking certain emotions in the player. Many environments require the player to cope with, e.g. stress, and has limited usefulness without being able to provoke such emotions. A field of study called affective computing deals with monitoring human responses, like facial expressions and physical responses, which will be crucial in having the game react appropriately. At the time the article was written (2005), it was said that such monitoring systems would be available to a low price within a couple of years, but this seems to still be some years away.
Another element that breaks immersion today is the quality of computer controller entities, i.e. we need better AI.
Requirements Engineering and the Creative Process in the Video Game Industry
Combining create and technological processes are hard to do, where many problems can be traced back to the transition from pre-production to production, i.e. requirements engineering. The article presents some of the problems, highlighting the need for an improved requirements engineering process.
- NFR: Non-Functional Requirement
- GDD: Game Design Document (conceptual description of the game)
Requirements engineering is the process happening between preproduction and production, where the technical team needs to create a specification using the GDD. Some of the issues that arise are described below.
The problem with emotional requirements is there are no formal techniques of eliciting specific emotions, and may be hard to specify.
In order for people in different fields and processes of game development to understand each other, they need a common language and understandable documentation. However, creating understandable documentation, at least for the creative process, will impair the end result, and possibly require more iterations of feedback and adjustments.
Elicitation, feedback and emergence
After documentation has been reviewed by the team responsible for the next step in the process, there will often be discovered limitations or misconceptions that needs to be considered in the previous step (e.g. creative team assumes AI will be better than state-of-the-art). As a result there will be a loop of feedback and adjustments, that emerges as new requirements.
Transition from preproduction to production
The current processes of requirements engineering have several faults that should be improved in order to shorten development time and avoid errors and misconceptions.
- GDD as requirement specification: Either, the GDD is overly specific or the GDD is solved on a case-to-case basis
- Going into production too soon
- Not documenting changes
In the evaluation, members of development teams and middle management were asked top 5 things of what went right and what went wrong. They were also asked to stay away from "common" problems, and tell them what they perceived as unique or different for their project.
The responses in the evaluation was attributed one or more of the following categories:
Internal issues had many more "rights" and "wrongs" than any other category. Many issues were reflected in several categories, which shows a strong cross-domain correlation. All categories were reported to have about equal amount of "rights" and "wrongs", even in the same project, based on different factors. The reason for this is unclear, but might be attributed to a problem with the categorization, or its just an inherent property of the data.
Examples from real games
External problems would often lead to internal problems, which again would make the schedule uncertain.
A documentation transformation roughly needs to go through these steps:
- Story: Background for the game
- Gameplay: How the story should be played
- Requirements: What the gameplay requires from a technical perspective
- Specification: Detailed implementation descriptions based on the requirements
Each step produce longer documentation, and workers at each step must take different viewpoints, domain language, NFRs, and inconsistencies from the previous step into account.
GDDs contains a lot of implied information (probably because of the abstract nature of the specifications?), which needs to be analyzed and understood in order to be specified in a formal manner later in the requirement engineering process. Some levels of implication mentioned in the article:
- First-level implications: Derived directly from the presented material
- Domain knowledge implications: General knowledge about the domain required (e.g. genre elements)
- Implementation knowledge: Knowledge about how the game will be created (e.g. architecture)
An issue raised here is "when should feedback be given?". Late feedback means more work for the programmers, early feedback could have a negative impact on the creative process (conditioning from multiple early restrictions).
A priori knowledge
Everyone cannot know everything about every step of the process, and teaching technical details and such may take longer than an iterative feedback process. Often, the people that should formalize documentation have too little time, and junior staff members which have less knowledge and experience are assigned the task. All of this leads to multiple collaboration problems:
- Lots of abbreviations
- Lack of technical knowledge
- Difficulties in representing visual content in a formal manner
Some challenges that are presented as unique to the game development industry:
- Stakeholders with different backgrounds
- Resisting feature additions
- Influence of prior work (e.g. sequels of game series)
- Media and technological integration and interaction
- Importance of NFRs
- Gameplay requirements
Evaluation of Object-Oriented Design Patterns in Game Development
Compared with earlier, games today are subject to higher change rates and greater complexity. Because of the increasing demand from customers we can expect this trend to continue, and so there is a great need to find design patterns in games to mitigate these developments.
- LOD: Level Of Detail
- WMPC: Weighted Methods Per Class
Design patterns should be used in order to improve
of code, which is especially important when future development and/or updates are required. One of the obvious answers to these problems are using modules of independent code that can be reused, and exchanged if necessary. By keeping all relevant logic in separate modules, the maintainability and comprehensibility will increase, and switching between modules for different behaviour increases flexibility.
Modules, or design patters, can be used in both logic and graphics of the game.
The strategy pattern denotes a family of algorithms which are interchangable. Example: Different difficulties of a chess computer.
An observer pattern is a one-to-many relation, used when an object needs to notify many other objects of changes. Example: Football team have had a practice, and so all players' skill should increase.
This pattern allows an object to alter its behaviour when its internal state changes. Example: LOD according to distance from the object
Decouples abstraction and implementation, i.e. lets an object have multiple different, interchangable properties. Example: Ball having the possibility to have either smooth or rough texture.
Tests were conducted on two different open-source games, Cannon Smash and Ice Hockey Manager, because of availability, multiple releases, and presence of design patterns in one version and not in another.
- Lines of code
- Number of classes
- Attribute complexity: Sum of attribute complexity values in a class (each type assigned a subjective value)
- WMPC 1: Sum of weighted CC
- WMPC 2: Number of methods and parameters (higher number = higher complexity)
- Coupling factor: Number of non-inheritance couplings divided by maximum number of couplings
- Lack of cohesion methods: Number of pairs of methods in a class that shares an attribute
where CC (Cyclomatic Complexity) denotes the number of paths through an algorithm.
- Size: Class size went down (good), project size up (bad)
- Complexity: Went down (good) except slight rise in project WMPC2
- Coupling factor: Went down (good)
- Lack of cohesion: Went down (good)
More object-oriented design patterns should be examined to decide usefulness in keeping projects simple. Also, investigations to decide if classes participating in patterns are more prone to change should be done. The article authors are planning to implement a game engine or game according to the findings of the article.
Scripting Versus Emergence: Issues for Game Developers and Players in Game Environment Design
The article presents the issues associated with the two different design approaches, and discusses the methods used for facilitating each design.
Player enjoyment is the most important criteria when developing games, and require great consideration when choosing design. The criterias considered in this article:
- Consistency and immersion
- Intuitiveness and learning
- Emergent gameplay and player expression
Different games have different requirements, and the developers need to be aware of the pros and cons when deciding which approach to take. Criterias considered in the article:
- Effort in designing, implementing, and testing
- Effort in modifying and extending
- Level of creative control
- Uncertainty and quality control
- Ease of feedback and direction
A scripted game is limited to the behaviour and progression the developer has predefined. While it is possible to create meaningful and engaging stories, some degree of immersion might be loss when the player discovers limiting dynamics.
Evaluation of player criterias
- Inconsistency between player's expectations and scripted dynamics, which degrades immersion
- Limited interaction with environment, which breaks intuitivity and player needs to learn its limitations
- Low degree of freedom
Evaluation of developer criterias
- Planning requires a lot of time, all elements need to be controlled and tested
- Scales poorly, hard to extend
- Full creative control
- No uncertainty, but needs to be tested for inconsistencies
- Knows when and how player will interact, so it is easy to give feedback and directions
- Finite State Machines
- Scripting languages: Simplify some set of programming tasks
An emergent game has general rules and mechanisms that dynamically controls game elements.
Evaluation of player criterias
- Intuitive behaviour of world, so greater immersion. Objects consistently behave as expected
- Intuitive world lets player use external experience, which requires less learning
- Creative control to solve problems, higher replayability
Evaluation of developer criterias
- High initial effort in planning, building and fine tuning, but high reusability
- Easy to scale and extend
- Lose creative control, hard to control the flow of the game
- High uncertainty, does not always behave as intended and requires lots of testing
- The player needs more feedback due to the open environment (but possibly harder to give? Article does not say)
- Flocking: E.g. movement of groups of individuals
- Cellular Automata: E.g. influence maps for decision-making or social behaviour
- Neural Networks
- Evolutionary Algorithms
Scripting vs Emergence
Emergence focuses on what the player wants to do, whereas scripting focuses on what the designer wants the player to do. There are drawbacks with each extreme of designs, which suggest that using a combination is a good approach, and will be used significantly in the (near) future.
Not directly an element of Flow, and can be both constructive and destructive. The social interaction must either be just what it is, a social device, or improve other flow elements, e.g. motivate cooperation, competition, or immersion.
Example: Multiplayer modes, matchmaking and rankings, text chat, ability to create and share game content.