Jump to content
  • Advertisement
  • Remove ads and support GameDev.net for only $3. Learn more: The New GDNet+: No Ads!

  • 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
  • Advertisement
  • Latest Featured Articles

  • Featured Blogs

  • Popular Now

  • Similar Content

    • By william.equal
      Hey, I just finished a new episode of "Game Audio Lookout"! This time it's about musical sound effects in the Super Mario series. Here's the link to the video on YouTube:
      Musical Sound Effects in the Super Mario Series | Game Audio Lookout
      We’ll have a deeper look at musical sound effects in the Super Mario series in this episode of "Game Audio Lookout".
      I guess everybody has heard the sounds of the Super Mario series before. But I believe most of us don’t exactly know how these were constructed and what efforts were taken in later instalments of the series to produce sound effects that even harmonise with the game’s music.
      Feel free to let me know what you think
    • By OConquestGame
      Hello there!
      I’m the creator and producer of an upcoming visual novel / video game. 
      My team and I are looking for artists (character and background), writers (experienced in writing relatable characters and witty dialogue), and programmers (familiar with unity and creating mini games). 
      Our team is a group of close friends looking to break the mold of the traditional visual novel and create something new and positive. This game will be highly promoted and be a great portfolio piece. Rates are negotiable!
      If you are interested please contact/message us today! OConQuestGame@gmail.com
    • By Gas Lantern Games

      I have spent the last year and a half developing a game in my spare time in Unity! I am releasing it soon on Steam. Ant Empire is a strategic remake of some older games. It is influenced by games such as Ant Empire and Civilization.

      I am currently doing a kickstarter to help fund an AI before launch.

      I have attached some images (tried some gifs but they were too large) to show the current stage of Ant Empire, which is nearly completed.

    • By MarkNefedov
      So, initially I was planning to create a base class, and some inherited classes like weapon/armour/etc, and each class will have an enum that specifies its type, and everything was going ok until I hit "usable items".
      I ended up with creating UsableItem class, and tons of inherited classes, like Drink/Apple/SuperApple/MagickPotato/Potion/Landmine/(whatever that player can use) each with unique behaviour. I planned to store items in the SQLite database, but I discovered that there are not many ways of creating variables(pointers) with type determined at runtime (that preferably get their stats/model/icon/etc from DB). So, I think that I need to use some variation of the Factory pattern, but I have no idea how I should implement it for this particular case (giant switch/case 😂 ).
      It would be really nice if you guys can give me some advice on how I should manage this kind of problem or maybe how I should redesign the inventory.
      Inventory storage is an array of pointers. I'm working with CryEngine V, so RTTI can't be used.
      Example code:
      namespace Inventory { enum ItemType { Static, Building, Usable, Weapon, Armour }; class InventoryItem { public: virtual ~InventoryItem() = default; virtual ItemType GetType() = 0; virtual string GetName() = 0; virtual string GetIcon() = 0; virtual void Destroy() { //TODO: Notify inventory storage delete this; } }; class UsableItem : public InventoryItem { public: struct Usage { int Index; string Use_Name; }; virtual CryMT::vector<Usage> GetUsages() = 0; virtual void UseItem(int usage) = 0; }; class TestItem : public UsableItem { int Counter =0; ItemType GetType() override { return ItemType::Usable; } string GetName() override { return "TestItem"; } string GetIcon() override { return "NULL"; } CryMT::vector<Usage> GetUsages() override { CryMT::vector<Usage> Usages; Usages.push_back(Usage{1, "Dec"}); Usages.push_back(Usage{2,"Inc"}); Usages.push_back(Usage{3,"Show"}); return Usages; } void UseItem(int usage) override { CryMT::vector<Usage> uses = GetUsages(); switch (usage) { case 0: for (int i =0; i<uses.size(); i++) { CryLog(uses[i].Use_Name); } break; case 1: Counter--; CryLog("Dec"); CryLog("%d", Counter); break; case 2: Counter++; CryLog("Inc"); CryLog("%d", Counter); break; case 3: CryLog("%d", Counter); break; default: CryLog("WRONG INDEX"); break; } } }; }  
    • By Effekseer
      Effekseer Project develops "Effekseer," which is visual software for creating open source games; on September 13,
      I released "Effekseer 1.4," which is the latest major version release. 
      Effekseer is a tool to create various visual effects used in games and others.
      With Effekseer, you can easily create various visual effects such as explosion, light emission, and particle simply by specifying different parameters.
      Effekseer's effect creation tool works on Windows and macOS.
      The created visual effects can be viewed on Windows, macOS, Linux, iOS, Android and other environments with DirectX, OpenGL and so on.
      In addition, there are plugins / libraries for game engines such as Unity and UnrealEngine4 to view visual effects.
      Effekseer 1.4 is an updated version of Effekseer 1.3 released in November 2017.
      This update contains the following changes:
      The renewal of UI. Support the tool for macOS. Addition of a function to read FBX with animation. Addition of parameters to protect collied effects and objects. Addition of parameters for easier control of the effects. In addtion I improve plugins/libraries for Unity, UnrealEngine4 and Cocos2d-x.
      Besides that, more than 40 new sample effects have been added and many bugs have been fixed.
      Effekseer 1.4 is available on the project website.
      The license for the software is the MIT license.

      Sample Effects.
      Tool Demo

      View full story
  • Advertisement

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!