Monthly Archives: March 2014

Week 5, Monday

Today’s work

This day was spent with working on additional game mechanics for the game as well as the art asset for the first of the six game pieces. More game mechanics and technical work got done than expected today, but at the same time the art for the game piece took longer than expected due to technical problems with importing animations into Unity.

Art for the Red piece (The Book)

Today Calle started off with the work on the pieces. First up was the book, or the red piece as Michael would call it.

The piece is being made in 3D (we will be discussing why in a later post), and with that came some unexpected problems. The program the piece was animated in, Maya, played the animation one way while the game engine we use, Unity, played it another. Calle was given two different versions of the same animation, were the correct one was not the one present in the game. This has to do with how Unity handles animation, and how it “tweens” its animations while Maya does not. This problem took longer to solve than estimated, and the entire day was spent solving the issue.

Game mechanics and how they relate to Socratic dialogue

The first task of the day for Michael was to create the final three pieces, which the player can create by combining the three pieces that we already have (green, blue and red). These new pieces will have movement-sets that are a combination of the two colors that was used to create it. To see an example, look at the picture below.

red and redgreen movement example

The red-green piece gets the length of the red piece, letting it move further than the green piece and even over obstacles. The mechanic of combining pieces is inspired by Socratic dialogue techniques, while looking at the pieces as arguments in a dialogue. In a Socratic dialogue, every argument is carefully valued and tested. As the green and red argument collide, instead of simply removing one of the arguments (as would be done during a debate), we take the knowledge gained from valuing the arguments against each other and use that to create a new argument (piece). None of the combined pieces are entirely removed, they are merely merged into something new. As our aim with this project is to impart the understanding of the benefits in seeing a problem from different viewpoints, we feel it important to let this influence and form every aspect of the game.

Large amount of technical work finished

Michael managed to create the three “advanced” pieces today, henceforth called the combination-pieces. He created the highlights for the pieces as well as a function used to center the game-board in the middle of the screen. In addition to this, he started working on the HUD icons that will show what will happen if two pieces collide. These icons will show when the player has a piece selected and hovers with his mouse over another piece. The HUD and highlights are very important aspects of the game, since without them the game would be nearly unplayable by anyone except us developers. In order for us to influence our player, we need to easily explain to him how to play the game, at the same time as he’s actually playing the game.

The coming week

As there has been a lot of progression going on in the technical areas, time has been freed to implement additional features to the game that will help the player enjoy and understand how to play it. Before this week is over, we hope to have merged the mechanics and art for world one. We also hope to finish work on the icons that will help the player know what happens when two pieces collide. Michael will also do level design for world two, since the pieces for it are already done. He will also implement some of the texts in world one, mainly those that will show between the levels. In the coming week, we also aims to start reading the two texts that was recommended by the examiner.

The problem with the art for the first piece took longer to solve than estimated. Calle will still stick to the plan to have the pieces and the board done by the week, although with more pressure and perhaps less polish. Having them all done and in the game, ready for pretty effects when there is time, seems better than not having them at all.

Advertisements

Week 4, Friday

What happened this week?

Text-related coding

This week, Michael had planned to be done with the text-related technical backbone of the game, enabling him to add additional story segments in the coming weeks. He had also planned to write the texts relating to the first of the two “worlds” in the game, which was supposed to be based on debate. All of the above was finished on time, and the system Michael created for showing text and story bits is able to fade two text segments in and out, as well as fading the screen to a semi-transparent black. This was made to give the text more focus during the story parts.

Wrote first draft for story in world one

We did not start reading about Christianity and Secularism this week. We went to the library and ordered the texts we were recommended by the examiner, so hopefully we will get (and start reading) them next week. Because of this, it was harder than expected for Michael to write the story parts for the first world. He still managed to put together a first draft which we can update later, since it is easier to write about the differences of the two life philosophies than it is to write about their common aspects. Since the differences is what will be debated during world one, it fitted us to start writing about that first as the gameplay of the first world is nearly complete. Michael wrote 5 different story bits for world one, we will most likely only use three in the final product but it’s good to have several different bits to choose from.

Created highlights and scaling

Since he could not spend his time with reading, Michael decided to make the game more accessible to new players by adding highlights on spaces a selected piece is able to move to. This was initially meant to be done during the polish phase in about 2-3 weeks, but we realized that the highlights are necessary for us to playtest the game, thusly we had to create and implement them sooner. Below is an image of the highlights showing the movement of a selected piece. Michael ended the week with spending some time on making functionality for scaling the playfield, so that several different sizes can be made to fit well on different screens.

highlightsInGame

Background transitions in world one done

