code-x

[code-x]

Assignment 3 First Playtesting Session

For our first playtesting session, we had one playtester who had heard of our game and 2 naïve playtesters. The entire time playtesting was very enlightening as the playtesters found many flaws in our game but also had a lot of encouraging comments about it too.

Some of the flaws that were found were:

Playtesters being confused by the 2 different attack animations and how they worked (they were randomized).

The first attack animation, a poke, had playtesters feeling that its range was too short and didn’t want to use it.

The second attack, a larger sweeping attack, frustrated the playtesters when they couldn’t work out how the attack worked.

They couldn’t tell from the animation where the attack hitbox was.

It was not clear that the player needed a sword to attack the enemies.

Every playtester said that the speed of the moving platforms is too slow.

Some playtesters could not find the exit to the next level and suggested that arrows or signs would be helpful to find their way through the level.

Some playtesters got hard-locked in the first puzzle section because they did things in the wrong order.

The jump didn’t feel right for some of the playtesters.

Some jumps that the player shouldn’t have been able to make were possible, negating some of the mechanics.

Playtesters wanted a checkpoint because it felt too punishing if you fell in the water and died.

Some of the encouraging comments were:

They like the art style of the game.

They enjoyed the intro music of the menu screen.

The sounds and overall feel of the game was enjoyable.

The mechanics were interesting.

One thing that we noticed was that none of the playtesters interacted with the interactive menu screen however they all liked it once they knew it was there and said that it would have helped them understand the mechanics of the game better if they had known it was interactive. All in all the amount of information and feedback gathered was awesome and will help us to improve our game for the next playtest.

#development #igb220

[code-x]

Assignment 3 Development Progress

Game name: Keyper

Keyper is an adventure-style 2D platformer that will be playable on consoles and PC.

Game elevator pitch and documentation Keyper is an adventure-style 2D platformer where players control a bandit trying to break into an encampment to break out their gang of little bandit friends, who are all being held captive. The player traverses through the dark and ominous woods, avoiding guards as they patrol by, attacking creatures that inhabit the area, collecting items to aid them and trying to find keys to unlock their friend's cages.

Tools used to facilitate team communication

Discord for communication and team meetings to discuss task items.

Google Drive for assignment document storage.

Preferred contact method outside of discord is student emails as listed above.

Tools used to facilitate Game Development

GDevelop will be the game engine we will be using.

Tiled will be used for breaking up sprite sheets and level creation.

Piskel for any edits that need to be made to our assets. 

What is our Minimum viable product goal?

To develop a playable prototype of the game Keyper and to implement all the main gameplay mechanics so we can playtest, get feedback then iterate on the game design.

Game rules

Player has one life.

This life is represented as 5 Hearts, with each heart being a percentage of the player’s health. 

When the player’s health reaches zero they die.

If the player touches an enemy, is hit by an enemy, or an enemy's weapon, they will take damage.

Enemies can be hit (Attacked) by the player. Player’s hits damage enemies.

Enemies die once damage taken exceeds their hit points.

The player can collect keys; the keys will be used to open the cages/prisons where their friends are held captive. Players shrink/grow if they eat mushrooms.

Players can open chests revealing valuable items and weapons.

Coins are used to guide the player through the levels and as a scoring mechanism collected as a scoring used in a leader board.

Weapons have a quality. The more a weapon is used, the quality will decrease.

Players shrink/grow if they eat mushrooms. 

Playable Prototype for playtesting

For the prototype Keyper, the prototype will need to have the following mechanics from the mechanics to be implemented section to be ready for playtesting. We will need to review and finalise the game’s elevator pitch.

Mechanics to be implemented 

The prototype needs to have a shrinking and growing mechanic added; the trigger for this to occur is a plant/mushroom that the player “eats”.

Ladder climbing mechanic added.

Ladder climbing animation added.

Weapon attack mechanic added - melee sword.

Chests that have items that are useful to the player’s progression and the keys that the player can collect to open the cages of their trapped friends.

Once the key is collected, it is saved/stored on the player until used (Maybe displayed on the UI). 

Interaction button(E) - When a player opens a chest, uses the key to open cages/prisons or "eats" mushrooms. 

Enemies in the world that have basic movement and AI. They can attack the player and be attacked by the player; once killed, they are removed from the game.

Enemy movement - Patrolling

Jumping mechanic 

Player controls

Player attack - Attack Button(Q Currently) - can only be used when the player has a weapon.

Run Button (Shift)

When a player takes damage, they flash. 

Menu screens and menu navigation.

Sound effects when a player uses a weapon, an enemy dies, when friends are freed music plays.

music - main menu screen, background sound, the main game 

leader board

moving platforms mechanic.

A world/level needs to be created for players to traverse.

Score - Collecting coins. 

Level progression. 

Weapon degradation is shown as a UI element.

A weapon is repaired when picking up a new weapon of the same type. 

Player health bar. 

Playtesting Timeline

