n11283688-gdevelop

[n11283688-gdevelop]

Oh Buoy! Postmortem

Redevelop & Redesign

If we were to redevelop the prototype, we would make sure that the player character controls and physics were fully complete before designing the levels, as any changes we made to the player made us redevelop levels to work with the updated player.

If we were to redesign the prototype, we would add some sound effects to the game, as that would help signify to the player what events are happening, such as a danger sound when their oxygen gets low, or an electricity sound when the jellyfish begins zapping.

Further Development

If we were to develop the game further, the main thing that would be focused on is extra levels, and extra mechanics to go along with them. These may include having buttons do more than open doors, such as activating bubble columns or spawning boxes, or having walls that only players can pass through and not pushable boxes.

[n11283688-gdevelop]

Oh Buoy! Playtesting and Improvements

For Assignment 3 playtesting, I developed a questionnaire for users to fill out before playing the game, to get a sense of which demographic they fit into and whether they are apart of our core audience. This would help us measure whether their feedback was a result of our game needing improvement or their inexperience or distaste with our genre.

Next, the players played the game while the testers observed and took notes, before finally directing them to a survey where the player gave aspects of the game a score from 1 to 5, in order for us to see which parts of the game worked and which didn't

Playtesting Results & Fixes

Player Physics

One of the main issues encountered were certain bugs that affected the players movement. One of which was that occasionally the player would jump much higher than intended, causing confusion to the play testers. To fix this, a debug text was added to the UI, that updated to math the players current y-velocity. Doing this and then measuring a normal jump let me know the max velocity the player reaches.

The players max velocity is -574.5 when jumping

Using this, the players velocity can be capped at this value to prevent them from jumping higher.

Another issue was that the player could lose all vertical velocity when they moved into a wall while falling/rising. This was resolved by checking whether there was a wall on either side of the player and preventing them from moving in that direction if so.

Oxygen Meter

Another issue that players experienced was that they didn't pay attention to the oxygen meter and were surprised when they died from lack of oxygen. This also affected how players interpreted the oxygen box, as they did not notice that oxygen increased when colliding with the box.

This can be resolved by having the oxygen be measured by a bar underneath the health UI, that changes colour based on the amount of oxygen left.

Oxygen over 50%

Oxygen over 25%

Oxygen over 0%

Oxygen when being refilled

Level Changes

The other types of issues encountered were those relating to the layouts of levels, one of which is that a player could push a box past a door off of the button keeping the door open, preventing the player from using the box. This can be resolved by moving the button further away from the door/having a small outcrop to prevent the box from moving past a certain point.

Before

After

Another issue had to do with the final level, where players would miss the pearl after ascending the bubble column and have to restart the level due to either falling off the map or running out of oxygen. This can be fixed by extending the platform over to catch the player and adding an oxygen box on it.

Before

After

[n11283688-gdevelop]

Oh Buoy! Development

To begin development, it was decided that the games mechanics would initially be programmed separately, and then combined at a later date. In my development, I created the movable box, bubble columns, optional collectables and the final pearl that takes you to the next level.

Initially, I started with the bubble column pushing the player up immediately when colliding, regardless of whether they were on the ground or not. This posed an issue, as the platform I had placed a collectable on could only be accessed if the player jumped before entering the bubble column.

This meant that players had to jump outside the column, move into the column while moving upwards, and then change direction to make it to the platform. This caused it to be very inconsistent and tedious to pull off.

I was able to improve it by instead only having the player be pushed upward if they were already in the air, allowing them to position themselves where they wanted in the bubble column before jumping and only needing to move in one direction, which made it much more consistent.

[n11283688-gdevelop]

Assignment 3 Discussion - Oh Buoy!

Genre

After joining a group, we all discussed how to make our prototype. We first decided on the genres our game would fall under, as that would dictate the mechanics we would put into our game. We decided on developing a 2D platformer with simple puzzle, as that seemed to be one of the easier genres to develop using GDevelop while providing some variety to the gameplay. It also allowed for a very large demographic for playtesting, as the platformer is one of the most well known genres of play.

Setting

After that was decided, we then chose a setting that our game would take place in, as that would influence the look of the game as well as justify some of the gameplay elements. In this case, we left it up to the artist in our group, as the decision would affect her most of all, and she recommended that the game take place under the ocean. We agreed, and this decision inspired us to also add an oxygen meter that depletes when the player is not near an oxygen tank and refills when they are, adding an extra level of challenge to our game with a timed mechanic.

