Project Title

Screaming Kitty.

 

Group members (name + sdu login)

Chaehyun(chkim18), Huy(hutra14) & Mathieu(madau18)

 

Introduction

The blog will be about the making of the iOS game, screaming kitty as a part of an iOS course at the University of southern Denmark. The groups could decide to do an app about almost anything, and this group decided to make a game. The video game will be named Screaming Kitty. The goal of the game is to make the character Cat jump as high as possible collecting stars. The player makes Cat jump by screaming into the built-in microphone of the smartphone and steering Cat with the accelerometer. This blog will present the entire process of the project from the beginning all the way to the final result. There will be sections about some of the code and sections about how important user tests was for the making of the project. This blog post also have a discussion section, where reflection about the final product is presented.

 

What is your basic idea

Most people know or have at least heard the name Mario, from the super mario video game series. If not, super Mario is a video game franchise developed and published by the Japanese game company Nintendo. The core premise of all the games in the franchise is that Mario the hero of the game, should save princess Peach from the evil dragon Browser. The video game is then played as a platformer, where Mario can run and jump through levels and obstacles in order to save princess Peach. The player use a game controller with physical buttons to control Mario through the video game.

This project will be a mobile game, inspired by platform games like super Mario and many other platformers.

In Screaming Kitty, you control Cat who wants to be united with her mom, who is in cat heaven. Cat do this by screaming in order to ascend up to the heaven. On her journey up to her mother, there will be stars that Cat can collect, so she can buy a nice present for her mom once she reach cat heaven. That is not all. There will also be pink stars that will drag Cat down from her journey, essentially preventing Cat from dying. The unique twist about Screaming Kitty is as a game is, that the player have to scream into the smartphone in order to make Cat jump. The player can control Cat left and right by using the iPhone’s accelerometer.

 

Why is this subject important

There are countless of apps on the market that are similar to the idea of this project. Fortunately no app completely matched the idea for this project. Especially the in game story about Cat trying to reunite with her mom in cat heaven. In that sense the project idea might not have any substantial importance, but have the potential to a fun project to show your friends and family. Sometimes have fun is also an important thing.

 

Common platform

This early section of the blog will delve into different terms that will be mentioned and explained in deeper detail, later in the blog. This is done in order to have a common platform, before proceeding reading the blog.

As a requirement of the course, this project will be coded in the programming language Swift. Swift is described as a fast and intuitive programming language for the macOS, iOS, watchOS and tvOS (Apple, 2018). Swift can be used in the IDE (Integrated Development Environment) Xcode. At the time of writing this, Xcode is only available on mac, though pc users can get Xcode through a simulator. Swift is an open source programming language, which means that it is open for everyone. This means that there are many libraries / frameworks for the Swift language that provide additional functionality. One such library is Audio kit. Audio kit is an open source framework for the Swift that comes with functionality concerning audio in apps (AudioKit, 2018). Another library that will be used in this project, is Sprite kit (Apple, 2018). Just like Audio kit, Sprite kit is an open source framework for Swift. Sprite kit is used to create games with swift.

This section has introduced the most important terms that will be mentioned and used in this project. The different terms will be explained in greater detail, when the time calls for it. Throughout the blog post, some other terms will be introduced as well, but they are not as important as the ones introduced in this section and that is why they are not a part of this section.

 

Problem statement – What is the problem you wish to solve?

The reason behind the decision to develop the current game idea is first and foremost, because it would be a fun and cute game to show friends and family. Before that is a possibility, a game must be made. This leads to the problem statement for this project.

Design a simple platform game with Swift for smartphones, where the player controls the game by using their voice and the smartphone’s accelerometer.

The biggest challenge about the game is figuring a way to translate the user’s voice through the smartphone microphone into a in game force that will ascend the game character higher on the vertical plan. The open source framework Audio kit, will be used to solve this challenge. The Spritekit framework will used in order to design the game logic and visual. Utilizing the accelerometer in the smartphone will be done by using the framework CoreMotion.

 

Methods and materials

This section will describe the process of the project, from the genesis of the idea, to the final product and everything in between. It is possible to reproduce this project by following this section to its conclusion.

 

Brainstorm