Two main playtesting sessions are planned to iterate on the game’s design. During each session, the playtesters will be asked to fill in a short questionnaire to gather background information about them this is so we can understand the type of players the playtesters are. Then a script will be read to the playtesters so they understand what is about to take place and gets the playtester the mindset of describing aloud. Once the playtest is over, the playtesters will be asked to fill in a short survey about the game and what they experienced. While the play tests are happening notes will be taken about what the playester said and the events that took place. The first session will take place in week 11/12, and all findings from this session will be documented and reviewed to identify issues or improvements that need to be made. Based on this feedback, the prototype will be modified accordingly for the second playtesting session in week 12/13.

#development #textbook #igb220

[code-x]

Assignment 2 One-Sheet One-Page Final Design

With the One-Sheet of my assignment complete, my attention now moved to the One-Page this is where I could add all the cool things and ideas I had for the game, like what the shop would look like inside the ship thing you might be able to get from the shop. Some aspects of the game that I would like to add that are currently missing from the prototype. For instance, you could recharge your shield and expand your inventory. The enemies may drop powerups, and the fact you can buy new ships that have different attributes. This was a fun assignment as it let my imagination create the game I want my prototype to be.

One-Sheet:

One-Page:

Sources:

 いらすとや. (2022) かわいいフリー素材集 いらすとや. Retrieved September 10, 2022, from https://www.irasutoya.com/

Kenney. (2022) Kenney • Home. Retrieved September 10, 2022, from https://www.kenney.nl/

Alen. (2013) Starfield - Free Stock Photo by Alen on Stockvault.net. Retrieved September 10, 2022, from https://www.stockvault.net/photo/152183/starfield#

#development #igb220

[code-x]

A Racing Game Post-mortem

This was my first attempt at making a racing game prototype, and I thoroughly enjoyed it even though my prototype was not complete to a level that I would have liked it to be, there was a lot of learning to be had in creating this prototype as it was a big step out of my comfort zone. The ideas given to me about balance from my lecturer and Tracy Fullerton book The Game Design Workshop (2018) really had a big influence on the direction that this racing game took and even though the prototype was incomplete, the playtesters did enjoy the prototype. They mentioned that “The controls for steering the vehicles were very good. The changing of the road surface was a really cool mechanic, and the transitions were very smooth and made the game more interesting.” And “The driving controls felt very smooth and was easy to understand, the road surface changing was also very interesting, and you could definitely feel the difference that the change in the vehicle had while driving on the different kinds of road.”. However, they also said “Ai not functioning properly, the player needs to receive some prompts as to how to play the game. Needs an end state.” And “I think it needs an endpoint or goal, maybe some levels in difficultly as well.”  

If I were to change anything about how I developed my prototype. I would have spent a lot more time researching how to get AI cars working in GDevelop as this was a massive thing that was missing from the game. I also would have used another method for building the track as using sprites was a big pain, and I think it may have been better to do the track switching with layers rather than sprite animation swapping. 

If I were going to change something about the design of my prototype, it would be a suggestion that one of my playtester had said, “This would be a great single-player best lap time game.” This is a great idea as I could have a leaderboard, and the players could compete to get the fastest lap times. Also, another idea was rather than having the track as asphalt, sand, and dirt and having to match the track. The rumble strips on the side of the track could change colour, and you’d have to match your vehicle colour to the colour of the rumble strips to get the max speed. This would then allow for more variance in the tracks, and the player would have to concentrate on the area around them a bit more.

Sources:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988

#postmortem #textbook #igb220

[code-x]

Assignment 2 One-Sheet One-Page Progress

For IGB220, we have to do a One-Sheet One-Page for a game we would like to make. So, since I was enjoying making my Asteroid-Like so much, I have decided to use that and elaborate on it for this assignment. To make my One-Sheet One-Page I decided to use Microsoft Publisher as this is a program I know well, and it is really good for this type of thing. Also, I thought I would use the assets I got from Kenney’s Simple Space Assets and Topdown Shooter Assets the other place I will get some pictures from is a Japanese royalty-free site I know of and have used frequently called Irasutoya. The cool thing about the pictures from this site is that they will fit the cartoony aesthetic I want to go with for my game, and there are thousands of pictures to choose from.

My elevator pitch for my Asteroids-Like was:

'Mineasteroid is a Single person Space Action-Adventure game. The player is a lonely asteroid miner just trying to make a living. But with the vast emptiness of space and the constant threat of asteroid collisions, space pirates, and spaceports trying to underpay you. Life is not easy. The player will have to do their best to battle these elements through the help of upgrades and power-ups to make it to the next day.

The game's rating will be PG as the content will contain abstract violence and mild themes that younger audiences may be confused or upset by. That said, the target audience will be 10+ due to the content (e.g., working for a mining company and dying in space) and the difficulty of the gameplay.

So using this as a guide and the fact that I managed to get a simple prototype created for my Asteroids-Like, along with some good feedback from the playtesters, some of which I would like to add to the game and thus my One-Sheet One-Page. Like shop for upgrading your ship and for the space station so you could add weapons to the shop so they could assist in the battles and protect themselves. I then got to work cropping and organising all the elements I would need for my assignment.

