Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Contents
Introduction ....................................................................................................................................................... 2
General remarks ................................................................................................................................................ 2
On the issue of consensus-driven design .................................................................................................. 2
On the development process .................................................................................................................... 2
On the course in general ........................................................................................................................... 3
The 80/20 rule ........................................................................................................................................... 3
Clarity of User Interface and Communication ........................................................................................... 4
The challenges and the games .......................................................................................................................... 5
Challenge # 1 ................................................................................................................................................. 5
!Gravity ...................................................................................................................................................... 5
Individual notes: ........................................................................................................................................ 6
Challenge # 2 ............................................................................................................................................... 10
Animal Factory ......................................................................................................................................... 10
Individual notes: ...................................................................................................................................... 11
Challenge # 3 ............................................................................................................................................... 14
Debate Smash 2008 ................................................................................................................................. 14
Discussion on the process / Individual notes: ......................................................................................... 16
Challenge # 4 ............................................................................................................................................... 19
Total Word Domination ........................................................................................................................... 19
Individual notes: ...................................................................................................................................... 20
Challenge # 5 ............................................................................................................................................... 22
Description of the portfolio ......................................................................................................................... 22
Prioritizing games ............................................................................................................................................ 23
IGDA Demo Night ........................................................................................................................................ 24
Conclusion ....................................................................................................................................................... 25
Literature: ........................................................................................................................................................ 26
1
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Introduction
The following document accompanies four games made during the course Experimental Game Play at ITU,
Copenhagen during the fall of 2008. It contains reflections on the overall development process, the design
decisions made for each game and personal notes from each of the four members of the production team
Pure Fire Interactive, concerning the individual games. Furthermore, a portfolio was created to present the
games and the team members. A description of the portfolio rounds up this document, followed by a
general conclusion about the overall process.
General remarks
First of all, certain reflections concern the overall development process, and not just specific games, are
explained in the subsequent section.
On the issue of consensus-driven design
Even though each team member had roles corresponding somewhat to small team “industry norms” as
described for instance by Byrne (2005), and that these roles did reflect practical responsibilities as well as
areas of personal autonomy, many of the design decisions concerning core gameplay and behaviour was
made more by consensus than by “game designer unilateralism”. We expect this would be the case with
most small development teams, certainly with the ones we have participated in. Even though it could be
argued that such an arrangement somehow “diminishes” the role of the game designer and that it’s not the
“standard practice” in the game industry, we believed that a collective creative effort among a handful of
people (probably not more than that), in the very early stages of development, is to be preferred as it
(depending on a trillion variables) should produce a concept that is rooted in several subjective experiences
of play as well as notions on what constitutes good gameplay. That four individuals, as in our case, can
agree on a concept as potentially playable, enjoyable or delightfully disturbing, suggests that the concept
has a better chance of “making sense” and being slightly more intuitive when put before a larger audience,
than the one-mans-vision might. There is of course a danger in that this approach instead will produce a
game based on the lowest common denominator, and that every novel or innovative feature that doesn’t
resonate with all members of the team gets rejected in favour of more traditional and established features.
That way, instead of producing a solid and lucid game, consensus-driven design will produce a dull,
business-as-usual type game, lacking any of the important “thrills” that can come from an individual and
uncompromising vision. We do not feel, however that this was the case with our designs, instead we
believe that our individual backgrounds, abilities, and philosophical approaches to games as a medium,
contributed on the whole, to some interesting and novel designs with its “freshness” still intact.
On the development process
As the schedule for all the teams productions was indeed tight, and as the focus was more on producing
experimental and interesting games and ideas, not a lot of effort was dedicated to setting up and following
traditional development models like the one described by Fullerton, Swain & Hoffman (2004: p 348) that
require a Concept- Pre-production- Production- Q&A- and Maintenance phase. According to this scheme,
we probably rarely got beyond the pre-production phase that, following Byrne (2005), is often used to build
a working prototype, enabling publishers to evaluate the game concept and decide whether or not to fund
2
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
a full scale game.
We applied something along the lines of a very fast-paced scrum approach, were the team worked in a
fairly informal way, mainly synchronously in the same space, so that the numerous things that came up
during the process was discussed and solved in plenum almost instantly. On a practical level, code and
game assets where handled through Assembla1, to enable asynchronous work outside of the scheduled
group-session, as well as keeping track of progress and modifications.
As a consequence of, what we believed to be, the scope and agenda of the course, and the often tight
deadlines accompanying it, some things were prioritized higher than others. Among the tasks that often got
assigned till later in the process, was Q&A and especially playtesting. We aimed, as a minimum, to perform
– internally among other members of the course – playtests on our games to at least establish whether it
was playable and understandable at all, but often time did not permit us to really act on the information we
received.
On the course in general
A few remarks can be made as to the content and structure of the course itself.
Regarding the challenges, we felt it mirrored a broad range of interesting features about games and game
design in particular, and was successful in forcing us to think about our work in a different way from the
common approach. When required to take into consideration these sometimes quite conflicting
requirements that had to be present in the games in some way, you do tend to also revise more established
design practices and asses why they do, or do not, work. We also felt that, the more restrictive the
challenge was, the more creative we went about solving it, certainly the sheer number of concepts
proposed was higher with the first challenge, but other things could naturally be the course of this.
The structure of the course (5 challenges, 3-4 weeks pr. challenge) meant that, what we are essentially
producing is concepts and prototypes. This was an enjoyable, if sometimes a little stressful, way to work,
and a good way to add a decent amount of games to your CV in a short time, but it does not fully support
the more common development process in “the real games industry”, where it seems most of the time is
dedicated to balancing miniscule sub-sections of the game, and not to be creative, adventurous and “largescale involved in the product”. The question remains though, if this is ever possible – or even desirable – to
somehow model in an educational institution like the ITU, probably it wouldn’t make for a very “academic”
course. This is not as such a critique, but more of a reflection of the possibility to have a course that was
intended to be the opposite of Experimental Game Play.
The experimental emphasis we felt where a part of the course structure, obviously also had a way of
manifesting itself in the way the team worked, as mentioned elsewhere, mainly through the less
structured, formal and more dynamic way of approaching group work and team roles.
The 80/20 rule
One of the more general conclusion that applies to most if not all our games, is that the subjective
experience of actually playing them haven’t received the attention one could want, or put differently, that
any quality associated with the experience of play largely remains to be proved. The playtests performed
on each game was usually few, informal and done with fellow students. While we ourselves believe to have
1
http://www.assembla.com/. This platform served to host code, assets, game prototypes, reflections and designs.
3
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
been persistently successful in delivering a working prototype/game that demonstrated the concept we set
out to explore, the goal of getting 80% of the work done in 20% of the time – so that the remaining 80% of
production time could be dedicated to polishing and tweaking the last 20% of the game – was likewise
consistently never achieved. While we could possibly be excused given the scope and focus of the course,
we are well aware of the problems and flaws that will arise as a consequence of this, if we were to build a
“real game”, like the ones associated with the lack of meticulous Q&A and playtesting.
Clarity of User Interface and Communication
On the subject of general and less positive issues with our games, we can also conclude that getting that
perfectly intuitive and lucid UI was something we would often have to leave for later in the process. As a
result of this, and the limited time available, we often ended up with games that internally worked
according to plan, but often required us to do a lot of explanation when people were to play the games.
Needless to say, this was unsatisfactory to us, and we did try to handle some of the worse cases during the
very final moments of, what might be considered “post-production”.
4
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
The challenges and the games
Challenge # 1
!Gravity
Challenge: A game that relies on only one button for input.
The team had a lot of different ideas as to how to implement the one-button mechanic – a Formula 1 game,
a CO2 game and a drunken movement game, all relying on a single input source.
Figure 1. Concept drawings for 1st challenge. To the left, a racing game and to the right a C02-quota cloud
controlling game.
However, with most of these concepts, we felt that the one-button-element was put “on top” of good
ideas, rather than it being central to the design. In many examples we tried to delegate a lot of complex
navigation mechanics to a single button, but finally landed on the idea of just using the one button for one
specific action. Thereby we aimed at a very binary experience, one we believed was in greater harmony
with the challenge, while also being a bit more intuitive for players.
The design we eventually landed on consisted of a 2d level, with a “non-player” avatar that moves from left
to right autonomously through the level. Eventually the avatar will hit objects or wall and either shift
direction or die. The only way of negotiating the level was for the player to flip it around the horizontal axis.
The prototype itself was not put through a lot of iterations. Instead, after ensuring that the operation using
the SPACEBAR to flip the level was correct and intuitive, efforts to shape the game as a “fun”, interesting
and challenging experience, was put into level design.
The process of doing level design for !Gravity required:
Lots of paper prototypes
Patience, as it was difficult to get your head around at first
To be very conscious about learning curve of players
A focus on intentional confusion and surprise as design features
Overall, doing level design in two opposite perspectives at the same time proved to embody a steep
“learning curve”, and many sheets of paper was employed and scrapped. Eventually a custom level editor
was developed for the game which made evaluation-based iterations on the level design much easier.
5
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Theme: The theme came after the core gameplay, and the ambition was to establish a context wherein it
would be less surprising that you could actually flip the entire game world. After discussing it, we
(particularly among the artists) decided that a religious/spiritual theme might work, and settled on
orthodox iconography and the description of the different circles of hell by Dante in his divine comedy.
Even though it could be argued that the theme itself does not as such suggest a specific type of gameplay,
thus assisting the player in actually playing the game, we felt that the theme and the way we tried to
implement it, did have a positive effect on the playing experience. At the minimum, we reflected
afterwards that it did not sabotage or confuse the core gameplay.
Individual notes:
Alex Hartfelt: My tasks and responsibilities for this game was, besides game design – which, as mentioned
previously, was handled largely as a collective effort – mainly focused on the level design as well as
thematic issues like graphics, music, & sound. Concerning the last, an original musical background track was
created for the game. This was done by firstly writing a short poem about escaping the horrors of purgatory
(of which the wording has disappeared), translating that into Latin using an online (and semi-correct)
translation tool, and then dubbing a huge number of tracks, attempting the style of a monk-choir. After a
heavy dose of big room reverberation, I believe the track is pretty successful in communicating the arcane,
‘holy’ aesthetic central to the theme of the game. While I generally sympathize with the “essentialist”
school of viewing games as mainly being about rules and mechanics –in line with for instance Salen &
Zimmerman (2004) – I do not consider myself enough of a “puritan” to completely disregard these
elements as significant in the experience of games.
In addition I also worked a little on the wording and the visual foundation of this game, how to formulate
the goals and events of the game in some form of arcane, mystic manner. This is mainly present in the
menu system, regarding the different introduction-, win- and loose-screens.
Patrick Jarnfelt: This was the first game we developed for this course and it was therefore on this challenge
that the fundamental code base was set up. We had to decide on the programming environment we
wanted to develop the rest of our games in. The choice fell on Flash and Actionscript 3, which we felt would
be a good and easy environment to develop in, given the time constraints of the challenges. It was also the
choice since both the programmers had previous experience with this tool. Another benefit of choosing this
environment was that it would be easily distributable, since the market penetration of Adobe Flash Player
version 92 was 98 %3 in the European market.
In order to develop our game concept, described previously, we also needed to have some simulation of
gravity and some collision detection. We could have programmed these ourselves as, we know other
groups have done, but we felt that the physics engine market for Actionscript had matured enough for us
to use in our games. However, we did not have any experience in this field so a lot of research and testing
was required. I downloaded and tested a lot of physics engines, and only one felt intuitive to use and had
the required physics method implemented. This engine was the APEngine – Actionscript Physics Engine – in
short APE4. This physics engine was not perfect either. It has a lot of minor flaws and is not developed upon
any more. But the ease of use together with the fulfilled requirements made this the best choice. Later we
2
Adobe Flash Player 9 was the version chosen
http://www.adobe.com/products/player_census/flashplayer/version_penetration.html
4
http://www.cove.org/ape/
3
6
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
discovered that this engine has a branch (someone else is developing it further) that has fewer flaws and a
lot of new cool features that would have made our development easier, but we did unfortunately not know
this beforehand.
For the first challenge we had the idea that the world should flip. We would like the entire canvas to rotate
along an imaginary horizontal line to give the illusion of flipping a 2d world. In order to do this we needed
to rotate the 2d canvas along the y-axis in 3 dimensions. Since Flash Player 9 does not have a 3 dimensional
space5 we needed to implement a 3D engine. Also here there was a big market of engines. However our
choice fell more or less on the one we had heard most about, and since we should not implement a lot in
3d any engine would suffice. The choice fell on Papervision3D.
Other than all of the initial work, I used a lot of time implementing it all together with a working player that
could collide in a cave like world.
Sebbe Selvig: My primary responsibility in this game was programming the game. As previously mentioned,
this was the first game created in the course, so Patrick and I worked a lot with new technology. We
implemented the 2D physics engine APE for the first time, as well as the 3D visuals engine Papervision.
These made development of the game features a lot easier, and proved to be a good investment of time, in
the games created later.
Because of the introduction of new technology, as well as our first chance to get our hands dirty in
ActionScript 3.0 development, the main effort was put into learning in regard to advanced game code.
For this challenge a level editor was produced to make level creation much, much easier. It was created
with ActionScript 2.0 as we had a better knowledge of this language at the time. This helped the game
designers a lot and made the pressure on the programmers shoulders a lot lighter as we didn’t have to
schedule time for hard-coding the level design every time the designers had come up with a new idea.
The !Gravity was a great success in regard to fast adoption of new technology as well as a great design of
the one-button game mechanic. My personal opinion is that we managed to fulfill all the criteria of the
challenge in a well thought through way. We could have iterated more on the idea, but with the timeframe
given, the time was better invested in learning the technology and pushing game play features.
5
Flash Player 10 has a 3 dimensional space that would have sufficed for our purposes, but since that player was not in
full release at the moment and the market penetration was much smaller for that player (se previous footnote for
specific numbers), we chose to keep going with the flash player 9. See
http://www.airtightinteractive.com/news/?p=114 for comparison of Flash Player 10 vs, Away3d (another 3d engine
for flash)
7
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Figure 2. Screenshot of the !Gravity Level Editor implemented in Flash 8 & ActionScript 2.0.
Dajana Dimovska: Besides my contribution to the brainstorming and game design my main responsibilities
were working together with Alex on the thematic issues of the game as well as visual design and
implementation of the level designs. As mentioned before we settled down on the a religious/spiritual
theme and Dante’s Hell representation from his book “Inferno” which purpose was to inspire the visual and
audio style of the game and enhance the player experience. Before designing the graphics, I did research
which included reading about Dante’s description of the feelings in each circle of hell6 and analyzing some
of the William Blake’s art that represents Dante’s circles of hell7. The theme we chose is very dark, cold and
painful, but since we are dealing with a simple one-button mechanic where one controls only the gravity in
the world which is not as realistic and serious a concept, I decided to design visual style which
6
7
http://en.wikipedia.org/wiki/The_Divine_Comedy
http://en.wikipedia.org/wiki/William_Blake
8
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
corresponded with the music and sounds created by Alex which created a slightly humorous approach to
the theme. Other important tasks that I worked on during the development of this game was implementing
the level and level graphics in the level editor and testing the level design playability in the game. The level
design was preliminary done as a paper prototype, which worked very well and made my work easier
because I had a reference about what to implement. But very soon I realized that some design
improvements had to be done in order to translate the paper level design into a playable and fun !Gravity
level. However, with a couple of iterations and tests internally in the group we managed to deliver a
vertical slice of a game that shows its potential.
I would like to mention here that while my main interests and skills are in the areas of game design and
game programming, I chose to take responsibilities about most of the visual and interface design and its
implementation, mainly because we didn’t have an artist in our team but also because I wanted to learn
more about this section of game development, by actually doing it.
9
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Challenge # 2
Animal Factory
Overall:
The challenge, or the restriction, of this game was to make a multiplayer, cooperative game, but one where
an individual winner could be found. One of our guidelines for approaching it was the intention of having
this potentially problematic dynamic being present throughout the entire gameplay, so to avoid the sense
of breaking the game into two sections; that it was cooperative until a certain point where it would all
change and become dog-eat-dog.
We thought of a couple of different ways to implement this:
Tank-driver & Tank-gunner, where each player would have to deal with specific tasks, that had to be
performed in order for the game to continue. In this sense, the two players rely on one another to sustain
gameplay, but are at the same time involved in serving their own interests. The immediate problem we felt,
in relation to the challenge, was that there was no real difference between serving the common good, and
serving individual interests, and that we therefore would lose some of the potential interesting conflict
potential of the game.
Dr. Jekyll & Mr. Hyde, where two players fought over the control of the main character, while accepting
that there were certain tasks that could only be performed by the other player. This embodied the conflict
of interest that we aimed for, but meant that we in practice had to implement four different types of
gameplay; two states for each player. This idea seemed to have a lot of potential, but was rejected for
these practical issues.
Multi-user avatar/Siamese twin game, where the two players where controlling one half of a common
avatar, and had to pick up items giving just one player points, while avoiding getting to far away from each
other, which would mean that the avatar was ripped apart and died. Again, the agenda was intact, but from
building, and playing with, the prototype we learned that the “fun” (this word is consistently put in quotes
just to emphasize that no-one, including us, know what it means8) wasn’t that high. As Eric Zimmermann
(2003) suggests in his discussion of iterative design, we used the prototype to ask question about the
direction of the design, or to quote him: “…questions emerged out of the process of design” (Ibid, p 184).
We then decided – probably contrary to Zimmerman’s idea that the outcome of prototyping, testing and
analyzing (Ibid) should be a mere refining, and not the more severe change – to introduce the passing of
things among the two players.
A prototype of this last concept eventually changed into the Sausage Factory (later to be renamed Animal
Factory) game, and kept – one reason being that it simply was a lot of ‘fun’ to play.
In Sausage Factory the two players each control a robotic arm in a highly modernized industrial sausage
factory. The arm can move, grab and throw, and the objective is to make a certain amount of sausages
using the two kinds of animals in the factory, cute little rabbits and cute little chickens.
The cooperative element is present in the fact that you have to make good throws to your ‘fellow robot
arm’ in order to complete the different levels, which are build up around an increasing threshold of animals
that have to be grinded.
8
As an example of the ambiguous nature of the concept, Nicole Lazzaro (2004) lists four different types of “fun”,
based on her empirical research. Even with such attempts to exhaust the term, it’s still difficult to approach essentially
“what it is”, and how players experience it, and not least how we, as designers, create the basis of it.
10
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
The individual winner can be determined by the performance of the arm, as good and productive actions
give positive performance points, while bad ones like dropping animals, or putting them in the wrong
grinder gives negative performance points. When one of the arms has been consistently poor and has used
up all the performance points, the arm is shut down and the other player wins. Eventually you can also win
if the different levels are all completed and you have the highest performance score. This was never
implemented though.
Unlike the previous game, some time was devoted to balancing our prototype, while occasionally adding
new features to the core gameplay. In this sense, the process was much more iterative than with !Gravity.
Individual notes:
Alex Hartfelt: Again, counting the collective nature of game design, the task I performed in this game was
mainly the Audio. The sound serves a couple of different purposes, first of all to ground the experience of
playing more in the physical world, secondly to enhance the enjoyment of performing these bizarre actions
(positive reward for killing innocent small animals), and finally to establish a sense of absurdity (mostly
through the easy-listening Bossa accompanying the slaughter).
This last bit was personally significant to me, being vegan, amongst other things for ‘ethical reasons’, so
everything that would potentially emphasize the bizarre notion of industrialized killing, would seem to
serve my interest. To further advance this, an alternative sound design for the game was made, but
unfortunately not implemented due to time constrains, one that relied only on musical instruments, so
turning the robot arm would be a drum roll, releasing the animals would be a snare drum, the chickens
would sound like a sitar and so on. This was seen as adding a potential absurdity to the actions, while also
being experimental with other game elements than just the gameplay. Eventually, the sound settled on
accentuates the activities in a more cartoonish and “silly” way, for instance with loud booms and over-thetop grinding sounds.
Sebbe Selvig: This game featured the physics engine implemented in the first game, and therefore already
was much easier to handle. However the gameplay was much more complex and demanded much more of
the code than !Gravity. The code for this game features quite a lot of math to determine when and how an
animal is caught or grabbed from the floor, as well as the angle the animal will be thrown taking into
consideration the speed and rotation of the arm.
It took a lot of effort to adjust the control of the arm, and it would be very helpful to implement some
analogue controls via a game pad i.e. an Xbox or PlayStation controller. But because of flash, we were stuck
with the regular keyboard input which proved to be quite hard to control in an intuitive way for some
players. After some play testing doing polish, we fine-tuned what the arm was possible to catch, and it
improved game play a lot.
In this game we implemented a particle effect for the explosion effect of the animals when the where
passed through the electric field and had their fur or feathers removed. In the case of a sick animal the
animal would disappear and a cloud of black particles would appear illustrating the animal being burned.
The game was polished during the last project period and has been adjusted and made ready for release on
the web. In my personal opinion the game still lacks more clear communication of the co-operative mission
of the game in regard to producing sausages. The players are not necessarily aware of the “playing
11
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
together” part of the game.
The game was showcased at the IGDA Demo Night at the ITU on Thursday December 11th, and it received
good reviews and the other game designer and developers liked the game quite a lot. So with a bit more
work, the game would be a great candidate for release on one of the major flash mini-game sites.
Patrick Jarnfelt: In this challenge I mostly worked on the visual expression of the game and the usability.
Moreover I was involved in the finishing touchups on the game, which meant it had to be completely
playable by anyone on the net and therefore also uploaded on a game host.
The visual style was developed my Dajana and I. We felt that the 8-bit aliased style would contrast the
cuteness of the character and would emphasize the macabre even more in the game play. In order to do
this we only worked with bitmap images, even though it in flash would have been possible to make vector
graphics. Working with bitmap images, animation would have to be with sequential images, meaning that
every frame had to be hand drawn. The chicken had easy animation and was therefore implemented. The
bunnies however were more complicated to animate. Since I am not an animator, these were unfortunately
not implemented.
As I stated before, I also had the pleasure of working with usability. In this game the usability was of utmost
importance, since the game had an extremely high learning curve. The throwing mechanic was very difficult
to master, but also rewarding when mastered. I therefore had to experiment with it so make it easier to
grasp. Another problem with the usability was for the player to understand the motivation behind the
actions he should take and the goals he should pursue. The initial idea was that the players should make
sausages at this factory. Other than giving the players the “mission” text to “make 10 sausages” it was not
apparent for the player what was meant by this. The concept of sausage making should be more apparent.
As the usability guy, I therefore changed the name from Sausage Factory to Animal Factory and removed all
reference to sausages. The user does not know what the factory is there for and knows only his own
immediate goal: To “skin and grind 10 fluffy animals”.
Other than this I worked on implementing the menu system we developed for later games, so we could
upload the game to before mentioned game host: Namely Nonoba.com.
Also, to make the game more enjoyable and feel like a “real game”, I implement a new level, one that was
easier than the initial level, which also helps ease up the learning curve of the game. When you have played
around a bit on this first level, you advance to the next level, which is the one we made in the earliest
phase of production.
Dajana Dimovska: The brainstorm process of this game was long and difficult, as we found it very
challenging and interesting to create a cooperative game with one clear winner in the end. We wanted to
have a game where players are forced to cooperate and play together during most of the game play in
order to achieve good results. However, the long brainstorm paid off in the end and we settled on a
concept that the entire group was very satisfied with. The first main task I was working on in this game was
designing the overall visual style and in-game interface such as icons on the grinders and trash disposal.
Before I started the visuals design process I did some brief research on 2D cute fluffy animals’ art9 since our
desired effect was visually sweet and appealing animals that combined with the slaughtering fabric in over
exaggerated cartoonish style, which will give humoristic atmosphere to the game and will raise awareness
about cruelty towards animals. However, our aim was just to touch upon the issue of cruelty towards
9
http://www.deviantart.com/#
12
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
animals without necessarily conveying any message or pursuing any opinion concerning that issue.
Another task I was working on mainly during the polishing period of this game was the playtest, which was
seen as crucial for delivering the game into a playable state. In this game we struggled with the level design,
which needed many improvements in order to satisfy the challenge stated above. For each iteration I did an
unofficial playtest. The results from the playtest were used as basis for team discussions on possible
improvements in the level design.
13
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Challenge # 3
Debate Smash 2008
Challenge: Formulate a persuasive game.
The following is the preliminary design document for our take on the 3rd challenge, brought here in its
original form10. A discussion of the process is attached after it.
Overview
Two players engage in the 2008 presidential election debates, assuming the roles of either Senator Barack
Obama or John McCain. A series of current policy issues – in the form of iconographic balls – are exchanged
between the candidates, who then respond by selecting the appropriate ideological Bat to hit the ball, thus
returning it.
Argument
The type of discussion that is afforded by a presidential debate is often, rather than being dialectic in
nature, simply a manifestation of where the two candidates hold opposing views. We see these differences
mainly as expressions of ideological differences between the Democratic- and the Republican Party.
Furthermore, we have come to expect – from casually following the US election 2008, as well as other
parliamentary ‘rituals’ – that the main basis for answering questions in debates is the set of ideological
‘tools’ or ‘clichés’ that have been established within these two parties, tools that are used often and appear
to be very stabile.
All this is not so much a critique of the way the US (or indeed any parliamentarian and representative)
political system works, of the way that established ideologies tends to ‘override’ personal convictions and
values, or a claim that following debates between candidates is useless to assess their individual
personalities, charms or favorite causes (if you count such things as important). Rather it should be seen as
an attempt to express – through a videogame – just how often candidates will turn to these pre-defined
‘ideological tools’ when replying to critical questions asked by journalists or political opponents.
Rules
The objective of the game is to win 2 of the 3 debates. The winner of the individual debates is the last
person to have returned the ‘issue-ball’ before the other player fails to return it, or put differently; the
winner is the player that does not loose.
Each candidate has 5 different Bats – ideological tools that can be used to return a number of specific
Issue-balls. An Issue-ball will only be returned if hit with the corresponding ideological Bat.
Once hit with a legitimate Bat, the Issue-ball will change state into one of the other 5 issues.
Game objects
There are 5 different Issue-balls: (the following is just suggestions…)
 Financial crisis
 Welfare policy
