zealseal

[zealseal]

Chaos Street DevLog #3

During the final few weeks of development, we had an afternoon full of playtesting with more naive players. This would be our last major chance to gather all the testing results and feedback we needed for the final prototype.

Before the session, I had spend time making two forms - one for player demographics and a survey for feedback of the game itself. During testing, I was normally the one to take notes of any remarks made, although occasionally I would help the test conductor and remind the player to speak their mind when they could. Reminding the player to think aloud is essential to playtesting (Fullerton, T. 2018. p.g. 302) as it allows us a window to see what the player is expecting and insight into the choices they make. It helps us as designers understand what may need to be changed and what works well.

For our prototype, road hazards, controller support, an end of level boss fight which moves across the screen had been implemented. Most of the feedback gained was in relation to a lack of clarity with the interface, hazards, damage taken and dealt, and game objective. I knew there was a severe issue with how we had integrated the fuel mechanics after this test. The implementation then was that the fuel was directly linked to health and level progression which was incredibly confusing without explanation. If you were damaged by an enemy, hazard, or didn’t pick up enough fuel to sustain yourself, you would eventually fail the level. This was not made clear in the interface and we hadn’t included a tutorial or instruction screen. I made note that we needed to separate the distance travelled (level progress) with the health bar and label each so that there was no more confusion. References:

Fullerton T. (2018). Game Design Workshop : A Playcentric Approach to   Creating Innovative Games, Fourth Edition. ProQuest EBook Central.   Accessed 5 November, 2021 from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

#A3 #Assessment 3 #Devlog #Chaos Street

[zealseal]

Chaos Street DevLog #2

A few weeks into the project, we started doing some playtesting with naive testers. One of the main complaints we received was that the secondary weapon was far too powerful as it would defeat any enemy in one hit. I made a note to the team suggesting that we change the rockets to either be an active ability as stated in the design document, or drastically increase the cooldown of the weapon so that the player must resort to using it strategically. This issue of balance is described as being a dominant object (Fullerton, T. 2018. p.g. 323). In this case, the secondary weapon, while unlocked after a certain distance, is still similar in accessibility and usability to the primary weapon. This made it extremely abusable and made the primary weapon redundant. References:

Fullerton T. (2018). Game Design Workshop : A Playcentric Approach to   Creating Innovative Games, Fourth Edition. ProQuest EBook Central.   Accessed 5 November, 2021 from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

#A3 #Assessment 3 #Devlog #Chaos Street

[zealseal]

Chaos Street DevLog #1

As part of our third assessment, I’ve been grouped up with two other game designers to make a prototype. With some discussion, we decided that we would use my main game concept of the space shooter, and take some of the gameplay and coding from my team member’s space shooter prototype and start from there.

We settled on the name ‘Chaos Street’ and I got to work making a revised One Page. The One Page was important to establish what additions, features, and future implementations would need to be made. It ensures that everyone is on the same page and has enough space for designers to make their own edits and suggestions. I tried to make it as detailed and comprehensive, while giving others enough room to add suggestions.

Final One Page:

#Chaos Street #Devlog #A3 #Assessment 3

[zealseal]

Wk 6 DevLog - Shooter

During this week’s workshop, I made the basics of an Asteroid space-shooter game. I later changed the game entirely, using the shooting code to work with individual turrets.

Changed the spaceship into turrets. The placement is at certain locations on the left and right side of the truck. To make coding flexible, I made it so that each one was assigned a variable. This is so in future I will be able to allow a player to upgrade, choose a different turret, or change the appearance of their turrets with ease.

The truck moves on a horizontal plane for the moment. I considered limiting movement to jumping in-between lanes grid-style, however It may allow players to feel more in control by having the ability to weave in and out of lanes. Doing so would require more skill and fulfil a player’s need for competency as described by Maslow’s Hierarchy of Needs (McLeod S. 2020). Once more formal elements have been introduced - mainly hazards - I will need to test the feel of the gameplay.

Turrets rotate to aim at the cursor’s position. I will play with having a ‘blueprint’ or ‘marker’ to indicate certain weapons’ line of fire, such as shotguns’ spread range, bouncing bullets’ trajectory, and charged lasers’ line of sight.

To Add:

Hazards should appear on the road. Accompanied with the freedom of movement, players should feel challenged with these basic dramatic elements. As covered by Fullerton, part of enjoyability comes from a balance of challenge and ability as well as giving players a sense of control over their actions (2018. p99-100). As the level progresses, it should get faster, higher priority enemies will start to appear on the screen, and eventually, once the player fills up the progress bar, a boss fight will appear.

Enemies. Defeating them will award coins that can be used to upgrade guns and buy new ones. Later in development, enemies that deal damage to the player using various methods will be added.

Different weapons. Allow players to gain a sense of achievement and progress as they gradually unlock new and different weapons. Each weapon will have what my lecturers have covered as orthogonal differentiation; weapons will have unique damage ratings, shooting styles, and reload times. This will give players a unique choice and allow them to tailor gameplay to their play style. For the Collectors, (Fullerton T. 2018. p.104) it will give them incentive to play and discover the variety of weaponry.

References:

McLeod S. (2020). Maslow's Hierarchy of Needs. SimplyPsychology. Accessed 2 September, 2021 from https://www.simplypsychology.org/maslow.html

Fullerton T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. ProQuest EBook Central. Accessed 2 September, 2021 from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

#wk6 #wk7 #wk8 #devlog #shooter

[zealseal]

Wk 5-8 DevLog - ‘Space’ Shooter

Concept

2D Shooter

Using a game of Asteroids as a base.

Bullet hell arcade

Crazy taxi x driveby shooter.

Enemies will appear on the road, extra enemies and targets will be on the sidewalks.

Pickup powerups, destroy buildings to retrieve coins, destroy enemies before they destroy you.

Some enemies climb onto the truck. QTE event to shoot them off.

Upgrade vehicle, weapons, and powerups in-between runs using resources and currency gained from playing the game.

Highscore and cosmetic system

Players will chase an enemy’s vehicle. The vehicle will be throwing stuff out of the trunk which the player will have to avoid.

Each object thrown has different properties.

Elevator Pitch

_ is a 2D, top-down shooter where the player controls a vehicle driving down a chaotic road. They will collect coins, powerups, as well as shoot, drive, and haphazardly weave around obstacles and pedestrians as they try to defeat their enemies. The graphics contain mild violence and are suited for a mature audience who enjoys action-packed gameplay and pushing themselves to beat past high scores of themselves and others.

#Wk5-8 #wk5 #wk6 #wk7 #wk8 #devlog #spaceshooter #shooter

[zealseal]

Wk8 Reflection - Pokemon Mystery Dungeon Explorers of Sky (Randomised)

I’ve been playing lots of Pokemon games recently and this particular one just so happened to give me a painful yet oddly fun first hand experience of the importance balancing game systems and the effects of lacking such balance.

Normally in EoS, each Pokemon species has two Abilities (usually taken and tweaked from the main franchise to suit Mystery Dungeon’s gameplay), an IQ group which determines the extra skills/perks the Pokemon gains upon raising IQ (eating Gummis), and a list of moves that they will learn on level-up. The dungeons themselves are random by layout, but each dungeon has a set item and Pokemon list that determines what can be found and fought. This randomised Rom gave each species of Pokemon random Abilities, movesets, and IQ groups. Furthermore, the set list for Pokemon were randomised, so although the 3rd floor for Mt. Bristle will always contain the same list of Pokemon, the Pokemon you find might usually only be found in a completely different dungeon and usually be more or less common.

Abilities I was given completely disabled weather effects which made me avoid potentially deadly scenarios early on and in future. One Ability didn’t affect my Pokemon at all, while another halved my partner’s movement speed, turns, and attack for the first 10 or so turns. The imbalance of Abilities made certain scenarios easier and even worry-free while it made other scenarios like early floor encounters extremely difficult.

Monster houses spawned early in the game; a normally rare, late-game challenge that makes the player use every resource, turn and strategy they can and consider their options carefully. My moveset included a move that damaged the entire room, saving me constantly from what would have been an unfair and deadly event.

There were plenty of frustrating encounters that I felt I had no control over. Most of these situations were due to the enemy units having strong, unbalanced properties, whether powerful moves or stats that are usually seen in late-game or boss-fights.

A Pokemon was once adjacent to my partner when we entered a new floor and one-shot them before we could attack.