And after a bit of work and some suggestions from my lecturer Chris Lee. My one-Sheet is complete.

Sources:

 いらすとや. (2022) かわいいフリー素材集 いらすとや. Retrieved September 10, 2022, from https://www.irasutoya.com/

Kenney. (2022) Kenney • Home. Retrieved September 10, 2022, from https://www.kenney.nl/

#development #igb220

[code-x]

Digital Prototype Racing Game Development

Following on from my elevator pitch and the lizard-frog-mouse race idea, we presented by our lecturer Dr David Conroy. I decided to use a road bike for the road, a buggy for the sand and a truck for the dirt. To add balance to the game, I will want to switch the track’s surface at random intervals throughout the race. As the book The Game Design Workshop by Tracy Fullerton(2018) explains, the balance needs to meet the goals I, as the developer, have set for the player’s experience. The experience I want to give the player is one where they feel like they have a chance of winning even when they are in last place. However, I don’t want that to come from rubber banding as this is a feature in racing games I don’t enjoy as a player.

So, getting started, I chose to once again go with the awesome asset from https://www.kenney.nl/ and choose a top-down racing set they have there (https://www.kenney.nl/assets/racing-pack) as it had all the elements I needed for my racing game

Next, I had to work out a way to lay out the track, but this turned out to be a long and tedious process as I would have to add all the sections as sprites. This was so I could add collision and the track swapping mechanism to them.

Once that was done I got started adding the track to the game and then tried adding a random time swap the problem that I found was that swapping the animation with a random function meant that each track piece swapped separately, and although this looked cool and may even be a cool feature to add to the game in the future it did give the result I wanted. To fix this, I created a master road sprite that I hid and had it swap randomly. Then all the other road sprites check if they are the same as the master, and if they are not, they swap to match it. This resulted in all the track sprites swapping together and was the result I wanted. The Gif below has been sped up normally, the swap will happen between 5 and 10 seconds.

Then, I added the player with their 3 vehicles. To get the right acceleration and movement, I used delta time as the built-in behaviours with GDevelop didn’t quite feel right. So, the player could switch I had added an animation chance trigger when the space bar was pressed.

Now I needed to add a way to slow the player if they were in the wrong vehicle for the track’s surface. I did this by checking both values and misusing the delta time of the player’s acceleration if their vehicle was incorrect to the track. I also added some camera shake if the player hit the roadside markers and an acceleration boost if they were in the centre of the track.

Finally, it was time to add some AI players however this was quite difficult for a racing game and not because of GDevelop it was more due to my lack of knowledge of the engine as I wasted a lot of time with having the Ai react when it collided with an invisible object and although this method worked to an extent, it was far from good. Later I found that I could use a path-finding behaviour for the AI and have their path find to a point on the track however, I ran out of time to implement this correctly. And thus, the game is incomplete, but it was playable for testers.

Also, this was my first attempt at interactive AI, and I don’t consider it a failure I consider it a great learning experience and a must come back to.

Sources:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988

Kenney. (2022) Kenney • Home. Retrieved September 18, 2022, from https://www.kenney.nl/

Kenney. (2010) Kenney • Racing Pack. Retrieved September 18, 2022, from https://www.kenney.nl/assets/racing-pack

#development #textbook #igb220

[code-x]

Elevator Pitch a Racing Game

IGB220, this week we have to create a Racing Game. So I started by reflecting on the book The Game Design Workshop by Tracy Fullerton(2018), focusing on chapter 10, Functionality, Completeness, and Balance. Through this chapter, she discusses how a game needs to be functionality complete and how this can only be found through playtesting I would like to revisit this later; however, because later in the chapter, she discusses balance, and she explains how balancing is an important process to make sure the game meets the goals you as the developer has set for the players experience. Which I feel is quite important for a racing game. This was further emphasised by our lecturer Dr David Conroy in his week seven lecture about conflict and balance. Also, in his lecture, he mentioned a balance technique called lizard-frog-mouse; a lizard does best on rocky ground, a frog does best in swamps, and a mouse does best on grassy ground. This seemed like an interesting concept that I would like to focus on for my racing game.

So, focusing on what I have learnt and the lizard-frog-mouse race.

What is my gameplay?

The player will play race against other players and Ai vehicle in newly created technology advanced switch rigs. The switch rigs are able to change between three types of vehicles Motorbike, Truck, and Buggy, at the press of a button. The races will also be held on a Nanite track that can change from Asphalt to Dirt or Sand. The player will have to match the switch rig vehicle to the road’s condition to maintain a top speed to win the race.

Why will it be compelling?

The track will change randomly, creating an opportunity for less skilled players to catch up to skilled ones. Also, this means that every race will be unique and hard to prepare for.

Who is the target audience?

Target audience: ages 7+ and should be classified G, as there will only be language and themes of a very mild nature and impact.

What is the players' role?

The player will take on the role of a Switch Rig Racer, who will have to use their quick reflexes and concentration to switch their rig to match the road so that they lose as little speed as possible, allowing them to win the race.

How will you motivate the player? How will you reward them?