This week Calle has, just as planned, worked on the levels and their transitions for the first world in the game. The entire world is done, perhaps except for its introduction which we still feel is unclear. The technology behind the transitions and the visuals is however robust, meaning that making some sort of introduction will be a breeze. This also means that when the time comes to merge Calles and Michaels projects it will be without too many hiccups, since it is basically only dropping their scripts into the same folder.

Started creating concept art for the pieces

Concept art for the pieces has also been made, although only this last day of the week. During pre-production a lot of quicker concepts for the pieces were made, mostly to get ideas of what they actually were out there. The problem Calle faced was what the pieces should represent, since there are many different approaches. As it stands right now, the pieces show different types of arguments, or different meaning of the arguments. One piece is a tree, which could mean life or the natural. Another is a star which could indicate the scientific or astronomy. Even though there is an original interpretation of the piece, it should still be subjective. Calle feels it is important that it is still kept quite abstract, so that the player may be a co-creator and reflect his/her own views on the pieces, but that we as the artist start them off with a hint. The picture below shows the thumbnails of the book, tree and star (from top to bottom).

Pieces_Week4

Research question and the work so far

Our research question is: How can game developers create entertaining experiences that have the potential to affect the player outside of the game?

In order to make the game affect the player outside of the game, we need to plant a seed of thought about the theme we’re trying to discuss within the game. The though planted can be different for every player, and doesn’t need to be mature enough to grant any conclusions. What’s important is that the game sets a thought in motion within the player that can then grow out from his subconscious during the weeks after he has finished playing. In order to achieve this we have chosen gameplay that will keep the player’s mind focused while at the same time giving the emotional part of his brain the chance to process what he has read during the story bits.

We envision the game to alternate between story (which will be shown with text and art) and gameplay.  The gameplay will use the game board and pieces that we have spent our first weeks of production creating. So far, it has taken us a while longer to create the gameplay than it has to create the underlying story, which might feel odd as it is the story that will leave the seed within the player’s subconscious. However, if the gameplay didn’t exist, the message we’re trying to convey through the story might feel too pretentious and alienating to the player. By wrapping it in an entertaining game, we can lure the player to read our dialogue pertaining life philosophies and even question assumptions that he might not even know that he had.

Our plan going forward is to begin testing the gameplay and story to see if we’re close to affecting the user in the way we want. We haven’t settled for a method of testing yet, we do believe that it is more important for us to find a way to test the story bits than the gameplay as we have already tested the gameplay in analogue form.

Week 4, Wednesday

Continuing from last Monday, our 2 man team is still struggling with technical issues, however not without prevail! Below we will walk through the barriers we have faced, how we got around them and what is left to be done. For this week, at least.

Graphical optimization and smoothing out transitions

Up until today the graphical assets for World One had only been tested in the Unity Editor, with no changes to the standard settings. This means that the graphics has so far been made to look smooth and nice on machines exactly like Calles, and with the exact same settings. This is of course not viable, as we want as many people as possible to have the possibility of playing the game. More so if we want to release the game on mobile devices, which are often weaker than the average PC.

As it turns out, the otherwise so smooth transitions between levels were not so smooth when the graphic settings were bumped up. However with help from Michael we were able to find a bug in the script for the transition, keeping it consistent between graphic settings and machines.

The transitions at hand is what most of the work has been done for. How they are made were however covered in our last post, so this slideshow to show our progress will suffice:

Something Calle did

What is obviously missing is the transition from the last stage (W1L3) to this worlds ending sequence (W1L4), were the player will dive into the vast ocean (W1L4.5). That too is left to be done.

Organization and fading text

As Michael started to finish up the programming for the gameplay mechanics last post, and was hence ahead of schedule, he could start working on the mechanics for the text. The text in the game is the story bits of it, and is planned to be shown in between levels. It is crucial that the player reads this text and might need some motivation; however this is something we can cover when we get there.

There was perhaps more work than planned needed for the text, which needed functionality to fade in and out. The same functions were initially meant to be used for the texts background, but needed other methods as GameObjects does not act the same as GUIStyles (both are classes in Unity). An option was to have the text be a texture, basically making it behave the same as the background, but its quality would be lower and the iteration clumsy as a change in the text would warrant the import of an entirely new texture.

Timers or cool downs were needed to make the text behave properly, gradually fading while the timer ticks to zero, but did not work as intended. The fading would act weird, but was later solved by using a solution similar to the one Calle uses for transitions between levels.

Michael later created a base class which held all the basic functionality needed by every child class (the sequence classes), the children could now be made smaller and easier to manage. These smaller classes retrieve basic functionality, such as the creation and fading of text and backgrounds, from the base class which means that Michael will be able to create new in-game text sequences faster.

