Jump to content
  • Advertisement
  • 02/06/12 08:00 AM
    Sign in to follow this  

    The Six Facets of Serious Game Design: a Methodology Enhanced by our Design Pattern Library

    Game Design and Theory


    Download the PDF version of the paper: click here.


    One of the main problems with serious games (SGs) is that if they are designed only by game designers: they may be very entertaining, but knowledge acquisition may not be forthcoming. On the other hand, teachers and trainers may design games that are educationally very efficient, but lacking in the capacity to motivate and engage the player. Our experience of collaborating with design teams and browsing published examples of serious games has led us to the above conclusion and the necessity to create a Design Pattern library to facilitate the cooperation between the different stakeholders in the game design process. We can broadly group the stakeholders into two categories, the pedagogical experts and the game experts. By pedagogical experts or teachers we mean knowledge engineers, teachers, educators, and domain specialists. By game experts we mean game designers, level designers, game producers, sound and graphic designers, and so on. However, defining a serious game is a tall order.

    Serious games can be defined as “(digital) games used for purposes other than mere entertainment” [1]. This definition is very wide in its scope and to combine fun and learning, we prefer to narrow it down to the notion of the “intrinsic metaphor”. The latter can be defined as “a virtual environment and a gaming experience in which the contents that we want to teach can be naturally embedded with some contextual relevance in terms of the game-playing [...]” [2]

    For the moment, a difficulty arises when the teachers and the game experts work together: do they understand the goals of each other? Are they able to communicate efficiently to produce a product that is both educationally efficient and fun to play?

    The aim of this paper is to define and describe tools which allow everybody concerned to speak the same language, to be on the same conceptual wave length, and to allow some insight into the design process. We chose to build and review a common solution for these problems: a Design Pattern library to be used within our conceptual framework. We shall therefore focus first on the latter: The Six Facets of Serious Game Design. Then, we shall discuss the previous work on Design Patterns (DPs) and present our library. Finally, we shall present our fieldwork applying the library to it.

    The Six Facets: a Conceptual Framework for Serious Game Design

    Some conceptual frameworks are cited as a method to help designers to blue print serious games. For instance, Yusoff [3] and related work [4], define within his framework the steps to be taken when designing a serious game. The latter do not specify which experts should intervene in each step of the process. On the other hand, Marfisi-Schottman [5] introduces a seven step model, which attributes specific roles and steps to each expert (cognitive and pedagogical experts, storyboard writers, artistic directors, actors, graphic designers, sound managers, etc.). One difficulty, however, with both of these models is that they are sequential and do not easily fit into an iterative design model.

    Especially for the serious games based on an intrinsic metaphor, we designed a non sequential and more flexible framework, clearly making explicit the experts needed at each step. We shall present our six facet model and show how it can be used.

    Our conceptual framework aims to help evaluate the design process and improve it, either during the design process period or after it (post-mortem) to extract Design Patterns. Each facet is defined by its title, an SG design problem, a general solution and its experts. Previous papers have detailed the facets with numerous examples [6, 7]. Therefore, we shall make only a quick overview of each facet of this framework in order to present how our Design Patterns library will fit into it.

    The goal of the first facet, “Pedagogical Objectives”, is to define the pedagogical content. The general solution is to describe the knowledge model (including misconceptions) of the domain and the educational objectives. The key players here are the pedagogical experts. However, the other participants can gain important information as to how the former work and build a knowledge model.

    For Instance, Donjons & Radon1 is an SG meant to help junior high school students to study the transitions of the states of matter. Its Pedagogical Objectives are compiled in a graphed model of a physics course. This model was made by teachers and pedagogical experts with a graphical knowledge and pedagogical modeling tool (MOT [8]) and was intensively used by all the stakeholders during the design process.

    “Domain Simulation” (second facet) raises the problem of how to respond consistently and coherently to the correct or erroneous actions of the game players within a specific unambiguous context. The solution consists in defining a simulation based on a formal model of the (educational) discipline. The specialists of this facet are the pedagogical experts.

    For instance, as further detailed below in our section about fieldwork (fifth section), the Donjons & Radon Domain Simulator was finally based on the water phase diagram model, to ensure the relevancy of the interactions in the game.

    The third facet, “Interactions with the Simulation” specifies how to engage the players by allowing them to interact with the simulator. The solution is to define the interactions with the formal model through the intrinsic metaphor chosen for the specific SG. The specialists of this facet are the game experts (mainly game designers, level designers, and game producers).

    For example, we are working on Défense Immunitaire, an SG project meant to teach immunology to junior high students. Interactions with the immunology Simulator are based on the metaphor of the “Tower Defense”. It is a particular kind of Real Time Strategy (RTS) game. The students must defend a territory (the metaphor of the body) by adjusting the defenses (metaphor of the immune system).

    “Problems and Progression” (fourth facet) concerns which problems to give the players to solve and in which order. The solution is to design the progression taking into account both required knowledge acquisition (pedagogy) and the progress of the player (fun) from one level to the next. The progression in the game can be viewed as a sequence of challenges (obstacles/problems) that have been overcome. One important point is how to gain feedback concerning the progress made by the player and to transfer it to both the player himself and the trainer. The specialists of this facet are both the pedagogical team and the game experts. Here both groups must be able to communicate clearly and understand each other unambiguously.

    For instance in the famous SG Americas-Army 32 progress in both game and domain competencies are reified with rewards badges.

    “Decorum” (fifth facet) specifies which type of multimedia or fun elements, unrelated to the domain simulation, will foster the motivation of the players. This can be the shape of the avatar, a game within a game, a museum, a hall of fame etc. The specialists of this facet are the game experts. The main objective here is to increase the fun element and consolidate engagement.

    For example, the SG Prévenir la grippe H1N13, is about the flu in a virtual world where cowboys are fighting using soap against different kinds of aliens. The representations for cowboys and aliens create a Decorum with a comical atmosphere based on an absurd situation. These representations, and associated interactions, are made to enhance students’ engagement and are not in any way related to the domain simulation.

    “Conditions of Use” (sixth facet) specify how, where, when, and with whom the game is played. Games can be played by one or several players, in class or online, with or without an instructor etc. The specialists of this facet are both the pedagogical team and the game experts: the former to ensure the efficiency of the learning process, the latter to maintain motivation and engagement.

    For instance, early in the design of Donjons & Radon, the stakeholders decided that the SG should be played during 30-40min sessions, to fit into the French secondary school schedules.


    Fig 1. Graphical representation of The Six Facets of Serious Game Design. For each facet, each type of expertise is shown by an icon.

    One benefit of the Six Facets model is to designate the right expert(s) for each design area. But there still remains the problem of how to share the expert knowledge with all those involved within each facet. How can we do this with a view to helping everyone to find their place in the design process, with the goal of improving the combination of fun and pedagogy in serious games based on intrinsic metaphors?

    Hopefully the knowledge of the experts is sometimes extracted and set out in the form of “Best Practices”. We choose to use the latter approach as Alexander [9] did, by building a Design Pattern library. DPs constitute a set of good practices, focusing on one specific domain (architecture [9], software design [10], SG design [11], etc.), classified so as to be easily retrieved. They can be organized typically in terms of Pattern Name, Context, Problem, Forces, Solution, and also Examples and Related Patterns (if available) facilitating the building of a common pattern language that fosters communication.

    Indeed, when Design Patterns are organized by referring to one another, they form what Alexander called a Pattern Language [9]. As far as we are concerned, both Design Patterns and Pattern Languages aim at facilitating the re-use of the best solutions or favoring discussion, brainstorming, and exchange of ideas between game designers and the pedagogical team.

    Previous Work and Methodology

    Since not so much has been written about DPs for serious games, we extended our reading to the field of TEL and video game design. Our study begins with TEL systems. For example, Design Patterns were found about active learning [12], Learning Management Systems [13], Intelligent Tutoring Systems [14] or about analyzing usage in learning systems [15]. But they do not take into account the game-playing dimension needed to design an SG based on an intrinsic metaphor.

    In the game and serious game design area, we found that the eleven DPs for Educational Games conceived by Plass and Homer [16] did not have the coherence we were looking for because of their lack of categorization. Barwood and Falstein [17] provided a 400 tag-referenced pattern website based on a DP library but with the same problem: tagging is not an effective enough categorizing tool to build a concrete language for both types of experts of SG design. It would be a tall order to organize them coherently and make use of them efficiently.

    On the other hand, many authors provide a highly structured DP library. For example, Gee [18] provides a wide list of principles organized according to design problems built after examining many games involving learning. But it was not really based on serious games. Aldrich [19] did present a sophisticated encyclopædic DP library based on simulations and SGs. However, the structure of the library is too complex to be used as a language to help both types of experts of SG design to communicate. On the other hand, Schell [20] presents one hundred “lenses” in a very understandable visual structure. Unfortunately, the purpose of Shell's lenses is to help designers to build good games and not good serious games.

    In the end, we preferred to keep those of Kiili [21], and Björk and Holopaienen [22] especially for their ability to be used for SG design and their compliance with Alexander’s [9] and Meszaros’ [11] DP library structure. The library of Björk and Holopaienen [22] is both coherent and functional. They created their 200 DPs after interviewing seven game designers. Their aim was to build a catalogue allowing discussion and collaboration. The latter were not intended for the pedagogical aspect of serious games. Nevertheless, Kelle [23] designed a pedagogical meta-structure for Björk and Holopaienen’s DPs. Kelle linked the key pedagogical functions with the game design patterns. By mapping the latter they foster the discovery or the adaptation of new DPs specifically designed to mix fun and pedagogy. We have also adapted some of Björk and Holopaienen’s DPs such as “Serious Boss” adapted in “Boss Monster (GD)” (DPs from Björk and Holopaienen will appear in Table 1 with the letters GD).

    The work of Kiili [21], however, concentrates on serious game design. The weak point is that Kiili [21] conceived a very small library (only eight DPs in six categories), having designed only one game: AnimalClass. We have kept some of them and they will appear followed by the letter K.

    To collect, adapt patterns and add to the library, we gathered a work team composed of researchers, one game designer and two teachers. Then, in this team, we used an empirical method (bottom-up research) described below. We began with four serious games created by our private partner KTM-Advance4 (StarBank, Blossom Flowers, Hairz’ Island, Ludiville), an e-learning company, located in Paris, which has been developing serious games for several years. Unlike many SGs, the latter are not based on quizzes, but use an intrinsic metaphor, thus deploying quite advanced interaction to enhance learning. For example, a builder game (like Sim-City) is used to teach the ins and outs of banking. We also used one more serious game design with an intrinsic metaphor, Donjons & Radon, developed by a private consortium to which we belong.

    We chose to study these five SGs for two reasons: the games were based on intrinsic metaphors, and we had full access to all the design documents. Moreover we made an in-depth analysis of twenty games selected from the Serious Game Classification Library [24]. We selected the games on the same criteria: intrinsic metaphor and access to the greatest quantity of information we could gather. We also conducted interviews with researchers and game designers and the detailed study of two particular design cases.

    For each facet of our Six Facets Framework described above, we compiled all our collected data covering different types of design experience, knowledge, and methods. For each facet, we looked for the common problems the designers faced. And we compiled the most interesting answers we had collected in order to build a pattern language as described in the Design Patterns for DP Design provided by Mescaros [11].

    Our Design Patterns Collaborative Library

    Our DP collaborative library is made up of 42 DPs within our Six Facet framework [25]. Table 1 presents the library thus organized. Within each facet, the DPs can be useful for those involved, highlighting the methods used, and form a knowledge base favoring discussion. The ultimate goal of the DPs is to enhance communication between the experts so that the game is both appealing and efficient as a learning process.

    We shall first present the list of DPs in the synoptic table, and second, we shall present two examples to illustrate how DPs can best be used. The first one is "Time for Play / Time for Thought" (Facet #3: Interactions with the Simulation), the second is "Reified Knowledge" (Facet #4: Problems and Progression). Design patterns are typically written in italics.

    Synoptic Table of Our Design Pattern Library



    Pattern: Time for Play / Time for Thought

    Context: Suppose one starts the Game-Based Learning Blend with a list of educational objectives, including high-level knowledge.

    Problem: How can one teach high-level knowledge while the player is engaged in the game?

    Forces: It is difficult for learners/players to concentrate on the interactions of the game and be engrossed in high-level thinking at one and the same time because of cognitive overload. We must point out here that video games are often based on instantaneous interaction while some knowledge acquisition requires standing back (distance with respect to the problem) and taking time to ponder over what is to be learnt (the reflective phase).Solution: It is a good idea to use intensive action phases for practice and training; and create less intensive phases for thought and reflection. Frequent comments compare and contrast playing and learning; whereas, the real antithesis may well be between action (doing something) and reflection (thinking about what one is doing or evaluating what one has done).

    In “Foundation for problem-based gaming” [21] analyzing problem-based gaming, Kiili highlights the need for reflective phases. The latter are for “personal synthesis of knowledge, validation of hypothesis laid or a new playing strategy to be tested”. During action phases, users are engaged emotionally, or focused on a goal, thus they are unlikely to be able to revise or re-structure knowledge acquired during the game. It must be pointed out that those two phases should be part and parcel of the fabric of the game. Video games, like thriller scenarios in the cinema, often provide less-intensive phases for (comic) relief purposes.

    Examples: Warcraft III and Plants vs. Zombies are well-known examples of the “Tower Defense” type of video game. In this kind, the transition between phases of action and thought provides the core of the gameplay. There are some serious games of the Tower Defense variety, with the time for play separated from the time for thought, for instance Le Jardinier Ecolo8, or Defense immunitaire on which we have been working (similar projects already exist [26]).

    Uncharted and L.A. Noire, are famous video games for their scenarios in which the switch between phases of action and thought is a central element of the story. This is another way to include the flip over between these phases.

    Related Patterns: Instructional Gameplay: during action phases to allow the player to discover, experience emotionally, or experiment with new knowledge.

    Debriefing: during reflective phases, to explain or return to what has been happening during the action.

    Reified Knowledge and Advanced Indicators: (useful supplementary information providing food for thought) incorporated into the action phases can give the player a bird’s eye view of the action.

    This DP belongs to the third facet (Interactions with the Simulation) and mainly concerns the game experts but can be extremely useful for the educational team.

    Pattern: Reified Knowledge

    Context: The particular game that the team is designing involves a variety of competence and knowledge problems.

    Problem: How can one help users become more aware of their acquired knowledge?

    Forces: Several problems arise. How can we make the player aware of the progress he has made for each skill or activity without taking him out of the Flow [27]? How can we use this type of information to enhance his/her motivation and enjoyment of the game?

    Solution: Represent items of knowledge or competencies (skills) with virtual objects to be collected. If players have acquired the requisite skill or piece of knowledge, they will be given an object symbolizing this or that knowledge acquisition.

    For instance, the users can see their acquisitions either in knowledge or skills embodied in medals, stars or other objects awarded. Every award is placed in a showcase, and thus is exhibited as a means of recapitulating what has been acquired.

    Example: in America's Army 3, medals can be won when special deeds are accomplished. For example, users win a “distinguished auto-rifleman” medal when they have won 50 games as riflemen in combat. Medals, however, do not further player progress in the game; and are more a way of reifying the playing style by rendering it concrete.

    In Ludiville (a KTM-Advance game for a bank), knowledge about home loans is reified by beautiful trading cards (as in a game called Magic the Gathering). Once having learnt a new piece of knowledge, players obtain the related card, which they can use later in the game to meet new challenges.

    Related Patterns: Object Collection: also used to motivate players who like to collect things.

    This DP belongs to the fourth facet (Problems and Progression) and concerns both game experts and teachers, who have to cooperate here

    Fieldwork and Discussion

    Initially our Design Patterns were tested with a group of twenty students specialized in video game design10. They were interviewed and given a questionnaire to fill in after studying the DPs. At the time, our DPs were mainly game design centered, and as the students were knowledgeable in game design they seemingly did not have any use for our DPs. Nevertheless, they showed much interest in some more DPs focusing on pedagogy.

    Subsequently, we tested the patterns with two teachers, one working in high school on the body’s immune system, the other in college working on a course to help French students understand the US educational system. Both found the DPs useful.

    The first project, called Graduate Admission, is hypothetical. The English teacher started the project from scratch and used our first DPs to explore game design possibilities. He began by using the Design Pattern Game-Based Learning Blend, thus following the procedure used by KTM-Advance game designers [4].

    He first clearly formulated the educational objectives of the game before designing the storyboard: acquiring the skills and knowledge for admission to an American graduate course; understanding the American higher education system, and the attitudes that Americans have about study and college life; pitfalls that must be avoided (main, most commonly made mistakes.)

    Secondly, he used the pattern Narrative Structure (GD) to invent a game scenario: A French student in his/her last year at a French university (Bachelor’s degree), has met an American visiting Paris. They fall in love and decide to live together. However, the American has been admitted to a graduate school in the US. The French person has decided to apply to the same university. The game consists in acquiring the necessary skills and knowledge to be selected for admission.

    In this game project, the thought or reflective phase (Time for Play / Time for Thought) could come after the failure to write an acceptable letter or CV. The player should be guided towards understanding the cultural differences, the usage gap between France and the US. Subsequently, the statement of purpose (SOP), which does not exist in France, would probably be a major drawback and a terrible pitfall for a French student. The DP Debriefing could be implemented by showing the learner examples of bad SOPs, or by showing his SOP and getting advice from American friends. In other words, Debriefing consists in making the player/learner aware of his/her errors and presenting him with the required knowledge necessary for accomplishing the specific task, and especially
    understanding a higher level cultural trait in depth.

    The DPs were useful in helping the teacher to organize his project, outlining the main pedagogical content, creating a simple storyboard. Several students took part in a workshop where they could try out the different phases of the game and acquire symbolic objects. The game prototype was extremely simple and used interconnected web pages, video, and text to show the players how to apply for a university, write a statement of purpose, a résumé, fill in an application form, and prepare an interview.

    The human immune system motivated the second game project for junior high students. After consulting the library, the teacher chose the DP Time for Play /Time for Thought as it corresponded to one of the main issues when it comes to teaching immunology. Indeed, students find it difficult to focus on the matching mechanisms related to the body defense system and microbes while endeavoring to do the exercises. The DP helped the teacher to choose a specific game play: Tower Defense. This kind of game enables players to select their strategies, test them in action, and if they are valid, move on to a reflexive phase during which the initial strategy can be modified if need be.

    To conclude, both teachers found the DPs useful and stimulating because the library allowed each of them to find game play solutions for pedagogical problems. This fieldwork with both game design students and teachers demonstrate that DP users are not very interested in DPs focused on their expertise, but more in DPs exploring different or new knowledge. As we had built our first DPs focusing on game design solutions to pedagogical problems, they drew the teachers’ attention. On the contrary, game design experts were looking for more educational aspects in our DPs.

    For these initial tests of DPs, we were in the context of a single SG designer (teachers or game designers alone). However, we also had the opportunity to try our DPs with some multidisciplinary design teams, closer to the real conditions for which we made the library. On these occasions we also tried to enhance the library. At first, we used facets to identify areas of work, and then we used the Design Patterns to help the team of designers when they were stuck with some problems. For instance, we had relevance problems in the game design of the project Donjons & Radon. It is an SG meant to teach water transition phases. The game designer used only schoolbooks to build the core of the puzzles in the game. Doing so, and because he had not a wide knowledge of physics, he made several mistakes concerning the laws of physics. Fortunately, these mistakes were spotted by a physicist during a design meeting. But as the experts were very unlikely to be present during these meetings we were concerned about new mistakes being made.

    Thanks to the facets and the DP library, we rapidly established that the design methodology was erroneous: the water behavior was not ruled by a simulation, but had been built by the game designer with simple rules based on the gameplay. And, for that reason, these rules were wrong in many cases. The DP An Early Simulator (Inside the second facet: Domain Simulation) was used to convince the game expert to build interactions based on a simulator designed by physics experts. The DPs Do not Simulate Everything and Elements that Cannot be Simulated helped the physics experts to exclude the kinetic aspect of the changes of the states of matter, and to build a proper simulation using a simple diagram of the water “triple point” (three axes phase diagram of the state of water).

    On other occasions, these types of design problems had occurred and we had to refer to several Design Patterns of one of the facets. In some other situations, good examples of design processes led us to build new DPs for our library.

    Even if it is very difficult to assess DPs, we are currently working on further evaluation tools for our Design Pattern library. The first aspect of these new evaluation tools is community evaluation. We made a collaborative library, giving everyone the ability to consult, assess, comment on, and even translate, modify, and create DPs. When our DP library is well known enough, we hope that the community will give us some qualitative evaluation feedback through comments and modification suggestions. The tracks of the website visitors are also fully recorded in our logs, and we hope that full analysis of the users' navigation will help us to evaluate our library quantitatively.

    In order to assess the library, the comparison of two serious games designed with and without DPs is difficult. It is necessray to use indicators to show that games designed with our DPs are better designed than others. We are working on tools to construct a typology of serious games based on the facets. One particular goal of this typology is to serve as an indicator to assess if the game achieved matches the original objectives. Therefore, for a game project, we must determine the "initial type" as early as possible and then compare it with the "final type" of the game made.


    Fig. 2. Each scale represents the valence for each facet. The triangles give the measure of the valence. On the left, there is a stereotype of a serious game with an intrinsic metaphor (it could be the “initial type”). On the right there are the valence scales for a typical TEL system (it could be the “final type” that designers may not want to obtain).

    This typology is based on a valence scale for each of the Six Facets. For instance, for the fourth facet (Condition of Use) there is a tendency to describe very early in the design process the exact conditions of use (e.g. Donjons & Radon described above in section 2). However, some designers prefer not to describe the condition of use, and let the users determine it as needed. We are designing some questionnaires to measure these valences for each facet and to set the type of a game project at every step of its design.

    We hope to show that the DPs help enhance the compliance with specifications regarding the mix of fun and pedagogy by measuring the gap between the valences measured at the beginning and the end of the serious game projects built with or without them.

    Conclusion and Future Avenues of Research

    By using the Six Facet approach, we have tried to relate the different phases of game design for educational purposes. A team of game designers and teachers should be able to work together and communicate their ideas, brainstorm when necessary, arrive at some kind of holistic coherence.

    Thanks to our fieldwork, we have established that when we use our DP library within our Six Facets Framework, it helps the teams to solve some design problems and fosters the communication between stakeholders. Moreover, we noted that our DPs were well suited to the needs of teachers, allowing them to understand the aims, means, and methods of the game experts. Nevertheless there is still much work to be done to help game experts to embrace the pedagogical aspects.

    To help in this undertaking, we have created a collaborative web site where those interested can make suggestions, or give us feedback on their experience with DPs, and even create new DPs. We hope to manage this emerging community successfully along the lines of the Bazaar [28] to get feedback and fruitful contributions. Hopefully, this paper will attract some interest. We are also working to find some way to benchmark our DPs and to follow the evolution of SG projects and their use of the DP library.

      Report Article
    Sign in to follow this  

    User Feedback

    There are no comments to display.

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Advertisement
  • Game Developer Survey


    We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a $15 incentive for your time and insights. Click here to start!

    Take me to the survey!

  • Advertisement
  • Latest Featured Articles

  • Featured Blogs

  • Advertisement
  • Popular Now

  • Similar Content

    • By Loosearmy
      Concept for Delayed Shots in a Fast Paced Shooter
      The base for this concept is that with each click or trigger pull there is a X-second delay before the gun would actually fire. This would make it alot more difficult to time shots and could create unique design elements that would cater to this delay. (i.e sharp corners and hallways where it would be hard to time when to click in such a tight enclosed space). Ive had this concept for a minute and i know we could code it to work but my main concern with this is, would it be a good design choice?
    • By mujina
      What could be a way of avoiding using inheritance and virtual methods when designing components for an entity-component-system?
      I'll be more specific about my design issue:
      I currently have different classes for different kinds of colliders (let's say, CircleCollider and LineCollider).
      My system that checks for collisions and updates the positions and/or velocities of my entities should be something like:
      for entity_i in alive_entities { collider_i = get_collider_of_entity(entity_i) // components of same kind are stored contiguously in separate arrays transform_i = get_transform_of_entity(entity_i) for entity_j in alive_entities { collider_j = get_collider_of_entity(entity_j) transform_j = get_transform_of_entity(entity_j) if check_collision(collider_i, collider_j) { update(transform_i) update(transform_j) } } } my problem is that I don't have a generic `get_collider_of_entity` function, but rather a function `get_circle_collider_of_entity` and a separate one `get_line_collider_of_entity`, and so on. (This happens because under the hood I am keeping a mapping (entity_id -> [transform_id, sprite_id, circle_collider_id, line_collider_id, ...]) that tells me whether an entity is using certain kinds of components and which are the indices of those components in the arrays containing the actual components instances. As you can see, each component class is corresponding to a unique index, namely the index position of the array of the mapping described above. For example, transforms are 0, sprites are 1, circle colliders are 2, line colliders are 3, and so on.)
      I am in need to write a system as the one in the snippet above. I can write several overloaded `check_collision` functions that implement the logic for collision detection between different kinds of geometric primitives, but my problem is that I am not sure how to obtain a generic `get_collider_of_entity` function. I would need something that would get me the collider of an entity, regardless of whether the entity has a circle collider, a line collider, a square collider, etc.
      One solution could be to write a function that checks whether in my internal entity_id -> [components_ids] mapping a certain entity has a collider at any of the indices that correspond to colliders. For example, say that the indices related to the collider classes are indices 10 to 20, then my function would do
      get_collider_of_entity (entity_id) { for comp_type_id in 10..20{ if mapping[entity_id][comp_type_id] not null { return components_arrays[comp_type_id][entity_id] } } return null } This could turn out to be pretty slow, since I have to do a small search for every collider of every entity. Also, it may not be straightforward to handle returned types here. (I'm working with C++, and the first solution - that is not involving inheritance in any way - would be returning a std::variant<CircleCollider, LineCollider, ... all kinds of components>, since I would need to return something that could be of different types).
      Another solution could be having some inheritance among components, e.g. all specific component classes inherit from a base Collider, and overrride some virtual `collide_with(const Collider& other)` method. Then I would redesign my mapping to probably reserve just one index for colliders, and then I would actual colliders in a polymorphic array of pointers to colliders, instead of having a separate array for CircleColliders, another for LineColliders, and so on. But this would destroy any attempt to be cache-friendly in my design, wouldn't it? That's why I am looking for alternatives.
      A third alternative would be to just have a single, only, Collider class. That would internally store the "actual type" ( aka what kind of collider it is ) with dynamic information (like an enum ColliderType). Then I would have all colliders have all members needed by any kind of colliders, and specific collision detection functions which I can dispatch dynamically that only use some of that data. (Practical example: a "Collider" would have a radius, and the coordinate for 2 points, and in case its type was "circle" it would only make use of the radius and of one of the 2 points - used as the center -, while if it was a "segment" it would only make use of the 2 points). My gut feeling is that this would bloat all colliders, and, even if the bloat could be reduced - using unions in some smart way for storing members? I wouldn't know how -, then still the design would be pretty brittle.
      I'm clueless and open for ideas and advice! How do you handle in general situations in which you have components that can be naturally modeled as subclasses of a more generic component class? Inheritance? Smart hacks with variants, templates, macros, custom indexing? Dynamic "internal" type?

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!