Platforming

For platforming mechanics, we chose some sea creatures to act as obstacles for the player, namely eels that swim from side to side, killing the player if they touch them, and jellyfish, which try to shock the player at separate intervals and can act as platforms when not shocking. This can give the players another timed challenge during gameplay.

Puzzle

For puzzle mechanics, we decided on a simple button that the player can stand on to open a door, as well as a movable block the player can push that can also activate the button. The block can also act as a platform, allowing the player to reach higher places by moving the block.

Chapter Review

In Chapter 11 of the Game Design Document by Tracy Fullerton, it is explored how to make sure the game that we develop is fun, and gives a way to analyse how fun a game is through different requirements that a game can meet. Our game mechanics can then be analysed, improved upon or added to based on the list porvided.

Reaching and Exceeding Goals - Subgoals need to be established to keep players interested while contributing to the overall goal of beating the game. In our game, each level could have a goal be to collect a pearl, with the game ending once all the pearls are collected.

Exploration & Discovery/Collection - Another way to keep player engagement is to introduce a collectable of some sort that is more challenging to get to than the level end pearl, either by being well hidden, requiring a certain puzzle mechanic or through difficult platforming. This would also create an interesting player choice, as trying to obtain the collectable is risky and might cause the player to restart the level.

The collectable also contributes as a reward within the game for completing a difficult puzzle/platforming challenge, and can represent progress if each level has a collectable to obtain.

Sources

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[n11283688-gdevelop]

Road Rage Postmortem

If I were to redevelop the prototype, I would try to move the origin points of all objects to their centre, as I find it easier to work with and code for.

If I were to redesign the prototype, I would make the car respawn timer decrease while also increasing the speed of the game. This would make it so that the gaps between the cars don't change size, as the distance the cars currently have is the perfect size for the player to weave between them. This would make the only increase in difficulty be based on the players reaction time, which would get harder until the game ended, because currently the game does not end if you are competent enough at the game.

[n11283688-gdevelop]

Road Rage Development Post

For the development of Road Rage, I wanted to especially focus on the contrast when the car is in rampage mode vs when it isn't. The three main ways I plan to do this is through gameplay, visuals and audio.

Gameplay

I was able to do this through gameplay by doubling the speed of all objects, making it seem like the car was moving twice as fast as before, as well as only giving players a score when they destroy a vehicle.

Visuals

To change the game visually, I started with changing the colour of the rage meter at the top of the screen, from green when calm to red when rampaging.

This changed helped but only slightly. I decided to also change the background colour of the scene to see if that would help.

This changed worked well, but the background now contrasted with the trees. I thought it would fit if the trees also changed during a rampage. I considered having the tress be set on fire, but thought that would be too hard to draw, so I settled on them looking dead instead.

Audio

To successfully contrast the audio between the two modes, I need to first implement audio for the calm mode. For the calm music, I wanted to find something happy but still reserved. I eventually decided on the song 'Carefree' by Kevin MacLeod.

To contrast with this, I wanted a heavy rock song with a high tempo. I chose the song 'Action Rock' by MaxCoMusic.

Sound effects were also added for explosions.

Sources

Carefree Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 4.0 License http://creativecommons.org/licenses/by/4.0/ Music promoted on https://www.chosic.com/free-music/all/

Action Rock by MaxKoMusic | https://maxkomusic.com/ Music promoted by https://www.chosic.com/free-music/all/ Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) https://creativecommons.org/licenses/by-sa/3.0/

Arcade Game Explosion, Obtained From https://mixkit.co/free-sound-effects/explosion/

[n11283688-gdevelop]

Road Rage Elevator Pitch

Road Rage is a simple Top-Down 2D racing game on the PC. You play as a car taking a calm Sunday drive, avoiding the cars going slower than the speed limit and having a good time. That is until your rage builds enough and you go on a rampage destroying everything you touch, and getting points for it. Road Rage is designed to emphasise the contrast between these two styles of gameplay, calm/reserved and fast/destructive.

Vector, V. (2017). Cars on the road view from above vector illustration stock illustration. iStock. Retrieved from: https://www.istockphoto.com/vector/cars-on-the-road-view-from-above-vector-illustration-gm815783226-132047785

[n11283688-gdevelop]

Blasteroids Postmortem

Readings