One of our group members came up with an idea to make a game using voice. And we expanded the idea like controlling with voice frequency. Like many game apps, we chose jumping as the main movement of the game and the degree of jumping controlled by frequency looked interesting. We all agreed to implement such a game as our project. And also the group couldn’t find any other interesting idea.

There were some apps that inspired our project, and we want to describe the two kinds of apps and how they are different, but also how they are similar to our project idea.

  • Doodle jump(Figure.1) : this game has similarity with ours in terms of that the character steps up the moving platforms. But it is played by touching the screen whereas ours is by screaming. And also this game uses accelerometer to move the character left and right.
  • Scream Ninja Go / Chicken Scream (Figure.2) : In these games, the player makes the character move and collect coins by screaming like our project. But the character moves horizontally curving through the air whereas Screaming Kitty moves just vertically going upward.
Figure.1
Figure.2

 

Conceptual Design

Figure.3

Figure.3 is a sketch one of the group members did to illustrate the idea for the game. A game character jumps by the player screaming into the smartphone. The player starts at the ground and then have to move up. The game have some moving platforms and there will be coins to collect. The initial sketch gave the group the ability to get on the same page in terms of the concept of the game.

 

Simple prototyping

The initial sketch for the game lead to the design of paper prototypes. Paper prototypes are low fidelity prototypes and are a great design tool in the early stages of the development.

Figure.4

Figure.4 is the prototype of our project, Screaming Kitty. Like any other game apps, it will have a menu for starting the game. After pressing start, it goes on to loading page that loads all the data needed for playing game. After falling down from the platform, the game is over and it will show your score on the screen. Also the button for replay is on game over screen.

 

User tests of the paper prototypes

The group went for a user centered approach to designing the game. This meant that user tests was conducted throughout the process, including the paper prototypes. The purpose of testing the the paper prototypes was to see if people could navigate the UI and understand the game’s concept. The test was conducted as a open structured interview, where the group would ask general questions about the prototypes. What did they think? Was there anything that they thought could be better, or something that didn’t quite understand? The paper prototypes from figure.4 was used to test the navigation of the game. Users would pretend that the prototypes was actual screens, while the group members would simulate a feedback everytime the user tried to interact with the prototypes.

 

Figure.5
Figure.6
Figure.7

Figure.5 – 7 are another set of prototypes that focuses on the actual gameplay.

The paper prototypes were used to test the gameplay of the game. The user was told to scream into the prototype in order to get the Cat to jump, and steer the paper as it had a accelerometer while group members would simulate the feedback in real time. The paper prototypes was tested on other students and friends. The overall impression of the idea was positive, based on the responses from the tests. Effort was spent on the visual of the paper prototypes, which lead to no confusing in terms of navigating the UI of the game. Even though the gameplay session was a bit clunky in execution, people still understood the idea and thought it could be a fun game. The result of the tests gave the group the confident to start designing the MVC model for the game and start programming the game.

 

Use-case diagrams

Based on the results of the paper prototype test, it was possible to create a user-case diagrams, which shows the experience path through the app.

Figure.8

Figure.8 is the user-case diagram. The path through the game is very linær. It is only doing gameplay that the user have two different outcomes. Either the user wins or loses. In each cases the user will be sent to another screen that shows the score and a message according to the outcome. The user then have the ability to try the game again or close the game from the home screen.

 

 

Object diagrams

Creating an object diagrams makes designing a MVC model easier. The object diagram helps with breaking the game logic down into smaller and manageable pieces.

Figure.9

Figure.9 is the object diagram for the gameObjectNode. The diagram gives the group an idea of what class, enum and struct that should be used in the file, and also how some of the objects are connected to each other. This was done for all the other files as well.

It is worth mentioning that the following tutorial was used as a reference point for designing the project.

https://www.raywenderlich.com/2007-how-to-make-a-game-like-mega-jump-with-sprite-kit-and-swift-part-1-2

The tutorial is about creating a 2d platformer, where the player controls the character with the accelermometer. Some design assets and code snippets was used as reference point for this project.

 

MVC

The object diagrams served at a closer look at the MVC model, where the focus was on the individual files of the project. MVC stands for model-view-controller and is a model used in object oriented programming languages, like Swift. The purpose of the model is to separate the code in three manageable parts, which also makes it harder to clutter the source kode.

Figure.10