Motivation will come in the form of beating or catching other players and Ai opponents as they race around the track. They will be rewarded by winning the race.

What genre is the game?

This will be a Racing game with a lizard-frog-mouse twist.

What is the setting of the game?

The game will be set in the distant future, where a new type of racing has been developed called Switch Rig racing.

Now bring all that together, my elevator pitch for my Racing game will be:

Switch Rig Racing or SRR is a Single or Multiplayer Racing game where players will have to battle it out using a Switch Rig, a vehicle that can change between Motorbike, Truck, and Buggy on a Nanite track that can change from Asphalt to Dirt or Sand. Players will have to use their quick reflexes and concentration to switch their rig to match the road so they can win the race.

The game's rating should be G, as there will only be language and themes of a very mild nature and impact. The target audience will be 7+, as the randomisation of the track should make an even playing field for all ages seven and up.

Sources:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988

Power Automedia. (2022) Stadium Super Trucks Hit The Dirt Hard At Glen Helen. Retrieved September 10, 2022, from https://www.offroadxtreme.com/event-coverage/jeep-fest-2022-brings-record-numbers-to-toledo/

Sean Tirman. (2019) Sand Crawlers: 8 Best Off-Road Dune Buggies | HiConsumption. Retrieved September 10, 2022, from https://hiconsumption.com/best-off-road-dune-buggies/

Aftermarketnews Staff. (2020) Exide To Sponsor Intact GP Racing Team For Moto2 Season. Retrieved September 10, 2022, from https://www.aftermarketnews.com/exide-to-sponsor-intact-gp-racing-team-for-moto2-season/

The Fia. (2021) How to design a racing circuit track - Automotive Daily. Retrieved September 10, 2022, from https://www.autodaily.com.au/how-to-design-a-racing-circuit/

#elevator pitch #textbook #igb220

[code-x]

Asteroids-Like Post-mortem

As before, I continued my game development based on my interpretation of Tracy Fullerton's book Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Fourth Edition, chapters 7, 8 and 10. However, I decided to skip the physical prototyping and start with digital prototyping. This was solely due to time constraints for the prototype. As this was an Asteroids-Like, a lot of emphasis was put on how the controls moved the player and the players feeling of movement in the game. This was achieved with the help of the Physics2 engine built into GDevelop, and the playtesters did respond in kind to the movement. However, also, through playtesting, an invisibility bug was found. This bug happened when your shield was low, and you flew over an asteroid that was spawning. This would kill the shield and screw with the Physics2 engine, causing the player to become invincible, thus causing the game to no longer have a fail state, meaning it no longer became a game. A fix for this was found, but it did take some time and rearrangement of code. Later, playtesters were unable to replicate the invisibility bug.

Most playtesters did enjoy the prototype, but some found the game’s objective missing as they thought it was just a straight Asteroids clone, but once the objective was explained, they found the game enjoyable. The lack of a clear objective could be recertified in later iterations of the prototype by adding some mission text at the beginning of the game.

If I were to change anything about how I developed my prototype. I would have liked to have had more time to flesh out the prototype as a lot of ideas had to be left out. Some of these were the enemies that attacked you and the ship mini bosses and boss battles, as well as a shop to upgrade your ship and powerups that would be dropped from enemies.  Playtesters gave some ideas while playing that would have also been nice to implement. One Idea was to add a section to the later-to-be-developed shop for the space station so you could add weapons to the shop so they could assist in the battles and protect themselves. Also, as mentioned above, I would have added some mission text to the game so players would know the objectives of the game.  

If I were going to change something about the design of my prototype, it would be how you unload rocks at the space station. Currently, you fly close, and the rocks disappear from your inventory. I would like it to feel a little more involved, like an arm extending out of the space station that you hook on to then slowly unload your inventory. This action could also allow the player to enter the space station so they could buy upgrades and get fetch quests.   

If you would like to try my prototype, you can at https://gajitz.itch.io/mineasteroid

Also, any feedback would be greatly appreciated.

Sources:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988

#postmortem #textbook #igb220

[code-x]

Game Design Workshop Chapter 10, Exercise 10.10: Skill Levels

While reading chapter 10 of Tracy Fullerton. (2018) Game Design Workshop I came across an interesting exercise that I thought I would do and share as it was relative to my current Asteroid-like prototype I am creating. The exercise was 10.10 and read:

Does your game have a design that incorporates skill levels? If so, describe how they work and the method you used to balance them. If not, why not? Can you add skill levels, and how would they affect the gameplay?

Thinking back about my prototype, I realised that, no, my current prototype Mineasteroid does not incorporate skill levels. So, why was this thinking it over I realised that the player is slowly introduced to the game’s controls, movement, and rules. Then as they progress through the game, the difficulty is increased by the increasing number of asteroids and by the introduction of new enemies. I purposefully did this so that the player has time to acclimate to the game and so they would feel a sense of gratification from getting better at the game.

But skill levels could be added to the game. However, I feel the current difficulty would be set as the easiest setting as making the game any easier would remove some elements of the game and also significantly impact things I would like to add to the game, namely spaceship upgrades.

