Analyzing: Betrayal at House on the Hill

Introduction:

So, time again for another blog post. The second one for the Game Design: Analysis course. This week me and my group have been playing Betrayal at House on the Hill.

The Game:

This game is all about exploring a house with your friends. You can play as one of 3-6 players which must walk through a haunted house to find different items and rooms to defeat a traitor in their midst. In the beginning of the game, none of the players know who the traitor is, not even the person that will betray the rest. This is due to the fact that the game has two stages and the traitor is only revealed in the second round.

This game is using dices, but not the regular kind, it used normal 6 sided dices with most sides blank. You could only get one or two.

Every player has a card which displays their stats. There are four different stats that every player has: strength, speed, sanity and knowledge. Every character starts with a set number of points, varying from character to character. There are those who are very athletic and have high numbers in speed and strength, but not so much sanity and knowledge. Then there is the opposite: low speed and strength with high sanity and knowledge. There is also one or two hybrids, which have decent everything.

The speed stat is used for determining how fast you can move through the house, you get to move through one extra room for each point you have in speed. It is also used for some room based events, like for example to exit one room you need a certain amount of speed or you’d lose one point in strength.

The strength stat is mainly used to make physical attacks, either with a player or a monster as the target. When you do an attack against something, you get to roll one dice for every point you have in strength. Then the thing you attacked gets to roll one dice for every point they had in strength. The higher of the two numbers minus the lower value would be the damage. This means that if you were to attack something that was much stronger than you, or if you were really unlucky with the dices, you could take damage instead of the enemy. The person losing the fight would then decrease his/her speed and/or strength equally much as the number they got from decreasing the winning roll with the losing. The strength stat was also used for certain rolls in some of the rooms in the house.

The sanity and knowledge was mostly used for rolling for different things in the game, like open locked doors and such. There is certain conditions in the game that will let you use sanity or knowledge instead of strength to make an attack. This is called a mental attack and unlike a physical attack it targets sanity and knowledge.

The first half of the game is about exploring the house, finding new rooms with things in them. The house had 3 floors: ground floor, upper floor and basement. As you were exploring the house further you picked a tile from a pile, where they laid facedown. The back of the tiles showed if they were supposed to be in the basement, ground floor, upper floor or a combination of two or all of them. When you moved through a door into a not yet explored room you picked a tile from the pile that were for the same floor you were on and placed it next to the room you came from. You then proceeded to do what the tile said, if anything. The things that you had to do when entering a room for the first time were mostly draw a card. There were also certain rooms which required you to roll a dice when leaving, to prevent loss of stat before continuing.

There were three different kinds of cards present in the game: omen, event and item cards. What was on the different cards varied heavily from card to card, but it could be something like: You saw a ghost, make a sanity roll (if it was an event or omen card). And then different things might happen depending on what you got. Every time someone picked up an omen card, he or she had to make a dice roll with six dices. The number that the person got had to be equal or greater than the total number of omen cards in play at that time. If it was less it would trigger the second half of the game, the Haunting Phase.

When the haunting phase begun, the person responsible for triggering it would take up a secondary rulebook and check who became the traitor and what he or she did to become treacherous. This was dependent on what card was picked up to trigger the event and where it was picked up. This made it possible to get over 40 different second phases, ensuring that the game wouldn’t be played the same way twice. When the traitor and event had been figured out, the person that became the traitor got the traitors handbook, telling him or her what to do to be able to win the game and how to do it. For example there was one Haunt where the traitor became a gigantic two headed worm that were supposed to move around (which caused it to grow bigger), leaving body tokens after it. If the traitor got sixteen tokens onto the board before the players could kill it, he or she won.

The players on the other hand had to do a ritual, involving a skull and a knowledge roll to get rid of the worms damage immunity before they could try to kill it’s two heads. Each head had its own protection, movement and health. They did however share the same attack value.

Some of the Haunts didn’t have a traitor and then it was more every man for himself than a team effort. Others had a hidden traitor.

At the same time that the traitor got his or her rulebook, the rest of the players also got a rulebook. In this was the information necessary to defeat the traitor. They then had to talk everything through and try to come up with a tactic to try to win.

Round one:

The first round went slightly slow, since we were learning the rules but it didn’t take too long time to figure out the basics of the game. We mostly just ran around aimlessly, focusing on exploring as much as possible. When the haunt were later revealed, we got the World Destroyer Worm haunt which I described previously. After the haunt was revealed the game ended fairly quickly due to the fact that the player that had the item required to break the invulnerability of the worm was the person that became the traitor. So all that we had to do was to get to where the traitor began and then go to one of its heads. This was also fairly easy due to the fact that one player stood in a room which had a secret passage to the room next to the worm spawn.

Second round:

The second round began pretty much the same way as the first one did, but we got another Haunt, namely Frankenstein’s Monster. In this haunt the traitor kept his or her original character as well as gaining the control over Frankenstein’s monster. The monster could not be killed by normal attacks but had to be either pushed from a high part of the house or attacked 12 times by fire. The latter was done by throwing torches on it, which required a speed roll. You could get the torches in certain rooms in the house that had a fire in them. About half way through the second round we managed to kill the traitors original character, which meant that we only had to focus on the monster. We had, however miscalculated how things would be played out during the game and the monster cornered us one and one until only one of us were left. This was quite troublesome, since the character were a small boy which didn’t have much chance against the monster and was quite quickly killed.

Core Mechanics:

The two things that was consistent through the game were moving and attacking. You moved to explore, gather and other stuff while you attacked the enemy to destroy it (like many other games).

Good things:

The thing that I consider to be the best thing about its design is the high replayability. Since you randomize the entire house by moving around, no round is like the other. Where it previously were a kitchen, there could be a hallway the second time you played the game. Another thing that greatly increases the replayability is the haunt system, which also utilizes randomization to generate new experiences each playthrough. The fact that the second phase is also triggered randomly each time is also a thing that increases the replayability.

Bad stuff:

The thing that isn’t a very wise design choice when it comes to this game is the fact that the different characters have different starting stats and they gain and lose stats differently. This could have been done a lot better, as it is right now it is not properly balanced. If you were to pick a certain character you would almost have the game in your hand from the beginning.

The second thing that I found about the game that wasn’t very cleaver is snowballing. The fact that you gained more stats when you had more made the game slightly dull after a while. It also worked in the opposite way, decreasing your stats the lower they were. This only applied to certain rooms and events though.

Target Audience:

I don’t completely agree with the suggested age of this game (12+), mostly due to the fact that it’s a quite simple game. I would instead say that 8+ would be a more appropriate age.

Outro:

Congratulations for making it to the bottom of this huge wall of texts. I feel slightly sorry for you, but i hope that it was atleast somewhat interesting to read.

Analyzing: Kill Doctor Lucky

Introduction:

We in the Game Design program got an assignment, to analyze a board game that we chose in a group. The game my group chose is a game called Kill Doctor Lucky.

The game:

So, the game is about killing a man named doctor Lucky. You play as one of 3-7 people that has been invited to his mansion a stormy midsummers eve. The house is quite big, sporting 24 named rooms, 6 hallways and 2 stairways. Each room is connected to between 2 and 5 other rooms via doorways.

Since you absolutely hate the old man for one reason or another, so you decide to kill him. This is made quite difficult due to the fact that there are a number of other persons in the house with you and Lucky. Not to mention his trusty dog, which will alert anyone in the house in case you try anything.

As a murderer you most certainly don’t want anyone to know that it was you that killed the old man. To make things more interesting, the doctor seems to have hidden passages all over his home that he uses frequently to get around quickly. You however have no knowledge whatsoever of these hidden passages and must therefore move one room at a time. Should you step into a notable room you may find something that may help you kill the old man. Examples of these things you might encounter are: Ropes, Guns, Crepe Pans and cursed monkey hands. You may also, if you are lucky accidentally stumble upon one of dr. Luckys secret passages. Should you do this you could use this to get ahead of the old man and plan an ambush.

If you felt that the time was right for a murder attempt on the doctor, you had the ability to play a weapon card, which would increase the effectiveness of your attack by a number stated on the weapon card. Certain items also had some bonuses in specific rooms. The Crepe Pan was for example extra effective in the kitchen. When you had decided to make an attempt, your fellow players had the opportunity to stop your plans by using different kinds of distractions. Should their distractions work, the doctor escapes and you become even more angry at the old man than you previously were and gain a “Spite Token”. This token is a representation of the fury built up within you when the old man once again escaped your clutches. These spite tokens can be used in your next murder attempt to stay more focused on the task at hand than you previously were. Every spite token you use when attempting a murder will increase your murder value by one point.