Figure.10 is the MVC for the project. The model consist of two files that have the code for what the base game logic is, but not how it is displayed. The controller hae three files for every view that game have, in this case it is three. The controller files is the connection between the model and view. The code found in these files shows how the code in model files should be presented, UI logic. The view consist of two storyboards, which is the elements the user can actually see and interact with.

 

Explanation for some of the code

Most of the code snippet will be from the GameScene file.

import SpriteKit
import GameplayKit
import SpriteKit
import AudioKit
import CoreMotion

The necessary frameworks are imported at the top of the file. In this case, framework as Audiokit and Spritekit are imported.

 

Placement of stars and level design

The placement of the stars and therefore also the level design is done by extracting data from a list file.

This is how the file looks like in Xcode. The file contain data about the height the player must reach in order to complete the level and position and patterns of the stars.

        let levelPlist = Bundle.main.path(forResource: "Level01", ofType: "plist")
        let levelData = NSDictionary(contentsOfFile: levelPlist!)!
        
        // Height at which the player ends the level
        endLevelY = (levelData["EndY"]! as AnyObject).integerValue!
       
        // Add a star
        
        // Add the stars
        let stars = levelData["Stars"] as! NSDictionary
        let starPatterns = stars["Patterns"] as! NSDictionary
        let starPositions = stars["Positions"] as! [NSDictionary]
        
        for starPosition in starPositions {
            let patternX = (starPosition["x"] as AnyObject).floatValue
            let patternY = (starPosition["y"] as AnyObject).floatValue
            let pattern = starPosition["pattern"] as! NSString
            
            // Look up the pattern
            let starPattern = starPatterns[pattern] as! [NSDictionary]
            
            for starPoint in starPattern {
                let x = (starPoint["x"] as AnyObject).floatValue
                let y = (starPoint["y"] as AnyObject).floatValue
                let type = StarType(rawValue: (starPoint["type"]! as AnyObject).integerValue)
                let positionX = CGFloat(x! + patternX!)
                let positionY = CGFloat(y! + patternY!)
                let starNode = createStarAtPosition(position: CGPoint(x: positionX, y: positionY), ofType: type!)
                foregroundNode.addChild(starNode)
            }
        }

In order to extract the data from the file to create the level, a path to the file is defined as a let and the end level height is found a translated into an integer. Then by using a for loop the different positions and patterns for the stars are extracted, and the stars are added to the scene.

// Add the player
player = createPlayer()
foregroundNode.addChild(player)

Just like the stars, the player sprite are added to the scene in the init function of the file.

 

The accelerometer

//Motion manager for accelerometer
let motionManager = CMMotionManager()

//Acceleration value from accelerometer
var xAcceleration: CGFloat = 0.0

A motion manager for the accelerometer are initiated and the value from the accelerometer.