Chapter 6 and 9 of The Game Design Workshop by Tracy Fullerton helped inspire my design process during the development of Blasteroids. The brainstorming challenge ‘Come up with a game that makes interesting use of only one control’ provided in chapter 6 helped inspire one of the unique selling points of my prototype.

Chapter 9 of the Game Design Workshop assisted me greatly when it came to playtesting my prototype, as it allowed me to get valuable feedback from naïve play testers.

Development

If I redeveloped the prototype, I would try to implement sound effects, as I feel that they are very important in terms of providing feedback to the player directly. This would help with one of the biggest problems with my prototype, the fact that players don’t register that they got hit. If my prototype had sound effects, that wouldn’t be an issue.

Design

If I redesigned the prototype, I would put a larger focus on the variety of upgrades the player could obtain, as the current selection is highly repetitive, and the game becomes not interesting after a while. If I could develop the game further, I would also implement a shop in the menu where players can buy upgrades instead of collecting them from asteroids, and make the game have a longer, permanent progression system. Players would use their accumulated score gathered during gameplay to purchase them, giving the score a practical application.

Sources

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[n11283688-gdevelop]

Blasteroids Playtesting

In Chapter 9 of the Game Design Workshop by Tracy Fullerton, playtesting is outlined in great detail, including recommended methodologies and who should playtest the prototype at what stages of development. Fullerton recommends to playtest the prototype yourself during development, to get the game to a functional state. I achieved this while developing the game already, and any major bugs have been fixed.

One of the things I felt while playing was that the ship felt stiff when controlling, as an instant force was being applied to it when the player moved. This was remedied by changing the instant force to a permanent one, which made the ship seem a lot smoother, due to it having inertia.

Fullerton then recommends to playtest with confidants to get an outside perspective on the project and identify issues that you have overlooked. Later on in the chapter, Fullerton also gives a recommended methodology to follow when conducting playtesting, which I will use for mine.

Create the prototype

Previous posts I have made outline the development I've accomplished on the prototype.

Prepare your Questions and Script

Script

Welcome Playtester, and thank you for assisting me in the development of my prototype. I am Ethan, a student studying a Bachelor of Games and Interactive Environments, and I am developing a prototype for a game. Today, you will playtest the prototype and provide feedback on it, which I will use to make improvements to the game. A questionnaire will be held after your playtesting session relating to your thoughts and feelings on the game. It is important that the feedback you give is honest, as that has the best chance of improving the game the most. Also keep in mind to try to verbalise all your thoughts while playing the game. You may now begin your playtest.

Questions

What are your overall thoughts on the game?

What were your thoughts about gameplay?

Were you able to learn how to play quickly?

What is the objective of the game?

How would you describe this game to someone who hasn't played before?

Now that you have played the game, is there any information you feel would have been useful before you started?

Is there anything you did not like about the game?

Was anything in the game confusing?

Recruit Testers

For play testers, I chose two of my roommates, as they were the most readily available people I had, and both had the capacity to be very honest. One was extremely knowledgable when it came to video games as they had plenty of prior experience, and the other was less experienced.

Playtesting

Playtesting was conducted by having each player read the script above, then begin their playtest. Notes were taken during the playtest about the testers actions and thoughts as they played. The answers to the end questionnaire were also recorded.

Summary

Both play testers enjoyed the beginning moments of the game, appreciating that the object colours helped indicate what each object does, as well as the simple shape outlines being pleasing to look at.

Both play testers found the health and energy UI hard to keep track of, recommending that they be placed closer to the centre of the screen.

The playtester with less experience found it difficult to understand how to move, and didn't associate the 'boost' tutorial on the menu screen to mean movement.

Both play testers also had difficulty understanding what each upgrade symbol meant before picking them up.

One play tester wished that the upgrades had limits, as a bit into the game the ship became hard to control due to the speed and hard to see due to the large amount of bullets being fired.

Changes

To attempt to fix the energy and health UI issue the play testers experienced, I created health and energy bars located at the top of the screen, hopefully giving players an idea about how much energy and health they have relative to their maximum values.

As shown above, the bars scale relative to their centres, as both play testers spend most of their time in the centre of the screen. The energy bar also grows in size when an energy upgrade is collected, providing player feedback

To further fix the issue of players not understanding what the upgrades do, an upgrade menu was added to explain what each one does, which can be accessed through the main menu.

Sources

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[n11283688-gdevelop]