Source:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988

#development #textbook #igb220

[code-x]

Prototype Asteroids-Like Development

For my Asteroids-like prototype, I decided to forgo the physical prototype. This was done due to time constraints. As this was an Asteroid-Like, I wanted to focus on the movement of the spacecraft while adding a few unique mechanics of my own. This meant the controls had to keep the feel of the classic asteroids game, the rotate left, rotate right, thrust and fire. Tracy Fullerton describes the same control scheme of Spacewar from 1962 in chapter 8 of her book Game Design Workshop; she also explained that Spacewar was programmed by Steve Russell and several other MIT students and is often credited as the first digital game. This classic feel of the controls was achieved by a lot of trial and error with GDevelops physics engine.

This allowed a force to be applied to the player object giving the feeling of thrust and positive and negative torque to provide the left and right rotation.

Next to tackle was the fire, and thanks to GDevelop, this was relatively easy.

For the asteroids, I wanted them to spawn in, but I also wanted them to feel like they appeared from the depths of space rather than just popping in. When an asteroid spawned in, I set the opacity to 0 and then increased it by one every frame until the opacity reached its maximum at 255. This resulted in the exact effect that I wanted.

Now that all the classic elements had been added, it was time to add my mechanics to the game. First off, I added a tractor beam. This was added to alter the gameplay from destroying all the asteroids to getting them small enough to suck up. To make the effect feel like a tractor beam, I used the Tween behaviour in GDevelop.

For health, I want to add a shield that is depleted with every asteroid hit, and this is where I hit my problem. The shield asset I wanted to use is a crescent shape meaning that the shield would have to be rotated to the point of impact. A lot of maths was done to try to get this to happen with no luck. I was about to give up on the idea until I had a poke around in GDevelop and found they had already provided a way to do this with the code snippet {Change the angle of [Child Object]: set to [Parent Object].AngleToObject(Object to face)}. So once again, it was just a lack of knowledge that could have saved some time. However, I do feel my experience with GDevelop has grown exponentially between my platformer and now.

To add to that gameplay, I added a space station so that you could take your collected asteroids to get some Coin for them. I hope that later, I could add some shop where you could buy upgrades and things for your ship.

Finally, I added some UI elements so that the player can track how complete their inventory is and how much Coin and shields they have. However, I could not find a modulus operator which would have helped display the Coin. I am sure there is one some were in GDevelop I just have to find it.  

To finish off, I would like to thank https://www.kenney.nl/ for the royalty-free asset that I have been using in my prototype. I would also like to add that I have enjoyed making this prototype and would like to expand upon it, if not in IGB220, as a side project because I can see a lot of potential in this game.

Sources:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988

#development #igb220 #textbook

[code-x]

Elevator Pitch an Asteroids-Like Game

This week for IGB220, I have to create an elevator pitch revolving around the mechanics of the classic game Asteroids. Asteroids contains only a few fundamental mechanics, but for such an early game, it really captures the feeling of moving through space. So, looking back at my earlier post, "Evolution of an Elevator Pitch", I want my Asteroids-Like to have a feeling of constant motion, how one might imagine flying through space would feel. Then I would like to add some enemies and power-ups to my game to create tension and conflict. Finally, would like to change the gameplay by adding a fetch quest to give a little storyline and a goal to the gameplay.  

Movement: I would like to take some inspiration from the game Asteroids and the side note by Steven Swink, "Prototyping for Game Feel," in the book The Game Design Workshop by Tracy Fullerton. In his side note, he explains how controlling a game should feel intrinsically pleasurable, and to achieve this, you should focus on the input, response, context, polish, metaphor, and rules. So, I will need to get the feeling of moving a vast void with little to no friction right.

So, focusing on that and thinking about the classic game Asteroids.

What is my gameplay?

I will be focusing on the feeling of moving through space. Then I would like to add a mechanic where the player needs to break the asteroids into smaller pieces so they can collect them with a tractor beam giving a feeling of mining in space. Then have them return them to a spaceport to unload their hall. With this, we can add the element of space pirates attacking to steal the mined asteroids leading to the opportunity to add power-ups and upgrades and exciting gameplay. 

Why will it be compelling?

As the player plays through the game, they will come across harder and harder enemies and zones. However, they can counter this difficulty by upgrading themselves through salvaged parts and power-ups.

Who is the target audience?

Target audience: ages 10+; however, it may have to have a rating of PG as the content will be mild, but younger audiences may be confused or upset by it.

What is the players' role?

The player will take on the role of a space miner who needs to mine asteroids by breaking them into small pieces to capture with their spaceship.

How will you motivate the player? How will you reward them?

Motivation will come in the form of basic "fetch quests" and the lure of better parts for their ship, as well as the desire to protect their hall of mined goodies. They will then be rewarded with a currency, parts and power-ups for achieving milestones.

What genre is the game?

This will be a Space Action-Adventure game.

What is the setting of the game?

The game will be set in the distant future, where travelling, living, and working in space is common but not easy. The threat of dying in the vast emptiness of space is ever-present.