Michael initially worked with Coroutines (Link below) to try and find a way for the fading to work on the text. A Coroutine is a function that can use the yield keyword to wait for the next frame to continue performing its logic. Michael had problems getting the Coroutine to work with several different texts at the same time, as the increment variable for the fade wasn’t reset once a new text called the same Coroutine. This made for buggy fades where some texts would pop up without even fading, or even fade multiple times.

In the end, Michael decided to skip the Coroutines for the fades, but still managed to use their functionality to solve another bug. The GameHandler class is used to initialize every other Handler-class, such as the TextHandler Michael has worked with this week. A bug arose where a function call made to the TextHandler class ran before the Constructor of said class. This created an error as the function used a variable initialized in the Constructor. The problem was solved by creating a delayed Constructor in the GameHandler class, which could run the function call to TextHandler with a delay of two seconds, giving the Constructor of TextHandler enough time to run first. The delayed Constructor was made using Coroutines, since a Coroutine can be made to wait for a set amount of time before continuing with its statements, the function call could be made at the end of the delayed Coroutine thus eliminating the bug.

Coroutines in Unity: http://docs.unity3d.com/Documentation/Manual/Coroutines.html

Future plans

As the text mechanics are shaping up Michael can start implementing the text, or the story rather, to the game. The texts relating to life philosophies have been ordered and we are awaiting their arrival. To get the most use out of these texts we plan to wait with the story until we have actually read them.

As said above, some of graphical assets are still missing for World One, but the plan is to get them done by the end of the week. Calle will also begin making proper concepts for the pieces, continuing from silhouettes and other quicker concepts made before. With this we will almost have World One complete, however with some graphical assets missing, no sound and no story. This will of course come at a later stage in development.

 

Week 4, Monday

We have spent the day mainly with solving different technical issues, which I will describe more in detail below. I will also go through some of the game’s mechanics, how they relate to the theme of understanding through conversation, and what we hope to have finished by the end of the week.

Using prefabs to fade the background of World One (Fire and Ice)

Calle has spent the day working on the fading between levels. In the first world, there will be clashing ice and fire. These two sides will recede and create a pool of water in the middle. Calle worked on finding a solution for how to make the ice and fire recede while also fading in the water in the middle. He decided to create prefabs, which are similar to predefined blueprints of objects that can be placed in the scene. He created three prefabs for each side, since the sides will recede three times. Each time the sides recede, the current prefab (existing on the scene) will fade out, at the same time the next prefab will fade in making the transition seamless.

Creating the Red Piece

Michael spent the day with creating the Red Piece. This piece is supposed to move similar to the Rook in chess, with the exception that it has to move as possible along its movement path. This movement system created some problems for Michael, as it was quite different from the other piece’s movements but still had to be implemented in some of the same classes. Michael managed to implement the feature by placing the majority of the code in the class specific to the Red Piece, while doing some checks in the Input Handler class to make sure that the functions specifically needed for the Red Piece are run if a Red Piece is moved.

Mechanics of the first World

The following mechanics have been implemented and will be used in the first world:

  •          Blue piece, one-step diagonal movement
  •          Red piece, Rook-like movement
  •          Green piece, one-step 90 degrees movement
  •          Wall, blocks pieces
  •          Win space, have the last piece on this space to win
  •          Collision rules:

o   Red beats Blue

o   Blue beats Green

o   Green beats Red

  •          Turn space, turns any piece that lands on it to the next one in the collision order (Red becomes Blue etc.)

With these mechanics, we have tried to illustrate how a debate typically works. Our idea was to show the player a debate in the first world, then changing the story, mechanics and art into a dialogue in the second world.

Each piece is supposed to represent an argument. While the individual movement patterns are not inspired directly by debate, the usage of the collision rules are. In a debate, participants are focused on crushing the opposition’s arguments in favor of trying to understand them. We want to illustrate this by letting the arguments the player controls (pieces) have strengths and weaknesses against each other, for instance, a “red” argument will always destroy a “blue” argument. The Turn Piece was meant to showcase the way an argument can be turned and twisted by rhetoric to represent something entirely different, depending on how the person explains it.

Plans for the week

We are currently ahead of schedule, and all of the mechanics that were meant to be implemented this week are already done (with the Red piece and Turn space being the final parts). Michael’s plans for this week are to begin work on the story-related texts that are to be shown in between level- and world changes. He will work with writing the text itself but also with creating the technical backbone that will handle the transitions. We have received two texts from our Examiner that relate to the theme of life philosophies, which explain the core values of Christianity and Secular Humanism respectively. We will begin reading these texts and take notes on what to incorporate in the debate/dialogue Michael is about to write. Calle aims to finish his work on the transitions for the first world this week. He is also going to start doing concept art for the three pieces that will be in the first world.