Blasteroids Development Post

GDevelop

The main thing I've had issues with during development was figuring out how to spawn a random upgrade when the player destroys an asteroid. In other engines, I would have added all the upgrade objects to an array and have one be randomly selected when spawning. However, GDevelop does not have an array option that holds game objects. Instead, I generate a random number and then save that to a global variable 'RandomNum', then check if that variable is a certain number before spawning the associated upgrade.

GDevelop also doesn't have the ability to create base classes for objects, meaning that every upgrade has to detect collision and control movement individually. This discouraged me from adding many upgrades as it would have made the event screen too long and hard to manage.

Game Design

One of the things I wanted to make sure I accomplished for this game is to try to make it seem somewhat complete, even if it is still very basic. The aim of my thought process was to make sure that someone who has never heard of the came could play it completely without my input. After a while, I determined that to accomplish that I would at least need a menu screen, a game over screen and a tutorial, as shown below.

While extremely basic, I hope these screens inform the player of all they need to know to play the game.

I also wanted to have all art in the game made by myself, as it is an aspect of game development that I am not experienced in. I decided to still keep it simple however, as I felt it was still important to focus mainly on the mechanics and gameplay of the prototype, and I didn't want the art to be too complicated to take time away from that.

[n11283688-gdevelop]

Chapter 6 Influence

This week, I read Chapter 6 of The Game Design Workshop by Tracy Fullerton, which focused on the Conceptualization stage of game development. This blog post will outline how this chapter influenced my thought process when conceptualizing Blasteroids.

Brainstorming

The first way I was inspired by Fullerton came in the Brainstorming section of the book, where it was recommended to state a challenge before you start brainstorming. One of the examples provided stated to 'Come up with a game that makes interesting use of only one button for control.' (Fullerton, 2018) This inspired one of the unique selling points of Blasteroids, in which all of the ships functions are handled by the same button.

X-Statement

Fullerton also recommended the development of an 'X', which featured both a razor, a short sentence for developers to consider when choosing which ideas to keep and discard, and a slogan, a short sentence used to market the game to your target audience.

When considering the razor for my game, I wanted prototype development to be balanced between being quick to finish while being somewhat complete, as opposed to my last project which was neither. I believe that the best way to do this is to make an 'endless' game, where the only win condition is to get a high score, and the only way for the game to end is either for the lose condition to be met, or for the game to stop functioning. So I looked to other endless games for inspiration on my design. I eventually considered the game 'Vampire Survivors', a bullet-hell rouge-like where players gather upgrades to improve their weapons against an ever increasing horde of enemies. This inspired my razor: 'Asteroids meets Vampire Survivor Upgrades', which influenced my ideas to have upgrades occasionally spawn from asteroids, while having asteroids spawn faster as more upgrades were gathered.

For my slogan, I wanted to keep it simple to understand for as many people as possible, and also reflect the main goal of the game. I figured the slogan 'Rack up your points' fit well.

Formal Elements

The last thing I focused on from Chapter 6 was to consider the formal elements of my game. Fullerton provided recommended questions to ask myself to help flesh out these elements:

What is the conflict in my game?

Player is stuck in an asteroid belt and needs to defend themselves in order to not explode.

What are the rules and procedures?

Player takes damage when colliding with asteroids, this also destroys the asteroid.

If the player loses all their health, the game is over.

The player uses energy when performing actions, once energy reaches zero the player cannot perform actions.

Energy refills when the player is not attempting any actions.

Asteroids can drop upgrades when destroyed.

Upgrades automatically move toward the player.

When the player collides with an upgrade, the upgrade is applied to the ship and the upgrade object is destroyed.

The players score increases for every asteroid destroyed.

The asteroid spawn rate increases with every upgrade obtained.

What actions do the player take and when?

Player can rotate their ship using mouse movement when trying to aim at asteroids or in a different direction to try to move to avoid them.

Player can move the ship forward when an asteroid is moving toward them or an upgrade is.

Player can shoot bullets when an asteroid is in front of the ship.

Player can shield themselves when they don't have enough time or space to move out of the way of the asteroid.

Are there turns? How do they work?

There are not turns.

How many players can play?

Only one player can play.

How long does a game take to resolve?

Games take between 10 seconds and 5 minutes to resolve, which I find appropriate for 'endless games'.

What is the working title?

Blasteroids.

What platforms will this game run on?

