1
OSMA-SGE
TOWARDS A FRAMEWORK FOR OPENSOURCE MULTIPLAYER SERIOUS GAMES
Research project sponsored by IWT-TETRA
Research Partners
2
INTRODUCTION................................................................................... 4
GAME DESIGN ..................................................................................... 6
The nature of serious games ...................................................................................... 6
Multiplayer serious games ......................................................................................... 6
References ............................................................................................................ 8
Learning in serious games ......................................................................................... 8
The OSMA VDAB demonstrator game design .................................................................. 17
The Faro demonstrator design ................................................................................... 20
GAME ART ........................................................................................21
Graphical Style Guide .............................................................................................. 21
Graphical Assets Documentation ................................................................................ 21
Game Audio design ................................................................................................. 31
GAME PROGRAMMING ..........................................................................33
OSMA Architecture ................................................................................................. 33
Game programming in Unity...................................................................................... 34
OSMA Gameconfig backend ....................................................................................... 46
USABILITY TESTING ............................................................................48
Testing with the user group ...................................................................................... 48
APPENDIX 1: OSMA MANAGERS, COMPONENTS AND ACTION COMPONENTS .......52
Managers .............................................................................................................. 52
Osma componenten ................................................................................................ 58
Osma actie componenten ......................................................................................... 68
Backend communicatie ............................................................................................ 73
3
APPENDIX 2: OSMA REST INTERFACE .......................................................77
References ........................................................................................................... 78
General remarks .................................................................................................... 78
Authentication....................................................................................................... 78
Create a node ........................................................................................................ 79
Get a node ............................................................................................................ 80
Log out - clear session ............................................................................................. 80
Node indexes ........................................................................................................ 80
Updates ............................................................................................................... 81
Upload an image or file ............................................................................................ 81
Registration : creating a user account ......................................................................... 83
Services usage scenarios .......................................................................................... 84
APPENDIX 3: CONFIGURATION RED5 .......................................................86
Algemeen ............................................................................................................. 86
Installatie ............................................................................................................. 86
Red5Plugin maken .................................................................................................. 89
AMFPHP ............................................................................................................... 91
4
INTRODUCTION
Serious games are games that are primarily designed for purposes other than pure entertainment.
Using game design techniques people practice or learn new skills or become aware of unknown
problems and solutions.
The main goal of the OSMA project is to reduce the cost barrier for the development of these
serious games. To achieve this we look for generic, extensible and reusable components within
the three pillars of game development: game technology, game art and game design.
Figuur 1 Deliverables of the OSMA project within the three pillars of game development.
The OSMA serious game engine is the core of the project. This engine is built up from existing open
source technology components. The guidelines to use this engine are outlined in the Game
Programming chapter .
This engine is extended with game environments, objects and characters that can be used in
different game contexts and for different audiences. Therefore a universal style manual is
developed that is the basis of the various game assets. More information on the adopted graphical
style and the reuse of the assets in other projects is described in the chapter on GAME ART.
Within this engine a conceptual framework for a multiplayer serious game is implemented. This
gaming framework finds its roots in game concepts proven to give good game play in mainstream
games, and is customized to the learning objectives of serious games. The conceptual framework is
outlined in the GAME DESIGN chapter.
The OSMA platform is tested and finetuned in two showcases, the VDAB demonstrator and the Faro
demonstrator . Based on these showcases guidelines and best-practices are formulated to allow
users to use and expand the OSMA platform.
The project is constantly growing and the latest results can be consulted at the osma project
website.
5
Besides a technology platform, OSMA also comes with a community platform
http://www.gameconnection.be where people can exchange information and knowledge about
serious games for games-based learning.
During the course of the project, the projectteam is guided by a number of stakeholders
representing practitioners in the field of gaming and learning, ranging from small game companies,
e-learning companies to larger educational, cultural and employment organizations .
LOUISPLATINI.COM/ADERA
6
GAME DESIGN
THE NATURE OF SERIOUS GAMES
To many people, a “serious game” is an oxymoron. Indeed, it is not easy to see how a game can be
both entertaining or fun and serious or educational at the same time. It has been suggested by some
that merely labeling a game as “serious” can break the fun and entertaining cachet of a game and
take away the motivation of the player. Creating a game as a harmonious mix of education and
entertainment is not easy to achieve. Examples of games that are too serious to enjoy, or not
serious enough to learn from, abound. Still, Ritterfeld et al (2009) finds that serious games are
living up to the challenge of combining learning and playing through digital games by:
Generating intrinsic motivation for the player to engage in the game.
Providing a responsive game environment that gives the player immediate feedback.
Delivering complex content that allows for ample learning opportunities.
MULTIPLAYER SERIOUS GAMES
The OSMA-SGE project aims to lower the production cost of online multiplayer serious games. Such
games hold much potential, because of their close resemblance to some of the current dominant
game paradigms. Indeed, many popular game forms are online multiplayer, like massive multiplayer
online role-playing games (MMORPG), first person shooters or real-time strategy (RTS) games.
A first reason for selecting the online multiplayer game as a basic format for the creation of
serious games is to offer the player a familiar gaming environment in which to learn. Secondly, a
multiplayer game offers many interesting learning opportunities, like peer review and human-to-
human interactions approaching real-life interactions. Thirdly, multiplayer games have a superior
ability in producing emergent game dynamics as a result of simple game rules and mechanics. As
people play against each other, the simplest rule set can engender complex emergent game play
between players. It has been proposed by Salen & Zimmerman (2004) that emergent aspects in
games lead to a sense of wonder and surprise and make games more enjoyable. A fourth reason for
looking at multiplayer serious games is that games like World of Warcraft or Call of Duty - Modern
Warfare have proven that online multiplayer games can provide a sustainably enjoyable game play
that players keep coming back for. Finally, as today most serious games are single player, we
believe it is worth the while from an academic point of view to investigate multiplayer serious
games and how they can be different from their single player cousins.
While the multiplayer format is interesting, we do not aim to develop massive online multiplayer
games, in which thousands of players can play together in one game environment. The reason for
this choice is that the development and maintenance cost of such games is prohibitive to their
implementation by most organizations. Still, a non-massive multiplayer format can be relatively
easily deployed using modern game editors like the Unity engine, used in this project.
Some conceptual frameworks have been developed for serious games. However, they are either too
general, like Yusoff et al (2009) or not suited for online multiplayer serious games as is the case for
Nadolski et al (2008). In order to create online multiplayer serious games, we need a framework
that would match this gaming paradigm and offer enough room for customization in order to harbor
a learning payload. We are aiming to construct this by using a general design framework that has
proven its use by creating good game play in mainstream games, and to customize this framework
to the learning objectives of serious games.
7
Figuur 2 The SURM serious game design framework
The framework we are developing, which we have called SURM (Stats, Unlockables, Rank and Mini-
games), is based on the type of high-level game design that is used in MMORPG's and some first-
person shooters. Each player has a certain score in a statistic category that can be improved by
playing mini-games. These categories can be personal attributes like “stamina” and “stealth” in a
MMORPG or "creativity" and "leadership" in a serious game focused on the labor market.
A rank can be obtained by achieving a certain amount of points on a given statistic category or a
combination of categories. For example, the rank "inspirational leader" could be reached when a
player has reached 70/100 in the leadership category and 60/100 in the creativity category. A rank
acts as a status symbol that players will aim to attain by increasing their stats and represent goals
that users seek to meet in the game.
Unlockables are items or abilities that can be obtained when a certain amount of points has been
reached or when another type of game objective has been met. These unlockables give the player
extra abilities and impact the game dynamics of particular mini-games. For example, a “veto”
unlockable could be obtained when scoring high on leadership, allowing a player to overrule the
decisions of other players in a mini-game mimicking the decision-making process in a company.
The elements of the SURM framework have proven their value by providing enjoyable and durable
game play in numerous games. However, the games in which it is normally applied are not
“serious”. In order to infuse the framework with a learning dimension, the different elements have
to be made more concrete to fit the learning objectives at hand.
8
REFERENCES
U. Ritterfeld, M. Cody, and P. Vorderer, “Serious games: explication of an oxymoron -
Introduction,” Serious games - Mechanisms and effects, London and New York: 2009, pp. 4-9.
K. Salen and E. Zimmerman, Rules of play, Cambridge, Massachusetts: The MIT Press, 2004.
A. Yusoff, L. Crowder, and G. Wills, “A conceptual framework for serious games,” Riga, Latvia:
2009.
R.J. Nadolski, H.G.K. Hummel, H.J. van den Brink, R.E. Hoefakker, A. Slootmaker, H.J. Kurvers, and
J. Storm, “EMERGO: A methodology and toolkit for developing serious games in higher education,”
Simulation Gaming, vol. 39, 2008, pp. 338-352.
LEARNING IN SERIOUS GAMES
CHARACTERISTICS OF GOOD GAMES FOR LEARNING
Good games teach players more than just facts because they provide ways of seeing and
understanding problems and supply opportunities to become different kinds of people [1].
Along the pleasure of playing, good games have some unique benefits [1] :
games provide a safe area for practice
games make learning concrete
games encourage socializing
games level the playing field
games make training more appealing.
Based on these assumptions, characteristics, that are supported by various learning theories and will
reinforce learning, were formulated [1].
Repeat and reinforce key information
Give immediate feedback
Provide safe practice of new skills
Develop understanding of new skills
Provide meaningful challenge
Stimulate as many senses as possible
Furnish social contact and group work
Provide realistic and complex experience
Include analysis, interpretation and reflection.
REFERENCES
[1] Squire, K., Video game-based learning: An emerging paradigm for instruction, retrieved
from http://website.education.wisc.edu/kdsquire/tenure-files/09-PIQ-Squire-su...
9
[2] El-Shamy, S., Training Games: Everything You Need to Know About Using Games to Reinforce
Learning, Virginia: Stylus Publishing: 2001
EVALUATION & FEEDBACK
EVALUATION
WHAT IS EVALUATION?
Through evaluation can be ascertained to what extent the participants have reached the predefined
goals.
FUNCTIONS OF EVALUATIONS
Summative evaluation focuses on the assessment of the student. This assessment is result-oriented
and focuses on what the student has reached at that time.
Formative evaluation aims to guide the student. Giving feedback plays an important role hereby.
This feedback can be used to steer the learning process.
FORMS OF EVALUATION
Peer evaluation: students evaluate each other according to specific criteria.
Self-evaluation: the student will review his own work on the basis of certain criteria.
After observing the results over twenty years of peer assessment, [1] concluded that peer
assessment in learning is generally a useful, reliable and valid exercise. Self-assessment is also
important because people can only learn if they understand the learning goal and can assess what
they need to do to meet it [2]. Both forms are complementary.
FEEDBACK
Feedback can be a strong component in learning through games. In games, players can immediately
be confronted with the results of the activities they have performed. To promote reflection, the
feedback should not only be goal/outcome-oriented, but also process-oriented. Not only the
content of the feedback is important, but also the timing. Feedback should come after a logical
'break' in the game and not necessary immediately after an action, because the feedback than
'breaks' the process too much.
REFERENCES
[1] N. Falchikov, “Peer feedback marking - developing peer assessment” in Innovations in Education
& Training International, 1995, pp 175-187.
[2] E. Redish and M. Vicentini, “Research on physics education” in International School of Physics
series Volume 156, 2004.
[3] Verheul, I. & van Dijk, W. (2009 mei). Effectiviteit van een COTS game in het MBO: Oblivion.
CLU, Universiteit Utrecht. http://onderzoek.kennisnet.nl/onderzoeken/rendement/cots
10
OVERALL LEARNING PROCESS
Learning is a process of constant growth.The context in which the OSMA games take place is a
simplified representation of the real domain.
Learning is a dynamic process. For each problem several solutions are possible (e.g. a score
on a statistic can be increased by playing mini-games or by taking quizzes).
Error is tolerated and the consequences for failure are minimized (e.g. no negative scores or
lost of points).
Constructive feedback is promoted.
Meaning is created by playing mini-games.
Interaction between players is the key feature of the mini-games.
Feedback is provided through multiple evaluation channels (e.g. automatic generated
feedback, peer feedback, coach feedback or self-evaluation).
Statistics are „measured‟ throughout the process.
A player can improve his score on certain statistics by undertaking actions in the virtual
environment (e.g. playing mini-games, communicating with other players and taking
quizzes).
ROOTS OF THE PROJECT
CONSTRUCTIVISM
This project is rooted in constructivism, a learning theory that defines learning as a change in
meaning constructed from prior experience [1]. The theory assumes that knowledge is individually
constructed and socially co-constructed by learners based on their interpretations of experiences in
the world [2].
The constructivist assumptions of learning can be described as follows [3]:
All knowledge is constructed (albeit socially) and not transmitted.
Knowledge and meanings result from activity and are embedded in activity systems.
Knowledge is distributed in persons, tools, and other cultural artifacts.
Meaning arises out of interpretation and, thus, multiple perspectives are recognized.
Meaning construction is prompted by problems, questions, issues, and authentic tasks.
THE ZONE OF PROXIMAL DEVELOPMENT
The Zone of Proximal Development is “the distance between the actual developmental level as
determined by independent problem solving and the level of potential development as determined
through problem solving under adult guidance or in collaboration with more capable peers"[4].
This zone refers to the distance between what a learner can do without help and what he can do
with help.
EXPERIENTIAL LEARNING
Experiential Learning Theory (ELT) provides a holistic model of the learning process and a
multilinear model of adult development with an emphasis on the central role that experience plays
in the learning process [5]. ELT can be defined as "the process whereby knowledge is created
11
through the transformation of experience. Knowledge results from the combination of grasping and
transforming experience" [5]. This circle was adapted in order to obtain a conceptual basis of the
process of experiential learning [6].
Figuur 3 Experiential Learning cycle
Broadly, the cycle consists out of (1) do, (2) review and (3) develop and (4) implement ideas for
improvement.
REFERENCES
[1] Newby, T., Stepich, D., Lehman, J., & Russell, J., Instructional technology for teaching and
learning: Designing instruction, integrating computers, and using media, NJ: Prentice Hall: 1996
[2] Reigeluth, C.M., Instructional-Design Theories and Models, Volume II: A New Paradigm of
Instructional Theory. Mahwah, NJ: Lawrence Erlbaum Assoc: 1999
[3] Uden, L. & Beaumont, C., Technology and problem-based learning, London: Information Science
Publishing: 2006
[4] L. Vygotsky, Mind and society: The development of higher psychological processes, Cambridge,
University Press, 1978.
[5] D. Kolb, “Experiential Learning: experience as the source of learning and development”, New
Jersey, Prentice-Hall, 1984.
[6] Thomson, M. experience-based learning - guide to facilitating effective experiential learning
activities, 2008
12
STEALTH ASSESSMENT
As was already said in the general introduction on serious games, the major design challenge for
serious games is to balance enjoyment and learning. One way of achieving this is by making sure
that the assessments that take place in the game and the feedback that is provided to the player
does not break the flow of the game.
Shute et al (2009) proposes the concept of stealth assessment to allow this. "When embedded
assessments are so seamlessly woven into the fabric of the learning environment that they are
virtually invisible, we call this stealth assessment" (Shute et al 2009, p299). In order to guide the
design of stealth assessment in serious games, the authors propose to use the method of Evidence-
centered design (ECD) from the educational research field.
The idea is to construct a model of competences, evidence and tasks. The competences are what
the players are expected to learn. The evidence is the information that can be gathered to assess
the performance of a player on a certain competence. The tasks or actions are the concrete
elements that can be measured in the game to assess the competences of the player.
In the paper, an example is described on what it could mean to apply stealth assessment through
ECD in the game Elder Scrolls IV : Oblivions. in order to measure the competency of creative
problem solving, this concept is de-composed in a number of sub-concepts (problem-solving,
creativity, efficiency and novelty). Essentially, this decomposition says that creative problem
solving can be assessed by measuring efficiency and novelty. The model then proceeds to define a
number of actions that the player can take in the game, indicating their efficiency and novelty in
solving problems.
13
Figuur 4 ECD model for the Elder Scrolls IV : Oblivions game (Shute et al 2009, p308)
Once the ECD model has been established, the assessment can be quantified using Bayesian
networks. While we will not digress on this subject, it allows the assessment model to measure the
performance of the player in terms of efficiency and novelty of problem solving and to calculate an
overall score for creative problem solving. Based on this score, a number of things can happen :
The player is given explicit feedback on his performance, in words
The game structure is altered to further instruct the player on creative problem solving
REFERENCES
Shute, V.J. et al., 2009. Melding the Power of Serious Games and Embedded Assessment to Monitor
and Foster Learning: Flow and Grow. Serious Games Mechanisms and Effects, (1), pp.1–33.
14
ENJOYMENT
As was discussed in the section on The nature of serious games, one of the main challenges of
serious games is to obtain a balance between learning and enjoyment. In this section, we will focus
on what literature has to say on enjoyment in serious games.
BIG FIVE AND ENJOYABILITY THRESHOLDS
In a study of game reviews, Wang et al (2009) analysed entertainment game reviews by expert
gamers. These were not serious games, but mainstream games focused on entertainment.
Nevertheless, Wang et al (2009) proposed that serious games have something to learn from
entertainment games. From their study, they proposed what they call the Big Five of enjoyment in
games : technological capacity, game design, aesthetic presentation, game play experience and
narrativity.
In addition, Wang et al (2009) propose that there is a three-level threshold perspective on game
enjoyability. The first threshold is the playability threshold, which determines if players are able to
play the game. This means that players should be able to use the game controls and grasp the rules
of the game and is mainly related to the Big Five aspect of technological capability. Once this
threshold has been passed, the enjoyability threshold determines if a player will have fun playing
the game. Good game design and aesthetics are the elements of the Big Five that allow a game to
pass this threshold. Finally, there is a "super fun-boosting threshold", which is characteristic for
great games. This aspect is most influenced by the aspects of game play experience and narrativity.
GAMEFLOW
Another perspective on enjoyment is to see from the perspective of Flow theory, established
by Csikszentmihalyi (1990). Flow theory is the result of the analysis of what makes experiences in
general enjoyable. Sweetser & Wyeth (2005) based themselves on flow theory to investigate the
elements that make games enjoyable. They proposed 8 different elements that can produce
enjoyment in games :
1. concentration
2. challenge
3. skills
4. control
5. clear goals
6. feedback
7. immersion
8. social interaction
15
16
Figuur 5 gameFlow criteria (Sweetser & Wyeth 2005)
These elements have been operationalized as concrete question that allows the evaluation of a
game as being enjoyable or not. In addition, it allows the identification of possible areas of
improvement. This was done by Jegers (2009) to asses the enoyability of pervasive games. In fact,
the approach proposed by Jegers (2009) presents a way to identify the elements of the gameFlow
model that users find important in relation to a certain game and to quantify how well a player
finds an element is being addressed by the game they just played.
REFERENCES
Csikszentmihalyi, M., 1991. Flow: The Psychology of Optimal Experience First Edition., Harper
Perennial. Available at: http://www.amazon.com/exe℅bidos/redirect?tag=citeulike07-
20&path=ASIN/0060920432.
Jegers, K., 2009. Elaborating eight elements of fun: Supporting design of pervasive player
enjoyment. Comput. Entertain., 7(2), pp.1-22.
Sweetser, P. & Wyeth, P., 2005. gameFlow: A model for evaluating player enjoyment in games.
In ACM Computers in Entertainment. ACM Press.
Wang, H., Shen, C. & Ritterfeld, 2009. Enjoyment of digital games - What makes them “seriously”
fun? In Serious games - Mechanisms and effects. New York and London: Routledge, pp. 25-47.
17
THE OSMA VDAB DEMONSTRATOR GAME DESIGN
Figuur 6 The lobby in the VDAB game
On this page, we describe how the elements that have been outlined in the above pages have been
implemented in the OSMA VDAB demonstrator. By comparing the demonstrator with serious game
literature, we are also able to provide an introspective critique of our work and identify areas of
improvement for the future.
The design document for the VDAB demonstrator can be find on the project website:
http://osma.phl.be/sites/default/files/Game_design_document_VDAB_demonstrator.pdf.
In this demonstrator, we have focused on the two main elements of serious games : enjoyment
and learning.
ENJOYMENT
In the section on enjoyment in games, we have discussed the GameFlow model, which proposes 8
different elements that produce enjoyment in games.
CONCENTRATION
Playing the VDAB requires quite some concentration. Coming up with stories for the truth or lies
game, or finding the right strategy to play the auction game is non-trivial.
CHALLENGE
The VDAB demonstrator mini-games are rather simple in nature. However, as they are not played
against a computer player, but against other humans, the game experience will change with every
new group of players.
18
Adapting the challenge to the skill level of the player is a point on which we could do future work.
The element of skill progression is present in the game, in the form of the stats. The original design
of the game did forsee in the availability of unlockables based on skill progression, but the available
project resources did not allow us to implement this. In a possible future version of the
demonstrator, in which unlockables would be available, adapting the challenge to the skill level of
the player would be possible, as new unlockables would change the game dynamics.
Another original plan that was not implemented is the idea that certain mini-games would only
become available when the player has reached a certain skill level.
PLAYER SKILLS
We feel that the game design is simple enough that it does not require the player to read a manual
before playing the game. However, we do recognize that parts of the game need further work in
order to become more usable and easier to understand. Adding tutorials could be an interesting way
of explaining the game.
CONTROL
In terms of control, the game design foresees in the ability of the player to move around freely in
the game world and choose the games that are played. In addition, the control aspect, which gives
players the sense that the actions they take really matter in the game, is provided by the
interactions between the player. An action taken by a player reacted on by another player, which
provides the players with a natural sense of control, that in non-multiplayer serious games needs to
be created by making game-elements like NPC's respond to player actions. In this, we feel that
multiplayer serious games provide a distinct added value when compared to their single-player
cousins.
CLEAR GOALS
We have tried to provide the player with clear indications of both the overriding goals and the
intermediate goals in each minigame. However, to evaluate how succesful we have been, further
testing seems appropriate.
FEEDBACK
The element of feedback is even more important in serious games than it is in other game types to
which the gameFlow model applies. We have worked extensively on the creation of a generic
feedback model, based on both summative and formative evaluations. This is described in the
section on Evaluation & Feedback.
IMMERSION
3D worlds are reputed to be quite immersive. However, Jeger 2009 notes that immersion is hard to
measure and should be observed. Therefore, it is hard for us to claim that we have created an
immersive game environment and would require further evaluation in order to make assertions
regarding this element of the gameFlow model.
19
SOCIAL INTERACTION
Social interaction is one of the potential strengths of the VDAB demonstrator game design. Indeed,
the mini-games are heavily based on the interaction between players over VOIP. The elements of
competition and cooperation are present. However, more support for community building and social
network features could be benefit future versions of the demonstrator.
REFERENCES
Jegers, K., 2009. Elaborating eight elements of fun: Supporting design of pervasive player
enjoyment. Comput. Entertain., 7(2), pp.1-22.
LEARNING
FEEDBACK BLOCKS
In OSMA, there are 3 types of feedback blocks that can be used: summative 1, summative 2 and
formative 1.
SUMMATIVE 1 SUMMATIVE 2 FORMATIVE 1
Score on statistics Score on statistics Feedback through text- or
voice chat
Score is automatically
generated output from
the minigame
Score is given by a
coach or a fellow
player
Feedback is given by a
coach or a fellow player
Minigames can be connected to the feedback blocks in various ways. An example:
(1)
MINIGAME
Truth / lie
minigame
+
(2)
SUMMATIVE 1
Score on
statcats
(system
generated)
+
(3)
SUMMATIVE 2
Score on
statcats (peer
generated)
+
(4)
FORMATIVE
1
Feedback by
peers through
voice-chat
+
(5)
MINIGAME
Truth / lie
minigame
+
(6)
...
or
20
(1)
MINIGAME
Truth / lie
minigame
+
(2)
SUMMATIVE
2
Score on
statcats (peer
generated)
+
(3)
MINIGAME
Truth / lie
minigame
+
(4)
SUMMATIVE
2
Score on
statcats (peer
generated)
+
(5)
FORMATIVE
1
Feedback by
peers through
voice-chat
+
(6)
MINIGAME
Truth / lie
minigame
THE FARO DEMONSTRATOR DESIGN
In the FARO demonstrator we have focused on the reuse of technical and graphical components. The
design document can be found on the website http://osma.phl.be/node/229.
21
GAME ART
GRAPHICAL STYLE GUIDE
In the first months of the project a universal style guide was developed. This style guide was used
to work out the graphical assets of the two showcases and can be downloaded at
http://osma.phl.be/node/299.
GRAPHICAL ASSETS DOCUMENTATION
All graphical assets are available for download in the sourceforge OSMA project:
http://osma.phl.be/node/326.
INTRODUCTION TO OSMA GRAPHICAL ASSETS
This documentation is specifically for instructing OSMA users, clients and community members to
give summarised information on the following topics:
How to use and adapt the example files that were created during the OSMA production
period, and the fundamental information needed to create similar work.
Provide supporting information on good working practices to that end, and how to meet
certain working standards when creating graphical work for sharing in an online CG
community.
How to get the OSMA assets and further share and upload graphical content.
Information on further learning within the skill areas required for content creation.
22
HOW TO USE THE 'EXAMPLE' GRAPHIC FILES AND COMPONENTS?
2D FILES: INTRODUCTION TO THE LAYOUT AND STRUCTURE
The editable texture files provided from the research production phase of OSMA make use of several
specific working practices that allow for a high amount of repeatable customisation options without
having to make lots of manual adjustments by hand.
For ease of use, the structure and hierarchy setup and
subsequent customisation options take place almost exclusively
within the 'Layers' tab (1). The image opposite is an example of
the overall structure, with the basic hierarchy options
highlighted. It is taken from a Characters editable file as they
are generally more complicated and have more customisation
options. Environmental editable graphics follow the same
principles but have less complexity and variation for their
relevant 3D object.
Going through the Layer tab contents: Blending Mode, (2),
determines how each individual layer looks and how it interacts
with other layers; The UV's layer, (3), is the two dimensional
'unwrapped' version of the 3D object the texture is applied to. It
acts as a guide for how the content is arranged, and is always
the top layer; the Layer Visibility, (4), is exactly what it says. It
hides or displays the content of layers and groups so the user can
choose what set of visual content is displayed in the texture; The
Background, (5), is always the bottom layer, and will always be set to white or black; The layer
order, (6), is set so that the lowest 'layer' of content is always on the bottom and ascends in order.
In a character example, flesh is the lowest, then solid colours and details followed by 'overlays'
containing fabric details, then
finally raised patterns and
unique objects like logos.
Shown on the right is one
combination from the provided
female characters upper body
texture.
23
The wireframe is the UV layer, (although this layer is not normally
displayed on a final version of a texture); The white of the T-shirt is
from its own layer group; the red stripes on the trims, and the 'Hello
Kitty' logo in the middle of the chest on the front are both from the
same layer group, symbols group which is shown in the above image.
An expanded version of the editable layers is shown on the next
page of this range of options, highlighting the greater range of
options available in the individual layers provided.
The image on the left is displaying the layer customisation options
required to make the texture image shown on the previous page:
[1] The blending mode is displaying 'Multiply' which is the chosen
blend for the highlighted, (blue), layer. (Multiply looks at the colour
information in each channel and multiplies the base colour by the
blend colour. The result colour is always a darker colour. Multiplying
any colour with black produces black. Multiplying any colour with
white leaves the colour unchanged. It is a very useful blending mode
for texture combination).
[2] 'Opacity' and 'Fill' both affect the transparency of a layers
contents, and are used to adjust and enhance layer interactions,
especially blend modes.
[3] As mentioned before, the UV's are always at the top of the
hierarchy. To create the texture on the previous page, they were
left visible.
[4] These 3 'linked' boxes are the visible layers in the expanded
'Patterns And Symbols' group; showing that
customisation/combination options can be retained and be easy to
organise by grouping any number visual objects with a common
theme.
[5] These are 'adjustment layers'. Any option from the
Image>Adjustments menu is also available as an adjustment layer.
These are commonly bound to layers to allow for lots of
customisation options without permanently changing the values and parameters of the layers
original content. In the bound image 'Brightness/Contrast' and 'Hue/Saturation' adjustment layers
are added, giving changeable values in all those areas.
[6] The expanded 't-shirt' layer. One of the other adjustment layers that is
often used is 'colour fill'. When working with base fabric textures, white is a
good colour to use for retaining details such as folds. A colour fill + suitable
blend allows any colour of clothing whilst retaining the details.
A note on Overlays:
Another technique not mentioned yet, but that occurs in many of the
example files especially character textures, are grey scale layers with an
'Overlay' Blend. The image on the left shows an example of this. It is often
used for fabric based textures.
24
The base layer will typically be a flat colour, (with the 2 adjustment layers discussed previously,
highlighted in the lower box). The texture details will be in another layer that matches the UV
layout but is desaturated of colour, (the layer group shown with the arrow). Each of these grey
scale layers will be set to an 'Overlay' blend mode (highlighted in the top box). This retains almost
all of the subtle details, such as folds, shadows etc, but allows the base colour + its variable
adjustments to show through clearly.
2D FILES: MODIFYING AND COMBINING THE PROVIDED EXAMPLE CONTENT
Although the summary of the file structures in the previous section barely scratch the surface of
working with Photoshop and the very basics of making textures for 3D, it covers enough to know
how to work within the provided 'example' 2D Files. What follows here is a summarised reference
list of how to make variations on the provided textures and create a range a new texture
combinations without having to do any manual painting or creation of brand new content. Relying
instead on the manipulation of sliders, layer hierarchy, blending modes, opacity and visibility.
The image group below shows most of the range of tabs, sliders, and adjustable functions that have
been discussed and which will be used to make basic modifications. They are all already included in
the layer structure in most of the example files. All of these tables are located by default on the
right hand side of the Photoshop application layout. They are either already visible, or appear when
the appropriate layer is highlighted.
Top left – Hue/Saturation tab, accessed from highlighting the
relevant 'adjustment layer'.
25
Top mid left – Expanded layer tab displaying 'layer effects'. These allow for various basic 3D effects
and are accessed by clicking the boxed 'fx' button in the bottom of the tab. Their visibility can be
turned on or off the same way as layers.
Top mid right – Previously shown standard layer hierarchy of example files. Important components
are ringed.
Top right – The fully expanded menu of 'Blend mode' options. Highlighted as [1] in the adjacent
image.
Bottom Right – Brightness/Contrast tab, likewise accessed from selecting the relevant adjustment
layer on layers that have it as an option.
2D FILES: SETTING UP FILES TO THE “OSMA EXAMPLE” STANDARD
Once users have experimented with adjusting and customising the example 2D files and seen the
results on the provided 3D objects, they may choose to make further modifications involving making
entirely new additions to the content, manual adjustments or making their own assets from scratch.
Ultimately these will hopefully be able to be uploaded to the database and shared with the OSMA
community. However, to maintain a consistency of quality and a structural standard for an easier
understanding and workflow, some fundamental steps will be discussed here for the replication of
the the example file standards. These will reference and build on content discussed in the previous
sections. (N.B. A very useful short cut to know for Photoshop is 'creating a new layer', which is:
Ctrl+Shift+N).
Background Layer – With a new Photoshop file the default layer is always the background layer.
Unless there is a specific reason, leave this white, (or black), and create a new layer to start
working with.
UV's – As has been covered, the UV's of the mesh the texture is used on should always be the
top/highest layer in the hierarchy. The UV map itself should be part of the editable texture file, or
importable as a separate file. Typically the wireframe will be made of contrasting colours, (usually
Black and White). If it hasn't been done already, it is good practice to either, (a) remove the filler
colour, leaving just the wireframe using magic wand selection, (see reference). (b) Invert the
colours so that the wireframe is black and the filler colour is white with Ctrl+I, if it isn't already,
then set the 'Blend Mode' to 'Screen', so that the lower layers show through the white areas.
Overlays – When opting to use overlays, the texture in question should have suitable levels of
contrast in its visual patterns. It should be desaturated to a colourless greyscale image. It should be
suitably mid-tone in shade; if it is too dark or light use the brightness/contrast adjustment option,
(see reference), to reach an even grey tone. Then set the Blending mode to 'Overlay' in the drop
down menu. Be aware that Overlay layers don't show up on a white background, you need some kind
of colour or image on a lower layer.
26
Flat Colour Shapes – Usually used in conjunction with various overlays for a quick way to make lots
of variations on a similar theme. A flat colour should always be a primary or secondary colour of
mid-level saturation. Making it too vibrant or dull, and too light or dark will limit or skew
adjustment options. Once it has been painted into the areas desired then the following 'adjustment
layers' should be added in this order: 'Brightness/Contrast' then 'Hue/Saturation'. In both instances,
the option box to 'use previous layer as clipping mask' should be selected. Otherwise every layer
below the adjustment layer will be affected rather than just the one wanted.
Layer Hierarchy – As discussed previously, this plays a crucial role in the textures visuals and layer
blending. It is not complicated however, and is generally based on common sense. Taking a clothing
texture as an example: a 'skin/flesh' layer goes lowest, just above the background; Then if there is
one, a 'Flat Colour' layer, or the solid basic shapes and colours of the clothing; Next, if included
would be a patterns layer for things like stripes, chequer patterns and colour variations separate
from the base colour that may also require adjustment options; Typically 'overlays' go above this, in
the example they contain the details of the clothing fabrics folds and material texture; Lastly, top
level details like belts, buttons, braces, tie-pins, zips and other items that aren't part of the
clothing fabric and sit on top of it should be placed; Above all of this, (as it is a guide layer), goes
the object UV's.
Layer Groups – In many cases, there will be multiple layers and customisation options that are
similar in purpose and hierarchy, which is where layer groups come in. For example, if there are
multiple 'Overlay' files, and none of them are being used for a specific item and a certain level,
then placing them in an 'overlay' group makes it much easier to adjust hierarchies; this is done with
Ctrl+G. Groups can also be put inside other groups, so if one accessory like a belt has multiple layer
parts, then putting them in a 'belt' group, and then putting that group in an 'accessories' group gives
more control over the editing and adjustment. Layers inside groups don't have any additional
restrictions compared to ungrouped layers. Whole groups can also be made invisible in the same
manner as individual layers. Examples of layer groups are in the provided files; layer group
hierarchies should follow the same principles as individual layer hierarchies.
Naming Conventions – One of the most important but overlooked steps in visual content creation is
a sensible and consistently used convention for naming assets in a file. Not naming things makes it
impossible for anyone but the creator to find their way around the file contents, as does using
totally arbitrary and nonsensical names. With multiple variations of similar assets, it is a good
practice to adopt the scientific method of starting with the most general part of a description, and
making each word a more specific component, i.e. Shorts > Cargo > Brown. Using layer groups can
be a part of this process, and can prevent individual layer names becoming unnecessarily long.
This list by no means represents comprehensive coverage. With any artistic material being created,
a lot of things may occur that are quite specific, uncommon, and require additional methodologies.
Plus it doesn't cover 'how' to actually make things from scratch, as there are thousands of articles,
books, magazines, videos and more covering every facet of learning content creation and tool
definition, many of which are high quality and freely available. However, the above list represents a
27
list of fairly 'universal' standards to apply to creating 2D customisable textures in Photoshop for use
with the OSMA database that will make it much easier for other users to interpret and make use of
uploaded work.
2D FILES: CREATING NEW CONTENT FOR THE PROVIDED UV'S
Once users have gotten to grips with the provided customisation tools in the example files, and the
basic modification tools in Photoshop that were discussed in the previous sections, some may wish
to try and create new content for a provided 3d mesh.
This process allows for a limitless range of 2D options, and coupled with following the file setup
steps outlined in this chapter, can provide a range of new textures for an object from a small
selection of base components. However with this much greater range of options comes an
exponentially more complex and involved process, as the full potential of the Photoshop application
becomes relevant, and it is a powerful tool written for professional graphic artists. Like all
applications though, the more basic elements aren't prohibitively complicated.
This document is not going to give full instructions for all the fundamental tools in Photoshop for
2D graphics creation; partly as it would make the document far, far too long, but moreover there
are numerous free, good quality tutorials and instructional material available online that has been
written by professional users covering every single aspect of the programme and how to make
anything from a basic logo to a full piece of landscape art. This final section in the first chapter will
point users in the right direction, with summarised listings of relevant links and tutorials for using
Photoshop, for users who want to go further with content creation for OSMA.
FURTHER LEARNING WITH PHOTOSHOP
These resource links will focus on using Photoshop itself, and further information on the
customisation and content creation topics discussed in this chapter:
http://simplephotoshop.com/photoshop_tools/ : An extremely useful site for anyone wanting to get to
grips with any and all of the contents of the Photoshop main 'tool' palette, located by default on the
left of the screen when opening the application. Each tool is demonstrated with a normal speed
video and accompanying audio. Users will need Flash Player version 6 or later to view the video
content.
http://phong.com/tutorials/adjust/ : A simple introduction to creating 'adjustment layers', with an
animated tutorial gif. The 2nd method with the clipping mask is the one used in the creation of all
adjustment layers in the provided example files.
http://www.tutorial9.net/tutorials/photoshop-tutorials/layer-styles-in-photoshop/ : An easy to complete
introductory tutorial on layer styles. The example files primarily make use of manually created
layer effects, (the mid left image tab, in section 1.2 for reference). This tutorial covers that part
way down, but also introduces pre-built layer styles, which will help users with faster content
creation and modification.
28
http://www.freetimefoto.com/photoshop_blending_mode#overlay : A comprehensive visual and verbal
breakdown of all the layer blending modes in Photoshop. There are quick links to each description,
and every example image is interactive, so users can see how each blend mode varies from normal.
http://www.thegraphicmac.com/layer-opacity-vs-layer-fill-photoshop : A quick visual demonstration
and description of Layer Opacity vs. Layer Fill, as discussed previously in the chapter.
REFERENCE FOR CONTENT CREATION
This section will focus on some information on the theory of certain processes, (like how UV
wireframes correspond to a 3D object for example), and also contains some reference tutorials to
basic 3D work, and considerations for creating basic textures:
http://en.wikipedia.org/wiki/File:Cube_Representative_UV_Unwrapping.png : Basic visual
representation of how UV's 'unwrap' from a 3D object.
http://blenderworld3d.blogspot.com/2010/11/basic-uv-mapping-tutorial.html : Very basic tutorial for
applying a UV map to a basic 3D object in 'Blender'. (The provided 3D work was completed in 3ds
max and Maya, however these programs cost thousands of Euros to buy. Blender can create
professional standard work, and it is a free open-source program).
http://teaching3d.com/resources/articles/uv_mapping_theory.pdf : Comprehensive PDF format web
page on UV mapping theory, covering all the basic aspects of how it works. This may be somewhat
complicated for a complete beginner.
http://www.blender.org/education-help/tutorials/getting-started/ : The 'Getting Started' section of the
blender website. Because it is a free, open-source piece of software, there are numerous good
quality introductory tutorials on their official website that are free to access, that include
introductions to the program itself, and work for someone just starting out.
http://www.blender.org/education-help/tutorials/modeling/ : This is the 'beginners' tutorial section for
modelling in Blender. It follows on smoothly from the previous 'introduction' link. There are several
other free-to-access tutorials in the other tabs on the site that cover the primary areas of the
program.
NB: Autodesk 3ds max, and Maya, are the two most popular and commonly used 3D programs.
There is a vast amount of free, high quality support and reference for them as well. If users have
the opportunity to use these it is recommended, as they are more powerful tools, with much more
documentation and options. However, it cannot be assumed everyone has access to these kinds of
licenses or funds.
http://www.gamasutra.com/view/feature/2071/uv_mapping_tips_and_tricks.php?print=1 : This is a
comprehensive article on the fundamentals of texture projection, and texture mapping. The first
parts of it cover the basics of 'projection' and 'unwrapping', and issues to be aware of concerning
texture creation such as stretching, shearing, and seams. The latter part of the article concerns
more complex principles, such as shaders and mip-mapping. These are more complex professional
fundamental games development, and will most likely be too complicated for a beginner. However,
they are useful for future reference.
29
GOOD GRAPHICAL WORKING PRACTICES
This chapter is a summarised focus of good working practices to maintain when customising
provided content, or creating your own. It focuses primarily on the artistic content creation aspect.
There is a more comprehensive 'artist efficiency guide' on the OSMA website which includes
production and project efficiency, which may be of interest to some users wishing to apply the
framework to a greater degree.
GENERAL CONTENT CONSIDERATIONS
Editing Priority. How users spend time on assets, either multiple assets or individual parts
of a single one, is a crucial consideration for all disciplines. The biggest considerations when
deciding this are visibility and importance. If a game makes use of a player character model
in a genre where it is always seen, then it should have a lot more time spent on making it
look great than background prop assets, like crates and bin bags. Continuing the example,
the parts of the character that get seen the most should have more time spent on them
than minor secondary details. This goes for the allocation of memory budget as well. A
garbage bag asset does not need a shader with a massive texture size, multiple mapping
channels, and a large number of polygons. The fact it will probably be re-used a lot should
be a reason to make it look good as it can with as small a memory budget as possible, rather
than be a reason to give a lot of processor intensive additions.
Viewpoints and Camera angles. This is another major cross-discipline consideration for
graphic creators. Returning to the player character example, in a 3rd person action-
adventure, more attention should be paid to the polygon usage around the shoulders, head
and back, than around the front of the feet as that is the part of the character that the
player will see the most. The whole asset should still be extremely polished, but on complex
assets additional priority for parts of the asset will create better art in a more efficient
manner. The same principle applies just as strongly to game environments concerning both
artistic production and level layout/design.
UV TEXTURING WORKING PRACTICES
Obeying the 'Power of 2' rule. This refers to the binary rule of “2 to the power of 'n',“ i.e. 2²
= 4, 2³ = 8 etc. When creating textures, each one without exception should have its
dimensions set to obey 'the power of 2', (so sizes of 256 x 256, 512 x 512 and so on). Non
square dimensions are also acceptable so long as they conform to the nearest power of 2,
such as 512 x 1024. Exporting to an game engine will often cause errors if the textures
aren't set to these parameters. Some pipelines will export non-adjusted textures, but if
they're over a set size on just 1 side, e.g. 1033 x 1024, game engines may often fit that to
the next accommodating size, which using the example, is 2048 x 2048, meaning the texture
takes up 4 times as much memory.
Work at a larger size and scale down. If the memory budget for the texture is 256 x 256,
work at 512 x 512 then scale down. This is effective for two reasons; firstly it easier to work
quite quickly at the larger size as small discrepancies in detail or neatness won't matter so
much as the detail will still look good sized down, and minor mistakes disappear. Although
this works more suitably with painted textures, than with textures derived from photos.
Secondly, if there is more room in the memory budget later, a larger resolution of texture is
30
ready to put in as a replacement, with room for more details and at most only a bit of
cleaning up to do, saving a lot of time.
One is better than many. It seems obvious, but too often an artist will create 10 'very basic'
textures for even simple objects, under the assumption that every texture can get re-used.
This puts a massive workload on the game engine as having multiple textures on one model
is exponentially more memory intensive. For specific environmental objects and characters,
an efficiently created and sized single texture is always better that using multiple 'micro'
textures for a single object.
3D MODELLING WORKING PRACTICES
A polygon count doesn't have to be reached: If an object has an assigned limit of 500
polygons, but an artist can make it look great with 450, then the remaining polygons don't
'have' to be used. This doesn't mean polygon counts should be reduced excessively as it will
effect the overall quality of the asset, but rather that lots of extra time shouldn't be wasted
adding extra details just to get the polygon count to a given limit. Not only is it extra
modelling time, but it translates to extra time setting up and creating textures as well.
Furthermore, if there is a memory optimisation pass then all those additions will have to be
removed anyway, and the UV texturing work will be lost. With the lower polygon count
there is a safety net in case assets have to be adjusted down to account for performance
restrictions.
'Triangle Count' not 'Polygon Count': When artists talk in terms of polygon count concerning
budgets and memory, it can be confusing, as in game engine terms, the polygon count is the
number of triangles on a model. However, in a 3D application, the polygon count and
triangle count are two different things. When working to a polygon budget within a 3D
development tool the 'triangle' count is what an artist should be referring to for their
'polygon' limit.
Not everything in a scene needs to be a model: When working with busy scenes and limited
memory budgets, artists employ a lot of faking. Billboards/cut-outs, and 'alpha maps' on
single quad planes can provide a lot of good, cheap background detail when implemented
correctly. Not everything requires a solid 3D shape, and often it will eat into more of the
memory budget, and look worse when placed in a location where an alpha mapped object
would be suitable.
Don't over optimise: It may seem contradictory, based on some of the previous statements,
but many artists when modelling at least, believe 'less triangles = better', in terms of
obtaining more memory performance. Whilst this is true to a point, with the standards of
modern graphics cards, removing ever smaller numbers of polygons become quite negligible
to performance. Yet at low numbers, the difference that will make to the visual quality of
the model becomes exponentially more detrimental.
FURTHER GRAPHICS RESOURCES
OPEN SOURCE CG MARKET PLACES
http://www.turbosquid.com/ : One of the biggest online marketplaces for all things 3D or CG
related. Searches can specify category, i.e. animals, furnishings etc; a particular application
only, like 3ds max or Maya; or a type of content, like models, textures, application plug-ins
or tutorials. The majority of the content is paid, but there is still a massive amount of free
31
material, and there is the standard viewable 'rating and feedback comments' on every
piece.
More recently, they added a 'Checkpoint' system. There are 'Pro' and 'Lite' versions; every
piece of content submitted to the 'checkpoint' system has to match a substantial checklist
of professional standards.
The forums are very busy, with many threads dedicated to how best to market content, and
as with all good forums, informative 'stickies' from the moderators and tops sellers for the
most popular articles.
http://www.creativecrash.com/ : Similar to Turbosquid. They don't make use of a checkpoint
system, however they are very popular and have a huge range of models, textures, scripts,
plug-ins, etc. They make use of quick tabs for top rated, and most downloaded, and have
quick links directly to software specific categories. They also have a very active forum
community with helpful feedback.
http://www.adobe.com/cfusion/exchange/ : Adobe's official exchange section is a major
community hub for any artist who uses Adobe's tools and applications. It's clear, professional
and very easy to navigate and browse; most of the content is free downloads; it has
dedicated sections for content related to the most popular applications. The keyword
search coupled with a rating system for specific searches helps narrow down what would be
best if a search returns several viable results.
Concerning Adobe the official forums, naturally they're popular and used a lot due to the
company making such a wide range of quality products. But one of the most positive things
about them is that when users access the 'Help' function in new Adobe products, it returns
results from the forum, as well as the more 'standard' answers from the online manual/help
files. This means the forum community directly contributes to helping other users without
the need for browsing endless pages of posts.
ONLINE FORUM COMMUNITIES
http://www.cgsociety.org/ : The biggest and best CG community on the web. Forums for
every kind of discipline, skill, piece of software, and everything else is here. Tutorials,
artwork inspiration, challenges, workshops and more. It's completely free to browse, and
free to sign up and join the community.
http://www.game-artist.net/forums/ : An off-shoot from the CG Society that is dedicated
purely to artwork for games, rather than all forms of computer graphic based art. It has lots
of useful resources and reference, and sub-forums dedicated to 'sketchbooks' and 'work-in-
progress' so users can see how things have been made.
http://www.cgchannel.com/ : On par with the CG society, this a major hub of the graphical
development community. Free tutorials, training, reference, comprehensive forums, event
coverage, competitions, and a store with instant download options.
GAME AUDIO DESIGN
From Collins, K. (2008). Game Sound: An Introduction to the History, Theory, and Practice of Video
Game Music and Sound Design. Boston: The MIT Press.
The first stage in the audio workflow is the creation of an audio design document.
Supplementary to the game design document, an audio design document details the design
32
and implementation of the game's audio. There may be seperate music, dialogue, and sound
design documents (...)
Spotting is the next major element in the audio's development. At this stage, it is
determined which parts of the game should have ambient sound and music. Specifically, this
involves defining cue point entrances, exits, play-ins/play-outs, and game state changes, as
well as deciding if game variables (such as player health, surface properties, and so on) will
be used to change sound parameters. (...)
Spotting the game and creating a list of assets needed is the first step in the sound design of
a game. This involves a reading of the script or design document, looking to spot for
objects, actions, environments, pace, tension/release, characters/personalities, and so on.
(...) Asset lists are often based on descriptions of levels, and are broken down into sound
types (weapon sounds, ambient sounds, menu sounds, foley, and so on). The asset list can
be used to track recording in order to be able to reproduce sounds at a later stage, if
necessary. (...)
With these music and sound design decisions made, a list of required sound assets can be
assembled, with separate asset lists for sound design, dialogue and additional audio content. The
sound design document for the VDAB Truth or Lie minigame can be found on the OSMA project
website http://osma.phl.be/node/156.
OTHER REFERENCES
Collins, K. (2008). Game Sound: An Introduction to the History, Theory, and Practice of Video Game
Music and Sound Design. Boston: The MIT Press.
Collins, K. (2008). From Pac-Man To Pop Music: Interactive Audio in Games and New Media. Ashgate
Popular and Folk Music Series.
Marks, A. (2008). The Complete Guide to Game Audio: For Composers, Musicians, Sound Designers,
Game Developers. Focal Press.
Viers, R. (2008). The Sound Effects Bible: How to Create and Record Hollywood Style Sound Effects.
Michael Wiese Productions.
Wilde, M.D. (2004). Audio Programming for Interactive Games. Focal Press.
33
GAME PROGRAMMING
All code mentioned in this chapter is available for download at the sourceforge OSMA project:
http://osma.phl.be/node/326
OSMA ARCHITECTURE
Figuur 7 OSMA architecture
De OSMA architectuur omvat verschillende onderdelen:
Centraal staat de GameConfig webapplicatie (http://osma.phl.be/gameconfig) zoals
beschreven in het hoofdstuk OSMA Gameconfig backend. Met deze drupal webapplicatie
kunnen de verschillende games en game componenten geconfigureerd worden. Gebruikers
van de webapplicatie kunnen afhankelijk van hun rol, bepaalde games configureren en
spelen. Vanuit het spel kunnen er ook bepaalde gegevens (zoals de avatar configuratie, de
scores op de spelen) in de drupal backend opgeslaan worden.
De ontwikkelde games halen de configuratie gegevens van het game en zijn componenten
uit de gameconfig databank. Daarvoor werd een game-gameconfig interface opgesteld die
verder besproken wordt in paragraaf Unity-Drupal Interface.
Een mogelijke uitbreiding van het platform – maar nog niet geïmplementeerd – bestaat erin
om vanuit de gameconfig applicatie te communiceren met verschillende third-party
applicaties, en dit voor de configuratie van de componenten of het verder verwerken van de
verkregen spelgegevens.
34
Voor elk spel wordt een game client en game server applicatie ontwikkeld. Zoals
beschreven in het hoofdstuk Server en Client zullen verschillende spelers via de game client
connecteren met dezelfde dedicated server.
Voor elke ontwikkelde game wordt een node (drupal pagina) aangemaakt die de gameclient
plugin bevat.
Verschillende van de ontwikkelde spelen maken gebruik van VOIP. Voor deze games moet
dus een Red VOIP server geïnstalleerd worden.
GAME PROGRAMMING IN UNITY
KEUZE GAME ENGINE
Voor de ontwikkeling van de verschillende games werd gekozen voor de Unity3D game engine. De
keuze van de Unity3D game engine kwam er na een onderzoek en uittesten van verschillende game
engines. De verschillende game engines werden in kaart gebracht en in een databank opgeslagen.
Deze databank kan geraadpleegd worden op http://osma.phl.be/node/49.
Tijdens het OSMA project werden verschillende game engines bekeken en afgewogen op basis van
specifieke criteria. Een verslag van dit onderzoek kan teruggevonden worden op de project website:
http://osma.phl.be/node/49.
UNITY
In deze handleiding wordt geen specifieke aandacht besteed aan de exacte werking van Unity.
Informatie over unity zelf is te vinden op http://unity3d.com/.
Enkele handige links:
- Unity documentatie: http://unity3d.com/support/documentation/
o Handleiding: http://unity3d.com/support/documentation/Manual/index.html
o Reference guide:
http://unity3d.com/support/documentation/Components/index.html
- Unity forum: http://forum.unity3d.com/
SERVER EN CLIENT
Een game server zorgt voor het netwerkverkeer en de instandhouding van de gamelogica.
35
Een game client connecteert op deze server om deel te nemen aan de beschikbare applicatie.
In OSMA wordt gebruik gemaakt van dedicated servers. Dit wil zeggen dat een server instantie van
een bepaald spel actief is op een bepaalde server die te bereiken is door alle clients. Dit wil zeggen
dat er een aparte build gemaakt moeten worden voor de dedicated server en voor de client.
AANMAKEN DEDICATED GAME SERVER IN UNITY
Zet bij de NetworkManager de checkbox “Dedicated Server” aan. Dit zal ervoor zorgen dat wanneer
deze build opgestart wordt, er automatisch een server opgezet wordt. Enkel de connection port is
verplicht in te vullen. Dit is de poort waarop de clients op de server kunnen aansluiten.
Stel de andere server variabelen naar wens in. Maar hierna een standalone build om een uitvoerbaar
programma (.exe) te creëren voor de gameserver van dit game. Zet hierna dit programma op de
gewenste machine die als gameserver zal dienen en voer het programma uit om de gameserver te
starten.
Door bij het doel van de exe file of de snelkoppeling ernaar „-batchmode‟ te plakken (bv: "D:\Unity
projects\testbuild\wachtzaal\truefalse_dedicatedServer.exe" -batchmode), zal deze exe opstarten
in batchmode. Deze modus zorgt ervoor dat het programma zonder grafische laag uitgevoerd wordt.
Enkel het programma draait in de achtergrond zonder dat deze grafische berekeningen moet maken,
wat ideaal is voor een dedicated server
Let erop dat de machine waarop deze applicatie zal draaien bereikbaar is voor de client applicatie.
Het IP en de ingestelde poort van de server zal dus ofwel binnen het internet netwerk bereikbaar
moeten zijn, of eventueel extern voor de buitenwereld.
Zie NetworkConnection voor verdere uitleg.
AANMAKEN GAME CLIENT IN UNITY
Zet bij de NetworkManager “Auto Connect As Client” aan. Dit zorgt ervoor dat deze build
automatisch connecteert met het meegegeven ip (hier moet natuurlijk een dedicated server draaien
van het desbetreffende spel).
Zie NetworkConnection voor verdere uitleg.
BACKEND CONFIGURATIE
Op de root van de webserver moet de xml file crossdomain.xml staan. Zonder deze file kan de
webplayer versie niet communiceren met deze server. Zie
http://unity3d.com/support/documentation/Manual/Security%20Sandbox.html
VAN CENTRALE RUIMTE NAAR GAME EN OMGEKEERD
Voor de VDAB demonstrator werd een game ontwikkeld bestaande uit verschillende minigames. Er is
een centrale lobby (centrale ruimte) waar spelers elkaar kunnen ontmoeten en van daaruit naar
andere kamers kunnen gaan. Elke kamer omvat één minigame: waarheid-leugen spel of
onderhandelingsspel.
36
Figuur 8 VDAB Lobby met toegang naar verschillende kamers
Met behulp van de OSMA component Game Link (zie verder) kan van de ene level naar een ander
level gegaan worden.
Concreet betekent dit dat vanuit de centrale ruimte Game Links gelegd worden naar meerdere
minigames. Dit gebeurt via klikbare deuren met een Click Trigger component, waaraan een Game
Link gekoppeld is. Deze Game Link zal voor elke deur ingesteld worden naar een andere game.
Vanuit de minigames kan ook teruggereisd worden naar de centrale ruimte. Dit kan door de Main
Gui Manager via de Central Area Game Link Component te koppelen aan een Game Link die verwijst
naar de centrale ruimte.
Een Game Link kan een nieuwe unity3d file inladen. De url voor deze file is in te stellen via het
component. Dit betekent dat de huidige game volledig uitgeladen en het nieuwe ingeladen wordt.
Het gemakkelijkste is als alle te gebruiken unity3d files in dezelfde map op de publieke server
staan. Zo moet er enkel op gelet worden dat elke Game Link naar de juiste bestandsnaam verwijst.
Deze structuur, in samenwerking met het feit dat elke game een eigen dedicated server heeft en
een client build die automatisch zal connecteren met deze server (zie hoofdstuk “Server en
Client”), zorgt ervoor dat wanneer een game ingeladen wordt, deze ook automatisch zal aansluiten
op de correcte server.
37
OSMA COMPONENTEN EN MANAGERS
Een OSMA game wordt opgebouwd uit verschillende managers en componenten.
Dit hoofdstuk biedt een uitgebreid overzicht van alle instellingen van beschikbare OSMA
componenten en managers.
Manager: naam Component: OSMA_comp_naam ActieComponent: OSMA_act_naam Overige: naam
Figuur 9 Naamgeving OSMA managers, componenten en actiecomponenten
Managers zijn verplicht aanwezig in elke OSMA game. Zij zorgen voor het algemene netwerkverkeer,
het ingame menu, de avatar creatie enz.
OSMA componenten kunnen aan elkaar geschakeld worden om de beoogde functionaliteit te
bekomen. OSMA componenten bieden meestal een volledige gameflow aan (zoals multiplechoice
component voor het VDAB waarheid/leugen game, het bidding component voor het VDAB bidding
game,…)
OSMA actie componenten kunnen eveneens aan elkaar geschakeld worden, met als verschil dat actie
componenten eenvoudige functionaliteit voorzien terwijl OSMA componenten uitgebreider zijn.
Dit aan elkaar koppelen van componenten gebeurt door enkele functies, genaamd osma_start (een
componenten starten), osma_stop (een component stoppen), en osma_setPlayer (een speler aan de
spelerslijst van het component toevoegen). De beschikbare inkomende en uitgaande functies zijn
afhankelijk van de geboden functionaliteit.
Een standaard component zal er dus als volgt uitzien:
38
Figuur 10 Diagram standaard OSMA component
Daarnaast zullen bepaalde componenten nog andere specifieke functies aanbieden. Zo zal de
combinator input component een setChannel signaal kunnen uitsturen, wat opgevangen kan worden
door een combinator.
Zie Appendix 1: OSMA Managers, Components and Action Components voor een overzicht van alle
managers, componenten en actiecomponenten
COMPONENT COMPOSITIE
Een voorbeeld van het aan elkaar schakelen van componenten vinden we in dit diagram waar een
deel van het waarheid/leugen game wordt voorgesteld:
Figuur 11 Compositie van OSMA componenten
- De collision trigger stelt de stoel voor. Wanneer een speler in aanraking komt met de
stoel, wordt deze geactiveerd.
- Hij stuurt een setPlayer signaal door naar het multiplechoice component (het
waarheid/leugen game) om aan te tonen dat deze speler er deel van zal uitmaken.
- Daarna stuurt hij een osma_start signaal naar zowel een playerAnimation die een
zitanimatie afspeelt voor de juiste avatar. Na deze animatie stuurt hij een osma_start
signaal naar een combinatorInput.
39
- De combinatorInput zal een bepaald kanaal van een combinator activeren.
- Wanneer alle kanalen van die combinator geactiveerd zijn, zal een osma_start signaal
gestuurd worden naar het multiplechoice component, en zal dus het waarheid/leugen
game gestart worden met de daarvoor ingestelde spelers.
GAME PROTOTYPES
In dit hoofdstuk worden de game prototypes die reeds ontwikkeld zijn uitgediept via
sequentiediagrammen. Deze stellen de opvolging van functies voor een bepaald component, en dit
voor zowel 2 clients (de spelers) als de server (die het grootste deel van de functionaliteiten omvat)
en beheert).
MULTIPLAYER VERBINDING
Aangezien de osma games multiplayer games zijn, wordt er, zoals in voorgaand hoofdstuk reeds
uitgelegd, een verbinding opgesteld tussen een client (de speler) en de server.
In dit diagram worden de stappen uitgelegd die doorlopen worden bij het aansluiten van een nieuwe
client op de server.
Dit diagram omvat functionaliteit van zowel de networConnection, networkManager als de
avatarGenerator, allen verplichte componenten binnen de osma games.
WAARHEID/LEUGEN GAME (MULTIPLECHOICE COMPONENT)
40
Dit diagram omvat functionaliteit van het multipleChoice component, en start vanaf het
binnenkomen van het osma_start signaal, dus het eigenlijke begin van het game.
41
BIEDINGSGAME (BIDDING COMPONENT)
Dit diagram omvat functionaliteit van het bidding component, en start vanaf het binnenkomen van
het osma_start signaal, dus het eigenlijke begin van het game.
42
FARO GAME (FARO COMPONENT)
Dit diagram omvat functionaliteit van het faro component (een afgeleide van het bidding
component), en start vanaf het binnenkomen van het osma_start signaal, dus het eigenlijke begin
van het game.
43
44
UNITY PROJECTEN OVERZICHT
GAME PROTOTYPES
Betreft mappen: project - unity\osma unity project, project - unity\OSMA_library
Het osma_library project omvat een kleine class library om een eenvoudige dialoog te verwerken
zodat deze gemakkelijker in een game gebruikt kan worden.
Het unity project bevat de code en nodige game assets voor de prototype games.
Voor elk game werd een standalone build gemaakt met de nodige server instellingen, en een
webplayer build met de nodige client instellingen. Om gebruik te maken van voicechat
functionaliteit moet voicechat_interface.js en voicechat_program.js op de webpagina aanwezig
zijn.
De webversie van de game client wordt embedded in een pagina in de OSMA gameconfig
webapplicatie:
VDAB game: http://osma.phl.be/gameconfig/vdabgame
Faro game: http://osma.phl.be/gameconfig/auctiongame
AVATAR TEXTURES TOEVOEGEN
Om extra textures voor de avatar te installeren gaat men als volgt te werk:
- Kopieer de nieuwe textures (die uiteraard moeten voldoen aan de juiste schikking, zie
bestaande photoshop bestanden van de huidige textures) naar de juiste submap binnen
“osma unity project\Assets\Resources\Avatar”. Momenteel bevinden zich hier 2
submappen, “Man1” en “Vrouw1”, verwijzend naar de twee verschillende avatar
modellen die aanwezig zijn. Binnen elk van deze mappen bevinden zich 5 mappen
genoemd naar het betreffende onderdeel van de avatar. Dit zijn “Body”, “Feet”, “Hair”,
“Head” en “Legs”. Zet de nieuwe texture in de correcte map.
- Open het osma unity project in Unity. Unity zal de nieuwe textures automatisch
importeren.
- Nu moet er voor elke game en avatarconfiguratie scene waarin deze textures beschikbaar
moeten zijn voor de avatar een nieuwe build gemaakt worden.
Men doet voor elke scene:
o Open scene.
o Klik in het menu op File > Build Settings.
o Onder “Scenes to build” verwijderen we alle scenes behalve de momenteel te
builden scene (scene aanklikken in de lijst en op de delete toets drukken,
eventueel lijst volledig leegmaken en op het einde op “Add current” klikken).
45
o Kiest het gewenste platform (voor server is dit waarschijnlijk PC standalone, voor
clients de webplayer).
o Klik op build.
Dit moeten we doen voor elke game, zowel voor de server als client zijde, die gebruik kan
maken van de nieuwe texture. Als we bijvoorbeeld een nieuwe texture toevoegen aan de
avatar configuratie scene, moeten we ook nieuwe builds maken van elke game omdat de
ingestelde texture uiteraard in elke game beschikbaar moet zijn.
Meer informatie over het builden binnen Unity is te vinden op
http://unity3d.com/support/documentation/Manual/Publishing%20Builds.html .
VOICECHAT
Betreft mappen: sourcecode voicechatserver, sourcecode voicechatclient, voicechattest
Het project myApp2 binnen de map „sourcecode voicechatserver‟ omvat de Red5 voicechat server
applicatie code.
Het project voicechatClient binnen de map „sourcecode voicechatclient omvat de client zijde voor
de voicechat applicatie.
Deze projecten zijn gezamenlijk als Red5Plugin gemaakt.
Meer informatie hierover in Appendix 3: Configuration RED5
De map voicechattest bevat enkel html testcases om de voicechat client te testen.
Deze map bevat ook de gecompileerde voicechatclient flash applicatie en de interface binnen
javascript:
- voicechatClient.swf: de voicechat client applicatie.
- voicechat_program.js: javascript om voicechatClient.swl (de build van de client app met
Flash Builder) toe te voegen aan een webpagina.
- voicechat_interface.js: verzorgt de interface tussen de flash voicechat client en de unity
webplayer.
- WebPlayers.html: een voorbeeld van hoe de voicechat client en unity webplayer toe te
voegen aan een webpagina.
De Red5 server inclusief voicechatserver webapp (build - Red5 server webapp, hier staat een
gecompileerde versie van de voicechatserver) moet op een intern of extern toegankelijke webserver
geïnstalleerd zijn. Om de Red5 server te starten op de server gebruikt men red5-debug.bat. De
eenvoudigste manier om de Red5 server inclusief voicechatserver webapp te installeren is
simpelweg om de Red5 folder binnen „Red5 server incl voicechat app‟ op de server te zetten, om
vervolgens de server te starten.
Op de Red5 moeten naast de default http poort 5080 ook de RTMP poort 1935 en RTMPT poort 8088
beschikbaar zijn. Via deze poorten zal de red5 server communiceren met zijn clients.
46
OSMA GAMECONFIG BACKEND
GAMECONFIG INSTALLATION
The gameconfig drupal code and database can be downloaded from the OSMA sourceforge site:
http://osma.phl.be/node/326. To install copy the drupal code to the webserver ( and name the
application <gameconfig>) and install the MySQL database. Modify in the settings.php file
(<gameconfig>/sites/default/settings.php) the database name and database login.
CONFIGURATION OF OSMA GAMES AND COMPONENTS
Some of the OSMA components defined in “OSMA componenten en managers” can be configured in
the gameconfig application. Depending on the role a user gets in the Drupal system, he/she can
configure GameLinks, Slideshow, dialogs etc.
UNITY-DRUPAL INTERFACE
UNITY-DRUPAL USER IDENTIFICATION
The gameconfig drupal userID and userName are stored as javascript DOM variables in the page in
which the Unity player is embedded.
For every game a drupal game page needs to be created:
- The startpage for the VDAB POP Game can be found here
http://osma.phl.be/gameconfig/vdabgame
- The startpage for the Faro Auction Game can be found here
http://osma.phl.be/gameconfig/auctiongame
UNITY GAME EXTERNE CONFIGURATIE
47
Figuur 12 Unity - GameConfig API
For the different components described in Appendix “Osma componenten” the external
configuration can be realized with the unity-gameconfig api. This API returns the correct XML
format for the different components.
URL parameter
http://osma.phl.be/gameconfig/getavatar uid
http://osma.phl.be/gameconfig/getgamelink code
http://osma.phl.be/gameconfig/getdialogue code
http://osma.phl.be/gameconfig/getfeedback code
http://osma.phl.be/gameconfig/getgoal uid
http://osma.phl.be/gameconfig/getimage code
http://osma.phl.be/gameconfig/getmcquestion code
http://osma.phl.be/gameconfig/getmultiplechoice code
http://osma.phl.be/gameconfig/getpoll code
http://osma.phl.be/gameconfig/getbidding code
http://osma.phl.be/gameconfig/getbiddingextended code
http://osma.phl.be/gameconfig/getserver code
http://osma.phl.be/gameconfig/getvoicechatserver code
http://osma.phl.be/gameconfig/getstats uid
http://osma.phl.be/gameconfig/setavatar uid,modelName,hair,head,body,legs,feet
http://osma.phl.be/gameconfig/setscore uid,scorecode,score
Figuur 13 Unity-GameConfig API
OSMA REST API DOCUMENTATION
Besides the API described in the previous paragraph the GameConfig webapplication also comes
with a REST API. This API can also be used to integrate games in the OSMA platform. A more
elaborate discussion of the REST API can be found in Appendix 2: OSMA REST Interface.
48
USABILITY TESTING
TESTING WITH THE USER GROUP
Tijdens de gebruikersgroep van 8 juli 2011 kregen 8 personen de mogelijkheid om in groepjes het
waarheid/leugen en het biedingsspel te spelen. Na het spelen kregen de personen een schriftelijke
bevraging voorgelegd. Deze vragenlijst kon anoniem worden ingevuld zodat de personen de kans
hadden om hun mening anoniem op te schrijven. De enquête bestond uit de volgende open vragen:
Wat is je eerste indruk van het spel?
Hoe duidelijk waren de spelregels voor jou?
Hoe zou u het doel van het spel kunnen samenvatten?
Wat is het meest positief aan het spel?
Wat is het meest negatief aan het spel?
Wat vond je van de lengte van het spel?
Als je het spel een score mag geven van 1 tot 10, hoeveel zou je dan geven?
Zie je mogelijkheden om de spelen te gebruiken binnen de eigen organisatie? Indien ja,
op welke manier?
Hoe zouden we het spel beter kunnen maken?
Was er teveel of te weinig interactie tussen de spelers?
Hoe tevreden ben je met de resultaten van het OSMA project?
Zie je potentieel in OSMA?
Heb je nog andere opmerkingen/suggesties?
Na de bevraging volgde er ook een bespreking in groep om verder te kunnen doorvragen en de
belangrijkste opmerkingen te bespreken.
EERSTE INDRUK VAN DE DEELNEMERS
WAARHEID/LEUGEN SPEL
Uit de anonieme bevragen tijdens de gebruikersgroep blijkt dat de eerste indruk overwegend
positief is. De gebruikersgroep drukte dit uit in de volgende verwoording: “catchy, goede basis”,
“leuk, verrassend”, “goed”, “mooie look & feel”, “goede proof of concept”, 2x “okee” en één
persoon verwoorde zijn eerste indruk als: “flow moet intuïtiever”.
BIEDINGSSPEL
De meerderheid van de eerste indrukken was positief: “fun: leuk niveau en interactie“, “leuk”,
“fijn spel” en “mooi”. Twee spelers haalden aan dat ze niet begrepen wat ze moesten doen: “heel
onduidelijk” en “wat moet ik doen?”
49
DE SPELREGELS
WAARHEID/LEUGEN SPEL
Over het algemeen kan gesteld worden dat de spelregels van het waarheid/leugen spel vrij duidelijk
zijn. De gebruikersgroep omschreef de spelregels als: “voldoende duidelijk”, “vrij duidelijk, iets
meer begeleiding mag”, “helder”, “duidelijk”. Voor enkele personen waren de spelregels minder
duidelijk. Dit blijkt uit de reacties “niet heel duidelijk omdat ik niet als eerste moest starten” en
“Welke spelregels?”
BIEDINGSSPEL
Een persoon gaf aan dat het spel vrij duidelijk was. Voor de anderen was het spel niet meteen
duidelijk tot helemaal onduidelijk:
“Pas duidelijk na 1x spelen. Eerste item hebben we verkocht zonder dat we het
beseften. We wisten niet dat we verkopers waren.”,
“ Redelijk duidelijk, veel duidelijker na de eerste spelronde. De uitleg van de bieding
wordt gestart door spel, dat je niet zelf kan beginnen verkopen.”
“Niet duidelijk welke materialen van ons waren”
“Het verschil tussen de puntenwaarde en geldwaarde was niet volledig duidelijk in het
begin“
Hieruit blijkt dus dat de spelregels duidelijker in het spel verwerkt moeten worden.
DOEL VAN HET SPEL
WAARHEID/LEUGEN SPEL
De spelers kregen ook de vraag om het doel van het spel te omschrijven. De helft van de personen
liet deze vraag open. De andere helft omschreef de doelen van het spel als volgt: “interpersoonlijke
interactie evalueren”, “spelenderwijs verhaaltjes / mensen inschatten”, “vertellen dat een verhaal
waar niet waar is” en “zelf een verhaal overtuigend brengen en de andere spelers beoordelen”. Dit
geeft aan dat de personen die de vraag hebben beantwoord het doel van het spel vatten.
BIEDINGSSPEL
De personen omschreven het doel van het spel als volgt: “kennismaken met mogelijkheden van
onderhandelen”, “ Interpersoonlijke interactie evalueren”, “Verkopen”, “Verzamel zoveel mogelijk
punten door objecten te verkopen”.
POSITIEVE ASPECTEN VAN HET SPEL
WAARHEID/LEUGEN SPEL
Als positief aspect springt de interactie eruit: “Goed gebruik van het sociale aspect” en “Interactie
tussen de spelers” werd 2 keren vermeld. Ook de duidelijkheid van spel, het concept en de
flexibiliteit werden opgenoemd als sterke punten.
50
BIEDINGSSPEL
Als sterk punt van dit spel komt de interactie naar voor: “leuke communicatie onder deelnemers”,
“vlotte interactie zodra het spel start”, “Sterke interactie”. Ook het competitieve is een positief
punt: “meer competitie dan bij waarheid/leugen spel” en “het spel laat zowel toe om rechtuit te
onderhandelen als om tactisch te spelen”.
NEGATIEVE ASPECTEN
WAARHEID/LEUGEN SPEL
Als negatatief aspect primeert de relatief lange wachttijd. Enkele personen hadden de indruk dat
het te langzaam ging en/of dat ze te lang moesten wachten. 5 personen haalden het lange wachten
aan als negatief punt. Ook het finetunen van de grafische elementen is nog een verbeterpunt.
BIEDINGSSPEL
Aan de duidelijkheid van het spel is er nog werk. Dit blijkt aan de hand van de volgende
opmerkingen: “het overzicht geraak wel eens zoek” en “niet overzichtelijk”. De chatvenster kennen
ook nog enkele problemen: “Chatvensters zijn soms onbereikbaar” en “Chatvenster sluit als
volgende bieding begint”. Verder was een wachten op de anderen ook twee maal aangehaald als
negatief punt.
LENGTE VAN HET SPEL
WAARHEID/LEUGEN SPEL
Over de lengte van het spel zijn de spelers in het algemeen tevreden tot zeer tevreden. Enkel het
wachten duurt soms te lang.
BIEDINGSSPEL
Over de lengte van het spel zijn de opinies verdeeld. Eén persoon vond deze vrij lang, terwijl
andere deze voldoende tot goed vonden.
SCORE VAN 1 TOT 10
WAARHEID/LEUGEN SPEL
Aan de spelers werd ook gevraagd om het spel een score te geven op een schaal van 1 tot 10. De
modus was 6 en het gemiddelde laag op 6.5. Niemand gaf het spel een score onder de 5.
BIEDINGSSPEL
Het biedingspel kreeg een gemiddelde score van 7,4 en scoort dus hoger dan het waarheid/leugen
spel. De modus bedraagt 8.
51
MOGELIJKHEDEN OM HET GEBRUIKEN BINNEN DE EIGEN ORGANISATIE
WAARHEID/LEUGEN SPEL
Slechts één persoon zag geen potentiële toepassingen binnen zijn eigen organisatie. De andere
zagen volgende toepassingsgebieden: “Misschien in assertiviteitstraining”, “voor laaggeschoolden,
speels ontdekken van competenties”, “zou een van onze tools kunnen worden “test je creativiteit”.
Maar dan zou één van de spelers de NPC moeten zijn, 1 persoon die alle vragen stelt.”, “i.p.v. van
een verhaal te vertellen zou ik graag een video met een case laten zien of foto‟s”, “een tafel voor
overleg is zeker bruikbaar maar dan zonder de beoordelingen”, “een module voor klantenprojecten”
BIEDINGSSPEL
Twee personen zagen niet direct een toepassingsgebied binnen de eigen organisatie. De rest van de
groep zag ditwel, volgende voorbeelden werden aangehaald: “om overtuigingskracht te versterken
bij collega‟s om interne betere beter ingang te doen vinden” en “voor spontane communicatie”.
VERBETEREN VAN HET SPEL
WAARHEID/LEUGEN SPEL
Het spel zou volgens de personen grafisch beter uitgewerkt kunnen worden: “GUI voor vragen
stellen kan beter” en “grafisch aantrekkelijker maken”. Ook het aanpassen van de dialogen naar
een scrollend formaat zou een verbetering zijn. Verder zou het volgens de personen nuttig zijn om
meer uitleg (kort en bondig) te voorzien.
BIEDINGSSPEL
Het spel zou verbeterd kunnen worden door de user interface aan te passen: “een betere schikking
van de chatschermen”, “geen transparante layers” en “minder schermen over elkaar”. Ook de
verzendknop van de chat kan aangepast worden door enter hiervoor te gebruiken. Verder kunnen
tips & tricks worden weergeven om het wachten zinvol op te vullen.
BEOORDELING VAN DE INTERACTIE (BEIDE SPELLEN)
Bij het waarheid/leugen spel is de interactie eerder beperkt: “Te weinig interactie bij
waarheid/leugen spel, betere interactie bij biedingsspel”, “eerder weinig tot geen chat bij het
waarheid/leugenspel , 2e spel veel meer chat”. Andere personen gaven dan weer aan dat de
interactie goed was. Ook het visualiseren van de winnaar en de persoon die een vraag stelt werd
aangehaald als een meerwaarde voor de interactie.
ALGEMENE TEVREDENHEID VAN DE RESULTATEN VAN HET OSMA PROJECT
52
Deze vraag werd door 6 van de 8 contactpersonen beantwoord. De antwoorden variëren van redelijk
tevreden tot een mooi resultaat: “redelijk tevreden: goede basis gegeven”, “met beperkte
middelen een mooi resultaat”, tevreden, ben vooral benieuwd hoe we verder kunnen aanpassen”,
2x “ok” en “mooi resultaat”.
HET POTENTIEEL VAN OSMA
Meer dan de helft van de personen ziet potentieel in het OSMA project. Al worden hierbij een aantal
kanttekeningen gemaakt: “afhankelijk van de beheersbaarheid naar niet Unity specialisten,
aanpasbaarheid / moduleerbaarheid van het originele materiaal”, “leidende technologieën zoals
Unity, Drupal, Collective Access samen met hergebruik zorgen voor materiaal hergebruik. OSMA kan
een goede basis zijn om op te bouwen”, “Soms een beetje onduidelijk, maar het browser-based
opensource second life idee is leuk”
OPMERKINGEN EN SUGGESTIES
Ik hoop dat er nog tijd op het einde gaat zijn om een manual te maken of camtasia video
hoe je een gelijkaardig spel kan opbouwen
GAGE verhaal integreren
Hints/tips tijdens het wachten
APPENDIX 1: OSMA MANAGERS, COMPONENTS AND ACTION COMPONENTS
MANAGERS
NETWORKCONNECTION
OMSCHRIJVING
Deze manager zorgt voor het opstarten van een server of het aansluiten van een client.
Per spel zullen er telkens 2 builds gemaakt moeten worden. Een met de server instellingen, en een
met client instellingen.
Enkele richtlijnen:
- Voor een server build:
o Controleer dat autoConnectAsClient onder client connection uitstaat.
o Zet dedicatedServer onder server connection aan, dit zal ervoor zorgen dat we
een server build gaan maken.
53
o Geef onder connectionPort een correcte poort in die op de gameserver machine
toegankelijk zal zijn voor spelers. Dit is dus de poort waarop clients zullen
aansluiten (in combinatie met het IP van de gameserver machine) (zie
GameServer onder Backend communicatie).
- Voor een client build:
o Controleer dat dedicatedServer onder server connection uitstaat.
o Zet autoConnectAsClient onder client connection aan. Dit zal ervoor zorgen dat
we een server build gaan maken.
o Geef bij connectToIP en connectToPort het IP op waar de server zich bevindt, en
de poort die deze gebruikt (dit is dezelfde poort als bij connectionPort ingesteld
is bij de server build)
o In plaats van deze gegevens bij connectToIP en connectToPort in te geven,
kunnen we deze ook via het backend inladen. Zet hiervoor
getGameserverDataFromDrupalCms aan, en vul de correcte URL in voor het
bekomen van de game server data (exclusief de basis url die in de
NetworkManager ingesteld is) (bv: “getserver/server_bidding”) (zie GameServer
onder Backend communicatie).
VARIABELEN
- Client Connection
o autoConnectAsClient: bij het opstarten automatisch connecteren als client
o connectToIP: te connecteren op de server op dit IP
o connectToPort: te connecteren op de server via deze poort (Let op, als er
meerdere servers op hetzelfde IP staan moet elk game een verschillende poort
hebben)
o checkLoginBeforeConnecting: eerst checken of de gebruiker wel ingelogd is op de
osma website vooraleer geprobeerd wordt om aan te sluiten op de server
o checkLoginURL: de url waar gecheckt kan worden of de gebruiken ingelogd is
(return template = user.xml) (momenteel niet gebruikt)
o getConnectionDataFromJavascript: de drupal cms url en het gameserver ip en
port worden uit het javascript in de webpagina gehaald (de variabelen hier
worden automatisch ingevuld door het drupal cms). Deze waarden zullen de
voorgaande waarden overschrijven (momenteel niet gebruikt)
o getGameserverDataFromDrupalCms: het gameserver ip en port worden uit het
drupal cms geladen. Deze waarden zullen de voorgaande waarden overschrijven
o gameserverDataUrl: url vanwaar gameserver ip en port geladen moeten worden
indien GetGameserverDataFromDrupalCms aan staat
o getUserIdFromJavascript: vraag het user id van de huidige gebruiker aan via de
javascript functie GetUserId. Hiermee kan herkend worden welke speler, en dus
54
welke avatar, stats enz, gebruikt moeten worden voor deze aansluiting
(momenteel niet gebruikt, als test wordt uit javascript een een test id en naam
ingesteld)
- Server Connection
o dedicatedServer: bij het opstarten automatisch een server starten
o publishOnMasterServer: geef deze server aan bij de masterserver (beta versie)
o maxPlayers: maximum aantal spelers dat kan connecteren
o connectionPort: open de server op deze poort
o gameTypeName: de naam van het game type (nodig voor masterserver)
(variabelen vanaf hier worden niet gebruikt, masterserver is momenteel niet
geïntegreerd)
o gameName: de naam van dit game (nodig voor masterserver, moet uniek zijn)
o gameComment: uitleg over de game (nodig voor masterserver, kan eventueel
gebruikt worden om gestructureerd enkele variabelen door te geven aan de
masterserver)
o masterServerIP: ip van de masterserver
o masterServerPort: poort van de masterserver
NETWORKMANAGER
OMSCHRIJVING
Deze manager zorgt voor het algemeen netwerkverkeer en het bijhouden van de spelerslijst.
VARIABELEN
- avatarSpawnArea: de positie van de networkmanager wordt als start plaats gebruikt als
avatars op de server aansluiten. Duidt hiermee aan hoeveel ruimte vanaf de
networkmanager positie gebruikt mag worden om een random startlocatie te genereren
voor avatars.
- myGameContextId: elk spel is onderdeel van een gamecontext (een verzameling van
minigames). Duidt hiermee het id van de gebruikte gamecontext aan (momenteel niet
gebruikt)
- myGameId: elk spel moet een bepaald id hebben om zich te kunnen identificeren bij de
backend (momenteel niet gebruikt)
- Base Url: de basis url naar het backend systeem. Alle gebruikte url‟s zullen van deze basis
url afhangen. (bv: http://osma.phl.be/gameconfig/) (Let op, deze en andere urls moeten
correct zijn om de werking van de games te garanderen)
55
- Stats Url: de url om stats van de speler op te vragen. (bv: getstats/)
- Doelen Url: de url om de doelen van de speler op te vragen. (bv: getgoal/)
- Set Score Url: de url om de scores van de speler door te sturen. (bv: setscore/)
- Avatar url: de url om de avatar van de speler op te vragen. (bv: getavatar/)
AUDIOMANAGER
OMSCHRIJVING
Deze manager staat in voor alle audio gedurende het game. Hij omvat 2 audiosources, een voor het
achtergrond geluid en een andere voor alle geluidseffecten. Op deze manier kan het volume en
andere instellingen verschillen voor het achtergrondgeluid en effecten.
VARIABELEN
- countdownSound8sec: adioclip met een aftel geluid dat exact 8 seconden aftelt
- countdownSound1sec: adioclip met een aftel geluid dat exact 1 seconde aftelt
AVATARGENERATOR
OMSCHRIJVING
Deze manager staat in voor alle avatar functies, zoals avatar instellen, of een avatar configureren
aan de hand van een bepaalde configuratie.
Per avatar kunnen de textures van enkele onderdelen veranderd worden.
Per avatar model moet in de avatargenerator een template ingesteld worden.
Deze template geeft aan welke mesh instaat voor elk onderdeel. Zo weet de avatargenerator pe
avatarmodel welke texture van welke mesh er ingesteld moet worden.
Deze instellingen kunnen in principe vermeden worden als elk model voldoet aan bepaalde
naamgeving, bv:
“headMesh” voor de mesh van het hoofd, enz. Deze naamgeving moet tijdens het aanmaken van het
moden in het 3d modeling pakket. Dit is momenteel niet het geval, waardoor dit per avatar model
in avatar templates ingesteld moet worden.
56
VARIABELEN
- Avatar Template List:
o templateName: deze aam moet overeenkomen met de naam van de avatar prefab
(te vinden in de map Prefabs\Player prefabs\) en met de naam van de textures voor
dit model (te vinden in de map Resources\Avatar\. Op deze manier kan deze
template gelinkt worden aan het correcte model en de beschikbare textures ervoor
o headBoneName: de naam van de bone die het hoofd controleert binnen dit model.
Dit is nodig zodat de namen en eventuele iconen voor die speler op de correcte
plaats kunnen meebewegen met elke speler
o head: de mesh die het hoofd van de avatar voorstelt
o hair: de mesh die het haar van de avatar voorstelt
o body: de mesh die het bovenlijf van de avatar voorstelt
o legs: de mesh die het onderlijf van de avatar voorstelt
o feet: de mesh die de voeten van de avatar voorstelt
MAINGUIMANAGER
OMSCHRIJVING
Deze manager staat in voor het ingame menu vanboven op het spelersscherm. In dit menu kan de
speler bijvoorbeeld een lijst van spelers oproepen, zijn huidige statistieken bekijken, enz.
VARIABELEN
- skin: de GuiSkin voor het ingame menu. Let op dat bepaalde custom gui styles verplicht
zijn voor het tekenen van het ingame menu
- newChatMessage: icoon dat verschijnt als er een nieuwe boodschap via de algemene chat
binnenkomt
- showStatsButton: moet de statistieken knop getoond worden
- showStatsButton: moet de chat knop getoond worden, deze geeft toegang tot de
algemene chat
- showPlayerlistButton: moet de spelerslijst knop getoond worden
57
- showExitToCentralArea Button: moet de exit knop getoond worden. Deze knop is gelinkt
aan een game link component en moet toegang geven tot de verzamelplaats voor spelers
(lobby)
- centralAreaGameLinkComponent: een game link component met toegang tot de
verzamelplaats (lobby)
- showPlayerNames: toon de namen van de spelers boven het hoofd van hun avatar
- playerNameOffset: offset ten opzichte van de head bone van de avatar waar de namen
getoond moeten worden
- mouseIconTextures: geeft aan welke iconen er getekend moeten worden wanneer de muis
zich over een bepaalde functie bevindt
o Deur: icoon wanneer de muis over een deur staat
o Npc: icoon wanneer de muis over een npc staat
GUIMANAGER
OMSCHRIJVING
Deze manager staat in voor overige gui functies, zoals het tekenen van een npc dialoog.
VARIABELEN
- guiSkin: de GuiSkin voor het ingame menu. Let op dat bepaalde custom gui styles
verplicht zijn
VOICECHATMANAGER
OMSCHRIJVING
Deze manager verzorgt de interface voor alle voidechat functies, tussen de networkmanager en de
javascript voicechat functies op de webpagina.
Deze is enkel verplicht als er voicechat functies gebruikt worden gedurende dit game.
VARIABELEN
- serverPath: url van de voicechatserver
58
- myRoomName: roomname op de voicechatserver waar alle spelers voor de betreffende
gameserver op mogen aansluiten
EXTERNE CONFIGURATIE Voorbeeld template: voicechatserver_truefalse.xml.
Xml structuur <server> <serverPath>rtmp://osmastream.phl.be/myApp2/</serverPath> <myRoomName>truefalseroom1</myRoomName> </server>
CHATMANAGER
OMSCHRIJVING
De chatmanager staat in voor de algemene chat op de server.
Deze manager is enkel verplicht indien de algemene chat in de mainguimanager is ingeschakeld.
PRIVATECHATMANAGER
OMSCHRIJVING
De privatechatmanager staat in voor de privé chat op de server. Spelers kunnen een privé chat
starten met andere spelers (momenteel enkel gebruikt in het bidding component)
Deze manager is enkel verplicht indien door het game gebruikt.
OSMA COMPONENTEN
Hier worden de osma componenten opgesomd en uitgediept, volgens deze structuur:
- omschrijving: wat doet het component
59
- variabelen: welke variabelen zijn er aanpasbaar binnen Unity
- externe configuratie: deze variabelen kunnen ook extern aangepast worden, zonder dat
hiervoor Unity geopend moet worden of een nieuwe build gemaakt moet worden. Dit
onderdeel geeft een overzicht van de structuur (in xml formaat) die nodig is om dit
component extern te configureren.
POLL COMPONENT
OMSCHRIJVING
Dit component kan gebruikt worden om te stemmen over een onderwerp. De initiator kan mogelijke
opties ingeven waarom de rest kan stemmen. Dit component staat op zichzelf en kan momenteel
niet gekoppeld worden aan andere componenten.
VARIABELEN
- showStartPollButton (bool): toon een startknop op het scherm om een poll te starten
- showCancelPollButton (bool): op het start poll formulier een knop tonen om te annuleren
- startFormTitle (string): de title van het start poll formulier (voor de starter)
- pollFormTitle (string): de title van het stem formulier (voor de stemmers)
- waitWhilePollFormTitle (string): de titel van het formulier terwijl de starter wacht op de
stemmen (voor de starter)
- pollResultTitle (string): de title van het formulier met de uitslag van de poll (voor starter en
stemmers)
- allowOptionsEditing (bool): opties kunnen aangepast worden bij het opstellen van de poll
- allowOptionsAdding (bool): opties kunnen toegevoegd worden bij het opstellen van de poll
- allowOptionsAdding_max (int): maximum aantal opties van de poll
- defaultAddedOption (string): nieuw aangemaakte optie krijgt default value
- startingOptions: een array van entries, dit zijn de initiële opties van de poll
- entry (string): een optie in de poll
- allowMultipleVotes (bool): mag de stemmer op meerdere opties stemmen
- votingTime (float): hoelang mag er gestemd worden
EXTERNE CONFIGURATIE
Voorbeeld template: poll.xml
Xml structuur
<component> <showStartPollButton>true</showStartPollButton> <showCancelPollButton>true</showCancelPollButton> <startFormTitle>startFormTitle</startFormTitle> <pollFormTitle>pollFormTitle</pollFormTitle> <waitWhilePollFormTitle>waitWhilePollFormTitle</waitWhilePollFormTitle> <pollResultTitle>pollResultTitle</pollResultTitle>
60
<allowOptionsEditing>false</allowOptionsEditing> <allowOptionsAdding>true</allowOptionsAdding> <allowOptionsAdding_max>5</allowOptionsAdding_max> <defaultAddedOption>default</defaultAddedOption> <startingOptions> <entry>waarrrr</entry> <entry>niet waarrrr</entry> </startingOptions> <allowMultipleVotes>false</allowMultipleVotes> <votingTime>10</votingTime> </component>
MULTIPLECHOICE COMPONENT
OMSCHRIJVING
Dit component kan gebruikt worden om multiplechoice vragen te stellen in een bepaald vast
patroon:
- De actieve speler geeft aan of het verhaal dat hij zal gaan vertellen al dan niet waar is
- Spelers gokken of het verhaal waar of niet waar is
- volgende ronde met volgende speler
Dit is het het component gebruikt in het true/false game. Zie documenten over dit game voor
gedetailleerde info.
Dit is een afgeleiden van het poll component.
De osma_next functie wordt gebruikt wanneer een feedback component aan dit component
gekoppeld is. Dit component controleert na elke ronde of het feedback component gestart moet
worden (osma_start aan de rechterzijde). Het feedback component stuurt een osma_next signaal uit
als de feedback gegeven is, waardoor het multiplechoice component verder kan met de volgende
ronde
61
VARIABELEN Alle variabelen van een poll
- questionFormTitle (string): de titel van het formulier terwijl de starter een vraag stelt of uitleg geeft
(voor de starter)
- listenToQuestionFormTitle (string): de titel van het formulier terwijl de stemmers de starter zijn
vraag of uitleg lezen (voor de stemmers)
- allowPointsEditing (bool): punten kunnen aangepast worden bij het ingeven
- allowPointsChosing (bool): punten kunnen enkel uit een beschikbare lijst (startingPoints)gekozen
worden bij het ingeven
- allowPointsChosing_UniquePoints (bool): bij het kiezen van punten moet elke optie een unieke score
toegekend krijgen
- defaultPoint (int): nieuw aangemaakte optie krijgt default value voor punten
- startingPoints: array van beschikbare punten om uit te kiezen o entry (int): waarde voor een startingPoints entry
- storyTime (float): tijd om vraag te stellen, of uitleg te geven
- autoRestart (bool): start volgende ronde van multiplechoice component met een andere starter
- autoRestartTime (float): na hoeveel tijd na het einde moet herstart worden
EXTERNE CONFIGURATIE Voorbeeld template: multiplechoice.xml
Xml structuur
<component> <showStartPollButton>true</showStartPollButton> <showCancelPollButton>true</showCancelPollButton> <startFormTitle>startFormTitle</startFormTitle> <pollFormTitle>pollFormTitle</pollFormTitle> <waitWhilePollFormTitle>waitWhilePollFormTitle</waitWhilePollFormTitle> <pollResultTitle>pollResultTitle</pollResultTitle> <allowOptionsEditing>false</allowOptionsEditing> <allowOptionsAdding>true</allowOptionsAdding> <allowOptionsAdding_max>5</allowOptionsAdding_max> <defaultAddedOption>default</defaultAddedOption> <startingOptions> <entry>waarrrr</entry> <entry>niet waarrrr</entry> </startingOptions> <allowMultipleVotes>false</allowMultipleVotes> <votingTime>10</votingTime> <questionFormTitle>questionFormTitle</questionFormTitle> <listenToQuestionFormTitle>listenToQuestionFormTitle</listenToQuestionFormTitle> <allowPointsEditing>false</allowPointsEditing> <allowPointsChosing>true</allowPointsChosing> <allowPointsChosing_UniquePoints>true</allowPointsChosing_UniquePoints> <defaultPoint>0</defaultPoint> <startingPoints> <entry>2863</entry> <entry>17777</entry> </startingPoints> <storyTime>10</storyTime> <autoRestart>true</autoRestart>
62
<autoRestartTime>10</autoRestartTime> </component>
BIDDING COMPONENT
OMSCHRIJVING Dit component kan gebruikt worden om object aan mekaar te verkopen, en te onderhandelen, in een
bepaald vast patroon: - Elke speler krijgt random objecten toegewezen, en random waardes voor elk object - Spelers kunnen onderhandelen over, en bieden op, het object in verkoop - De verkoper beslist naderhand zelf aan wie hij het object verkoopt - Volgende ronde met een andere verkoper
Zie documenten over het biedingsgame over het gedetailleerde verloop van dit game.
De osma_next functie wordt gebruikt wanneer een feedback component aan dit component gekoppeld
is. Dit component controleert na elke ronde of het feedback component gestart moet worden
(osma_start aan de rechterzijde). Het feedback component stuurt een osma_next signaal uit als de
feedback gegeven is, waardoor het bidding component verder kan met de volgende ronde
VARIABELEN
- startMoney (int): hoeveelheid geld dat spelers in begin van spel krijgen
- startAmountObjects (int): aantal objecten dat spelers in begin krijgen
- giveUniqueObjects (bool): geef elke speler unieke objecten (geen 2 spelers met zelfde object). Let
op, er moeten genoeg objecten aanwezig zijn om alle spelers unieke objecten te geven
(startAmountObjects aantal).
- allowedValues: een array van mogelijke waarden die toegewezen worden aan de objecten o entry (int): een aantal van punten
- objectNames: een array van mogelijke objecten o entry (string): de naam van een object dat uitgedeeld en verhandeld zal worden in het
spel
- objectImageUrls: een array van links naar fotos van de objecten. Deze staan in dezelfde volgende
als objectNames o entry (string): een url naar een foto van het overeenkomstig object uit objectNames
- autoRestart (bool): start volgende ronde van bidding component met een andere starter
- autoRestartTime (float): na hoeveel tijd na het einde moet herstart worden
63
- amountRounds (int): hoeveel volledige rondes (waarbij iedereen aan de beurt komt) moeten er
gespeeld worden
- infoTime (float): tijd om het overzicht van objecten en hun toegewezen waardes te bekijken
- auctionTime (float): tijd waarin spelers kunnen onderhandelen over, en bieden op, het object in
aanbieding
- sellingTime (float): tijd waarin de verkoper kan beslissen aan wie hij het object verkoopt
- soldTime(float): tijd waarin alle speler kunnen zien aan welke speler het object verkocht is
- feedbackEnabled (bool): Moet na elke ronde (van elke speler) het feedbackcomponent gebruikt
worden om feedback te verzamelen
EXTERNE CONFIGURATIE Voorbeeld template: bidding.xml
Xml structuur
<component> <startMoney>5000</startMoney> <startAmountObjects>2</startAmountObjects> <giveUniqueObjects>true</giveUniqueObjects> <allowedValues> <entry>10</entry> <entry>20</entry> <entry>30</entry> <entry>40</entry> <entry>50</entry> <entry>60</entry> </allowedValues> <objectNames> <entry>Boorden</entry> <entry>Baksteen</entry> <entry>Cement</entry> <entry>Liggers</entry> <entry>Isolatie</entry> <entry>Buizen</entry> <entry>Plaaster</entry> <entry>Dakpan</entry> </objectNames> <objectImageUrls>
<entry>http://osma.phl.be/drupalCMS/xml%20templates/objectimages/Boards_THUMB.p
ng</entry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/objectimages/Bricks_THUMB.pn
g</entry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/objectimages/Ce
ment_THUMB.png</entry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/objectimages/Girders_THUMB.p
ng</entry>
<entry>http://osma.phl.be/drupalCMS/xml%20templates/objectimages/Insulation_THUM
B.png</entry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/objectimages/MetalPipes_THUM
B.png</entry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/objectimages/Plaster_THUMB.p
ng</entry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/objectimages/RoofTile_THUMB.
png</entry> </objectImageUrls> <autoRestart>true</autoRestart> <autoRestartTime>60</autoRestartTime> <amountRounds>2</amountRounds>
64
<infoTime>60</infoTime> <auctionTime>300</auctionTime> <sellingTime>30</sellingTime> <soldTime>30</soldTime> <feedbackEnabled>true</feedbackEnabled> </component>
FARO COMPONENT
OMSCHRIJVING Dit component is een afgeleide van het bidding component. Dit component kan gebruikt worden om object aan mekaar te verkopen, in een bepaald vast patroon: - Elke speler krijgt random objecten toegewezen - Elke speler krijgt x aantal vragen over de objecten in zijn bezit. Bij een juist antwoord zal het object in
waarde stijgen en krijgt hij een geldbonus - Een object wordt geveild, spelers kunnen bieden - De hoogste bieder wint de veilig - Volgende ronde met een andere verkoper - Scores worden niet enkel op basis van de objectwaarde berekend, maar ook op het overblijvende geld
en en aantal gekochte objecten
VARIABELEN
- alle variabelen van het bidding component
- questionTime (float): tijd om op een vraag over het object te antwoorden
- pointBonus (int): aantal punten dat het object meer waard wordt, indien de speler een vraag over
dat object correct beantwoordt
- moneyBonus (int): geldbedrag dat de speler als bonus krijgt bij het juist beantwoorden van een
vraag over zijn objecten
- baseValue (int): startwaarde van een object
- bonusMultiplier (float): bonusmultiplier bij het berekenen van de winnaar op het einde van het spel.
Bv: Een bonusmultiplier van 1 geeft per object de volledige score (waarden van objecten +
overblijvend geld) als bonus. Dus bij 0 objecten wordt geen bonus gegeven, bij 2 objecten wordt
het dubbele van de score als bonus gegeven, enz.
EXTERNE CONFIGURATIE
65
Voorbeeld template: bidding_faro.xml
Xml structuur <component> <startMoney>5000</startMoney> <startAmountObjects>2</startAmountObjects> <giveUniqueObjects>true</giveUniqueObjects> <assignUniqueValues>false</assignUniqueValues> <allowedValues> <entry>1000</entry> </allowedValues> <objectNames> <entry>Jongetje</entry> <entry>Portret van keizerin Maria-Theresia</entry> <entry>Zelfsportret met de groene hoed</entry> <entry>Aardbeien met champagne</entry> <entry>De studie</entry> <entry>Zelfportret</entry> <entry>Tulpen</entry> <entry>Zestien September</entry> </objectNames> <objectImageUrls>
<entry>http://osma.phl.be/drupalCMS/xml%20templates/faro_images/Jongetje.jpg</ent
ry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/faro_images/Portret%20van%2
0keizerin%20Maria-
Theresia.jpg</entry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/faro_i
mages/Zelfsportret%20met%20de%20groene%20hoed.jpg</entry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/faro_images/Aardbeien%20met
%20champagne.jpg</entry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/faro_images/De%20studie.jpg
</entry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/faro_images/Zelfportret.jpg</e
ntry> <entry>http://osma.phl.be/drupalCMS/xml%20templates/faro_images/Tulpen.jpg</entry
> <entry>http://osma.phl.be/drupalCMS/xml%20templates/faro_images/Zestien%20Septe
mber.jpg</entry> </objectImageUrls> <autoRestart>true</autoRestart> <autoRestartTime>60</autoRestartTime> <amountRounds>1</amountRounds> <infoTime>60</infoTime> <auctionTime>60</auctionTime> <sellingTime>30</sellingTime> <soldTime>5</soldTime> <feedbackEnabled>false</feedbackEnabled> <questionTime>30</questionTime> <pointBonus>50</pointBonus> <moneyBonus>100</moneyBonus> <baseValue>1000</baseValue> <bonusMultiplier>1</bonusMultiplier> </component>
FEEDBACK COMPONENT
OMSCHRIJVING
66
Dit component kan na het multiplechoice en bidding component gebruikt worden om peerfeedback
te vragen aan de medespelers. De spelers moeten elke andere speler een score toekennen op een
bepaalde statistiek.
Wanneer dit component gestart wordt door het multiplechoice of bidding component, kan hij met
een osma_next signaal de volgende ronde van dat component laten starten.
VARIABELEN
- statTitles: een array van statistieken waarop de spelers een score moeten geven
o entry (string): naam van de statistiek
- scoreIds: een array van scoreIds. Deze worden gebruikt om de gegeven feedback terug te
posten naar de backend. Hiervoor zijn de overeenkomstige scoreIds nodig waarop deze
feedback invloed moet hebben.
o entry (string): een geldige score id
- peerfeedbackTime (int): hoelang mogen spelers feedback geven
- peerfeedbackResultTime (int): hoelang mogen spelers de resultaten van feedback
bekijken
EXTERNE CONFIGURATIE Voorbeeld template: feedback_bidding.xml
Xml structuur
<component>
<statTitles>
67
<entry>Overtuigingskracht</entry>
<entry>Onderhandelen</entry>
</statTitles>
<scoreIds>
<entry>score1</entry>
<entry>score2</entry>
</scoreIds>
<peerfeedbackTime>30</peerfeedbackTime>
<peerfeedbackResultTime>10</peerfeedbackResultTime>
</component>
COMBINATOR
OMSCHRIJVING
De combinator dient om te controleren of een bepaald aantal waarden geactiveerd zijn, waarna
eventueel een osma_start signaal kan uitgestuurd worden. Dit wordt gebruikt bij alle stoelen in de
games. De clicktrigger op deze stoelen sturen via hun eigen combinatorInput een setChannel (met
een bepaald kanaal nummer) signaal naar een gezamelijke combinator. Dus wanneer op elke stoel
een speler zit, is aan de voorwaarden van de combinator voldaan, en zal deze op zijn buurt het
game starten.
VARIABELEN
68
- channels: een array van bool waarden. Het aantal geeft aan hoeveel bool waarden (aantal
kanalen, bv stoelen) voldaan moet worden
- combinationType: AND of OR. In het geval van AND wordt een signaal uitgestuurd
wanneer alle kanalen geactiveerd zijn, bij OR is dit wanneer een enkel kanaal
geactiveerd is
- osmaComponents: een array van osma componenten waarnaar een signaal gestuurd moet
worden
- startComponentsOnAllow (bool): stuur een osma_start signaal als aan de combinator
voldaan is
- stopComponentsOnDeny (bool): stuur een osma_stop signaal als niet aan de combinator
voldaan is
- stopComponentsOnDenyAfterAllow (bool): stuur een osma_stop signaal als niet aan de
combinator voldaan is, wanneer ervoor de combinator wel geactiveerd was
- resetAfterStart (bool): zet alle kanalen op inactief wanner
OSMA ACTIE COMPONENTEN
OSMA_ACT_GAMELINK
OMSCHRIJVING
Dit component kan gebruikt worden om de gebruiker een ander game te laten laden (bv in de
centrale ruimte).
VARIABELEN
- goStraightToURL (bool): moet deze Game Link de browser doorverwijzen naar een andere
url?
- goToURL (string): naar welke link moet de browser gaan (Het doorverwijzen gebeurt door
het aanroepen van een javascript functie in de huidige webpagina. Deze moet GoToUrl
heten, een string parameter ontvangen, en deze gebruiken om een browser redirect uit te
voeren)
- openNewUnity3dFile (bool): moet een nieuw unity3d bestand geladen worden bij het
starten van dit component?
69
- unity3dFilepath (string): het pad naar het te laden unity3d bestand
EXTERNE CONFIGURATIE Voorbeeld template: gameLink.xml
Xml structuur <component> <goStraightToURL>false</goStraightToURL> <goToURL>http://urlToGoTo</goToURL> <openNewUnity3dFile>true</openNewUnity3dFile> <unity3dFilepath>http://pathToNewUnity3dFile</unity3dFilepath> </component>
OSMA_ACT_CHANGECAMERA
OMSCHRIJVING
Dit component kan gebruikt worden om de camera op een vaste plaats to positioneren. Dit wordt bv
gebruikt in het faro game, zodat iedereen hetzelfde beeld heeft op de veiling.
VARIABELEN
- position (transform): de plaats waar de camera komt te staan. Deze is statisch
OSMA_ACT_CLICKTRIGGER
OMSCHRIJVING
Dit component kan op een gameobject (met een collider) gezet worden, om een osma_start signaal
uit te sturen wanneer op de collider geklikt wordt. Dit wordt bv gebruikt op de deuren, waar de
clicktrigger in verbinding staat met een gamelink, of op de posters waar ze in verbinding staan met
het slideshow component.
70
VARIABELEN
- sendStartOnClick (bool): moet er een osma_start signaal uitgestuurd worden als op de
betreffende collider geklikt wordt
- osmaComponents_start: array van osma componenten waarheen een start signaal
gestuurd wordt
- sendStopOnClick (bool): moet er een osma_stop signaal uitgestuurd worden als op de
betreffende collider geklikt wordt
- osmaComponents_stop: array van osma componenten waarheen een stop signaal gestuurd
wordt
OSMA_ACT_COLLISIONTRIGGER
OMSCHRIJVING
Dit component kan osma_start signalen uitsturen wanneer de speler in aanraking komt met de
betreffende collider. Dit wordt gebruikt op alle stoelen in de games. Wanneer de speler tegen een
stoel loopt, zal hij gaan zitten. Wanneer de speler de collider verlaat, kan ook een signaal verstuurd
worden.
Daarnaast stuurt dit component een setPlayer signaal uit om bv de betreffende speler door te
sturen naar het multiplechoice of bidding component.
71
VARIABELEN
- osmaComponentsOnEnter: array van osma componenten waarnaar een signaal gestuurd
wordt bij het binnenkomen van de collider
- osmaComponentsOnExit: array van osma componenten waarnaar een signaal gestuurd
wordt bij het verlaten van de collider
- sendStartOnEnter (bool): stuur een osma_start signaal bij het binnenkomen van de
collider
- sendStartOnExit (bool): stuur een osma_stop signaal bij het verlaten van de collider
- sendSetPlayerOnEnter (bool): stuur een osma_setPlayer signaal bij het binnenkomen van
de collider
- sendSetPlayerOnExit (bool): stuur een osma_ setPlayer signaal bij het verlaten van de
collider
- sendStopOnEnter (bool): stuur een osma_stop signaal bij het binnenkomen van de collider
- sendStopOnExit (bool): stuur een osma_ stop signaal bij het verlaten van de collider
OSMA_ACT_COMBINATORINPUT
OMSCHRIJVING
Dit component wordt gebruikt om een bepaald kanaal van een bepaalde combinator te activeren.
Dit wordt bv gebruikt op elke stoel, waar een elke collisiontrigger via een combinator input een
signaal stuurt naar een combinator om het spel te starten eens alle stoelen bezet zijn.
VARIABELEN
- osmaCombinators: de osma combinators wiens channel geactiveerd moet worden
- combinatorChannel (int): nummer van het kanaal dat geactiveerd moet worden
72
OSMA_ACT_MOUSEICON
OMSCHRIJVING
Dit component kan op een gameobject geplaatst worden om ervoor te zorgen dat een bepaald
muisicoon getoond wordt wanneer de muis over het object beweegt.
VARIABELEN
- hoverIcon: het icoon dat getoond moet worden
OSMA_ACT_PLAYERANIMATION
OMSCHRIJVING
Dit component kan gebruikt worden om een bepaalde animatie van de avatar te laten afspelen. Na
de animatie kan eventueel een osma_start signaal uitgestuurd worden.
VARIABELEN
- animationName (string): de naam van de animatie die afgespeeld zal moeten worden
- moveToLocationFirst (bool): voor de animatie afgespeeld moet worden, de avatar eerst
verplaatsen
- animationLocation (transform): de plaats waar de animatie afgespeeld moet worden
- startComponentAfterAnim (bool): als de animatie afgelopen is een osma_start signaal
uitsturen
73
- osmaComponents: array van osma components waarnaar een osma_start gestuurd wordt
SLIDESHOW
OMSCHRIJVING
Slideshow is een component voor het weergeven van een afbeelding popup formulier. Dit wordt bv
gebruikt om informatie achter de posters in de VDAB lobby te hangen.
VARIABELEN
- Url (string): url naar de image xml file die ingeladen moet worden bij het actieveren van
de slideshow component
- showCloseButton (bool): moet er een sluitknop getoond worden op het
afbeeldingsformulier
- isDraggable (bool): mag het formulier verplaats worden
- maxHeght (int): maximum hoogte van de afbeelding (indien te groot wordt deze
geschaald)
- maxWidth (int): maximum breedte van de afbeelding (indien te groot wordt deze
geschaald)
- position (vector2): een specifieke plaats waar het formulier geopend moet worden
- centerForm(bool): centreer het formulier (dit override de positie)
BACKEND COMMUNICATIE
Naast de mogelijk externe configuratie van enkele componenten, kan er ook nog andere
communicatie plaatsvinden tussen de games en het OSMA gameconfig systeem.
AVATAR
OMSCHRIJVING Vraag de samenstelling van de avatar van een bepaald userId op. Hierin wordt omschreven welk model
gebruikt wordt voor da avatar en welke textures op elk deel toegepast zijn.
74
AANVRAAG VARIABELEN
User id
ANTWOORD Voorbeeld template: avatar.xml
Het antwoord bevat de volledige samenstelling van de gebruiker zijn avatar:
modelName (string): de naam van het avatar model
materials o hair (string): de naam van de texture voor de haren
o head (string): de naam van de texture voor het hoofd
o body (string): de naam van de texture voor het bovenlijf
o legs (string): de naam van de texture voor het onderlijf
o feet (string): de naam van de texture voor de voeten
Xml structuur <avatar> <modelName>Man1</modelName> <materials> <hair>male01_hairstyle1_brown</hair> <head>male01_headhands</head> <body>uv_male02_top</body> <legs>uv_male02_pants</legs> <feet>male01_shoes</feet> </materials> </avatar>
GOAL
OMSCHRIJVING Vraag het doel van de user op, afhankelijk van het ingestelde userId.
AANVRAAG VARIABELEN
User id
ANTWOORD Voorbeeld template: goal.xml
Het antwoord bevat het doel van de user (eventueel uitbreidbaar naar meerdere doelen): goal (string): het doel van de user
Xml structuur <goals>
75
<goal>Dit is jouw doel</goal> </goals>
NPC TEKST
OMSCHRIJVING Vraag een bepaalde npc tekst van een bepaalde game. Deze aanvraag wordt door een NPC gedaan, als
antwoord moet een dialoog teruggestuurd worden.
AANVRAAG VARIABELEN
Dialoog naam
Game id
ANTWOORD Voorbeeld template: dialog.xml Een dialog bevat meerdere entries, die op zich gedefinieerd zijn door:
actor (string): de spreker
content (string): de tekst
order_nr (int): de volgorde van deze entry
duration (float): de lengte van de zin in seconden
XML STRUCTUUR <dialog> <entry> <actor>npc1</actor> <content>Wel, wat een mooie zin heb jij</content> <order_nr>3</order_nr> <duration>5.554</duration> </entry> <entry> <actor>player</actor> <content>Zozo, en dit is de mijne</content> <order_nr>2</order_nr> <duration>6.998</duration> </entry> <entry> <actor>npc1</actor> <content>Hoi, dit is mijn eerste zin</content> <order_nr>1</order_nr> <duration>3.998</duration> </entry> </dialog>
76
GAMESERVER
OMSCHRIJVING De client vraagt het server ip en poort nummer waar de gameserver beschikbaar is voor dit type game,
zodat de client hierop kan aansluiten. Hiermee kan de gameserver applicatie eventueel van machien (en
dus IP) veranderd worden, zonder dat er een nieuwe client build gemaakt moet worden.
AANVRAAG VARIABELEN
Game id
ANTWOORD Voorbeeld template: server.xml
Het server adres wordt bekomen door: ip (string): ip van de gameserver
port (int): poort waarop de gameserver draait
Xml structuur <server> <ip>172.16.101.61</ip> <port>25001</port> </server>
SLIDESHOW AFBEELDING
OMSCHRIJVING De slideshow component vraag de volgende afbeelding.
AANVRAAG VARIABELEN
game id
slideshow id
ANTWOORD Voorbeeld template: image.xml
77
Het antwoord bevat een url naar de gewenste afbeelding: url (string): url naar afbeelding
Xml structuur <image> <url>http://osma.phl.be/drupalCMS/xml%20templates/fotos/foto1.jpg</url> </image>
STATS
OMSCHRIJVING Vraag de statistieken van de speler op, afhankelijk van het ingestelde userId.
AANVRAAG VARIABELEN
User id
ANTWOORD Voorbeeld template: stats.xml
De stats bevatten alle statistieken van een user, per statistiek is dit: name (string): de naam van de stat
score (int): huidige score op deze stat
Xml structuur <stats> <stat> <name>stat1</name> <score>0</score> </stat> <stat> <name>stat2</name> <score>5</score> </stat> </stats>
APPENDIX 2: OSMA REST INTERFACE
78
REFERENCES
http://drupal.org/node/1070066: Communicating with a remote API, implemented as a Services 3.0
REST Resource
http://drupal.org/node/783254:Working with REST server
GENERAL REMARKS
- For testing purposes, we use the REST client or POSTER plugins for Firefox.
- In terms of authentication, the Firefox plugins can be tested by first logging into the site.
This will then create a session for the particular user-agent, over which other requests can
be performed.
- In the API documentation, some php code has been added, as example code.
- Appending .json .xml or .yaml will change response format accordingly.
- The fields in a node can be seen by hitting the "devel" button on any node instance. This
helps to know what data needs to be sent in order to create/update a content type.
- In Drupal, paswords are sent un-encrypted over http. In order to have more secure
connections, we would recommend using https.
AUTHENTICATION
GENERAL DOCUMENTATION
http://drupal.org/node/910598
PROTOCOL
HTTP POST
URL
http://SERVERPATH/rest/user/login
HEADER
application/x-www-form-urlencoded
REQUEST DATA
username=USERNAME&password=PASSWORD
RESPONSE DATA
If the user is already logged in, the username is returned as part of the status code.
79
To create the session cookie that goes into the header "cookie" field for an HTTP request :
function login($url,$username,$password)
{
$request_headers = array();
$credentials = array(
'name' => $username,
'pass' => $password,
);
$credentialsData = http_build_query($credentials, '', '&');
var_dump($credentialsData);
$response = drupal_http_request($url . '/user/login', $request_headers,
'POST', $credentialsData);
$response = json_decode($response->data);
return $response;
}
$loginResponse = login($url,'testUser','test');
CREATE A NODE
PROTOCOL
HTTP POST
URL
http://SERVERPATH/rest/node
HEADER
content-type : application/json
DATA
fid would come from first saving an image as described above.
JSON encoded data example :
{"node":{"type":"game","title":"services
test","field_ip_address":{"0":{"value":"192.168.0.1"}},"status":"1"}}
80
GET A NODE
PROTOCOL
HTTP GET
HEADERS
unspecified
URL
http://SERVERPATH/ag/rest/node/<nid>
URL MODIFIERS
Appending .json .xml or .yaml will change response format accordingly
LOG OUT - CLEAR SESSION
PROTOCOL
HTTP POST
URL
http://SERVERPATH/rest/user/logout
REQUEST DATA
none
RESPONSE DATA
NODE INDEXES
PROTOCOL
HTTP GET
URL
http://SERVERPATH/rest/node
REQUEST DATA
For example,
http://SERVERPATH/rest/node?fields=nid,title,type¶meters[type]=game
81
Gets the nid, title and type fields of all nodes of type "game"
There's also a page argument, specifying "Page number of results to return (in pages of 20)."
URL MODIFIERS
Appending .json .xml or .yaml will change response format accordingly.
UPDATES
PROTOCOL
HTTP PUT
URL
http://server_path/rest/node/
HEADER
content-type : application/json
UPLOAD AN IMAGE OR FILE
PROTOCOL
HTTP POST
URL
http://SERVERPATH/rest/file
HEADER
content-type : application/json
DATA
As the JSON request contains binary data, any request would be too large to print. A better
approach would be to provide the PHP code so the logic can be ported to other languages.
Build the JSON encoded file object. Some php code to generate the JSON :
function buildFile($filePath)
{
$data = array(
'file' => array(
'file' => base64_encode(file_get_contents($filePath)),
'filepath' => 'sites/default/files/images/'.$filePath,
82
'filename' => $filePath,
'filesize' => filesize($filePath),
'timestamp' => time()
)
);
$returnData = json_encode($data);
return $returnData;
And for the actual request, the following function could accept the data that was returned from the
buildFile function.
The function uses durpal_http_request, but curl could be used instead.
$auth_cookie is the result of the authentication procedure, as documentent in the login section of
this page.
function buildFile($filePath)
{
$data = array(
'file' => array(
'file' => base64_encode(file_get_contents($filePath)),
'filepath' => 'sites/default/files/images/'.$filePath,
'filename' => $filePath,
'filesize' => filesize($filePath),
'timestamp' => time()
)
);
$returnData = json_encode($data);
return $returnData;
Obtaining a fid (file ID primary key) is done as follows :
function restFileRequest($url, $op, $data,$auth_cookie)
{
$request_headers = array(
"content-type" =>; "application/json",
"cookie" => $auth_cookie
);
83
$request_data = $data;
$request = drupal_http_request($url.$op, $request_headers,'POST',$request_data);
if ($request->error)
print ("error doing http request");
else
return $request->data;
An example request-response would be :
REQUEST
{"file":{"file":"\/9j\/4AAQSkZJRgABAQAAAQABAAD\/7QBYUGhvd}}"
In which the weird string would be a very long one and the result of php :
base64_encode(file_get_contents($filePath))
RESPONSE
["data"]=> string(57)
"{"fid":"18","uri":"http:\/\/localhost\/ou\/rest\/file\/"}"
["headers"]=> array(10) { ["Date"]=> string(29) "Fri,
18 Feb 2011 15:49:49 GMT" ["Server"]=> string(94)
"Apache/2.2.11 (Unix) DAV/2 mod_ssl/2.2.11 OpenSSL/0.9.8l PHP/5.2.9
mod_perl/2.0.4 Perl/v5.10.0" ["X-Powered-By"]=> string(9)
"PHP/5.2.9" ["Expires"]=> string(29) "Sun, 19 Nov 1978
05:00:00 GMT" ["Last-Modified"]=> string(29) "Fri, 18 Feb
2011 15:49:49 GMT" ["Cache-Control"]=> string(25) "post-
check=0, pre-check=0" ["Vary"]=> string(6) "Accept"
["Content-Length"]=> string(2) "57" ["Connection"]=>
string(5) "close" ["Content-Type"]=> string(16)
"application/json" } ["code"]=> string(3) "200"
REGISTRATION : CREATING A USER ACCOUNT
PROTOCOL
HTTP POST
URL
http://SERVERPATH/rest/user/
HEADER
unspecified
84
REQUEST DATA
{"account":{"name":"serviceUser","pass":"test","mail":"[email protected]"}}
RESPONSE DATA
If user already exists : Status code 406
SERVICES USAGE SCENARIOS
A bundle of scenario's for communication between Unity and Drupal, using the OSMA backend REST
API.
CREATE AND AVATAR CONFIGURATION AND ASSIGN TO USER
1. Get player profile id, as described in step 2 and 3 on this page [20].
2. Creating an avatar configuration can be done by following the general procedure for creating a
node [21].
An overview of the fields in the avatar content type can be found at admin/content/node-
type/avatar
{"node":{"type":"avatar","title":"lorem","field_avatar_hair":{"0":{"value":
"lorem"}},"field_user_profile":[{"nid":"473"}],"field_avatar_head":{"0":{"v
alue":"lorem"}},"field_avatar_body":{"0":{"value":"lorem"}},"field_avatar_l
egs":{"0":{"value":"lorem"}},"field_avatar_feet":{"0":{"value":"lorem"}}}}
POST AN ENTRY TO THE GAME LOG
The full JSON structure of a game log node looks as follows :
{"nid":"442","type":"game_log_entry","language":"","uid":"4","status":"1","
created":"1299527298","changed":"1301553662","comment":"0","promote":"1","m
oderate":"0","sticky":"0","tnid":"0","translate":"0","vid":"442","revision_
uid":"3","title":"Hendrerit","body":"","teaser":"","log":"","revision_times
tamp":"1301553662","format":"0","name":"testUser","picture":"","data":"a:1:
{s:13:\"form_build_id\";s:37:\"form-
e09a5d5d942224c6237ed29694f4fac0\";}","field_user_profile":[{"nid":"357"},{
"nid":"338"},{"nid":"359"}],"field_game":[{"nid":"326"},{"nid":"320"},{"nid
":"320"},{"nid":"326"}],"field_game_time":[{"value":"461"}],"field_skill":[
{"nid":"321"}],"field_skill_impact":[{"value":"9297"}],"last_comment_timest
amp":"1301553662","last_comment_name":null,"comment_count":"0","taxonomy":[
],"uri":"http:\/\/dev.dough.be\/osma\/osmaD6\/rest\/node\/442"}
Of this, the following fields are can be used in order to create a new game log entry :
- type : should be game_log_entry
- field_user_profile : should be a node ID for an existing user profile
- field_game : should be node ID of an existing game
- field_game_time : an integer, expressing game time in seconds
- field_skill : should be node ID of an existing skill
85
- field_skill_impact : an integer, describing the change in field_skill
The following JSON data stream would post values to each of these fields :
{"node":{"type":"game_log_entry","field_user_profile":[{"nid":"357"}],"fiel
d_game":[{"nid":"326"},{"nid":"326"}],"field_game_time":[{"value":"3424"}],
"field_skill":[{"nid":"321"}],"field_skill_impact":[{"value":"666"}]}}
UPDATE PLAYER SKILL LEVEL
1. Get skill node ID
Use the Node indexes to obtain user skill for a certain skill name.
For example :
http://dev.dough.be/osma/osmaD6/rest/node¶meters[type]=skill¶meters[tit
le]=Onderhandelingsvaardigheid
Parse the skill node ID, named nid. Skill node ID's could be cached.
2. Get player info
Use Node indexes the to obtain user info for a certain username.
For example :
http://osma.phl.be/gameconfig/rest/user¶meters[name]=tanguy
Parse the user ID, named uid. User ID's could be cached.
3. Get profile id
Use the Node indexes to obtain profile info for a certain uid.
For example :
http://osma.phl.be/gameconfig/rest/node¶meters[uid]=18¶meters[type]
=profile
Parse the profile node ID, named nid. profile node ID's could also be cached, together with user ID.
4. Get full profile object
Using the profile nid retrieved in step 3, use the Node indexes to obtain profile info for a certain
uid. This will produce a complete representation of the profile object, including skill fields and skill
levels.
For example :
http://osma.phl.be/gameconfig/rest/node/465
5. Get the position of the skill node ID in the profile object, returned in step 4
86
In step 4, an XML or JSON is produced.
After parsing this input, an object or array should be available, according to the XML or JSON
parsing methods available in the language in which the response from 4 is parsed.
field_skill should have an array of items. In each item, there is an nid. Find the nid that matches
the skill node ID retrieved in 1 and note the position of the item in the field_skill array.
6. Change the skill level
The skill position retrieved in 5. should now be used to change the skill value in the corresponding
postion of the field_skill_value array. Only values for this array need to be sent.
For example :
HTTP PUT
REQUEST HEADER : content-type:application/json
TO :
http://osma.phl.be/gameconfig/rest/node/465
With JSON data :
{"node":{"field_skill_value":[{"value":"2"},{"value":"20"},{"value":"50"}]}
}
APPENDIX 3: CONFIGURATION RED5
ALGEMEEN
Bron:
http://www.red5guide.com/
http://trac.red5.org/
mappen:
Red5 installaties: gedownloade installaties (hier kunnen ondertussen updates van zijn).
Red5 server incl voicechat app: Red5 server applicatie inclusief de voicechat server webapp binnen
de map Red5\webapps\myApp2.
INSTALLATIE
87
RED5 SERVER
- Download van http://red5.org (we gebruiken hier versie 0.9.1)
- Installeer setup-Red5-0.9.1.exe. Geef tijdens de installatie correct IP en http request port in (meestal 5080).
- Installeer java SDK, en stel de JAVA_HOME syteemvariabele in op de plaats waar de SDK geïnstalleerd is (config > systeem > geavanceerd > omgevingsvariabelen) (in ons geval C:\Program Files\Java\jdk1.6.0_24)
- Start de Red5 service via config > systeembeheer > services > Red5 starten
- Test http://localhost:5080/ om te zien of de Red5 server werkt
Demo‟s testen:
- Installatie folder Red5 > webapps > installer > installer.swf
- Installeer bv SoSample
- Ga naar webapps > root > demos dir
- Start BallControl.swf 2 keer en sluit bij elke instantie aan op server
- Beweeg op een scherm het logo, ander scherm volgt
- Als er een error wordt weergegeven bij het aansluiten op de server moeten enkele instellingen veranderd worden via http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager02.html#118539
- Bij algemene beveiligingsinstellingen (3e tab), altijd toestaan aanklikken, of specifieke toegestane sites ingeven
ECLIPSE
- Installatiefile te vinden op http://www.eclipse.org/downloads/ . Download eclipse IDE voor java EE developers
- Extract naar gewenst pad (best program files)
APACHE ANT
- Download installatie van http://ant.apache.org/ (binary distributions)
- Extract naar gewenst pad (best program files, best dir hernoemen naar ANT voor gemakkelijkheid)
SYSTEM VARIABLES INSTELLEN
- config > systeem > geavanceerd > omgevingsvariabelen
- klik op Path en bewerken (hier zijn verschillende paden opgegeven, gescheiden door een “;”, vervang deze niet, we gaan er bijvoegen)
- Voeg het pad van ANT > bin subfolder toe (in ons geval C:\Program Files\ANT\bin)
- Voeg pad van java JDK > bin subfolder toe (in ons geval C:\Program Files\Java\jdk1.6.0_24\bin)
- Indien JAVA_HOME nog niet is toegevoegd, nieuwe systeem variabele maken met als naam JAVA_HOME, en pad naar de java JDK (niet de bin subfolder, in ons geval dus C:\Program Files\Java\jdk1.6.0_24)
- Nieuwe systeem variabele met naam JAVA_VERSION en waarde de java versie (in ons geval dus 1.6)
88
- Test of ANT system variable werkt door in cmd ant (enter) te tikken. Het programma wordt nu herkend maar geeft wel nog een foutmelding
- Test JAVA_HOME variabele door set java_home (enter) te tikken, het resultaat moet het pad naar java jdk zijn
- Test JAVA_VERSION variabele door set java_version (enter) te tikken, het resultaat moet het versienr van java zijn
SUBVERSION
- Download de Tortoise installatie van http://tortoisesvn.tigris.org/
- Installeer met standaard opties
- …
APACHE IVYDE
- Zoek op de download pagina van http://ant.apache.org/ivy/ivyde/index.html naar de installatie naam + url (die we in eclipse zullen ingeven) (in ons geval: Name: Apache Ivy update site, URL: http://www.apache.org/dist/ant/ivyde/updatesite)
- Open eclipse
- Menu help > install new software > add
- Geef juiste naam en url in > ok
- Selecteer alle packages > next
- Even wachten > next
- I accept license > finish
- Wacht tijdens installatie
SUBCLIPSE
- Kopieer installatie url van http://subclipse.tigris.org/ download pagina (in ons geval http://subclipse.tigris.org/update_1.6.x)
- Open eclipse
- Menu help > install new software > add
- Geef als naam Subclipse in, en url de gekopieerde url van hierboven > ok
- Selecteer alle packages > next
- Even wachten > next
- I accept license > finish
- Wacht tijdens installatie
FLASHBUILDER
(voorheen Flexbuilder, deze is misschien nog te gebruiken?)
- Download de Flashbuilder trial (Flashbuilder is NIET gratis, misschien dat de laatste versie van Flexbuilder ook werkt, deze is wel gratis), kies voor de Eclipse plugin versie
- Start installatie
- Standaard installatie pad mag behouden worden
89
- Bij „select an optional eclipse folder‟, kies voor Plug into anothoer copy of Eclipse, en duid het juiste pad aan (in ons geval C:\Program Files\eclipse)
- Sluit openstaande applicaties af
- Next > install
- Done
- Ga naar eclipse installatie map (C:\Program Files\eclipse), dropins submap. Het bestand com.adobe.flexbuilder.feature.core.nl1.link zou aanwezig moeten zijn.
REG5PLUGIN
- Open eclipse
- Menu help > install new software > add
- Ga naar http://www.red5.org/ klik red5plugin, daar vindt men de red5plugin gegevens. Geef als naam en url in eclipse deze gegevens in > ok
- Selecteer alle packages > next
- Even wachten > next
- I accept license > finish
- Wacht tijdens installatie
- Restart eclipse na installatie
RED5-PLUGIN.BAT EN RED-SHUTDOWN.BAT FIX
- Als het pad naar red5-debug.bat en red5-shutdown.bat spaties bevatten, kunnen deze scripts niet uitgevoerd worden
- Open red5-shutdown.bat met een teksteditor
- Zet dubbele aanhalingstekens rondom %RED5_HOME%\red5.bat, dit wordt dus “%RED5_HOME%\red5.bat”
- Zet onderaan pause, zodat de output van de bat op het scherm blijft
- Save en sluit
- Open red5-debug.bat met een teksteditor
- Zet dubbele aanhalingstekens rondom %RED5_HOME%\red5.bat, dit wordt dus %RED5_HOME%\red5.bat”
- Zet onderaan pause, zodat de output van de bat op het scherm blijft
- Save en sluit
- Dubbelklik red5-debug.bat om te testen
- Dubbelklik red5-shutdown.bat om te testen
RED5PLUGIN MAKEN
Start Eclipse in Java EE perspective (window > open perspective > other > Java EE > ok)
Nieuw project starten:
90
- File > new > dynamic web project
- Projectname: myApp
- Target runtime > new > selecteer Re5 onder Infrared5 > next > default JRE is normaal ok, runtime directory instellen naar de Red5 server directory (in ons geval C:\Program Files\Red5) > finish
- Configuration > modify > Red5 Application Generation aanvinken > klik op runtimes tabblad > Selecteer runtime die we in stap hierboven hebben aangemaakt > ok
- Next
- Next
- Finish
- Use default SDK (normaal currently Flex 4.1) > ok
Er is automatisch een myApp server en client applicatie aangemaakt
Server app:
myApp > Java Resources: src > org.red5.core > Application.java bevat de server code
client app:
myAppClient > src > myAppClient.mxml bevat de client code
Test server app:
- Rechtsklik myApp > Run As > Run on server > eerste keer staat „manually define a new server aan, standard warden zijn ok (Red5 Server runtine, localhost als hostname, server name kiezen, server runtime env zelfde kiezen aan bij aanmaken van project, always use this server when running this project aanvinken) > next
- In elk pad moet het eerste deel, zijnde /Applications/Red5, vervangen worden door de red5 server directory (in ons geval C:\Program Files\Red5). Let hierbij op de slashes, vervang bestaande door gewone slashes (of gebruik browse knop).
- In 2de textbox extensie van red5-debug.sh veranderen naar bat
- In 3e textbox extensie van red5-shutdown.sh veranderen naar red5-shutdown.bat
- Next
- Finish
- Als je volgende error krijgt:
C:\Program wordt niet herkend als een interne
of externe opdracht, programma of batchbestand.
Check dan de stap Red5-plugin.bat en red-shutdown.bat fix onder installatie.
Client app:
- Rechterklik op myAppClient.mxml > run as > web application
- Indien er een waarschuwing verschijnt, rechterklik op de balk “allow blocked content”
Als de test client app geen verbinding kan maken, probeer dit:
91
- Sluit de red5server handmatig af (shutdown.bat), start handmatig terug op, test de cleint app opnieuw (check natuurlijk ook of de server wel in de webapps folder van red5 gebuild is)
Bij een finale build moet de map van de server applicatie in de webapps folder van de Red5 server
terecht komen. Om de flash client te gebruiken wordt aangeraden om voicechat_program.js en
voicechat_interface.js te gebruiken.
AMFPHP
Om vanuit een php script te kunnen communiceren met de Red5 server hebben we AMFPHP nodig.
Op deze manier kunnen we extern via een webpagina de Red5 server beheren.
Dit is momenteel niet gebruikt.
http://flashvisions.com/java/connecting-red5-and-amf-php/
Recommended