The dog had three types of rules, one variant was that he followed the doctor around. The dog had no knowledge of the secret passages that the doctor was using, therefore he walked as if he was a player. If the dog had the doctor in his sight, the players couldn’t attempt any murder. You may also try to kill the doctors dog, should it become too troublesome and thwart your plans one more time than you are comfortable with. In this case everyone stepping into the room the dead dog is in will feel sorry for the poor creature and take a moment of silence for it.

The second variant of the dogs rules was that it knew if someone in the house had attempted a murder of his master and after each attempt getting angrier after each attempt. The level of his anger would be represented by spite tokens, the dog gaining one after each attempt. The players could then, if they choose to, gather some or all of the tokens from the dog. The tokens came at a quite hefty price though, you had to discard one of the cards in your hand for each token you took from the dog. If the dog reached dr. Lucky before you could reach it, the doctor used his extensive knowledge of the creature to calm it down. This caused all the dogs spite tokens to go back to the spite token pile, before anyone had the chance to get them from the dog. If two players were in the same room as the dog stepped into, the one who would make his move the soonest would have the chance to “buy” spite tokens from the dog first. After he got the tokens he wanted, the other player in the room had his chance to get what was left if he desired to do so.

Contrary to the first set of dog rules, the dog could not be killed with these rules, but neither could he alert anyone of the crime, so you could try to kill doctor Lucky in his presence if you chose to do so.

The third set of rules for the dog was a combination of the previous two. The dog could detect and stop you if you tried to kill the doctor when he was looking. If you had the opportunity to kill the doctor and failed, the dog would sense this and gain a spite token which you could later “buy” from him. The doctor could also calm the dog down in this version, removing all the spite tokens from the dogs possession. In this version the dog could be killed.

Round one:

The first round we in the group played was quite booring, since we were too many people to play with the first version of the rules. The games line of sight mechanic, which meant that you could see into several other rooms from the room you stood in made it extremely difficult to do anything useful to the doctor. Once you did get the chance there were 5 other players trying to foil you plans with failure cards, negating your attack damage. Another thing that made the round longer than it had to be was that everyone tried to stop each other more than they tried to win themselves. All the players tended to stick to one side of the house, keeping as many as possible within sight range. This was an extremely effective way of keeping your enemies from killing the old man. After about 3 hours of constant playing we started to go for the doctor instead of trying to stop the others so, we got more frequent attempts on the doctors life. The attempts and failures continued for a while until we, after almost 4 hours ran out of failure cards. Then the next player that attempted to take the doctors life finally succeeded. After this we decided to go home and try again the day after, without the dog.

Round two:

We sat down to play a second time as we had decided the day before, this time without the dog. We also removed approximately half of the failure cards to get more successful murder attempts. This time the round were very much shorter. It only took about 15 minutes for the doctor to meet his demise.  This made us realize why the dog was in the game, and why there were as many failure cards as there was. We concluded after the second round that we should add the dog again.

Round three:

The third time we played the game I was the one responsible for mixing the cards and since my short time memory are not the best in the world, I forgot that were only playing with half the failure cards so I accidentally mixed all of them in. This proved to be one of those things that seem to be mistakes but are a good thing in disguise. The game lasted somewhere between 30 and 60 min both thanks to my mistake and the switch of dog rule set. We chose to use the second set of rules for the dog when we played the game the third time, which hastened the doctors demise.

Good things:

The thing I liked best with the game was the Line of Sight mechanic. Giving the game a feel of flow, as the players move around the mansion. This will of course force the players to anticipate the movement of his/her fellow players, if he/she wishes to be successful in the game.

Another thing that I find interesting is the dog that walks around the house, following the doctor. This is mostly due to the extensive impact he has on the gameplay, prolonging it or shortening it by possibly hours. This depends, however on which set of rules you choose to use for it. The rule set when he just follows the doctor has the most impact, at least if you are quite a bunch of people that’s playing. The second variant also has a rather significant impact on the gameplay, but in the opposite way as the first variation. The first prolongs the game while the second one shortens it.