The prototype will be developed for PC but considering the extremely simple control scheme the game would be appropriate for mobile devices.

What restrictions or opportunities does the environment have?

The environment does not provide any restrictions or opportunities.

Sources

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[n11283688-gdevelop]

Blasteroid Elevator Pitch

Rack up your points in Blasteroid, a Sci-Fi asteroid game where you control a spaceship that needs to destroy asteroids to get the highest score. The only problem is that the spaceship isn’t fully functional, so all the ships functions are handled by the same button, the left mouse button. That includes the ships weapons, thrusters, and energy shield. However, you can obtain upgrades that improve your ships capabilities. It is set in the middle of an asteroid belt and is comprised of simple shapes with simple outlines.

[n11283688-gdevelop]

Paci-Fist Postmortem

Chapter Discussion

According to Chapter 10 of The Game Design Workshop by Tracy Fullerton, designers need to focus their efforts on making sure the game is functional, complete, and balanced, and provides steps on how to do so, which influenced my design process.

Functional

To test that my game is functional, I needed to have a play tester play my game and determine whether they can finish the game without any input or assistance. When this was done with my prototype, players found it hard to understand how to complete the second jump of the level, as it required the player to point the shield at the moving enemy and bounce off it to reach the platform. This could be resolved by adding a tutorial that explained how to use each weapon in the form of text popups that appeared when the weapon needed to be used.

Complete

To test for completeness, I need to look out for moments during playtesting where the rules of the game can be argued on or whether the player cannot make progress. One such moment was when a player fell off the platforms and missed the ‘death plane’, causing them to fall forever. This can be fixed by increasing the size of the death plane, or implementing a rule that if the player goes under a certain y-value then they respawn.

Balance

Regarding the Balance section of Chapter 10, Fullerton mainly focuses on balancing multiplayer games between two players, both symmetrically and asymmetrically. However, there are still steps provided that can help to balance single player games.

One example of this is balancing the games variables. Some variables I have in my game include the players health and jump height/launch power. I set the players health to be three so that a new player, who didn’t understand that an enemy could hurt them, could be damaged and remain on two health, not cause stress of having only one heart left. The jump height in my game was also balanced with the launch power the player gets when landing on an enemy with their shield, which allowed me to place platforms at a distance so that the player had to launch off an enemy to reach them.

Game Progress

Since I usually focus on the functionality of the game and almost completely ignore how the game looks during development, I decided that I should try to focus on the look of the game instead. Since I’m also inexperienced with the visuals, I originally thought that having a smaller canvas would be easier to work with, which is why I made my game in a pixellated style.

To begin with, I found a knight’s sprite online (gathered from here) that I used as the base of my character, which is shown below.

Using this sprite as a base, I removed the sword (as the player weapons circle around the knight separately) and created walking sprites to use as animation.

The slime enemy was also shrunken to a 16x16 canvas size to also be pixelated.

A pixel heart was also made, which was originally completely red, but I eventually added the golden outline.

Finally, I developed a basic but seamless grey cobble texture to act as the floor, which I feel fit within the medieval fantasy aspect of the game.

After making those assets, they were implemented into the game along with other changes, causing my final prototype to look like this:

Only the shield could be implemented due to time constraints.

Redevelop

If I were to redevelop the prototype, I would develop it in a different game engine, as GDevelop does not have the player velocity modification I thought of using when I was considering the games feasibility. This is apparent when the player bounces off an enemy with their shield, as instead of a smooth force being applied, the player seems to teleport upwards, as the force could only be applied instantly, and did not affect the velocity of the player, only their position. This would have also given me more time to implement the other weapons, instead of trying to fix this movement issue. If I had to use GDevelop in redeveloping the game, I would have chosen a much simpler concept to better work within the limitations of the engine.

Design

If I were to redesign the prototype, I would have replaced the moving slime enemy on the first platform with a static ‘training dummy’ enemy that can’t damage the player. This gives the player multiple opportunities to learn about the shield bounce mechanic without worrying about their health. I would also change the flying slime enemy with a different simple flying creature that moves back and forth, as it looks a bit off with the slime floating in the air.

Sources

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

Sun, O. (2014). 16x16 Knight Sprite. DeviantArt. Retrieved from: https://www.deviantart.com/obinsun/art/16x16-Knight-Sprite-458197531

[n11283688-gdevelop]

Development Post/Chapter Review