I was instantly killed by a one-hit-KO move without knowing the Pokemon knew it.

My partner and I were attacking an enemy with incredibly good stats. It survived an unusual amount of turns before using a multi-hitting move to finish me off.

Fullerton describes “enjoyable activities” as having “clear goals, stable rules, and challenges well matched to skills...” (2018. p.101). Because the challenges and whether I got one-shot or lightly tapped was always so random, the challenge didn’t always feel enjoyable. The only times I felt in control was after an enemy had halved my health and within that instant, I realised I was going to fail the objective if I didn’t make careful choices for the next few turns. It was fun when it did occur due to the challenge still proving beatable, but in a way, the rollercoaster of snapping in and out of focusing or having to constantly be on high alert was mentally taxing.

Eventually after failing the second mission so many times, the game initiated a balancing/negative feedback loop (Fullerton, T. 2018. p.152) and gave me some healing and revival items to aid me on my next attempt. Funnily enough, despite playing this game multiple times as a kid, I never once saw this cutscene. In all honesty, it hurt my pride a little but was funny nevertheless to see how the increased chance/randomness and lack of balance had affected gameplay.

At this point in my journey, I ended up revising my objective. The game encourages the player to successfully clear a dungeon with little to no blackouts by using all of their resources. This is enforced with the high penalty for fainting which removes up to half of your items and gold carried on you. Being able to prepare before dungeons, taking a limited amount of resources with you, the high amount of information given to the player, and the turn-based, grid gameplay tells me that the game was originally designed to be strategy oriented.

The designer’s intention of gameplay changed due to its random nature. The player experience goal is now more akin to ‘trying again and not giving up, using everything you learn as you fail’ as you would see in games like Cuphead or other roguelikes. From an objective perspective, my goals changed to be ‘clearing the dungeon in as few attempts as possible’ rather than ‘little to no blackouts’.

Engaging gameplay is achieved when challenge and ability are balanced (Fullerton, T. 2018. p.98) . In this randomised version of Explorers of Sky, every story dungeon felt like a brick wall or dead end (Fullerton, T. 2018. p.320) where the only way to progress was by slamming my head against it until it fell.

Playing the regular game was extremely different. It was a gentle slope that gradually threw new challenges like the occasional move that hit in a line of sight instead of adjacent, or the boss fights you could prepare for. Seeing the effects of balancing systems first hand and how important they are was really interesting to experience. Although the randomised version can be incredibly frustrating and get a little tedious in its unwavering challenge, the newness and difficulty increase of my old experience satiates the Achiever in me (2018. p.103) with the new different cast of characters providing my Storyteller play style with new materials for telling my characters’ stories.

I’m curious to see how gameplay is affected in late game when dungeons are longer and how it feels when the challenges I was meant to face later on have already been faced before. My assumption is that because challenge is no longer increased over time, I will eventually become less invested and grow bored (Fullerton, T. 2018. p.98). I’ll see for myself soon enough!

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. ProQuest EBook Central. Accessed 9 September, 2021 from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

#reflection #balancing system #balance #wk8

[zealseal]

Wk6 Reflection - Pokemon Unite 'Case Study'

While playing Pokemon Unite, I realised how heavily the game revolves around Negative Feedback loops through their comeback mechanics. Tracy Fullerton states that these balancing relationships are used to "keep the game from resolving too quickly" (20p152, para 6).

Since rounds only last 10 or 5 minutes depending on the game mode and players may surrender with enough votes, players need enough incentive to stick through until the end.

As the enemy scores goals, the player's team is pushed back toward their spawn point. The goals situated closer to their spawn heal for more than those in the centre of the map. This allows players to jump right back into the fight sooner and allow them to heal, which means they can protect their goals for longer. The game system rewards players who aren't doing well and allows them to 'comeback'.

It's the same with certain wild Pokemon. Zapdos spawns at the last two minutes of the match. For whichever team defeats it, the opposing team's goals are left defenseless for a short period of time. This defenseless state means goals are instantly scored rather than require a charge-up time, and enemy players no longer heal from them for the duration.