Now bring all that together, my elevator pitch for my Asteroid like:

'Mineasteroid is a Single person Space Action-Adventure game. The player is a lonely asteroid miner just trying to make a living. But with the vast emptiness of space and the constant threat of asteroid collisions, space pirates, and spaceports trying to underpay you. Life is not easy. The player will have to do their best to battle these elements through the help of upgrades and power-ups to make it to the next day.

The game's rating will be PG as the content will contain abstract violence and mild themes that younger audiences may be confused or upset by. That said, the target audience will be 10+ due to the content (e.g., working for a mining company and dying in space) and the difficulty of the gameplay.

Sources:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988

Kurzgesagt – In a Nutshell. (2019) 1,000km Cable to the Stars - The Skyhook - YouTube. Retrieved August 28, 2022, from https://www.youtube.com/watch?v=dqwpQarrDwk

Kurzgesagt – In a Nutshell. (2020) Unlimited Resources From Space – Asteroid Mining - YouTube. Retrieved August 28, 2022, from https://www.youtube.com/watch?v=y8XvQNt26KI

#elevator pitch #igb220 #textbook

[code-x]

Platformer Post-mortem

I have been gaining a lot of insight into game development from Tracy Fullerton's book Game Design Workshop: A Playcentric Approach to Creating Innovative Games, Fourth Edition and reading through chapters 7 and 8, I learnt a lot about physical prototyping and digital prototyping and how these processes help to develop the rules, feel and controls of a game. Then after reading chapters 3 and 4, I started to understand the formal and dramatic elements. Since my prototype was a puzzle-adventure platformer, it follows the player-versus game pattern. This also led my prototype to a lack of story and world-building. Nevertheless, this meant I could focus on my game's challenge, objectives, procedures and rules. This was achieved by giving the player a handicap at the start of the level but having a McGuffin in the form of a lever near them. This also provides the player with an invitation to play. As levers and buttons always need to be pulled and pushed. This, in turn, would give them a want to explore the level and thus the puzzle. The level then teaches the players what is expected of them and what they can expect from the game. Thus, slowly introducing them to the aforementioned challenge, objectives, procedures and rules, I, as the game developer, want the player to accept. Also, through playtesting, many changes were added to the game as players who had no knowledge of the game played through it and showed me where the game could improve. These changes included adding arrows to show the player the direction they might want to go. Changing the placement of the starting lever, so the player gets a better understanding of what it does. Text at the intro to explain the key setup. Sounds to indicate that they can action had done something; for example, pulling a lever now has a powering up and down sound. The sounds volume also had to be adjusted as it was too loud, to begin with. I also adjusted the distance of the enemies' travel and the high of the platforms. So, they were not too hard or too easy for the player.

If I were to change anything about how I developed my prototype. I would have probably skipped the paper prototype, although it was very helpful in fleshing out my idea of the game, the level, and some of the rules. With how fast I could get a very basic digital prototype up and running with GDevelop and how basic and small the game would be, a physical prototype seemed unnecessary. However, I am glad I went through the process, as I can now see how valuable it would be for a bigger, more compacted game. That said, though, I need to spend a little more time with GDevelop to be faster and more time efficient with my prototyping.

If I was going to change something about the design of my prototype, it would have to be the feeling of low gravity. I have spent a lot of time tuning the variables associated with player movement. Although it does feel okayish, it doesn't feel like low gravity currently; it feels more like a jump boost. However, I do think this could be accomplished, but it would likely have to come from animation rather than movement. Sadly, animation is one area I greatly lack when it comes to game development. It could also come from another game engine I'm more familiar with, like Unity or Unreal. As my skill level with GDevelop and GDevelope itself is a little bit limited. Another thing I would change the set-up and size of the level by adding a bit more verticality. Currently, I feel it is a little too small, and the puzzles are not very challenging. However, as a starter level, I think they add enough learning to the game, its rules, and its mechanics. But it could be more in-depth with a more significant variance of enemies. Different coloured levers and buttons that change the level ever so slightly or even puzzles with stages and more complexity. Also, I would have thought a bit more about the starting puzzle and what I am teaching the player about the game's rules, as this is a large part of the game. Because I spent a lot of the time working on the movement, I didn't think much about how to make the puzzle fun and puzzle-like.

If you would like to try my prototype you can at https://gajitz.itch.io/what-is-up

Also, any feedback would be greatly appreciated.

Sources:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988

#postmortem #igb220 #textbook

[code-x]

Digital Prototype Platformer Development

Now it is time to get in and play with a game engine! But before I get too excited and go ham on making a platformer, I need to remember a few good points from chapter 8 of The Game Design Workshop by Tracy Fullerton.

The digital prototype extends the design work of the physical prototype.

Digital prototypes are made using only the elements needed to make them functional.

When looking a game mechanics, focus on one question and then answer it.

Have a digital prototype try to answer questions that are too hard to explain verbally.

Don’t get attached to any part of a digital prototype. What you make will most likely be changed in the future. This includes art, animations, mechanics, and controls.