To properly understand all the relevant aspects I need to consider when making my platformer prototype, I read Chapters 3-5 of Tracy Fullerton’s Game Design Workshop book, which goes over the basics of game design that designers need to consider when making a game.

In Chapter 3 of the book, Fullerton describes the importance of Formal Elements in games and to properly consider how to utilise them when designing a game. The elements that Fullerton goes over in the book include Players, Objectives, Procedures, Rules, Resources, Conflict, Boundaries and Outcome. To properly develop my prototype platformer, all these elements will need to be considered.

Players

My platformer will be played by one player, taking on the role of the heroic knight. The game will be structured using the Single Player versus Game Interaction Pattern, as it is the easiest to make in the short timeframe for the prototype.

Objectives

Fullerton also describes several ways to categorize the game based on the main objective. Using the list provided, my prototype would fall under the Rescue category, as the main objective is to rescue your noble steed. This category also recommends that other sub-objectives be introduced to motivate the player to make progress. This will be done by placing coins in the direction the player needs to go to progress.

Procedures

I will also need to consider the procedures that need to be developed for my prototype to function. Some important functions to consider are the Starting Action, Progression of Action, Special Actions and Resolving Actions.

Since the platformer is made using GDevelop, the starting action would be pressing the play button to start the game. Progression of action is seen in the players controls, where they can move left/right using the a/d keys as well as the left/right arrow keys respectively. The player can also jump using the spacebar and aim their current weapon using the mouse. Special actions will mainly occur when interacting with enemies, such as bouncing off them when a shield is equipped. Reaching the noble steed will be the resolving action that ends the game.

Rules

There are several different types of rules that need to be considered when prototyping. These include rules that define objects and concepts, rules restricting actions, and rules determining effects.

Rules Defining Objects and Concepts

These rules are self-explanatory, as they define the objects and concepts found within the game. Some rules that define enemies in my game include that they move sideways at a constant speed, switch directions when reaching a certain point and damage the player when in contact.

Rules Restricting Actions

These rules are designed to prevent the player from performing unwanted actions, such as moving into a losing state or balancing gameplay. Due to the prototype being so small, there are currently no rules in this category that I can think of.

Rules Determining Effects

A rule that applies to my prototype in this category is that the player respawns at the beginning of the level if their health reaches zero. This provides a punishment to the player for not managing the challenge that the enemies apply.

Resources

Resources will be used in the prototype to motivate the player into making progress, mainly through the players ability to collect coins. The coins will be placed in a way that encourages the player into moving in the right direction. The prototype will not have a monetary use for the coins, however it may need to be considered for future development. Another resource that will motivate the player is their health, however instead of the player being motivated to gain health, they will be motivated to not lose it, as losing all of it will result in a loss of progress.

Conflict

There are three main ways to create conflict in a game. Obstacles, Opponents and Dilemmas. Due to the prototype being a simple single player platformer, the only source of conflict will be from the obstacles between the player and the goal. These obstacles would include moving enemies, bottomless pits, and large spikes.

Boundaries

A simple boundary that the prototype will utilise is that the player will respawn if they fall ‘off’ the screen, defined as the player object moving completely below the view of the camera. Due to the player not being able to fly, this boundary can also be utilised at the edges of the playable area, as if a player jumps off an edge, there will be no platforms they can land on and they will be force to respawn.

Outcome

Due to the simple nature of the platformer, there is no definitive lose outcome. The only loss a player may experience is respawning at the beginning of a level. Given this fact, the only outcomes possible are either the player beats the level or the player pre-emptively quits.

Fully considering these formal elements has encouraged changes that need to be made to my prototype, namely the ways the player is encouraged (or discouraged) to do certain actions. This lead me to add a health system to my prototype, along with collectable coins to encourage players to go in the correct direction.

Sources

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[n11283688-gdevelop]

Paci-Fist Elevator Pitch

In the 2D-platformer Paci-fist, you take on the role of a heroic warrior, who must save your kidnapped noble steed. However, you cannot defeat enemies, and instead must find weapons to unlock movement abilities to avoid enemies and traps. These include throwing a spear tied with a rope to swing across chasms, launching yourself off the ground using a hammer, and bouncing off enemies using a shield. The game is set in a medieval world and has a pixelated style.

[n11283688-gdevelop]

First Post

This is the first post I am making to this blog. It's supposed to be an About Me post, however I already spent the time making that it's own page, so if you're looking for that, it's in the About Page.