Vecka 2, Produktion – Sammanfattning

Tankar efter redovisning av Del 1

I början på denna vecka hade vi redovisning för Del 1, dvs. den skriftliga delen. Vi gjorde vår presentation på tisdagen.  Den huvudsakliga feedbacken vi fick var att texten saknade en tydlig brygga in i produktionen. Detta var något som vi glömde skriva in, vi skrev inte ens en summering till texten. Vi har ganska klart för oss hur vi ska ta med oss våra efterforskningar in i produktionen, vilket vi nu har börjat med, så får vi komplettering för detta så blir det inte svårt att skriva ner våra tankar till en summering i slutet av den skriftliga delen.

Valde bort tutorials

Vi hade under denna vecka avsatt all tid till att titta på tutorials för vår valda spelmotor. Efter att ha spenderat ca 20 minuter på att se serien http://www.youtube.com/watch?v=yQXdREL4GGg så kände vi att vi hade en tillräcklig grund för att kunna hoppa in i motorn och börja testa våra idéer. Anledningen till att vi hade så många dagar avsatta till tutorials var för att vi inte visste hur avancerade spelmotorns system för 2D skulle vara, och därmed inte hur lång tid det skulle ta oss att lära oss dem. Efter att ha sett grunderna så bestämde vi oss för att gå rakt in i produktion och att istället lära oss de djupare sidorna av motorn när vi stötte på problem. Detta sparade oss mycket tid och vi har nu hunnit komma ca 3 dagar före i vår planering. Om vi inte hade haft erfarenhet av spelmotorn sen tidigare så hade den tiden vi avsatt för tutorials varit betydligt viktigare och troligtvis inte utbytningsbar.

Val av motor och tekniska problem