The final thing that I would like to mention is that certain weapons work differently in different rooms. For example, the cannon weapon card has a base damage of 3, but in the armory it does 5 damage instead.

Bad stuff:

The worst thing about the games mechanics is the possibility to utilize them to stay in certain rooms to block off extremely large parts of the map, making it impossible to kill the doctor there without anyone noticing. One thing that could have been used to counter this would have been the adding of more “Move cards” (moves the player or the doctor a number of steps) than there currently was. If there would have been more of them the gameplay would have been much more flowing.

Another thing that I didn’t like about the game is that if doctor walks into a room that you’re currently standing in, it automatically becomes your turn. This can be used to a players advantage by chaining multiple moves in a row to get ahead of the doctor. This would effectively give the player in question a wide variety of new cards that he/she could use to further the advantage the player had.

Target Audience:

I believe that this game was meant for families with kids the ages 13 and up. I base this conclusion on the fact that despite that it’s a game about something quite serious, such as murder and the planning of murder it’s quite colorful. The colorfulness suggests that it’s a game for younger kids but the high level of tactics required to win it says otherwise. Therefore I conclude that the optimal age for playing this game is 13 and up.

General Tweaking

Hello. I haven't done that much this week, wich is quite strange considering that there is only one week remaining of the project. I would have done more but the truth is, I’m not entirely sure what there is left to do (that we still have time to implement and test properly). So, what I’ve actually done this week is: found some memory leaks and fixed them. We store all of our game objects in 2-3 vectors in our gamestate so that we easily can use them to check for collisions and stuff like that. The problem was that we didn’t delete them after each time we’ve used them, but instead just exited the gamestate went into the upgrade state and then back to the gamestate just creating them again. I’m not entirely sure why someone havn’t done this earlier but hey, it’s there now and that’s the important part. Another thing that I will do this weekend is fix our start menu. Currently it’s a bit buggy at best. That is if you don’t hit the “Options” or the “Exit” buttons. If you do, the whole thing crashes. The other thing that I am going to work on is the mouse tracking in the main menu. Currently it’s a bit off, so when you try to click on the “Start Game” button you have to click the bottom of it for anything to happen. I kinda know what the problem is, namely the way I wrote it to check if the mouse position is on the button doesn’t include any code to calculate the frames of the window, so it calculates the buttons positions via the upper left corner of it. This is possibly a not so good idea but that is why we are updating it. Another thing that I will be doing this weekend is adding the final art to the graphical user interface and reposition the things so that they fit together nicely:

This will probably take a bit of tweaking since the background art is a bit too big for the rest of the things and needs to be scaled down a bit but I am certain that I will get it done. After all, I don’t have much else to do and coding is fun =). I thing that will have to do for this week, the last of blog posts for the Gamedesign – Intro course. Overall I’d say that it’s been a quite interesting and fun experience that I’ve learnt quite a lot from. Let’s just hope that the things stick aswell =p

Good luck with the Theme-Park in a couple of weeks.

/Robin K

Levels och Gui

Denna vecka har jag mestadels suttit och pillat med levels. Vi tyckte att det var hög tid att lägga in detta i och med att betan är nu imorgon. Så det första jag gjorde var att skriva en level klass. Den håller koll på vilken dag och vilken vecka det är, vilket tillsammans utgör levels. Den håller även koll på hur många barn som ska finnas på varje nivå. Efter varje nivå kommer man till uppgraderings skärmen där man ska kunna välja uppgraderingar (vi har inte lagt in några uppgraderingar än, men det kanske kommer någon gång nästa vecka). För tillfället ligger där istället en bild som säger att man ska trycka på C för att komma vidare. Just nu fortsätter spelet även i all oändlighet, vilket vi också ska lägga in så att det tar slut. Eftersom vi redan har funktioner i level klassen kommer detta förmodligen att gå ganska snabbt och smärtfritt.