Accompanying the last few minutes of the match is a double-point time period. Points scored are worth twice the points, whether you kill Zapdos or not. This not only feeds into the balancing feedback loop, but it also allows individual players a unique choice. They can deviate from securing Zapdos with their team, which risks a near-guaranteed victory, or if the match is close, could result in a sneaky win. The players are made to consider whether their opponents are attempting similar. Although this element of choice has the same options every match, the player will decide differently each time depending on their circumstance and the enemy team.

One negative aspect of Zapdos is that the system only counts the killing blow when determining which team should be rewarded. This often leads to frustration when an enemy player hides in nearby tall grass and springs in for the final hit, snatching away a hard-earned victory, especially since some Pokemon can attack from off-screen. Or, it may feel unfair if there is a team fight on top of Zapdos, and no one can see who had the last hit until the system tells them. Although it might seem unfair at times, this also puts priority for the players to scour the wild grass before they attack Zapdos. Or, it may give them a choice of whether they should wait and attempt the same. The behaviour and relationships of each Pokemon the players may choose from are also varied. Each may take up a role of Supporter, Attacker, Defender, or Speedster, but only one of each Pokemon can be on the same team (you can't have two Venasaurs, for example). Also, some Pokemon are better than others for the three lanes. This variety allows for team compositions and a bit of strategy.

Although the formal system, and map layout are consistent for each match, the system dynamics of each Pokemon, the balancing feedback loops, and how players interact with the system and make decisions are unique to each person, gameplay is always fun and exciting. Pokemon Unite is designed to keep the playing field even until the very last minute where any choice that is made has a significant impact to the overall result of the game. It makes players feel competent when they win a match as most of the gameplay elements are based on skill rather than luck.

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. ProQuest EBook Central. Accessed 9 September, 2021 from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

#wk6 #reflection

[zealseal]

Wk1-5 Concept: Scissors, Paper, Rock!

Sorry for the confusing title, this is something that should’ve been posted earlier in the conceptualising phase but has since grown due to my readings and classes. It’s more of a culmination of ideas throughout the five weeks.

Gameplay Mechanics

Moment-to-moment gameplay is a highly important element of game design. By honing the base structure and formal elements early in the design process, the game at later stages will consistently feel good to play. A strong skeleton also means that I can spend less time going back to fix and edit core mechanics and more time fleshing out the game’s features.

For this reason, and also considering that I’ll only be making a prototype, I’ve focused on core gameplay elements and moment-to-moment content first. The sub-points in italics are features that can be expanded upon from the base mechanics once the moment-to-moment gameplay is well refined.

The gameplay loop will include:

Basic attacks, charged attacks and special attacks.

Skill tree

Players can choose from branching paths how their basic attacks and special attacks interact with objects and enemies. E.g, Rock’s kick may be upgraded to deal extra damage OR, it may be upgraded to fling nearby objects at enemies and cause knock-back instead.

Ranged, Melee, and Utility/Healing skills.

Sliding or dodging.

Slightly increased cooldown after each consecutive use.

Character switching

Scissors

Melee. Damage, speed and stealth/surprise.

Can grapple onto certain surfaces and use momentum to swing onto usually unreachable platforms.

Can upgrade to (additionally) either: deal damage to enemies while swinging OR use to grapple and pull enemies toward the player.

Paper

Ranged. Damage over time, healing, object levitation.

Paper’s levitation will enable players to complete puzzles by sending out paper cranes and other origami to interact and lift objects.

Rock

Melee. Tanking/protection or damage, utility.

Can create rock barriers to block projectiles and enemy movement and break cracked walls.

Solving puzzles

Moving objects, coordination,

Players will be able to undertake various roles such as tank, healer, or dps. In later iterations of the game, and if it ever develops to the point where multiplayer can be achieved, the game may be playable with up to three or four players.

Three: A player takes up one of the three characters of Scissors, Paper, Rock and can use their own build for that character.

Four: A player can choose a colour palette and name tag. Each player can freely switch between every character and use their own builds.

By adding multiplayer, it would better accommodate for players who tend to take on a social role when playing games. Looking at games such as Trine and 9 Parchments, it also adds a level of chaos, strategy, sociability, and unpredictability. Personally, when I’m playing games similar with friends and the gameplay calls for a puzzle to be solved, half of the time I seek to wreak havoc by subtly sabotaging my friends. Introducing puzzles with (optional) teamwork was a really fun element of play and something I’d like to try and encourage more of in Scissors, Paper, Rock!.

While writing up the mind map, I tried out a few small icon sketches of each character. Another suggested element of game design was to implement visual references (icons and symbols) for menus instead of text. Not only would this create more appeal, but some symbols can be used to allow players to quickly interpret information conveyed by the system. A dynamic portrait of a heart shrinking might resemble current lives or health, for example. By creating small icons of each character and showing them on the skill tree for instance, the player will immediately be able to recognise whose skill tree they’re currently editing. Individual skills may have icons of scissors or origami paper as another example of how I plan to quickly convey information aside from text.

Other Comments

The original three was going to be Scissors, Paper, Gun. but because I couldn’t think of enough unique gameplay features and roles for Gun to undertake, I decided to change it to Rock. The benefits were that Rock could fulfil a tank/dps and utility role. Keeping Gun would’ve also had too much overlap with Paper’s ranged role.

It worked out well for the story concept. Gameplay wise, having the antagonists make a bullet-hell-storm for players to dodge through or homing projectiles for the player to reflect back sounds much more enjoyable than "stagger”.

#devlog #platformer #concept #mindmap

[zealseal]

Wk 5: Platformer Prototype

Adding a dodge mechanic, changing the rotation of a projectile to match the cursor’s position, and editing the graphics.

#platformer #prototype #image #screenshot #week5 #devlog

[zealseal]

Wk 5 DevLog: Platformer

Added a dodging mechanic.

Was hoping to make movement and gameplay more fluid by allowing players to dodge behind enemies to avoid damage. Mechanics will have to be refined multiple times and given feedback before it resembles anything fluid. Having a proper dodge animation would really assist the feel of it, however, given the emphasis on prototypes being efficient to quickly identify issues and refine base mechanics, I’ve held off on adding proper animations and stuck with a placeholder which does a decent job.

Added a cooldown to dodging.

Since dodging will have invulnerability frames, a cooldown is in place to balance it. There’s little challenge in indefinitely avoiding damage. I also used an object variable named ‘dodging’ which disables attacking if the player is mid-dodge.

Sword projectiles now disappear after one second.

This was to prevent them clogging up the system and having too far of a range. Once a charged attack action has been implemented, I can tweak the projectile’s lifespan to better balance it.

Added to the projectile’s movement which rotates the sprite depending on the mouse’s position.

Originally, I wanted to have the directional attacks be static. If you were facing left, an attack will face the same direction. Playing around with the mechanics in the GDevelop prototype, as well as similar existing mechanics from Terraria and Starbound, I’m starting to reconsider and change the targeting system to focus on the cursor’s position. This will need to be tested and given an external opinion of.

Got distracted and refined some of the tile art.

I really shouldn’t have at this stage but I’m an art student and you can only stop the urge for so long.

Added and removed a death system.

In this week, I tried to add a death and respawn system which failed miserably. Upon touching a bear trap (test object), the player should undergo “dying”. The character should freeze in place, play a death animation, before disappearing and reappearing at an angel statue.

Instead, the player was still free to move. The angel statue became a fountain of player models, all of which responded to the player’s input controls. After a few seconds, all player models, except for one, were deleted and the player could not move. The player was suspended in the air also. Projectile attacks only originated from the currently controlled player object, transferring over to the last one after all other models were deleted. Weird, but not what I need.

Other Comments:

Dashing feels clunky. Needs a visual indicator for when the player tries to dash while it’s still on cooldown. The movement and distance covered also needs further refining. I’m considering changing the dash to solely an animation where hitboxes disappear during the middle of the animation, thus creating invulnerability frames. This would be much simpler to achieve and may feel more fluid and responsive.

Sword projectiles need to be charged up and then released. Currently, it creates an infinite number of projectiles which disappear. I should also implement a basic attack for when the weapon isn’t fully charged.

#week5 #platformer #devlog

[zealseal]

Wk 4 Reflection: Platformer

[zealseal]

Wk 4: Platformer Prototype

Creating projectiles and refining movement.

#platformer #prototype #week4 #devlog #image #screenshot

[zealseal]

Wk4 DevLog: Platformer

In week 4, I attempted to further refine player movement. Although not intended to be a key aspect of this platformer like a Super Mario Bros’ game, making player movement that feels fluid and responsive can play a large part in a player’s enjoyment. I’ve also tried to use more variables to allow for greater flexibility and to allow easy tweaking.

Changes:

Refining movement:

Editing player acceleration/deceleration values

Adding momentum while in the air.

I made a falling animation to test whether my code was formatted properly and was recognising when the player was in the air. Afterwards, I added an action so that whenever the character was mid-air, the acceleration would be severely reduced, and the deceleration would be set to zero. Upon landing, acceleration and deceleration values reset to their original, global variables. This created an effect similar to inertia while jumping through the air. I wanted the player to still have slight control over their movements, and so reduced their mid-air acceleration instead of setting it to zero.

Whenever I start figuring out what conditions and actions need to be set, I try to write out my code in plain sentences. The mid-air momentum for example:

“While in the air, sideways directional control will not be received.” into:

“While not on the ground, set deceleration to x and acceleration to y.” before trying to find the conditions that best suit. Perhaps it’s a given, but not being fluent in any particular programming languages, I find this method to be very streamlined which helps while prototyping.

Adding an attack:

Adding a ranged projectile that moves toward the cursor’s direction before disappearing. Because I didn’t add a condition to when the sword projectile moves toward the cursor, the projectile continuously follows it. Unintended, but I can use this for other abilities too.

Gave each projectile a unique ID. Looking around online, I found a post which, in a way, allowed for unique variables to be set to instanced objects. I two variables, one called ID and a separate, global variable. The global variable counts upwards each time it’s used so that the number is always one ahead of the ID variable. The ID is assigned to a projectile upon creation/left clicking. Although this worked for the most part, this always left one projectile, the most recently created one, to follow the mouse after being created. I’ll have to go back and see if I can find a better method for directing projectiles.

#week4 #devlog #platformer

[zealseal]

Wk 3: Platformer Prototype

Focusing on the basic rules and mechanics before building out.

#platformer #prototype #week3 #devlog #image #screenshot

[zealseal]

Wk3 DevLog: Platformer

Being unfamiliar with GDevelop, I started by following the platforming tutorial provided on their website. I found the program quite easy to use, especially with prior experience using GameMaker Studio. Starting out, most of the sprites are placeholders while I focus on refining these core formal elements.

player movement and sprite direction, floor tiles and collisions, backgrounds, and experimented with variables for coin collecting.

#devlog #platformer #week3

[zealseal]

Wk 3 Reflection: Platformer

Reading through Tracy Fullerton’s Game Design Workshop book as part of the unit’s readings has made me realise things that should have been, but weren’t, apparent to me initially.

One realisation in particular is the fact that game designers don’t create fun. We make the systems, not the player’s experiences. As described by Fullerton, it’s a second-order design problem that prevents us as game designers from simply telling people to “enjoy yourself.”

The concept of a second-order design problem also enlightened me as to how varied games can be played. Take Skyrim for instance. One Youtuber, Ymfah, challenges himself with self-imposed rules that should, at a first glance, make the game incompletable. His “How to beat Skyrim without Walking” (2021) video shows gameplay of him doing exactly that – he cannot move, and so, must use other means to complete the game. In a way, he’s creating his own “magic circle” within the game’s pre-established one and in turn, making his own fun.

I didn’t realise until now, how proud I would have been, had I been part of Skyrim’s design team, to see one of my players striving to break and push the game to its limits, bound by the game’s rules, and their self-imposed ones. In other words - making their own fun using the tool that is Skyrim.

References:

Ymfah. (2021). How to beat Skryim without Walking. Youtube. Accessed August 25, 2021 from https://www.youtube.com/watch?v=MmpXf0nFCII&t=332s

Fullerton, T. (2018). Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. ProQuest EBook Central. Accessed August 12, 2021 from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

#week3 #platformer #reflection

[zealseal]

Wk2 Narrative: Platformer

The story of Scissors, Paper, Rock loosely follows a group of three school kids and their imaginations. The kids have taken the roles of three heroes whose powers come from the hand game, scissors, paper, rock. Their game is soon ruined by their fourth friend who insists on playing ‘gun’, a type which trumps all others. To restore order within their game and friend circle, the three heroes must travel across the land, defeating all other ‘gun’ users, before eventually confronting their friend in battle.

#platformer #week2 #narrative #story