Vi har valt att arbeta i Unity 4.2. Vi har erfarenhet av att arbeta med Unity 3D och läste om uppdateringarna i Unity 4 som gör det lättare att arbeta med 2D (http://blogs.unity3d.com/2013/08/28/unity-native-2d-tools/ ). När vi nu har arbetat i motorn ett par dagar så är vi väldigt nöjda med valet, då det innehåller lättillgängliga 2D verktyg vilket underlättar vår produktion.

Michael stötte tidigt på problem med hur Unity hanterar klasser och objekt. I Unity så måste varje klass sitta som en komponent på ett GameObject, vilket är det objekt som existerar på scenen. Michael är van vid att kunna instansiera klasser och att det är klassen själv som innehåller logik om kollision och sprite. Detta skapade problem innan Michael hade hunnit vänja sig vid Unity:s system, men löstes efter att han hade förstått hur Unity:s GameObjects relaterar till klasser och kod.

Calle hade från början en idé om att använda normal-maps för att skapa ett extra djup i vår 2D. Då Unity både fungerar som en 2D och 3D motor samtidigt så hade detta gett oss intressanta möjligheter att arbeta med förflyttningen av ljus i 3D framför våra 2D objekt. Han upptäckte dock att normal-maps inte kan sättas på partiklar, och valde därför att inte applicera normal-maps på resten av våra sprites heller. Han tänker att det hade brutit vår grafiska stil om våra 2D sprites hade haft normal-maps men inte partiklarna, då vi använder partikelsystem för att skapa rörelse över våra 2D sprites.

Detta har implementerats

Vi har nu börjat vår produktion och har arbetat långa dagar både på onsdagen och torsdagen. Michael har börjat med att programmera de grundläggande strukturerna och spelmekanikerna för spelet. Hittills har vi följande:

  • Ett Grid system som används för att rita ut spelbrädet. Kan användas för att göra olika storlekar (i Y och X led).
  • Två pjäser (grön och blå) som har olika rörelsesystem; En kan flytta till intilliggande rutor och den andra ett steg till diagonalt intilliggande rutor.
  • En vinst-platta. Spelaren vinner om han har en pjäs kvar på brädet som står på vinst-plattan.
  • Kollision mellan grön och blå. Om de kolliderar så förstörs den gröna pjäsen.

Nedan syns en bild på spelets första bana. All grafik är temporär. De röda pilarna syns inte i spelet:

värld1bana1

Grön pjäs (till vänster) och blå pjäs (till höger) rörelsesystem visas på bilden med röda pilar. Spelet kommer att vara uppdelat i två olika världar, där varje värld låter pjäserna interagera med varandra på olika sätt. I den första världen så kommer de tre pjäserna (vi kommer att lägga till en röd pjäs i nästa vecka) att fungera enligt ett sten-sax-påse system där de olika färgerna tar ut varandra. Denna första värld ska simulera en debatt mellan två sidor som kämpar mot varandra i sinnet hos en person, där pjäserna är sidornas argument. Spelaren kommer både få observera debatten i textform samt styra pjäserna. Sten-sax-påse systemet ska simulera hur debatten förstör olika argument, när en argumentation är över (en bana) så finns där endast ett argument kvar som kan vara vinnaren.

Grafik till den första världen (debatt)

Calle har börjat arbeta med bakgrunden till den första världen. Han har tagit inspiration från de två motsatserna is och eld, som visas på bilden nedan.

WorldClashProgress

Denna bakgrund kommer vara animerad och förändras allt eftersom spelaren klarar av banorna i den första världen. Vi beräknar att ha tre banor i varje värld (alltså 6 banor totalt). I den första världen så kommer elden och isen att, i takt med att spelaren klarar banor, flytta sig bakåt mot skärmens kanter. Ett hav kommer att formas i mitten, och när spelaren har klarat de tre första banorna så kommer han att dyka in i havet där den andra världen tar plats. Med detta vill vi visa att debattens två sidor tappar kraft mot varandra, och mellan dem finns nu en stor blandning med argument från båda sidor. I nästa värld, dvs. när spelaren befinner sig mitt ibland argumenten (i havet) och de två sidorna inte längre är närvarande, så kommer spelaren att få kombinera argument med varandra för att kunna undersöka spelets tema ifrån olika perspektiv.

Ljud outsource:at till Ola Bäckström

Då ingen av oss är kunniga inom ljudskapande så tog vi kontakt med ljudstudent vid namn Ola Bäckström. Vi har arbetat tillsammans i tidigare projekt och han visade stort intresse för vår frågeställning, story och spelmekanik. Han har gått med på att försöka hitta tid till att hjälpa oss med musiken till spelet, ett första utkast på musiken till spelets första värld (eld och is) som Ola har gjort kan laddas ner här: https://www.dropbox.com/s/u05l8nytj43tqzp/Fire%20and%20Nice_1.wav

Vecka 1/Del 2 – Presentation och Planering

Presentation

Med en uppkommande opponering och examinerande presentation satte vi veckans schema på förberedelser inför de två.  Våra förhoppningar var att få sätta igång produktionen på en gång, men valde istället att fokusera på att få en presentation som håller hög kvalité, likaså med opponeringen.

Det finns alltså inte så mycket att skriva om själva arbetet, då det har fått vänta. Vi har däremot skrivit ett preliminärt schema över arbetet, inte bara för att veta vad vi ska jobba med varje dag utan även för att få en känsla för scope. Vi har diskuterat idéer för spelet under hela del 1, så många av dem har hamnat i en stor hög. Denna hög har nu organiserats och staplats till ett fint torn, som vi ska ta tag i en bit åt gången.

Planering

Något vi märkte rätt snabbt var hur ont om tid det egentligen var. Vi vill hellre se en kvalité över kvantitet, då detta känns viktigt för att intressera spelaren från allra första början. Om spelet ger ett dåligt första intryck och vi inte lyckas få honom/henne att spela igenom den första minuten, kommer vi självklart inte heller lyckas få honom/henne att påverkas av spelet. Däremot, om spelet är så kompakt att det blir ett spel på 10 minuter, kan den då ge ett starkt nog intryck på spelaren? Även om vi inte siktar på att spelet ska vara just 10 minuter, hoppas vi att denna nerskalade version ändå kan framföra kärnan i projektet.

Vi har nu en klar vecka framför oss; vi vet att vi ska jobba i Unity, vi vet vilka spelmekaniker där ska vara och vi har en aning om hur det ska framställas estetiskt. Detta kommer från de dagar vi klämt in prototyp-arbete från del 1, vilket har hjälpt oss få denna chans för en rivstart. Med erfarenhet i Unity från förra projekt kommer programmeringsdelen inte bli en nylärandeprocess, samma med den tekniska biten av estetiken. Samma med spelmekanikerna, då vi vet vad spelaren ska göra, och den grafiska med övergripande koncept på spelvärldarna.

WorldClashWorld Clash rough concept (Egen bild)

Så, även om vi denna vecka inte börjat komma igång med den producerande biten av projektet så har vi ändå en bra idé över hur det kommer gå till. Vi har lagt grunden för projektets produktion, och kan med den börja bygga upp själva spelet. Delar av spelet har fått skäras av, men detta var förväntat och vi känner oss inte oroliga över det. Hur själva spelet kommer bli återstår däremot att se.