När jag hade lagt ihop min level klass med allt det andra upptäckte jag en ganska intressant bugg. Så fort man kom till nivå 3 och försökte läsa in den så kraschade spelet. Det tog en liten stund att lista ut vad problemet var eftersom att ”Vector subscript out of range” skulle kunna var vilken som helst av våra 5 vectorer. Jag kom efter en liten stund på att det var en kombination av alla våra vectorer some fick det hela att krascha.

 Vi hade nämligen glömt att tömma dom mellan varje nivå, så att koden fick för sig att storleken på vectorerna var större än 0 och jämförde därför listor utan något i. Detta var ett ganska klantigt misstag av mig, men jag kom ju på vad det var för fel iaf =)

När felet var hittat och återgärdat tog jag mig an uppgiften att implementera våran nya gui: 

Vi tyckte att det var ganska viktigt att få den uppdaterad eftersom vi tils idag hade använt placehoder sprites från google till större delen av våran gui. Detta kan ju ses som mindre optimalt, med upphovsrätt och så. Men förhoppningsvis är det ingen som märker att vi har använt deras bar och bestämmer sig för att stämma en hög med fattiga studenter =p

Förmodligen skulle dom inte kunna lyckas med detta, men man vet ju aldrig riktigt säkert.

Men det var allt som jag hade att skriva om den här veckan, se till att ha det bra nu under dom två sista veckorna av kursen.

Visuell Feedback

Hej igen, jag har denna vecka suttit och pillat med visuell feedback. Jag började veckan med att sätta mig ner och börja klura på hur jag skulle få animationer att fungera. Min första tanke var att använda mig av kod jag har skrivit till spelprogrammering1 men detta misslyckades fatalt, av anledningar som ingen verkar kunna lista ut. Det hela funkar som så att jag har en textfil som berättar vad av en bild som ska visas och detta laddas in och sparas som variabler i en Animations Klass. Sedan har animationsklassen en uppdate funktion och en draw funktion. Om en viss tid har gått sedan föregående animation så ska koden ställa om så att nästa bit av bilden visas på skärmen. Själva laddnings processen fungerar fin fint, men sedan när saker ska sparas i en vector blir det problem. I den delen av koden som dom blir inlästa fungerar allt som det ska, men så fort som koden är färdig med laddningen är allting som låg i variabeln borta. Detta är synnerligen underligt eftersom att variabeln är inte en lokal variabel utan global. Så med andra ord: det borde inte försvinna som det gör. Jag har kollat med flera av mina klasskamrater men ingen av dom verkar kunna komma på någon lösning. Dock har jag alltid varit bra på att komma på problem som ingen har haft eller hört om tidigare.

När jag insåg att jag inte skulle kunna komma på vad det var för fel med koden satte jag mig istället och började skriva kod för att kunna få in mer visuell feedback i spelet (vi har för tillfället inte mycket alls) då detta var en av de sakerna som Markus klagade på under pre-betan. Jag började med att fundera på hur jag skulle kunna lösa det hela och kom fram till att den bästa och simplaste läsningen vore att helt enkelt ändra transparansen på bilden beroende på hur smutsig spelaren/barnen är. Så jag tog och satte mig och gjorde en placehoder sprite (ihop slängd av lita annan art vi hade liggandes) för att kunna testa min kod och se om det skulle kunna gå att göra. det hela var väl inte överdrivet snyggt, men det är ju bara en placehoder, så här blev den iaf:

Mina första försök till transparans ändrande kod var ganska patetiska och misslyckades hårt. Men efter några försök lyckades jag komma på hur jag skulle lyckas göra det hela. Jag har inte lagt in kod för att fixa med barnens transparans, än men det kommer innan det blir måndag och beta =)

Detta var vad jag hade den här veckan, ha de gött.

Enemy Collision