10
As we felt a stronger call to formulate the intention of this particular game, and how we imagined the translation
into gameplay would be, this challenge is the only one that has a design document, in the more traditional sense.
Most other games were designed through communication and small notes.
14
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008



Foreign policy / National security
Crime
(more…we need to look closer at the topics raised in the current election)
Barack Obama has the following 5 Bats: (again, just suggestions…)
 State subsidies: Appropriate for Financial crisis and Welfare policy
 Welfare programs: Appropriate for Crime
 International diplomacy: Appropriate for Foreign policy / National security

John McCain has the following 5 Bats:
 Tax reduction: Appropriate for Financial crisis and Welfare policy.
 Long prison sentences: Appropriate for Crime
 Military force: Appropriate for Foreign policy / National security

In addition, each candidate has a Joker-Bat that can be used once during each debate. This bat returns any
ball, no matter the issue.
Mechanics
When a ball approaches one of the candidates, he must quickly decide which bat to respond with. This is
performed by positioning the mouse cursor over the desired bat, clicking and dragging it to collide with the
ball.
Procedural rhetoric
By coupling a claim about the nature of presidential debates with a gameplay that mostly resemble Tennis
or Pong, we hope to establish the notion that these two activities are similar in many respects. By
embedding the argument that candidates almost exclusively use established ideological ‘truths’ in these
debates in the mechanics of choosing specific bats for specific balls, we hope to convey this ‘message’
simply by letting the players interact with the game. It is the hope that playing as one of the senators and
having to think about, for example ‘what might a republican say about this issue’ would be an engaging,
and hopefully also enjoyable, path to forming or changing judgments about the framework in which the
two candidates have to fight for the white house.
Discussion
It could be argued that the gameplay of this game is not, in any radical sense, experimental (we made jokes
about it being a RPG version of Pong). However, for this particular challenge we felt that the coupling of
topic/argument and gameplay was more vital than coming up with totally novel mechanics and rules. It
should be mentioned though, that the game idea itself came after the subject, and not the other way
around. In this sense we have attempted to model presidential discussion through an RPG-Tennis/Pong
game, instead of just choosing a proven game concept (like space invaders or a boxing game) and then skin
it with a political theme, like we have seen – and disapproved of – so many times.
On this note, we should probably also mention that we only landed on this solution after many hours of
15
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
brainstorming on different concepts (Play as the Central Bank of Island and adjust the interest rate
according to inflation predictions, supply US banks with money and observe how the US dollar in- or
decreases in value, and many more) because it seemed to balance an interesting gameplay with a fair
amount of procedural rhetoric. The previous concepts seemed to either have a very strong rhetoric and
pretty dull gameplay, or fun gameplay and not so much of a clear persuasive goal. With this we hope to
land somewhere in the middle.
Changes to the design
Some things was naturally changed along the way, of which one of the more severe ones dealt with the
basic input device and by extension, how the game itself was imagined to be played. The idea to use the
mouse for more elaborate controls of the racket – thus making it more of dexterity/coordination-heavy
tennis game – as it is stated in the original design document, was change in favour of using the keyboard for
more basic up-down and hit mechanics. There were two different reasons for this: The first related to the
idea that our game would be more persuasive and interesting if played by two persons at the same time –
as we imagined some discussion would arise from the collision between players mental models of the
simulated systems and the procedural representation of this system (the “space” that Bogost (2006) refers
to as the simulation gap) – which conflicted with the initial reluctance to spend time setting up the
multiplayer server, thus leading to a decision where the two players would be sitting at the same computer.
This meant, as there is not two mouse inputs available for most setups, that we could not have a control
scheme based on two mice. Another, more theoretical, consideration that lead to the rejection of the
mouse controls was that it would remove attention from the more rhetorical aspects of the game, in favour
of sophisticated controls and game mechanics.
Discussion on the process / Individual notes:
Alex Hartfelt:
Personally, I was quite pleased with the outcome of this challenge, despite a few shortcomings, of which
most relates to clarity of communicating the meaning and consequences of the different rackets. I do
believe we succeeded in “landing in the middle”, as stated above, with respects to having an enjoyable
game that also made some meaningful statements through its core gameplay. From personal discussions I
have encountered the opinion that the game did not “persuade”, in the sense that it did not try to convince
players about the virtues of a specific and clear position, like “presidential debates are pointless” or
“candidates say whatever they think is most popular with voters”. In response, I would acknowledge that
we might not be using the word persuasive in the classical (classical Greek) rhetorical sense of “the art of
persuading someone to accept or reject a claim”, but more in the expressive – and according to Ian Bogost
(2007) more modern sense – of effective communication of expressive content. With regards to Debate
Smash 2008, this means that we aim at conveying a specific framing of the presidential debates – that they
rely chiefly on established ideologies – in an expressive (probably more than persuasive) manner through
gameplay and game rules. In this sense we are more concerned with expressing what we feel are the
established ideologies of the two Parties, and not so much with persuading players that, say one is better
than the other. Whether you consider this to be persuasive or not is probably related to what you imagine
the role of rhetoric to be. We were able to get some very valuable feedback from Ian Bogost on our game,
and while it – as an example of what he entitles election games – was criticized for not tackling the deeper
16
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
political issues separating the two candidates, he did at least acknowledge that it did in fact offer some
explanation as to these differences: http://www.watercoolergames.org/archives/000995.shtml
Sebbe Selvig: In regard to programming the core game mechanics, this game was quite easy. The largest
programming effort was put into the characters with their arms for holding the rackets as well as their body
movement. I think the result is very good and quite entertaining to look at. Also the APE physics engine as
in the two previous games was utilized for the ball dynamics.
In this game we also had the chance of implementing a screen manager allowing fast and easy
implementation of different menu screens and gameplay-screens. This feature was inspired by an example
provided by Microsoft for their XNA game developing framework. The result was so easy for implementing
game menus for the game, that we implemented this feature in Animal Factory during polish of that game.
This game also featured a new sound library that we developed for easy loading external sound files so we
could release it on the internet. The game was uploaded to nonoba.com which is one of the reasons Ian
Bogost had the possibility to review our game. We didn’t receive that many plays, probably because
Nonoba is catering for a different type of players than those interested in political games.
Our game was originally a two player game, but we implemented an AI player as well, but it is a bit too
unbalanced and is way too good at playing. In the future, if we decide to use it for another election (in
Denmark or elsewhere) this is one point to improve. Also a better communication of the different bats
would be useful, as the game is quite heavy on the information necessary to make good decisions while
playing, something that is not available during gameplay.
Patrick Jarnfelt: This game was one of the easiest to implement code wise. The game mechanic is very basic
and so are the rules (the actual implementation of the rules, not the creation of the rules themselves,
which were very difficult to make understandable; as stated in Alex’ text). The game is basically a caricature
version of pong with some extra rules. We therefore had some time to polish the game. This game is hence
the most “finished” game we have developed.
One of the extra polishes I had time to implement was a sound library that embeds all the sounds in the
beginning and lies a centralized place. This was done because all files had to be embedded in the actual
game file, so we could upload it to a game host. The file was then uploaded to Nonoba.com, where it got
moderate reviews from the player base.
One of the other things I had time to implement was the Artificial intelligence. The game is definitely meant
as a two player hot-seat action game, which as previously stated would also hopefully emphasize the
rhetoric of the game. However, we thought that we would like to have our game out to a bigger audience
and preferably, before the election, and the requirements of having to be two players at the same time was
working against this.
Dajana Dimovska: My opinion is that many game designers take the subject of politics and politicians and
use it only to skin their “political”, casual games with already very well known gameplay, like the
presidential pong game which is basically nothing else but playing pong with your character being a
politician. It is very surprising to me that this is the case and I think that serious concepts such as politics,
integrated in games, have a potential for making the game more than just entertainment. Therefore, I am
very satisfied that our Debate Smash 2008 game has a strong rhetoric and its purpose is to communicate
the ideologies that the American president candidates and their parties were defending for the election
2008.
17
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
My main tasks during the development of the game designing were designing the user interface for the
game as well as the visual style. The in-game user interface is a very important of the game since it is the
basis for the gameplay. The ideologies and issues had to be explained in the least amount of words possible
and instead associated with an icon. Making easy recognizable icons with an extensive meaning as an
opinion on a subject proved to be difficult but very interesting to work with. The most difficult part was to
find two somewhat different icons that represent ideologies wrapped around topics such as spending and
money. To solve this task I did research on icons used in media and tried to design fitting and relevant
symbols that will represent the concepts we are using in the game.
18
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Challenge # 4
Total Word Domination
Challenge: Make a game for a social network that enforces asynchronous gameplay between many players.
Description
A community based text-creation game for Facebook. Players engage in writing a story, poem, description
or other forms of text collectively, by building on previous contributions. Players can vote on the preceding
sentence – reject and write an alternative text, or accept and append their sentence – in order to choose
the one they feel best fitted. If a player gets a sentence accepted, he or she is awarded points according to
the number of reserved special word in that sentence.
Figure 3. Flowchart of Total Word Domination
19
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Mechanics
In addition to writing sentences, players can reject or accept contributions from other players. In this
particular game, players do have a lot of freedom in respect to how the game is played and what behavior
is considered acceptable. As it is mainly played among friends, we imagine that social considerations and
norms will replace the role of strictly rule-enforcing game design.
Reflection of the “social aspects” of the game
We imagine that – as the game is played among users of Facebook and their friends –that social rules and
norms will moderate the play so to emphasize a general “gentleman” approach, that will prevent players
from deliberately sabotaging other peoples suggestions and, as a consequence of this, eliminate their
possibility of winning the game. The game rules do not explicitly handle such destructive motivations,
which would be considered more of a problem in other contexts where players might not share the same
social relation to one another as we expect is the case with Facebook users and their “friends”. This could
prove to be a very dangerous assumption, and we have yet to verify it.
Joshua Porter (2008) summarizes many of the considerations one might have present when designing sites
and applications for, what he describes as, the social web. Among these is the observation that much of the
social web relies on the users wish for, and possibility to, share the things that are important to them with
other users somehow connected to them, and that designers should make available the opportunity for
doing so if they want to create products and services that are viable for long-term existence on this social
web. Much of this, as we see it, is already handled through Facebook, and so suggestions like having a
share button close to the other central functionality of the application, seems in some way “already taken
care of”. That sharing is an intrinsic part of the human experience, and that application longevity will be
greater if one targets it at the sharing process of the users, is an assertion we in the team agree with, and
one we hope to operationalize through the 4th game, by employing the functions of inviting, adding, and
not least seeing other player profiles in the game. We also took notice of the advice to include the share ID
(name and profile image) in the message send to the recipient, for the purpose of increasing familiarity and
in this also the chances of more successful sharing of our game.
Individual notes:
Alex Hartfelt:
For this game, I was mainly involved in the visual- and interface design. The ambition to communicate the
objective and possibilities of the game in a comprehensible and lucid way, was especially important in this
game, as there is nothing that as such “happens” to suggest the player how to respond to these actions –
unlike many games who have some “genre-related shortcuts” that help them address this problem more
effortlessly than with a collective text-writing game with asynchronous gameplay. Even though you have,
say difficulty comprehending the exact details of controlling, equipping or customizing an avatar in a 1st
person shooter, the moment you are approached by a giant blood spluttering alien, you probably start
thinking about – and expect – certain actions being afforded to you by the game to deal with this event. We
did not have this advantage in the 4th game, and so “guiding the play” became an important assignment of
the UI.
Sebbe Selvig: As opposed to the 3 other games, this game was not implemented in Flash and ActionScript
but was created as a regular website. Facebook provides a rather large API for programming applications
20
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
for Facebook. However it was easier said than done, as there was many features that was not possible or
hard to implement because Facebook parses the code produced by us and filters out anything they wish to
preserve the user’s privacy.
The game was implemented using PHP5 and MySQL to preserve game state. We made use of a DataObject
featured in the P.E.A.R. package available for PHP that helped us in the trivial task of saving and retrieving
data to and from the database.
Because of the asynchronicity of the game, we had to control the game in a very different way of what we
were used to in the flash based games, which only exists for a short period of time. This game is meant to
be played for a long period of time, checking in two or three times a day to see if anything has happened
and if a new sentence can be added.
When the player enters a game, the game in question will be locked, so if any of the other players enters he
or she is unable to vote for a sentence or add a new sentence. The game will automatically be unlocked
when the player adding a sentence is finished with her task. This is the only place in our game where some
synchronicity exists as well as the rule stating that the player is unable to vote for a sentence created by the
player herself.
The game is yet to be fully implemented, as it is missing the end condition and the possibility of adding an
ending to the story, however the game has been implemented enough to prove the game play.
The game has been implemented with the style of Facebook so the player has an easier time accepting the
game. The only thing indicating that the player is in a special application instead of the regular Facebook is
a banner depicting the name of the game (Total Word Domination) on each page.
Patrick Jarnfelt: The game we created for this challenge was the first and only game we created entirely in
HTML. Because of the asynchronous nature of the game, it made sense for the game to be made in HTML.
Even though HTML games are notorious for being ugly, bulky and slow, we felt that this would not be a
problem for our game. We thought that making a game in HTML would be quicker and more painless than
making the same game in flash. Also text editing would be easier with HTML and CSS. Furthermore, since
we are working with multiplayer games, there would be databases involved, and this is also easier with PHP
(which is the server-side scripting-language to make HTML pages).
What we did not think about was the problem with more people developing on the same HTML pages.
There has to be a good workflow set up for this way of working. And since our previous experience was
making local flash games (not only multiplayer games), we did not have this workflow well established. This
was a problem in development that we had to overcome.
Dajana Dimovska: My main task in this game was to implement the visual designs that Alex created in
Photoshop11. This process consisted of converting the graphics into web supported images and arranging
them in a web page by using html12 and css13 code. Unfortunately, the designs created for this game where
not entirely compatible and supporting of the already coded game. This happened because of the
inexperience of the entire group in creating a Facebook game. However, the communication between the
programmers, Patrick and Sebbe and the designers me and Alex was crucial to come to a common decision
that balanced the wanted design with the discovered constraints.
11
http://www.adobe.com/products/photoshop/compare/ - software for creating and manipulation graphics.
Markup language for Web pages.
13
Stylesheet language used to describe the presentation of a document written in a markup language.
12
21
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Challenge # 5
Challenge: To create team portfolio where all games made in this course are presented and use some of
the extra time to polish some of the games.
Description of the portfolio
The portfolio describes the team members, their individual tasks and interests, as well as the individual
games. Alex and Dajana were responsible for creating the portfolio from a concept to product.
This portfolio should represent us as a team and our work together. Therefore we used lot of the time to
define our goal and interest in making games as a team and to find a style and name that will represent us.
As is probably the case with most portfolios or websites in general, we wanted it to correspond to our
perspective on game development and game design (non-exhaustive keyword are understandable,
enjoyable and hopefully slightly upsetting), while also being informative and functional. We made a
portfolio structure which looks like this:
Figure 4. Portfolio structure
The game have a brief description of the most basic “key feature” elements, a section listing the game
mechanics, screenshots, gameplay video, tasks and notes from team members.
22
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Working with the portfolio was a good basis for thinking about the games we had done during the course,
what were the common traits? Was there a theme or a goal that persisted through all these very different
types of games? For one, the humoristic take on many of the game subjects seems to have been a guiding
principle, despite the potentially serious nature of this (politics, animal mistreatment, Hell). However, our
fundamental approach to games is still devoted to the issue of lucid – and for these games certainly also
experimental – gameplay and game mechanics, as we consider these to be the “core” of game
development and game design, the main place where the experience and meaning of playing games are
created.
Prioritizing games
The time between the final challenge and the hand-in date was used to polish two of our games. Sebbe was
in charge of the Facebook Total Word Domination game and Patrick handled the polish of the Animal
Factory game.
We brainstormed and tested a bit in order for us to come up with some specific issues to deal with during
polish. The goal of the polish period was to finish the selected games for release on the internet, get
feedback and see if the games could win any audience.
For Total Word Domination we came up with the following issues to correct before hand-in:




Text Analysis. Implement a way for the game to check which words have been used in a submitted
sentence and give points to the players accordingly. Also the sentence should not be able to be
submitted if the sentence does not contain any keywords.
End Condition. The game should be possible to end in a decent manner, allowing the players to add
an ending to the story, instead of the game ending abruptly when the players have used all of their
words.
Design Implementation. The first iteration did not feature a consistent design for the game, so we
aimed to implement that, also for guiding the player better while playing.
Spawning Words. We also lacked the feature of giving the player new words to use over time. The
design proposed to give the players a new word every 12 hours from game start.
The second game we selected for polish was the Animal Factory, where came up with the following issues
to correct before hand-in:




Tutorial Level. The game should feature a tutorial level for to give the player an easier and more
controlled environment to learn the mechanics of the game.
More Levels. To give the player a more exciting experience of completing a level, we implemented
the feature of subsequent levels to make the game more varied.
Easier Throw-mechanic. Many players had a hard time learning the to throw, so we needed to
adjust the throw-mechanic so the player had a more natural feeling of the arm. To improve it
further we added visual feedback of the hand closing although the hand did not grab anything.
Menu System. The game did not feature any menu and would start instantly, not that good for an
online game played by others than the developers.
23
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008

Give the Sausage word more meaning. The game features no direct visual references to sausages so
we agreed to change the name to Animal Factory and remove any possibility of misunderstanding
or confusion of the player.
A sub goal of the polish period was to present some of the games at the IGDA Demo Night and hopefully
get some useful feedback we could use to improve the two games – or at least to show off our skills to the
other developers at the Demo Night.
The two games we chose to present were the Animal Factory that we needed to polish, and the Debate
Smash 2008 that had been released and was ready to show.
IGDA Demo Night
The IGDA Demo Night was held at the ITU December 11th, and featured people from the industry. The
purpose of the event is to share ideas and show-off the new ideas one have. Also the event is a great place
to get contacts to “real” game developers that have developed larger games.
The people at the event liked our games a lot especially the Animal Factory game that amused the audience
quite a lot. But besides the positive attitude, we didn’t receive any useful feedback that could lead to a
better game.
When we presented the Debate Smash game the audience was very interested in how many plays we
received on the nonoba.com website, which was not that impressive, currently the game has 200 plays.
We did not receive any productive feedback for this game either, but the audience was impressed about
the comment from Ian Bogost on his blog. Maybe it is not the place to get constructive feedback, but we
did receive some respect for our games.
24
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Conclusion
As an overall conclusion, we all felt that we gained a lot from the course and the practical development of
the different games, and that the process itself was an enjoyable one more that just traumatic or hectic.
We believe to have been fairly successful in allowing a lot of creativity from individual members, while at
the same time not compromising on the “broader picture” of the design.
Group dynamics was good, and no major issues occurred regarding autonomy, despite an often dynamic
and loose approach to development roles and responsibilities.
We consider the games produced to be – besides the issues mentioned in this document – enjoyable, and
attractive in other ways, and to meet the challenges put forward during the course.
25
Development Diary, Pure Fire Interactive
Experimental Game Play, E2008
Literature:
Bogost, Ian. (2007). Persuasive Games: The expressive Power of Videogames. Cambridge: MIT Press.
Byrne, Ed. (2005). Game Level Design. Hingham, Mass: Charles River Media.
Fullerton, Tracy Swain, & Hofmann. (2004). Game Design Workshop: something…
Lazzaro, Nicole. (2004). Why We Play Games: Four Keys to More Emotion Without Story. Oakland, CA:
XEODesign.
Porter, Joshua. (2008). Designing for the Social Web. New Riders.
Salen, Katie & Zimmerman, Eric. (2004). Rules of Play: Game Design Fundamentals. Cambridge: MIT Press.
Zimmerman, Eric. (2003). Play as Research: The Iterative Design Process. In: B. Laurel (Ed.) Design Research.
Cambridge: MIT Press.
26