if let accelerometerData = motionManager.accelerometerData{
     let acceleration = accelerometerData.acceleration
     self.xAcceleration = {CGFloat(acceleration.x)*0.75) + 
(self.xAcceleration*0.25)
     player.physicsBody?.velocity = CGVector(dx: xAcceleration*400.0, 
dy: player.physicsBody!.velocity.dy)

In the update function the code will check how the player is using the accelerometer and add the force to the player character accordingly, making the character either go left or right.

 

AudioKit

First of all we initiate the accelerometer with the object named Motion Manager.

let motionManager = CMMotionManager()

//Acceleration value from accelerometer
var xAccerleration: CGFloat = 0.0

In the init method of gameScen we set the update interval at 0.2 second to have a smooth move. Every 0.2 second there will be an update of the accelerometer ‘s values.

Then we start the accelerometer updates.

// 1
motionManager.accelerometerUpdateInterval = 0.2
// 2
motionManager.startAccelerometerUpdates()

Then in the update method of gameScene, if there are data in the object motionManager, we get the acceleration from it. After that, we set the acceleration of the player with this value and using a formula to make the movement smoothest as possible.

The accelerometer is only used to move the player right and left, so that why we only get the x value.

override func update(_ currentTime: TimeInterval) {
        if gameOver {
          
          return
        }
            if tracker.amplitude>0.5{
               
                screamToStartNode.removeFromParent()
                player.physicsBody?.isDynamic = true
                print(tracker.amplitude)
                player.physicsBody?.applyImpulse(CGVector(dx: 0.0, dy: tracker.amplitude*10))
            }
            if player.position.y > 200.0 {
                backgroundNode.position = CGPoint(x: 0.0, y: -((player.position.y - 200.0)/10))
                foregroundNode.position = CGPoint(x: 0.0, y: -(player.position.y - 200.0))
            }
            if let accelerometerData = motionManager.accelerometerData{
                let acceleration = accelerometerData.acceleration
                self.xAcceleration = (CGFloat(acceleration.x) * 0.75) + (self.xAcceleration * 0.25)
                player.physicsBody?.velocity = CGVector(dx: xAcceleration * 400.0, dy: player.physicsBody!.velocity.dy)
                // 2
                // Check x bounds
                if player.position.x < -20.0 {
                    player.position = CGPoint(x: self.size.width + 20.0, y: player.position.y)
                } else if (player.position.x > self.size.width + 20.0) {
                    player.position = CGPoint(x: -20.0, y: player.position.y)
                }
            }
        if Int(player.position.y) > endLevelY {
            winOrnot=true
            endGame()
        }
        if Int(player.position.y) < 0 {
            winOrnot=false
            endGame()
        }

In the game we use AudioKit to get the voice’s amplitude of the gamer.

var mic: AKMicrophone!
var tracker: AKFrequencyTracker!
var silence: AKBooster!

First of all we initiate the microphone of Audiokit and a tracker to track the amplitude.

mic = AKMicrophone()
tracker = AKFrequencyTracker(mic)
silence = AKBooster(tracker, gain: 0)
AudioKit.output = silence
do {
            
     try AudioKit.start()
            
} 
catch {
         AKLog("AudioKit did not start!")
            
      }

Then,in the init method of game scene we initialize the microphone, the tracker and the silence with the minimum gain.

Then we try to start Audiokit.

override func update(_ currentTime: TimeInterval) {
        if gameOver {
          
          return
        }
            if tracker.amplitude>0.5{
               
                screamToStartNode.removeFromParent()
                player.physicsBody?.isDynamic = true
                print(tracker.amplitude)
                player.physicsBody?.applyImpulse(CGVector(dx: 0.0, dy: tracker.amplitude*10))
            }

Finally in the update method of GameScene, if the amplitude of the voice is higher than 0.5 we remove the text that say “Scream to start”, we make the player dynamic and then we apply to the player an y impulse which is equal to the amplitude of the voice multiply by 10. So the gamer can scream more or less and the player will jump more or less high.

When the gamer finishes the game, win or loose, before going to the game over or game win screen, we stop AudioKit to avoid errors.

func endGame() {
        // 1
        gameOver = true
        do {
            
            try AudioKit.stop()
            print("Stop")
            
        } catch {
            AKLog("AudioKit did not stop")
            
        }
       
        let reveal = SKTransition.fade(withDuration: 0.5)
        if winOrnot==false {
            let endGameScene = GameOverScene(size: self.size)
            self.view!.presentScene(endGameScene, transition: reveal)
        }
        else{
            let endGameScene = GameWinScene(size: self.size)
            self.view!.presentScene(endGameScene, transition: reveal)
        }
        
    }

Then when we are on the game over or game win screen, we initialise a new AudioKit microphone and we start again AudioKit.

Then in these screens there a sentence that say “scream to try again”. So in these classes, in the update method, if the amplitude of the gamer’s voice is higher than 0.5, we stop AudioKit and we go back to a new game scene to play again.

        mic1 = AKMicrophone()
        tracker1 = AKFrequencyTracker(mic1)
        silence1 = AKBooster(tracker1, gain: 0)
        AudioKit.output = silence1
        do {
            
            try AudioKit.start()
            
            print(tracker1.amplitude)
            
        } catch {
            AKLog("AudioKit did not start!")
            
            
        }
    }
    override func update(_ currentTime: TimeInterval) {
        print(tracker1.amplitude)
        if tracker1.amplitude>0.5{
            do {
                
                try AudioKit.stop()
                
            } catch {
                AKLog("AudioKit did not stop!")
                
                
            }
            
            
            let reveal = SKTransition.fade(withDuration: 0.5)
            let newGameScene = GameScene(size: self.size)
            self.view!.presentScene(newGameScene, transition: reveal)
            
        }
    }

 

 

Evaluation of the digital prototype

User tests of the digital prototype was conducted at the end of the development. Testing of the audiokit and accelerometer was done internally by the team. The internal testing lead to some design changes to the game. The use of the accelerometer and built-in microphone to control the player character lead to the realization that the moving platforms was useless. This in turn lead to the decision of removing the moving platforms from the game.  User tests for the digital prototype was done with the purpose of balancing the game and getting feedback on the visual of the game. The tests was open-structured interviews with general question about the feel and visual of the game. Tests was conducted on fellow students and friends. The feedback helped balancing the game for the most enjoyable experience.

 

Result – presentation of the final game

This section will present the final result of the project. The game is an 2D platform for iOS, where the player controls Cat. The player have to help Cat reach her mom in cat heaven. The player makes Cat jump by screaming into the built-in microphone of the smartphone and steers Cat left and right with the accelerometer in the smartphone.

Figure.11

 

The first thing the player will see when launching the app, is the loading screen. The loading screen contain some art work of Cat that servers as feedback for the player, while they wait for the game to load. This can be seen on Figur.11

Figure.12

When the game is loaded, a start screen will pop up. The start screen is very simple in design and the player only have the ability to start the game, when ready by touching the screen. The aesthetics of the screen is within the visual vision for the game, which is cute and fun. The start screen can be seen on figure.12

Figure.13

On the actual game screen, Cat will spawn at the bottom of the game level. A message is also displayed telling the player to scream in order to start the game. As soon as the player screams into the microphone the message will disappear and Cat is on her way to reach her Mom. The yellow stars throughout the level grants the player 10 points, while the pink stars subtract 20 points from the player. On top of that, the pink stars also pushes the Cat down, when Cat collides with a pink star. The game screen can be seen on figure.13.

Figure.14

figure.14 shows the player at the top of the level, where Cat’s Mom are waiting.

Figure.15

When the player reaches the top of the level, they have beat the game. The level is not infinite. This gave the group the ability to design the level exactly as they want. After beating the level, the player will be brought to another screen. This win screen tells the player that they have beaten the game and what their final score was. The win screen can be seen on figure.15. If the player falls down it is game over and they will brought to a similar screen that tells them that they lost and what their final score was. The player can retry the game by screaming into the microphone.

And the video below shows playing of our final application, Screaming Kitty.

 

Discussion

As the problem statement for this project states, the goal was to make a iOS game with the implementation of Audiokit and SpriteKit to have microphone functionality and auctal creating a game, respectively. The group managed to do just that. The end result is a functional game, though it certainly have its flaws. The game would benefit with a tutorial that explains the controls and rules for the game. A short section about the in game story could also be added. The in game story mainly served as a design pillar for the group in terms of the visual of the game. This in turn means that the story is not really present in the game, though the Cat and her Mom is present in the game, but with no explanation. The game would also be enhanced with more focus on juice. The game do use music, but only for the background music in the game screen. Music on the start screen could also be added, though technical problems prevented the implementation of music on the start screen. The game could also benefit from having sound effect for every time the user collects yellow or pink stars. A sound for game over and beating the game could also be added. Due to time constraints, these additions was not added to the final game. Storing the score of the player was also a function that was discussed in the group. This would save the player’s score even after they have left the app. Due to some technical problems, this feature was not added in the final game. The final result is a functional, fun and simple game with room for improvement.

 

Conclusion 

By using Swift, Audiokit and Spritekit is was possible to create a 2D platform game for iOS devices. The game is called Screaming kitty and follows Cat’s journey to reach her Mom in cat heaven. The player controls Cat by screaming into the built-in microphone to make Cat jump, and use the smartphone’s accelerometer to steer Cat left or right. The player is also able to collect stars on the way. The game was built on a strong foundation based on user tests throughout the development process. Testing the initial paper prototypes gave the group confident to continue the work and valuable data in terms of designing the MVC model for the game. User tests also had a vital part at the later stages of the development in terms of the games aesthetics and difficulty. The game ended up being a fun and simple game that is ideal to show of to friends and family. As presented in the discussion section, the game have room for improvement if the group decided to continue working on the game.

 

Perspectives

If the group decided to continue working on the game, the focus would be on polishing the game and adding additional levels. By adding additional levels, the in game story has the potential to have a bigger presence in the game.

Leave a Reply