Jag har denna vecka suttit och pysslat mestadels med Barn vs Barn Kollision. Från början tänkte jag att jag kanske skulle kunna använda samma kollisionsfunktion som jag använde till platformern. Detta visade sig vara mycket problematiskt eftersom programmet crashade när jag försökte fixa så att ungarna hade en kollider vilket gjorde det hela en aning problematiskt. När jag kom på att det var för mycket jobb för att fixa bestämde jag mig istället för att skriva en ny, egen funktion som använde sig av cirkel vs cirkel kollision. Detta valde jag för att jag redan använde mig av det för att kolla kollision mellan ungar och svampar. Det hela funkar som sådant att funktionen kollar punkterna på de två olika objekten. När den har räknat ut skillnaden så jämför den dom med radien på objekt 1 och radien på objekt 2. Om skillnaden är mindre än dom två radierna tillsammans så överlappar dom. Annars gör dom inte det. Jag har inte riktigt funderat ut hur jag ska kunna använda detta till min fördel men jag kommer nog på något när jag har blivit lite lagom trött, underligt nog är det när jag är trött och inte vill göra saker som de går bäst. Jag vet inte varför det är på detta vis men det har varit så ända sedan jag var liten. Hmm, tror precis att jag fick en idé. Hurra för sömnbrist ^^. När dom kolliderar blir det en liten (eller stor) bit av cirklarna som ligger över varandra, så om jag tar och skickar med denna lilla bit som överlappar in i barnens updaterings-funktion kommer det att sänka hastigheten på dom om dom överlappar. Om dom inte gör det kommer dom bara att fortsätta vandra som dom gjorde från det att dom dök upp på ”Dagis skolgården”.

Förutom att koda denna vecka har jag dessutom blivit utnämnd till producent. Så jag ska ta och hålla koll på saker och ting, vilket inte är min starkaste sida men jag tar mina uppgifter på så pass stort allvar att dom ska fixas oavsett om det är lätt eller inte. Jag har även börjat fundera lite på att leta efter folk som skulle kunna hjälpa oss och testa spelet någon gång nästa vecka så att vi hinner med att göra ändringar inför betan som är om två veckor. Det hade varit uppskattat om du som läser detta kunde höra av dig, antingen via komentar eller dylikt ifall att du eller någon i din grupp skulle kunna tänka sig att testa och ge kritik när vi är färdiga med att lägga in det vi för tillfället håller på att fixa. Självklart kan vi tänka oss att som kompensation testa erat spel och ge feedback på det =)
Aja, nu tror jag att det får räcka med bloggande för idag. Time to code =D

Overheat och enemies.

Den här veckan har jag suttit och pysslat med en hel del olika saker, bland annat med ett vapen heat system som håller koll på om vapnet kan skjutas eller om det behöver kylas ned. Det hela har en mängd små delar som var och en utgör en viktig del för att överhettningen ska fungera som den borde. Dels har vi variablerna som vårat player object håller koll på så som maximala mängden värme som vapnet kan klara av, mängden värme i vapnet för tillfället och om det har blivit överhettat (om värmen har gått upp till max). Sen har vi i våran game-loop kodbitar som börjar med att uppdatera det visuella, kollar först hur mycket värme som finns i vapnet för tillfället, sedan jämför detta med vapnets maximala värme och ritar ut en del av värme mätaren. Sedan går den vidare och undersöker om värmen är över noll och i sådant fall sänker den värmen lite. Sedan om något skulle gå fel och värmen skulle bli negativ så ändras den till 0. Jag har också lagt in lite kod i delen av koden som hanterar skottlossningen. Där lade jag in några rader som gör att värmen ökar så länge som spelaren skjuter. Anledningen till att vi lade in detta system var att utan det kunde man hålla nere vänster musknapp och fortsätta skjuta i all oändlighet, vilket inte var särskilt utmanande och utan utmaning – inget spännande spel. Vilket skulle i sin tur eliminera halva meningen med att göra spel, för vem vill spela ett spel som saknar utmaning? Troligtvis inte väldigt många. Dock finns det ju även sådana personer ute i världen och till dom har vi planerat lite intressanta grejer som har med uppgraderingarna att göra.

Jag har förutom att pyssla med värmesystemet också fixat lite med fienderna. Jag började med att fixa en extremt enkel pathfinding, dvs att fienderna kollar om spelaren är närmare än 400 pixlar så vänder sig fienderna mot spelaren och börjar vandra mot honom/henne. Skulle fienderna komma närmare än 50 pixlar börjar dom kasta lera på spelaren och vid 10 pixlar kvar stannar dom. Detta lade vi in för att kunna kontra en väldigt mysko bugg vi hade i början av projektet. Denna bugg hände när två fiender hamnade på exakt samma position och resulterade i att båda två försvinner mystiskt.

Men nu tror jag att jag har skrivigt tillräckligt, time to code once more.