A lot of time should be spent on the controls, viewpoint and UI because this is how the player will interact, see, and obtain information within your game.  

Considering all that, I started by looking for some placeholder assets. Something that gave a similar feel to what I was looking for and was ready to go. I found what I was looking for at https://www.kenney.nl/, a great little royalty-free asset store.

Next, I loaded up GDevelop and started working on the main mechanic I tested in my paper prototype. That switches release gravity allowing access to other higher areas.

Playing with the behaviours in the Object Behaviours tab, I found an excellent starting point that allowed the player to feel heavy.

Now I need to find the feel of less gravity. I did this by playing with the gravity, jump speed, jump sustain, and max speed. I found that turning up or down the gravity didn’t actually give the feeling of less or more gravity; instead, that feeling mostly came from jump speed, jump sustain, and max speed. So, by tweaking them, I got close to the desired result.

I then add a second lever to add some more feeling of lightness. Then so enemies and a spike pit. With those came a player death animation and a reset of the player and the level. After that, I added a button and blocks to block the exit. I also made the button a press action from a player jump. This button action also moved the blocks so you could g to the next level. Next came the collectable and score tracking. Finally, it was time for a tester.

Once I had it all set up, I sat my daughter down and let her have a play. Straight away, we had a problem as my daughter is used to playing Minecraft. She went for the WASD key set up; this meant she couldn’t move. Cause the set-up for GDevelop is the arrow keys. I fixed this by adding some intro text.

This fixed the problem. She proceeded to play the level. And give me some feedback about it. Things like; the controls could be better, the feeling o low gravity was missing and a few more.

There is still a lot of o work to do to get the game to any close to a ready state, but I think it does its job well for a digital prototype.

Sources:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988  

#development #igb220 #textbook

[code-x]

Paper Prototype Platformer Development

Today I started developing a prototype level for my platformer based on my platformer elevator pitch. I began by reading chapters 7 and 8 of The Game Design Workshop by Tracy Fullerton, as these 2 chapters cover physical and digital prototyping games. As Tracy Fullerton mentions in chapter 7, I am one of those first-time designers that would rather jump in and start making the game than prototyping. However, I thought I would take a note out of this chapter. Rather than just getting down and making a level, I would first try to physically prototype it first through a paper prototype.

I began with just a simple level made from some cut pieces of paper arranged in a manner that would resemble my level.

Then I got my target audience (my 8-year-old daughter) and explained the rules.

Your goal is to get to the door.

You can only move the number of spaces you roll with the dice.

If you have G- above your head, you can’t jump.

If you have G+ above your head, you can jump.

If you jump, you can travel up to 7 blocks up, then across the number you rolled -1, then you will fall back to the ground.

If you pull a lever, something will happen. I hid what would happen because I hoped she would be curious and try to get to and pull both levers.

So, I gave my daughter the die. The first thing she did was head to the black lever that gave her the G+ mark. Then she headed straight for the door ignoring the rest of the level and even the collectable.

“Okay. That was not what was expected,” I thought. I asked her why she had just gone for the door and didn’t go anywhere else. She said, “To win, I just have to get to the door.”. Clearly, a redesign was needed.

I quickly made a minor modification to the level, and we tried it again.

This time she went through the level the way I expected and even got the collectable.

I asked her what had changed and why she got the collectable. She said since she was going to the blue switch anyway, she thought she might collect it on the way, but she didn’t know which thing would move the block.

This was a pleasant outcome, and we played the level a few times, adding spikes in places and changing a few things here and there. Overall, I feel the experience taught me a new skill in game development. Although I still think getting in and making a quick digital prototype is better, paper prototyping is rapid. I didn’t have to learn anything before creating the level. If I was going to build a much bigger game with a complicated rule set, I would first consider some type of physical prototype.

Sources:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988  

#development #igb220 #textbook #design

[code-x]

GDevelop Experimentation

For IFB220, we will be using the game development engine GDevelop 5. This is a lightweight 2D development engine that is open-source and cross-platform. It also looks like it has a big emphasis on teaching new game developers how to design games. The fact that it is lightweight and open source does not mean it is not powerful. In fact, it contains a lot of powerful features for 2D games. I think also it is possible to develop 2.5D in the engine too.

When you first open GDevelop 5, you can see that they want to inspire new game developers because they present you with a few tutorials that help you to understand the engine. Then when you create a new game, there is a mountain of premade templates you can use to get started.

As I wanted to experiment with the engine, I created a blank project and started to poke around. The first thing I did was to find all the panels that I thought would be relevant. I then set them up in a way that felt helpful and not cluttered.

While playing with the background colours in the Layers panel, I noticed two little white circles on the canvas. These allow you to navigate left and right up and down, but they are tough to see if you don’t play with the background colour.

Since this is a 2D development engine, I thought I would start experimenting by making a very basic and incomplete platformer. This is also because we will be making a platformer for our first exercise in IGB220, and my first Elevator Pitch is for a puzzle-adventure platformer. I started by editing my scene name to something a little more appropriate. This can be done by clicking on the “Home” tab and then clicking the “Project Manager” button.

Then I added some objects, set them up like a little platformer, and started playing with the scenes events tab.

The events tab takes a bit to get used to, but once you understand how it works, it is relatively easy. The hardest thing I have found so far is setting up particle effects when the slime dies, as there are many options to tweak, and the naming of the options is not intuitive. But the great thing is that the GDevelop team have a heap of guides online that you can watch if you get stuck.

At first glance, and after some experimentation, I think it will be easy to create my platformer in GDevelop. However, it might be a little frustrating trying to work with a drag and drop engine over the code-based ones I am used to.

#development #igb220

[code-x]

Elevator Pitch for My Platformer Game

Considering everything is said in my post "Evolution of an Elevator Pitch", I want my platformer to focus on the feel of different amounts of gravity and puzzle mechanics. This means there will have to be a heavy focus on movement and level design.

Movement: I would like there to only be running and jumping, but the gravity in the game will affect the speed of your running and hover time/height of your jump.

Puzzle: I would like to take some inspiration from the "What is a Puzzle?" side note by puzzle designer Scott Kim in The Game Design Workshop by Tracy Fullerton. Scott says that a puzzle should be fun. Adding that, some things that make a puzzle fun include; novel: interesting with a twist, not too easy / not too hard: find the right balance to the puzzle, and tricky: test the way the player thinks. This means that the levels will have to be made with these considerations.

So, focusing on those two things.

What is my gameplay?

My game will focus on movement (running and jumping) in different gravities. It will feature the use of gravity and puzzles to traverse the levels.

Why will it be compelling?

The player will be able to use the mechanics of the level to change the gravity, and in turn, this will assist them in solving the puzzle. This will encourage players to think outside the box, challenging their problem-solving abilities.

The game will have a light, happy tone, meaning the player can relax while trying to solve the puzzles.

The puzzles will progressively get more challenging with each new level.

Who is the target audience?

Target audience: ages 7+.

What is the players' role?

The player will take on the role of an alien who has crashed on a strange planet – they must travel across this new planet, collecting wreckage to build a new spaceship.

How will you motivate the player? How will you reward them?

With pick-ups, sound/visual effects, and game mechanics.

What genre is the game?

Puzzle-adventure

What is the setting of the game?

The game is set on a mysterious planet that has a unique quirk of being able to alter its gravity.

Now bring all that together, my elevator pitch for my platformer prototype might look something like this:

'What Is Up, is a Single person Puzzle-adventure platformer game. The player plays as an alien and uses their problem-solving skills to find a way off a mysterious planet they have crash-landed on. However, this planet has a unique quirk in its gravity. Using this quirk, they will embark on a puzzle-solving journey as they collect parts for a new spaceship so they can go home.'

The rating for the game is G, as it should be suitable for everyone because elements such as language and themes will be very mild in their impact. The target audience is 7+ as the difficulty of the puzzles may be too complicated for those younger than 7.

Sources:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988

Kenney. (2022) Kenney : Pixel Platformer. Retrieved August 06, 2022, from https://www.kenney.nl/assets/pixel-platformer   

#elevator pitch #igb220 #textbook

[code-x]

Evolution of an Elevator Pitch

Currently, in IGB220, we are working on developing many prototypes. The first step in this process is to consider what type of prototype we wish to create and then make an elevator pitch about it.

As presented by our lecturers, Dr David Conroy and Chris Lee, an Elevator pitch is a three-sentence (30-second) statement. That is a distilled version of the game you want to create. It should effectively communicate within three-sentence why some should give you money to develop your game. Adding to that, Tracy Fullerton, in her book "The Game Design Workshop", discusses on page 454 that when creating descriptive text for a game description that a "description doesn't give any info about how the game is going to be made, the look and feel, technology, etc.". Meaning that it is just the basic idea and nothing more.

To aid in creating an Elevator pitch, I had to think about the game design process and the game's concept. For the first part, the game design process, I turned to The Game Design Workshop by Tracy Fullerton and the first few chapters because she discusses the playcentric method of design at the beginning of the book. Part of the method I like the most is to focus on playtesting early in game development. As this can help to prevent pitfalls and problems later in development. Another part I liked is that you are creating a game for the player and that the player has agreed to play by the rules and constraints you, the developer, have put on them and that this agreement between both player and game developer have made is what makes the game fun. For the concept of our game, we were provided with a list of questions in our first lecture. They were. What is your gameplay? Why will it be compelling? Who is it for (target audience)? What is the player's role? How will you motivate the player? How will they be rewarded? What genre? What world/setting? And when considering these questions, we should answer them with a high-concept statement.

With all this put together, I should be able to put together a good Elevator pitch. However, I also realize that what will make an elevator pitch great will come from experience and adjusting the pitch to my audience.

Sources:

Tracy Fullerton. (2018) Game Design Workshop : A Playcentric Approach to Creating Innovative Games, Fourth Edition. Retrieved July 29, 2022, from https://ebookcentral.proquest.com/lib/qut/reader.action?docID=54776988

#elevator pitch #igb220 #textbook