professionalvalkyrietrainer

[professionalvalkyrietrainer]

Assignment 3 Postmortem

At last, welcome to my final Tumblr blog for IGB 220. I can't believe I have written around 15 blogs for the span of this semester. I know sometimes they are not on time but hey at least its an average 1.15 blog per week for the semester so no complaints.

Lets start off with a recap from my last blog, in which I talked about my team and my experience of hosting playtest for Crab-splosion. We had a total of 3 playtest sessions and gotten a total of 9 play testers and their respective feedbacks. I was also responsible for hosting my first few play testing session which went alright. After all the playtesting sessions, the team then took the response from the questionnaire and survey that were filled up by play testers and have the data sorted and compiled. Credits to Evan for compiling the data into easy to read tables. Evan also compiled the questionnaire to create a demographic analysis to allow the team to have a better understanding of what type of user is testing our game.

Play Tester Feedback

Now unto the meat of the blog, we will now have a look at the feedback we had for our game and goes in depth at every single one. Different from usual postmortem sessions, we had a table of compiled data that shows every major feedback we instead of just playtesting notes I wrote down. This session will also be divided into 3 session corresponding to the 3 playtesting session we had.

Playtest 1

Tutorial Missing

The first big feedback we had for this playtesting session would be the lack of a tutorial stage. By this time, we still have not added a tutorial stage to the beginning of level 1 which explains the feedback. Other than that, our game is a bit complex due to the amount of systems we had so having a tutorial to explain everything beforehand would make it less confusing for players trying to pick up our game. I would say this is a valid feedback and is something that we managed to add in eventually.

No Checkpoints

This feedback is something that each of the play tester has brought up. I believe this is due to two points: 1) Our game is a little challenging if you are not that experienced in platformers. 2) Each level takes a pretty long length of time to complete. Both has caused play testers to suggest add in a checkpoint which makes death in-game less punishing and tedious. In the end, we did add in checkpoints through out the levels.

Player Aiming Direction Not Clear

Onto the next feedback, there're also several play testers that are not sure where the crab is currently facing because no matter which direction it is facing, the model will only show the crab facing towards the right. In order to sort out this matter, we decided to add in a sprite that show the crab is facing left.

No Enemy damaged indication/Feedback

During playtest, some of them said that there isn't a clear indication of whether the player's attack is having effect on the enemy, basically the play tester is looking for visual cues while they aren't receiving any. I believe this can be easily fixed by adding some form of visual impact that let the player know that their shots are indeed something. Originally we opted for make the enemy flash when it takes damage but that requires too much work since new animations need to be added to each enemy so instead we used an easier solution which is to add a hit sprite on where the shot connected with the enemy. This was seem effective as no similar feedback was received in future playtesting.

Orb physics messing with enemies

This feedback was given by one of our testers in which an enemy can push the orbs dropped by defeated enemies. This caused a phenomenon where players can just kill the enemy in front and had the enemy at the back push the orb towards to the player. This is something that the team didn't intend to happen but had a great laugh out off. This was fixed in the final demo of our game.

Playtest 2

Tutorial STILL Missing

Player Aiming Direction STILL Not Clear

During playtest 2, because not much development on Crab-splosion was done in between this playtest and the previous one, we are still receiving these feedbacks during playtest 2. However, as mentioned these were fixed before playtest 3.

Unclear UI Elements

There were also feedbacks from players regarding how the UI for Crab-splosion is very unclear of what they are trying to represent. The team decided that it can be tweaked by making the health bar easier to notice as well as add more visual cue to the weapon gauge to better represent the weapon being unusable for the time being as well as an icon to represent each weapon so player know which gauge represent each weapons.

Scatter Shot/Shotgun Alteration

One of the play testers actually commented on how our current scatter shot bubbles is not scientifically correct of it being red colored. As a suggestion, he think that the bubbles can be blue colored to better represent its damage or purpose. However, the team restrained from doing that because we believe that making the bubble blue color would make the bubble blend into the background instead.

Enemy AI

One major feedback we got from this session is definite regarding the lack on an AI within the enemy. Most play tester felt that the current enemy is too easy to avoid as they only move from right to left without considering player movement. A play tester suggested that a pathfinding can be implemented so that the enemy would be moving towards the enemy. There's another feedback that suggested the enemies to move back and forth as well. In the end, the team decided to go with the back and forth idea but as unable to implement it due to time constraints.

Bad Controls

Another major feedback that we have gotten is related to Crab-splosion's current control scheme where the play tester found it to be confusing and unfamiliar. The play tester stated that he prefer using WASD keys for movement when playing platformers instead of arrow keys, which is what we are currently using. We also used WASD for weapon controls which made it even more confusing to the play tester. The team have discussed about this and planned to research for commonly used control schemes to create a more publicly appealing control schemes.

Playtest 3

Game Unbalanced

Some of the play tester also found that the game is too unbalanced as well as too hard navigate. This is mainly due to the addition of level 2 that has too much path to go on as well as having too much enemies. The team suggest that more health can be given to the player, having more checkpoints and warning indicators will also help.

Lack of Death Screen

The lack of a death screen is also a feedback that we have received from multiple play testers. When playing Crab-splosion, if the crab ran out of HP, the crab will just be instantly teleported back to the previous checkpoint. Many play tester felt that having a game over or death screen would make it more visually clear that the player has lost and need to replay from the last checkpoint. This is definitely something the dev team would add in the future.

Second Level Tweaks

Many play testers have given feedback regarding level 2 of Crab-splosion being inconsistent with the overall level design of the first and final level. Some also believed that its not following the principle of going from left to right that was present in the first level. Hence, the team have decided that the second level will need to be redesign in the future to better suit the system of the games.

Portal Unclear

There are play testers who also responded that they were unclear what does the portal do. This is probably due to the fact that no proper introduction was given to the portal which made players confused when they approach one. I would suggest that we add a tutorial for the portal so that players can learn about what the portal does.

Bullet Travel Indefinitely

One more flaw with the game that the team realized during play testing which is also picked up by some of the play tester would be the fact that the bullet shot out of the crab will travel indefinitely. This meant that enemies can be killed off screen if the player constantly blind fire shots into the right. This I believe can be fixed by simply fixed by just adding a time limit for how far the bullet can travel before it de-spawns.

Personal Notes and Future Additions

Finally I would like to add some things that I would definitely implement into Crab-splosion if I were to keep working on it in the future:

Add in the upgrade/leveling system that we didn't add in for this demo

Add Enemy AI

Improve UI Visuals

Better Crab Animations

Add a better narrative/story to it

At last, I have completed all the blogs. I want to thank everyone for sticking with me throughout all the codes. I am not sure if I will continue writing blogs for my future subject but I would try to as it is in my opinion one of the best way I can keep track of all my development and growth as a game developer.

Signing Off,

S.

[professionalvalkyrietrainer]

Assignment 3 Playtesting

In this blog we will be talking about my playtesting experience as a developer for Crab-splosion. There will be three part of this blog with the first part being the first playtest I did that took place at 11th of October, the second part being the second playtest I did that took place at 18th of October and final part being the last playtest I did that took place at 24th of October.

Prior to my official playtesting, me and my group will need to come up with a couple of things that will assist us during our playtesting sections, that being a playtesting script that needs to be recited to the play tester before the playtest begins, a pre-playtest questionnaire and a post-playtest survey.

Luckily, all of these have templates that were provided to us and all we had to do its just to add in some specific-questions for our game like asking how they felt about the rock-paper-scissor combat system. Among my group, I was tasked with coming up with the playtesting script while the other group member worked on the other materials. In order to do this, I did look into the Chapter 9 Playtesting of Game Design Workshop by Teller Fullerton for some ideas. I found that in page 285 and 286, they talked about how a playtest script can be written and how it can be divided into 5 distinct parts, being Introduction, Warm-up Discussion, Play Session, Discussion of Game Experience and Wrap-up (Fullerton, 2018).

After looking at the script template provided to us which was based on Making Games More Fun: Methods for Playtesting Games by Bill Fulton and Michael Medlock, I can clearly see that the script has well covered all 5 parts mentioned within the book so I decided to only slightly modify the script by reinforcing certain aspect as well as adding a basic how-to-play to the deep playtesting part of the script.

First Playtest

With that out of the way and my teammates done with making the survey and questionnaire on Google Form, we begun our playtesting for Crab-splosion. The first playtesting session took place during the IGB220 tutorial session of week 11. In this playtest session I took a more laid-back role acting only as a note-taker instead of being the host of the playtest. We managed to get 3 play testers to playtest our game that day, which is a humble beginning for out target of 10 play testers at the end of all playtesting sessions. I managed to take a good chuck of feedback from players and all of them are stored within a document that is shared among our group so that everyone can put in their notes. The following is the note that I took down and complied during the playtest session:

I added a list of priority fixes for the game as well as the game is it not in its complete form so me and my teammates think that we should focus more on these aspects to ensure our game is more functional during the next playtest.

Second Playtest

After a week of fixes and tweaks, we have arrived at our second playtesting session that took place during the IGB220 tutorial session of week 12. On top of that, we also lucky enough to get an additional play tester during my IGB283 tutorial for the week, which I will be focusing on for this session of the blog as it is my first time hosting a playtesting session.

I first begun by reciting the playtest script that I prepared and got self-aware by how unfunny I made the playtest script even though my initial goal is to make it quirky. Nevertheless, I digressed and moved forward with the playtesting. After reciting my script, I pulled up the google form link for the questionnaire for the play tester to fill up and answered a couple of questions that he had for the questionnaire.

After that, I launched the demo and let the play tester had a go with it. While he was playing through the demo, he asked some questions but I have to refuse from answering some of them as it might affect the playtesting data if I have given him too much information. At the meantime I am taking down all the feedback that he gave. After the playtest ended, I also prompt whether he will be interested to proceed to deep playtest in which he accepted. I proceed to explain him the basic control and system of Crab-splosion and we had another 10 minutes of playtesting and discussion regarding the game. In the end, I would say my first playtesting session was a success with just a couple of minor hiccups. After writing down all his feedback and compiling everything, I ended up with the list as shown below:

In the end, we managed to get 2 play testers during this week's playtesting session which added up to 5, half of what we are trying to achieve. We will be relying on the Halloween Playtesting party that is taking place next week for the rest of our quota.

Final Playtest (Halloween Party)

After cutting up several levels and features from our demo due to time constrains, we finally had our final demo ready for our final playtesting session which is also a Halloween party hosted by the IGB 220 lecturers. This took place during the lecture in week 13 and has more people attending when compared to a normal tutorial which means more chance for us to get play testers. In this session I managed to host the playtesting session for two different play testers, one within the party and the other during an after party I had with a couple of other fellow IGB 220 students.

After my previous disappointment with my playtesting script, I did went back to revamp it a little. After that, I believe I had a more comprehensive script and my performance during these playtest does reflect on it. Together with my experience running playtest, I believe this playtest session is more successful than my previous one. The best part would be the fact that I got to let a less experienced gamer to playtest the game, which gave a better insight to Crab-splosion as a person with minimal game knowledge, which really gave us feedback that we might not get otherwise. The following would be the playtest notes that I have complied for each of the playtesters:

In the end, we only managed to get 4 play testers during the party. This also made me realize that a playtesting session will always take longer than 20 minutes to complete, which I believe is the main reason why we didn't manage to get a lot of people to playtest. Hence, I think for any future playtest one thing to consider would be to restrict the playtest to a time limit so that it doesn't get dragged too long, causing in a overall lesser play tester count. Nevertheless, we have still gotten 9 play testers throughout all three playtests which is one short from our target but way over the required amount so we were happy with what we had.

With that, I have completed the second last blogpost for the semester, its hard to think that I have gone so far from no post to having 15 posts and one more for the final week. I will be doing a postmortem for Crab-splosion next week so for the last time, Stay Tuned!

References:

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

[professionalvalkyrietrainer]

Assignment 3 Development Progress

Welcome to my second blog in my series of assignment 3 blogs documenting my process of going through creating and playtesting my assignment 3 game named Crab-splosion.

Let us start off with a quick recap from last time, in which we created a one-sheet Game Design Document, the MVP description/elevator pitch for Crab-splosion. In the meantime of coming up with those items, my team already begun the process of converting August's platformer into the first prototype for Crab-splosion. However, much work is still need to be done if we wish to have a playable demo done by week 13.

Player

Our work on Crab-splosion first begun with the player model and its controls. Since we already know that our protagonist in this game would be a crab, we headed straight into looking for inspirations for what we wanted our crab to look like. After digging around, we didn't found a royalty free sprite that we are satisfied with so we ended up using a stock image of a crab as our placeholder for the player. Our artist, Jarvis then proposed that he can do some of the pixel artwork that we need for the game which includes the character sprites so he get started on making the sprites. I then proposed the fact that the crab could be green which fits into the narrative that it is a radioactive/mutated crab, hence why he can fire weapons. The team loved the idea so Jarvis did a color swap of the crab and we have an end product that looks something like this:

The player model already have the basic movement controls like moving to the left and right as well as jumping which was inherited from August's previous game. This save us some time when it comes to implementing these features to the player character.

Enemy

After doing a basic texture swap to the player so that it resembles our vision for Crab-splosion, we begun our first real addition into the game which is to add in new enemy types to give the game more variety. When thinking of what the enemy of our game should be, we did some research on the predators of crab and found out that fish is actually one of them. With the game setting taking place underwater, we think that using a fish as our enemy would be appropriate so that's what we rolled with. We then found a placeholder sprite to be used to represent the fish before we can get official artwork from Jarvis.

We also planned to add 3 more enemy types so we get to brainstorming for enemy types. After some careful consideration, we decided that we will add in a flying-type enemy (Flying Fish) that will drop bombs on the player, Shield-type enemy (Shield Fish) that has a front shield that can't be shoot through and a boomer-type enemy (Bomb Fish) that will explode upon contact with the player.

After Jarvis have made some sprites for the different enemy types and August have coded in the necessary behavior for each of the fishes, we have officially had our first version of our 4 enemy types as shown below:

Weapon Types

Weapon types is where I spend most of my time developing this game as I was the one who initially came up with the Rock-Paper-Scissors system, where a certain enemy can be countered by a certain weapon. I believe that having weapons with different behavior and relationships with each and every single enemy would form the basic system dynamic of my game, like how it was mentioned in Chapter 5 Working with System Dynamics of Game Design Workshop by Teller Fullerton. The enemy and weapon will form the core system while other things like player status, control, pickups and level will be based off this core.

The first weapon that we had for the game is actually from August's old game as well, which is a normal projectile that can be shot from the player by pressing down the 'D' key dubbed the Normal Shot. The weapon deals 15 damage per shot and wasn't effective against any type. It is mainly used as a way to dispatch normal fishes due to it being the most economic choice. It can also be use as an backup weapon against other enemy type albeit not as effective. When facing a normal fish which has a 100 health, it will take around 7 shots to kill it.

The Charged Shot is an iteration of the normal shot that can be triggered if the 'D' key is held down for around 5 second and released. This weapon deals 110 damage to all type of fishes and is the ideal way to take out normal fishes that has 100 health. However, the shot will need to be charged before it can be fired so the player will need to avoid the fish while charging up the shot. One feature we implemented into it is the fact that you can charge it while you are using other weapons.

Next up, we have the Laser Shot which is a long laser beam that will be shot out after pressing the 'S' key. The laser shot deals 4 damage per frame to any enemy that is within the shot, one special feature the Laser Shot has is the property to pierce shields which made it the best weapon against shield fishes that has a 115 health.

The Scatter Shot is next which shoots out a set of 5 bubbles acting as the pellet of a shotgun by pressing 'A'. The Scatter Shot deals 10 damage per pellet so it will deal 50 damage to an enemy if all pellets registered. The unique property of the Scatter shot would be its ability to knockback any enemies. This made it counters the bomb fishes perfectly as their behavior would be to charge towards the player when within range as well as the bomb fish's health of 50. Player can then use the Scatter Shot to knock the bomb fish back and avoid taking damage from the bomb fish's explosion.

Lastly, we have the Missile Shot which can be activated using the 'W' key and shoots out a missile that tracks the enemy. This weapon deals 90 damage per rocket and has the unique property of tracking the enemy. The lock on has a priority on flying fishes which made it a very good counter against them. The flying fish having 80 health is also a reinforcement towards the counter idea as a missile shot can one shot a flying fish.

Now that all the weapon type is introduced, we can get into more technical aspects of each weapon. First off, other than the Normal and Charged shot, every other weapon has an individual gauge that tells how much more shot can be shot out before the player is out and will need to wait for them to recharge. This will be shown within the UI section of the blog as it is more relevant there.

Other than that, another technical aspect of the weapon type that I would like to look into would be how the missile lock onto enemies within the game. Essentially there is a large box called lock on detector that surrounds mostly the front of the player with a little at the back that detects if there are any enemies within the box, and if there's an enemy within it, the missile will then be shot when 'W' key is pressed and the missile will try to make their way towards the locked on enemy.

Pickups

Moving on to the pickups within Crab-splosion, this will be a short and sweet session as there's only two pickups present within Crab-splosion. The first pickup is called the Red Orb. Its a red circular object that gives the player a random amount of Orbs between 14~28 upon picking it up. The orb was originally currency of the upgrade system however the upgrade system was unable to be implemented into our game due to time constraints so the red orb doesn't serve a major purpose now.

The second pickup we had in our game is called a Green Orb that heals the player upon picking it up. It will give the player 20 health points back.

Animations

In order for players to have visual cue and feedback for how they can interact with the game as well as making the game more visually appealing. We decided to add in various animations for the player model as well as some other objects. Credit to Jarvis who made all these animations from scratch.

Player Animations

The player has two sets of animations, that being a walking animation and a damaged animation. Walking animation is to show that the player is currently moving while the damaged animation will be triggered when the player took damage from the enemy.

Bomb Fish Animations

The bomb fish has an animation that has it going all white for one frame and normal in another. This is used to show that the bomb fish is going to explode and as a visual cue for players to know that they should avoid it.

Laser Shot Animations

The Laser Shot basically only has one animation that show the spiral effect that the shot has when it was fired.

UI

The UI of Crab-splosion is mainly made up of three different components, being the health bar, orb count and ammo gauge.

We will start off with the health bar as it is the most straight forward, the health bar is the top most green gauge. When it is filled, it means that the player currently have the maximum amount of health (60 HP) and the gauge will be lowered according to the damage taken by the player. This is controlled using a player health variable which display the length of the bar.

Next up, we have the orbs counter which indicates how much orb that the player had collected so that players can easily keep track of the number of orb they currently have. This works similarly to the health bar where a variable stores the value and it is displayed on the UI.

Finally, we also added a ammo gauge that shows how much ammo remains in each weapon. The letter in front will be letters representing the keys that need to press to fire that weapon which corresponds to the selected weapon. Similar to how the health bar operates, a value will be stored for the total ammo count and that count effects how full is the gauge. When the weapon is fired, a fix amount will be deducted from the ammo count and if the gauge falls under a certain value, it then can't be fired until its filled back up to a sufficient amount.

Level

For our demo we managed to make a total of 3 levels. Level 1 would be a tutorial stage, Level 2 would be a normal stage while Level 3 is the boss stage.

Level 1

The beginning part of Level 1 would be several rooms that act as a tutorial to the basic mechanics of Crab-splosion. Each of these rooms will provide the player with a new system/mechanic that they can learn about and use in the following levels.

The back part of Level 1 is the actual level 1 before the tutorial segments were added in. This level mostly took place on the ground and has a couple of segments that require the player to carefully traverse the platforms so that they don't fall to their death. When players reached the end of the level, there will be a portal that will transport the player to the next level.

Level 2

Level 2 has more of a level on air vibe and features multiple routes that the player can take. If the player is observant enough, they can even get into a secret area and get additional Red Orbs. Similar to Level 1, there will also be a portal that brings the player to the next level through a leap of faith at the end of this level.

Level 3

Level 3 isn't too big of a level as it only includes the boss battle. The boss has three different attacks. That includes a vertical tentacle that comes out of the ground as well as a horizontal tentacle that come out of the boss. Other than that, the boss also has a ink-spiting attack that shoots out a ink projectile that would damage the player.

With that, my development post for Crab-splosion has come to an end. This can be considered my first game that me and a group of friends built from the ground up and I was very proud of what we came up with. After this blog, the game would enter its play test phase and I will be talking about them in my next blog so Stay Tuned!

References:

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

[professionalvalkyrietrainer]

Assignment 3 Group Formation and Team Discussion

Welcome to my Assignment 3 blogs! This series of blogs would be a walkthrough of my design process through out the third assignment of IGB220. Similar to my previous game blogs, the development post are separated into three different segments with the first one being elevator pitch, the second being development post and the third being a post mortem. For the blog today, we will be primarily focusing on the elevator pitch portion of the vlog as well as a section documenting my group formation for my assignment 3.

Starting off with group formation, for assignment 3 I managed to group with three of my friends whom two of them I grouped with in a previous assignment, August and Jarvis and the other being a friend I met in this class, Evan. While we never had a specify role within our team, we do have different people being different architypes you usually see in a game development scene. With me taking up a more produce/designer role, Jarvis taking up the artist role, August being our main programmer and Evan being a designer/programmer that assist me and August in our respective work.

As soon as the group is formed we have to get to work as we only have a week before we submit the first part of assignment 3, which consist of a team role table and a Minimal Viable Product (MVP) Description.

The first order of business is to find out what type of game are we making and whose game to base off. After everyone showed their game and had a little discussion, we realized that we wanted to make a game inspired by the Metal Slug and Megaman series and have the players use different types of weapon to kill enemies as they traverse a series of platforms. In the end we ended up using August's platformer as the base of our game as his Halo-inspired platformer already had shooting as well as enemy AI that are crucial to our game.

Once we had the base of our game chosen, we began brainstorming of things to add into the game to make it into something unique. Starting with the setting of our game, we ended up using a crab as the protagonist of our game. This originally came out as a joke from one of the group members but it was so good that we stick with it. The setting goes that our protagonist crab has came in contact with some radioactive materials in the ocean accidentally and exposure mutated it and granted it the power to shoot projectile out of its body. With this new found power, the crab decided to take on its main predators, fishes, as retaliation for its kind.

With the main setting lay out, everything else started to fall in place as base on the concept of a crab that shoots stuff out of itself towards enemies, we created several systems that will form the basic gameplay loop of the game. These includes the different weapon types, different enemy types, pickups system and an upgrade system.

After that, we continue by brainstorming and coming up with answers for several other questions such as:

Who's our target audience?

Answer: Our target audience would be people ranging from children to elderly people who likes platformer or 2D shooters.

What's the unique selling point of this game?

Answer:

A rock, paper, scissor combat system having different weapons that counter different types of enemies.

Upgrade system that allow players to experiment with different builds.

Hard and challenging bosses to overcome.

How will you motivate the player? How will they be rewarded?

Answer: As player defeat enemies and explore hidden areas, they will collect red orbs which can then be used to enhance the crab by making its attack stronger, let it have more health, etc.

What genre?

Answer: 2D, side-scrolling, shooter, adventure, platformer

What style?

Answer: pixel art style with vibrant colors to represent the ocean and its environments

At last, after answering all the questions, we are left with one and the most important one at that, being the name of our game. This is when our team bump into a bottleneck as at first there isn't a quick and catchy name that captivate what the game is. We begun trying to add the word Crab into different words to see if it sticks like "Crab-dioactive" and "Crab-dator". In the end we settled for "Crab-splosion" because the entire team feel that its catchy. Some of the team members exhibit skepticism for the name at first, but after a series of convincing and assurance, everyone eventually agreed with the name "Crab-splosion" .

With every single aspect of the game thought out, we went ahead and constructed our MVP description for Crab-splosion. Once that's out of the way, we began creating our one sheet for Crab-splosion by focusing on different system of the game and dedicating a part of the one-sheet explaining each individual systems. We then placed the MVP description of the game as the description provided at one-sheet. As a final touch, we also added a couple more descriptions to each UI elements, this is what the final product looks like:

With that, the first part of Assignment 3 has been completed and submitted. I am looking forward to my next post where I will be talking about the process of developing the different mechanics within the game so Stay Tuned!

[professionalvalkyrietrainer]

Assignment 2 Progress & Final Design

Welcome to my Assignment 2 blog. I have decided to make a blog to document my assignment 2 process as well as the final design of my assignment 2. To those who don't know, for assignment 2 I was tasked to design a one-sheet as well as a one-page for the game of my choosing. An one-sheet is am A4 sized pitch document designed to help other people understand the vision of your game and achieve buy-in, while an one-page is an A3 sized GDD that a team can use as a reference of what the game they need to develop.

When choosing the game I wanted to based my one-sheet and one-page off, I have decided to go with Miami 1987, my racing game, as my game since I already establish a 80s vibe for the game and I am a sucker for this kind of vibe, especially have it mixed with Synthwave aesthetics. At the end that's what I decided to go with for my design.

Image source: (Pixabay, 2023)

With the aesthetic and mood setup, I decided to first design my one-page since its more straightforward and I just have to make it look aesthetically pleasing. I first created a logo for my game that took inspiration from the Hotline Miami's logo. I fired up Canva and browse through the colors and font until I have one that I am satisfied with.

Next I created my one-page backdrop by combining several Canva Synthwave assets together and looked something like this:

I also picked a font that fits the aesthetic and started to insert several lines of text that gives the viewer a better understanding of my game including a X-statement, elevator pitch inspired game description, unique selling points, as well as details like platform, player count and genre. Last but not least, I also added a tiny line at the right bottom corner displaying my contact details. I then showed the text to my lecturer which gave me suggestion to change my X-statement as well as my unique selling points.

Next, I added a screenshot of my game to the middle of the one-page so viewer will have an understanding of what the game would look like. Last but not least, I added a couple of car graphic depicting the player car facing incoming traffic and running away from the police using Canvas assets. With that, I have my final one-page design.

Moving on to my one-sheet, the aesthetic portion can be skipped as they are establish on the one-page and I just need to reuse whatever is on it. With that out of the way, I created several rectangles within the one-sheet to put in description and details regarding the game's system. For the biggest rectangle I put in the screenshot of my game so I can add in boxes to describe each item on screen and their purpose within the game later down the line.

The first series of text I added into my one-sheet would be the game logo, description, version and date. The description is basically all the text I had for my one-page but rearranged into one long paragraph. As a side note I also added my email on the bottom left corner as a way for developer's to contact me.

Afterwards, I started working on the game capture but adding boxes with description to each element of my game. One secret I would share would be that the screenshot was not from the actual game itself, but the scene with assets dragged into it. This way I will have full control of all the elements within the screenshot. I added description boxes to the following elements:

SCORE, INCOMING TRAFFIC. GAS CAN, POLICE CAR, WANTED LEVEL, WARNING SIGN & PLAYER.

After some thinking, I decided for one of the bottom squares I would put the explanation of different traffic type as I have plans to add different properties to the incoming traffic to create variety for it. I planned out four different traffic types, being a Sedan, a Sports Car, a Pickup and a Truck. I then drag in all the different sprites for the different traffic type as well as giving them a basic description of how it's different to other types of traffic. I ended up with this box of information:

For the second square, at first I have a hard time thinking what I should put in it. After some careful consideration, I decided to put in the wanted levels and how it changes the game into it as it's a crucial part to my completed game. There is not much visual representation that I can provide for this box so I decided to have text detailing what will happen to each wanted level.

And with that, my one-sheet is officially complete. Although it isn't as well arranged with some part being very cluttered and some other places being to empty. I believe it gets the job done for conveying to the developers what need to be created. This blog post is a bit shorter as it's the smallest assignment among the three assignment I have to do for IGB220. Starting with my next blog post I will have a series of blog post documenting my process of making my assignment 3, so Stay Tuned!

[professionalvalkyrietrainer]

Racing Postmortem

After a few weeks of hiatus I have decided to finally come back to work on my blogs, it had been a very busy month for me so before I know it, it was weeks since my last blog post!

A Quick Recap from Last Time

From what I remember I was developing a racing game named Miami 1987 that has the player dodging incoming traffic while it was being chased by the police. Since my last blog post I have added several functions that flesh out the game a little more. First off I changed up the appearance of my game so that now it has a UI that display the player's score as well as a wanted level. The wanted level doesn't do much right now but I wish to implement a system where as the level goes up, police number will increase and posts as a threat to the player if we were to expand this game in future assignments. Other than that, I also added a pickup named the Gas Can which can boost player speed for a certain amount of time. Lastly, I also added new sprites to the incoming traffic so it fits the pixel art style I am looking for more. This is what my game looks like now:

Play Tester Feedback

For my racing game I managed to get two of my classmates to play test my game and give me some feedback. Since some of their feedback is very familiar I decided to merge their feedback together into one list which makes it easier for me to see what's the main concern they have with my game and talk about during my blog as well.

Difficulty Increase

This is the major concern that play testers have when it comes to Miami 1987. Looking back at my previous games and vlogs, this seems like an universal feedback every single one of the play testers have given me. This actually makes me very conflicted as people who play tested so far all studies in the Game and Interactive Environment degree which means they are more knowledgeable to video games and the basic mechanics behind them. I believe in future play tests I should try to let people who are less knowledgeable in this field to try my game as it gives a better representative of the public's opinion on the game's difficulty.

Speaking of which, the play testers this time have been kind enough to even provide me with ways to improve the difficulty of my game without me needing to think much about it. The first way they suggested that will increase difficulty would be to restrict the lanes that the player can move at or make it so that there will only be one safe lane when incoming traffic comes. It is already a feature within the game but I can tweak it so that this event happens more often as the game goes on.

Second, they also suggested adding a variety of obstacles to spice up the gameplay. One of the suggested obstacles would be spilled oil puddle which makes the car slow down if it comes into contact with it. Another one that I can think of would be a motorcycle that will try to change direction before it reaches the player to catch them off guard. One of the play testers also suggested to add variable difficulty to the game. variable difficulty is basically making the game easy sometimes and making it hard sometimes so that it makes the feeling of sometime the player feels really good at the game while other time they feel that the game is challenging and need to improve themselves. This dynamic rewards and punishes the player while at the same time encouraging them to keep playing.

Add more ways player can move

This is actually an interesting point brought up from one of the play tester as the player's car can only move left and right so far. He suggested that the car should be able to move on the y-axis as well. Adding it in my opinion can go two ways, one, it completely changes how the game is played as players can go forward or backward to maneuver around the incoming traffic. There's also a chance that the ability of maneuvering forward and backward break the game's balance as it makes it too easy for the player. I believe extensive balancing and play testing need to be conducted if I wish to implement this. If it is properly implemented, it is guaranteed to revolutionize the game.

No prompt when game gets faster

A bug is also discovered where the faster text prompt will only appear during the first time the game was sped up and never appeared for every consecutive speed up sequence. This makes it unfair for players as they won't know when the game is sped up so they might feel unprepared when that happens and feel cheated when they die from it. This should be an easy fix as I only need to figure out how to properly delete an item and have it respawn when it is needed.

Scoreboard

Although my game already have a scoreboard, the play testers didn't recognize it at first and only saw it when I bring it up. They also think that the score should be displayed at the game over screen as there's no way to see their score other than looking at it before the game over screen appears. Other than that, one play tester also suggested adding a leaderboard for my game since it's endless and there's no motivation for them to keep trying and get a high score. I believe it is a viable inclusion to the game as who doesn't like getting high scores and the bragging rights that come with it? Since I already have a score variable, I can just show the score variable during the game over screen and find a way to display the score as the high score before a bigger score was obtained and replaced the original high score.

Personal Notes

Similar to my last game, I went back to play test it myself afterwards and found some features that can be implemented as well as things that can be fixed. I will make a note of it here so I have a direction of how to improve if this were to be my game for the next assignment.

Add audio/ sound effects

Add ways for the game to infinitely speed up as now this is hardcoded and has a limit.

Add different behavior for incoming traffic (normal car, sports car, truck and pick-ups)

Redo the UI to make it clearer

Start on creating the wanted system

Add car customization

Add start menu

As this blog comes to an end, I have officially completed all the GDevelop game-making blogs and will move on to assignment 2 & 3 blogs. Throughout the blogs, I have feel that I have really learned a lot when looking back at my first ever blog until now. I have gained a better understanding when it comes to design and I wish this will help me in my future game design related assignments.

References

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

[professionalvalkyrietrainer]

Racing Game Development Post

Alright its time for the development post on the racing game I am working on. Just like my previous game and the one before that, I start off my development by following the tutorial and created a basic racing game that has a movable player, constantly moving tree to stimulate car movement, car spawning from the top of the screen that comes down towards the player, the collision between player and cars and camera angle adjustments.

Asset Flipping

Instead of first working on the main mechanics of the game, in this game I decided to first work on changing up the aesthetic of the game by adding some new sprite to make my game feels more unique to me. I found the following sprites in FreeGameArt.org for the player car and the main background in game(i.e. the road). Both has a pixelated flair to it which suits the aesthetic that I am trying to achieve. However, I was unable to find new assets for the other elements within the game so they will remain as it is until I have more time to find new sprite and change them.

Police AI

The first thing I decided to add into the game in terms of new mechanics would be a simple police AI that chases the player while they are dodging the incoming traffic. Although the police car doesn't really affect gameplay, it adds into the narrative of the game as this gives an explanations of why the player is driving in high speed against incoming traffic.

I begun by porting a police car sprite I found in FreeGameArt.org into the game. It came with a series of sprite to create a siren blaring animation which I added into my game as well.

After adding the animations, I decided to add in movement for the cop car so that it acts like its constantly chasing the player. This is easily implemented as all I did is added the command to move the police car towards the position of the player's car whenever the players move their car. However, after numerous play testing, I realized that the cop car will eventually catch up and clip into the player's car. Then, I decided to add a amount of force towards the Y-axis to the police to make sure that the police car is always a certain distance away from the player. This was exponentially successful and now it looks like the cop car is constantly tailing the player's car.

Finally I positioned the police car to spawn slightly behind the player's car so that when the game begins, the police car will already be at the back of the player car. This will also prevent the police car from clipping into the player's car.

Car Spawn Change

Originally, the example racing game uses two different car spawn, one on the left and one on the right to create cars spawning at different speed. However, this I feel doesn't matches what I want for my game and it creates the probability of all four lanes having cars at the same time, making the game unbeatable. Hence I have decided to majorly revamp the car spawning system by making the cars spawn in one set of spawn patterns instead of having two different spawn and two set of spawn patterns.

However, the implementation of this system isn't as easy as we have to account for all possible scenario of car spawning, which totals up to 24. This means that we have to create 24 different event scenarios that correlate to all the possibilities. In the end, I only managed to create 12 scenarios as this is just a prototype instead of a full-fledge game and I think 12 different scenarios is enough to convey my idea to play testers.

I also wanted to add variety in the vehicles spawned as the example game only have the same color of car for each lane. To achieve this, I added sprites of different color cars into my car entity and use a command to change to a random color every time the car spawns. When trying to implement this code, I ran into a problem where the color of the car keep swapping every second, the "Trigger Once" condition is later added to mitigate this.

Car indicator

After play testing the base racing game from the tutorial, one big problem I had with it is the fact that I was unable to anticipate where the cars are coming from, which become more obvious when more and more cars started to spawn as the player will not have enough time to maneuver through all of it. To deal with this problem, I decided to add in a warning indicator that shows which lane on the road will have cars spawning a second prior to the car actually spawning.

I first begun by finding a warning sign sprite from, you guessed it, FreeGameArt.org and did some recoloring to it so its sharper and more obvious. After that, I also scaled it to be bigger as the initial size was too small to the fact that its barely visible on the game scene. Finally, I created an animation of it flashing by putting a blank canvas at the next frame so it simulates flashing as the sprite is appearing and disappearing in a quick movement.

After that, I added lines of code so that before each car spawn, the warning indicator will first spawn and after 1 second it will be deleted and the actual car will then spawn.

Increase Difficulty

Another change that I think that can be added to the example racing game would be a increase in difficulty as I believe the difficulty of the example racing game was not well balanced as after playing the game for a certain period, I feel that the game is too easy and doesn't have a great difficulty curve. That's when I decided to increase the difficulty of my game by increasing the speed of the incoming traffic by 10 pixel per second every 15 second in game. This will last until the game time reaches 60 seconds, in which the cars will be at their maximum speed. In order to simulate the player going faster, the trees on the road will also come down quicker to act as an illusion to fool the player into thinking that they are going faster. With a couple simple line of code, I managed to add drastically increasing difficulty into my game.

Game Over Screen

In order to make my game more complete, I also went through the extra mile to add a game over screen for it. To make it I basically reuses the player car and police car sprite to create a scene in which the player car is being blocked by the police and was forced to stop with the word "GAME OVER" placed in the middle of the scene.

After implementing all the changes I wanted, the video below is a display of what my game looks like:

(For some reason Tumblr is not letting me put in videos so it will be just a screenshot of the game for now)

Personal Notes

Although I feel very proud about making this game, I still believe there are many things that can be changed for it to be better. Like the previous two games, if I will be using this game for my upcoming assignments, the bottom will be a list of things I would add into it:

Add A Start Menu

2. Add music/ Sound Effects

3. Add indication of car getting faster

That marks the end of my racing game development post, I am honestly very satisfied with what I made now when looking back to my first prototype game. Major improvements can be seen and I hope that during play testing at next week's tutorial play testers will like my game as well. Definitely stay tuned for the racing game postmortem!

References

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

[professionalvalkyrietrainer]

Racing Game Elevator Pitch

Another week, another game. (I have to think of better ways to start this) Starting from this week, I will begin my series of blogs documenting my journey in making a racing game. Let's cut the chase and head into answering a series of questions regarding the game I wanted to create first.

What is the name of your game?

Answer: Miami 1987

What is your game play?

Answer: The gameplay will consist of the player dodging incoming traffic while going in the opposite side of traffic as well as being chased by the cops. The player can move the car to the left or right to dodge the traffic.

Why will it be compelling?

Answer: It will be compelling as the player will experience cruising through the streets of 80s Miami while dodging incoming traffic. Players will definitely feel the adrenaline pumping when playing this fast-paced game which will get faster the longer the player plays it.

Who is it for? Which type of audience would be the game's target audience?

Answer: I think this game would be catered towards teenagers and adults who likes fast-paced but simple racing game. The game's target audience would be male players whose age ranges from 16~35 who enjoys games like the Forza series, Hotline Miami or Horizon Chase Turbo.

What is the player’s role?

Answer: The player will play as a crime boss who got caught red-handed by the cops in a drug trade and now need to escape the cops through a high speed car chase down a freeway.

How will you motivate the player? How will they be rewarded?

Answer: I will motivate the player by including an unlock system in which players can unlock different cars and tracks as they reach certain milestone within the game. This will also act as a way to reward players who put in their hours into the game.

What genre?

Answer: Racing, Casual

What style?

Answer: The style will be retro like 80s Miami Vice style that has palm trees, neon lights and nice cars.

What world / setting?

Answer: The game would be set in Miami in the year 1987, where the player will play as a wanted criminal trying to escape the cops after being caught red handed performing a drug trade. The world will be inspired by other 80s Miami aesthetic franchises like Miami Vice, Scarface and GTA: Vice City

Elevator Pitch

Miami 1987 would be a fast paced racing game where players will have to dodge incoming traffic while the car goes faster and faster until the player eventually crashes and loses. Players can control the car to move left and right to dodge the cars coming towards it.

The X statement for this platformer would be:

Need For Speed X Subway Surfers X Hotline Miami

Reference Images

(Generated with Craiyon using the phrase "AMC Delorean Speeding through highways while being chased")

Control Diagram

A key – Move Left

D key – Move Right

Unique Selling Points

Unique 80s pixels aesthetic for racing games

2. Endless runner style gameplay.

3. Extensive vehicle and playing field customisation

(Note to Self from The Future: USP should be more gameplay focused and ways to encourage players to come back and play instead of being aesthetic driven or other non-gameplay related stuff)

References

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

[professionalvalkyrietrainer]

Asteroids Postmortem

In between this post and my previous post, I read up on chapter 9 of Tracey Fullerton's Game Design Workshop, which talks about how to perform a proper play testing. One very intriguing point I come to conclude when reading through the chapter would be the fact that the designers of a game is always the worse person to play test the game they are designing. Other than that, I also realized that play testing is not a one and done process as multiple play testing should be conducted in different stages of development to make sure that users are able to understand the game without much outside guidance.

I also concluded that for my future playtesting sessions, I should try to include the following to make sure that I can get effective feedback from play testers:

A playtest script

2. Try different play testing method instead of 1-on-1 play testing

3. Let play tester plot my game on a Play Matrix

4. Write down questions for play testers to answer in my play test notes

A Quick Recap From Last Week

Now that's out of the way, lets begin the post mortem for my asteroid game called Astro-stuck. To recap from last week, I added an asteroid splitting feature, power-up, dashing and also change up the texture of my game. This is what it looks like now:

Play Tester Feedback

Unfortunately, I was unable to get a lot of feedback from my fellow classmates for my asteroid game this week, I still managed to get some feedback from one of my classmate. Although the feedback I gotten is lesser than I anticipated, the feedback given is still very insightful and should be talk about extensively.

Increase Difficulty

I believe this feedback to be the most crucial one out of all of them as there are many ways to look at this. On one hand, it might mean that my game is unbalanced and is too easy for my game's audience. On the other hand, we have to account for the fact that this is only feedback from one person who probably has a better gaming expertise than the average gamer, which means that the feedback might not represent the entirety of the gamer population. I believe if the play testing is performed with more people with different gaming expertise, I will be able to get a more accurate response regarding the difficulty of my game.

Nevertheless, if I were to increase the difficulty of Astro-stuck, I believe it can be done by increasing the spawn rate of asteroids, reduce player health or by adding additional threats like hostile spacecraft that will attack the player.

Alter the Speed of Spaceship and Asteroid

The play tester actually suggested me to increase the moving speed of both the spaceship and the asteroids as correlating to the previous feedback, he thinks this can make the game more challenging. In which I somewhat agree with him as its a way to create a more fast-paced game which in turn more difficult. However, similar to the last feedback, I am uncertain whether this is an opinion that applies to the majority of gamers as both of us are definitely better in games when compared to the average gamer. Hence, I would keep this feedback in mind however I will only implement it if most people still have this opinion after I have performed more playtesting with a more varied group of play testers.

Fix Ship Positioning/ Tracking

This feedback actually is referring to fix a glitch/bug that might happen to the spaceship when it reaches where the cursor is currently located. When the spaceship reaches wherever the cursor is, the ship will begun to flicker between facing left and right, I believe this occurred as the ship is controlled by heading towards where the cursor is pointed, however when it catches up with the cursor, instead of stopping, it still constantly heads towards the cursor which is unreachable as the point is inside the spaceship itself, so it basically became a dog chasing its own tail.

More Power-Ups

The play tester also given me the idea to add different variety of power-ups into the game. He suggested that a scattershot power-up can be added which causes the spaceship to fire a cone of bullets from where the spaceship is facing rapidly. Other than what the play tester suggested, I also came up with a couple ideas that could be potential power-ups that can be added into the game. One of them being a nuke power-up that wipes out all the asteroids on the field and the other being full repair power-up which will restore a set amount of health points to the player.

Override Collision When Dashing

This particular feedback was added after I explained to the play tester that there's a dashing feature within my game. In which he then tried to dash through asteroids thinking that he can phase through it. However, he was unable to perform that as it was not coded in, so he proposed that I can add a damage mitigation mechanic into my dashing mechanic, which I agree is a great idea as it can make the system more dynamic as highly skilled players can use this feature to survive longer on the asteroid field.

Personal Notes

After going back to play test my game, I also found a couple of major flaws that I believe need to be fixed if I am going to use this as the base for my upcoming assignment. Here is the list of things that I would add/fix in my game:

Tweak the fire rate of bullets as I think they are shooting too fast

2. Add more power-ups

3. Balance the game by tweaking asteroid spawn rate, asteroid speed, space ship speed and many more.

4. Add music and sound effects

5. Add a start menu for my game

With that, I have officially completed all three blogs for my asteroid game as starting from next week I will begin my work on creating a racing game in GDevelop so stay tuned!

References

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

[professionalvalkyrietrainer]

Asteroids Development Post

I begin the creation of Astro-stuck by first looking at the instructions provided within the tutorial and making a basic asteroid game that contains a controllable spaceship that shoots out bullets, spawning of different sized asteroids, spaceship taking damage when collided with asteroids, score and lives in game display, as well as a game over screen.

Power-ups

The first addition that I thought of is to add a power-up that can spawn after a certain amount of time that allow the player to shoot in 4 different directions instead of just one for a set amount of time once they have picked up the power-up.

Adding a power-up is the most complex addition that I have encountered in GDevelop so far as I am trying to make a new system for the game from scratch without looking at any tutorials.

I decided to first write the code for the power-up to spawn, which is trivial as the code basically breaks down into a timer will start running when the scene starts and after 30 seconds, the power up will spawn. After that, I made a condition to check whether the spaceship is colliding with the power-up and delete the power-up if they did collide, which basically act as if the spaceship "picked up" the power-up.

Moving on to the effect of the power-up, I wanted the spaceship to fire from 4 direction instead of just from the front of the ship which means I just need to have the spaceship spawn bullets travelling in 4 different directions instead of one when the player picked up the power-up. To archive this, I copied the code for spawning bullet from the front of the ship 4 times and change the spawn angle from wherever the spaceship is facing to the angle that it is facing + 90,180 and 270 degrees respectively, which allowed the bullets to always fire from the cardinal directions with east being where the spaceship is facing. Originally, I didn't account for the ship's current angle, which made the bullets that was shot out keep facing the same direction instead of altering depending on where the spaceship is facing,

Asteroid Splitting

The next feature I would like to add would be for the big and medium asteroids to split into their smaller counterpart when it is destroyed by the player. My thought and logic behind it would be to delete the original asteroid when it was shot and spawn in two new smaller ones around it, which is what I proceed to code in.

To explain the code, basically every time the bullet collides with either the big or medium-sized asteroids, two smaller ones will spawn from it at a random point within the sprite of the asteroid. The original asteroid will then be deleted and score is added to the player accordingly. One problem that I ran into when trying to implement this code is definitely the spawn location of the smaller asteroids. Before my current iteration, the asteroids will always spawn in the middle of the original which is easily destroyed by follow up bullets. After digging around the internet I have found a way to use RandomInRange and setting the range to be in between the minimum and maximum width and height of the sprite, I am able to let the asteroids spawn randomly throughout the sprite which made it harder for it to be hit by follow up shots from the spaceship.

Dash

To round out new features added into the game, I also added a dash function for the spaceship to dash away if it got into a unfavorable situation, the code basically checks whether Mouse2 is pressed and released and if the dash CD is over, the ship will then dash towards wherever the cursor is facing. A timer is also added to make sure the player doesn't abuse the dash feature and spam it.

Asset Flipping

I did also took some artistic liberty and added a new background, player model as well as a new game over screen which made it looked ten times better than the original white blank background. All the background assets were taken from OpenGameArt.org. I also went the extra mile to draw my own spaceship with the

Personal Notes

Going back to what I wrote in my previous blog, I will try to make sure that my game is functional, complete and balanced using what I read about in Chapter 10 of Game Design Workshop by Tracy Fullerton. Although much of these aspects can only be applied after some extent of play testing, I believe there are also ways to archive something similar to that without actual play tester feedback.

Starting with functionality, which can be tested by checking whether players can use the controls and the core loop and make progress in the game. Although it has not been play tested yet, I can at least make sure the game is functional by establishing a solid core loop of shoot asteroids -> get power-up -> shoot more asteroids -> get high score -> game over -> repeat.

After that, I can make sure my game is somewhat complete by anticipating what a player might do and add conditions that correspond to it. one example would be my addition of a dash cooldown as I anticipated there might be players who will abuse this feature to endlessly dash across the game map.

Last but not least, the balance of the game is in my opinion is the hardest aspect to do right. Nevertheless, I did try to balance my game by reducing the spawn time of small asteroids as I found that their spawn was too often which cluttered the screen up quickly. Since now destroying larger asteroid also spawn smaller ones, reducing the spawn rate seems like a reasonable change. However, I believe the balancing is not final and this aspect, together with the previous two would be drastically changed when actual play test has taken place.

With that, this marks the end of my second development post. When compared to the first development post, I believe I have improved as more details were added into the posts instead of me just writing down what I did to my game. Next week's blog will be the post mortem for this game after I had gotten some play testing data from play testers. I reckoned by then I would know what can be added to make my game more complete, functional and balanced. Stay Tuned for the upcoming postmortem of the Asteroid game!

References

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

[professionalvalkyrietrainer]

Asteroids Elevator Pitch

Another week, another prototype. Today I will begin the creation of my asteroid game prototype. Before beginning, I have decided to read up on Tracy Fullerton's Game Design Workshop Chapter 10 which talked about how to make sure that your game and its mechanics are functional, internally complete, as well as balanced. Throughout the chapter, it is explained that several tests can be carried out to determine whether a game is functional, internally complete and balanced, which is what I aim to archive in this new prototype. Before developing the game, let us first come up with the elevator pitch for it. Just like the last game, I will start by first answering a couple of question regarding the game.

What is the name of your game?

Answer: Astro-Stuck

What is your game play?

Answer: The game play would be moving around the asteroid field, shooting and destroying the asteroids before it crashes into the player's spaceship. The player can also pick up power-ups that help destroy more asteroids in quick successions. The player will survive as long as they until the spaceship is eventually destroyed and their high score is recorded.

Why will it be compelling?

Answer: It will compelling as it is a very casual game that doesn't take up much brain power so the players can feel relaxed and stress-free even if they play it extensively.

Who is it for? Which type of audience would be the game's target audience?

Answer: I believe this game is created for the wider audience, ranging from children to the elderly, hardcore to casual gamers alike. If we really need to specific a target audience, I would say it will be children or teenagers ranging from the age of 10~15 who is looking for a casual and easy to pick up and play game.

What is the player’s role?

Answer: The player would play as the pilot of Betty, a mining ship stuck on an asteroid belt after the ship was surrounded by asteroids and now armed with just a laser cannon, the player would try to blast their way out of the field by destroying as much asteroid as they can.

How will you motivate the player? How will they be rewarded?

Answer: Players can be motivated with the addition of a leaderboard to the game, in which players will try their best to beat their own or somebody else's high score and climb to the top of the leaderboard.

Players will also be rewarded with power-ups that can make them clear asteroids quicker for a certain amount of time once they survive a certain amount of time as a way of positive reinforcement

What genre?

Answer: The genre of the game would be a casual shoot 'em up.

What style?

Answer: The style of the game will be a simple pixel art style combined with a darker color palette and tone.

What world / setting?

Answer: It would be set in the future where intergalactic travel is commonly available for humans and a new prosperous space age has begun for them. Some humans have turned to asteroid mining in asteroid belts which is one of the most high paying but risky job throughout the galaxy as it is very easy for spaceships to get destroyed by incoming asteroids throughout the belt.

Elevator Pitch

Astro-stuck would be a casual shoot 'em up sat in the far future where asteroid mining have become one of the galaxy's highest risk and reward job. Play as the pilot of the mining ship Betty and try to survive as long as you can against asteroids that are constantly pouring towards Betty by avoiding and blasting them to pieces

The X statement for this platformer would be:

Asteroids X Temple Run

Reference Images

Image 1 Source: (Lapetino, 2016)

Image 2 Source:(Print Mag,2012)

Control Diagram

Mouse Movement - Move Spaceship

Mouse1 - Fire bullet

Mouse2 - Dash

Unique Selling Points

Easy to pick up controls for both hardcore or casual gamers alike.

2. A homage to the classic Atari game with a twist of its own

3. Players will need to actively engage asteroids to get a better score instead of just focusing on survival.

References

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

Lapetino, T. (2016). Art Of Atari. United States: Dynamite Entertainment.

Print Mag. (2012, July 1). Atari at 40. Retrieved from printmag.com: https://www.printmag.com/daily-heller/atari-at-40/

[professionalvalkyrietrainer]

Platformer Postmortem

A quick recap of my previous post

During my previous development post, I mentioned how I have added several new features like dashing, hovering, shooting, etc to the basic platformer. After posting that, I have also added a couple new platforms to my platformer and officially made a level for it. I believe this temporary level will be sufficient for play testers to have a grasp of what the different feature within the complete game would feel like.

On the bottom right corner of the level, the vertical platform was supposed to disappear when all enemies are killed, however, I was unable to find a way to implement it so for now its just a board up space with not much going on.

Play Tester's Feedback

In total I have let 3 different individuals play test my game, because I see all the game developers doing it and its something mentioned within Game Design Workshop by Tracy Fullerton, I decided to write down all the feedback given by all the play testers.

After organizing and sorting all the feedbacks given by them, I have concluded that these are the play tester's main concern towards my prototype.

Tweaks to Player Movement

Player movement is where most of the criticism regarding my game came from. First of all, the movement felt slippery and not snappy. There are cases where the character is still moving towards right after the D key is released. I believe this can be fixed by adding an small opposite force to the player when the A or D key is released.

Another big problem came from when LShift and Space key is constantly pressed, the character will be constantly dashing and jumping respectively. Which lead to the player character moving in very high speed as well as constantly rising higher and higher until it disappear from the playable area. In order to deal with this issue, I would add a timer to limit the number of input that can be received before the next one is received as well as a limit of how high the character can jump.

Another movement related feedback would be the fact that the player couldn't climb back up to the platform once they fell off the edge, some classmates even suggested adding a ledge grab or copy Super Smash Bros and add a mechanic to jump back onto the platforms. I think this can be added easily as there's a ledge grab feature that can be toggled on the Platformer behavior. Adding a way to jump during mid-air is also an element that can be considered integrating into the game as well since it enhances the player's airtime horizontal mobility.

Sprite/Animation

There's also report of the player model animation flickering when the player model is flipped horizontally in a quick succession. However, I reckon if I were to remake this prototype, I would port in new sprite and animations instead of using the current one that was provided in the workshop resources. In my opinion the aesthetic of the sprites doesn't really fit the theming that I am looking for.

Same goes for the enemy sprite as some play tester said that having a death animation to the enemy can also make it more visually clear on whether the enemy was killed.

UI/Status

Another feedback I gotten was the lack of a health system and a user interface in general. I believe this can be easily dealt with by implementing a damage system where the player will take damage when it touches the enemy and once play health reaches zero, maybe a game over screen will be displayed.

Lack of Variety in Levels

Many players also thinks that my level is too dull and boring, they think that the sprite and aesthetic of my game doesn't fit what I am trying to achieve. Other than that, they also feel that level can also be designed better to fit the advanced movement that I am aiming for.

Bullet Properties

One problem the play tester had with bullets fired from the player character is the fact that it only travels towards the right and doesn't travel towards the left even when the character is facing left. This is a major oversight on my end and can be easily fixed by adding a condition to check whether the character is flipped horizontally, and if it is, then the bullet will travel towards the left instead of right.

Although many criticism were given to my prototype, my classmates still loved the prototype overall. Many enjoyed the dynamic movement system that was implemented and wishes to see more. They also provided many ways that I could improve my prototype which I hope I will put into good use during my assignments as well as other games that I will design in the future.

Personal Notes

After receiving feedback from play testers, I have also went back to my prototype and after play testing it myself. I felt that it had some other flaws that weren't pointed out by the play tester, which prompted me to make a personal note session to put them down in. These includes:

No win condition

No timer

No Game Over screen

No enemy variety

If I were to make a platformer during my next assignment, the flaws listed would be some of my top priorities to tackle for sure.

And... That marks the end of my first design process for this subject. Next week I will stop development on this prototype and begin my work on an asteroid game, as well as the corresponding blogs for it. Stay Tuned!

References

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

[professionalvalkyrietrainer]

Platformer Development Post

Before I begin creating my prototype for Ronin's Path, I decided to read some chapters in The Games Design Workshop written by Tracy Fullerton, specifically chapter 3,4,5, which talks about working with Formal Elements, Dramatic Elements as well as System Dynamics. From the reading I have conclude that I will need to add the following features to my prototype: platforming, jumping, dashing, hovering, enemy AI and shooting. These formal elements are chosen as they will form the main core gameplay system for Ronin Path.

After following the tutorial in week 2, I have successfully created a simple platformer with a jumping and moving character and simple enemy AI. However, it is far from a completed game. Now I will have to add my own personal flair to the prototype to make it to something with identity.

The main thing that I wish to add would be the following:

Dashing

Double Jumping + Hovering

Kill enemy if dash towards

Dashing

Although adding a dashing feature is in my opinion the simplest addition to my prototype , it is also the feature that will drastically change how the game is played as it can make the game more fast paced. It is simply achieved by adding an instant force towards the direction the player is facing when the character pressed LShift together with either left or right direction keys (A or D).

Double Jumping + Hovering

I decided to tackle double jumping first and found out that I can allow the player character to jump again by allowing the player to execute another jump again when the character is falling, which is exactly how I implemented double jump into it.

After having prior experiences with double jumping, I figured that hovering can also be achieve by tinkering with the character when it is falling. In which I am right as I am able to make the character hover by just drastically lowering the falling speed of the character when the Space key is constantly pressed down.

Kill Enemy If Dash Towards Or Was Shot

Originally the tutorial code only allowed the enemy to be killed when stomped on, however I would like to add alternate ways to kill it since when playing as a mech, the player will have more engagement option that just stomping on enemies. I decided to add a slash attack that can be triggered when the player dash into the enemy as well as a shooting attack.

Slashing is implemented easily as I just need to check whether the player is in collision with the enemy and also whether the player is pressing LShift a.k.a. the dash key. If both conditions are met, then a slash attack will be triggered and the enemy will be deleted.

Shooting however is more complex than just checking conditions. To create it I will have to create a new bullet sprite as well as code to spawn the bullet from the player when Mouse 1 is clicked. The bullet will also need a force to push it towards the enemy. Lastly, the bullet will also need to check its collision with the enemy and delete the enemy when they collided.

Now that I have implemented several functions that I envisioned to be in my game, I believe that there is still much more that need to be added such as changing the texture of the game, adding a timer to show how long was spend to clear this level, an end goal, game over screen as well as a gate that won't open until every enemy is eliminated. Due to a lack of knowledge as well as time constraints, I was unable to add these functions in. I hope to add these functions in in the future when I have learned how to.

My next post will be my first post mortem in which I will talk about the feedback from play testers as well as what need to be changed to the platformer in the future, so stay tuned!

References

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

[professionalvalkyrietrainer]

Platformer Postmortem (Outdated)

*This is a previous version of Platformer Postmortem that combined both the development post together with postmortem and is not the official postmortem blogpost. To visit that, please click on this link to get there*

Before I begin creating my prototype for Ronin's Path, I decided to read some chapters in The Games Design Workshop written by Tracy Fullerton, specifically chapter 3,4,5, which talks about working with Formal Elements, Dramatic Elements as well as System Dynamics. From the reading I have conclude that I will need to add the following features to my prototype: platforming, jumping, dashing, hovering, enemy AI and shooting. These formal elements are chosen as they will form the main core gameplay system for Ronin Path.

I first created a simple platformer that includes simple player movement such as going to left and right and jumping, appropriate sprite animations were also given to each corresponding action. After that, a basic enemy AI is also created using a moving enemy as well as commands that allows it to change direction when it touches a certain object. Finally, platforms were also added using GDevelop's built in platformer behavior. So far, this is what I have created:

I believe this temporary level will be sufficient for me to test out the elements I am trying to implement.

Dashing

Starting off with dashing, I created an event where if the LShift key is pressed together with one of the two direction keys, it will add an instant force to the player in that direction which simulates dashing.

Hovering

Hovering might sound tricky to implement but I have found a way to implement it with ease. It can be done by drastically lowering the gravity/falling speed of the player when it is in mid air and the Space key is pressed down.

Shooting

Thanks to the build in FireBullet behavior, shooting a bullet out of the player can be done easily as well. I mainly added the behavior into player, inserted a new event to shoot out a bullet from the player model when Mouse1 is pressed. I also added the condition where if the bullet collided with the enemy, the enemy will be deleted.

After letting some of my fellow classmates play test my prototype, they provided some vague but helpful feedback which allowed me to know what needs to be improved in term of the design of my prototype.

Tweaks to Player Movement

Player movement is where most of the criticism regarding my game came from. One big problem came from when LShift and Space button is constantly pressed, which leads to the character constantly dashing and jumping respectively. In order to deal with this issue, I would add a timer to limit the number of input that can be received before the next one is received.

Another movement related feedback would be the fact that the player couldn't climb back up to the platform once they fell off the edge, some classmates even suggested adding a ledge grab or copy Super Smash Bros and add a mechanic to jump back onto the platforms. I think this can be added easily as there's a ledge grab feature that can be toggled on the Platformer behavior. Adding a way to jump during mid-air is also an element that can be considered integrating into the game as well since it enhances the player's mobility.

Sprite/Animation

There's also report of the player model animation flickering when the player model is flipped horizontally in a quick succession. However, I reckon if I were to remake this prototype, I would port in new sprite and animations instead of using the current one that was provided in the workshop resources. In my opinion the aesthetic of the sprites doesn't really fit the theming that I am looking for.

Collision

The collision of some of the object is also not implemented, such as collision between player and enemy when player is dashing. These are easier to fix as we just need to implement an event where the condition is collision between object as well as the action that should follow.

UI/Status

Another feedback I gotten was the lack of a health system and a user interface in general. I believe this can be easily dealt with by implementing a damage system where the player will take damage when it touches the enemy and once play health reaches zero, maybe a game over screen will be displayed.

Although many criticism were given to my prototype, my classmates still loved the prototype overall. Many enjoyed the dynamic movement system that was implemented and wishes to see more. They also provided many ways that I could improve my prototype which I hope I will put into good use during my assignments as well as other games that I will design in the future.

References

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

[professionalvalkyrietrainer]

Platformer Concept and Elevator Pitch

After my first tutorial we were told that we need to come out with an elevator pitch, as well as a prototype for a platformer that we will be making for the next two weeks on GDevelop.

Platformer Concept

I guess before we can come up with an elevator pitch, we need to first have a concept of what the game should be. According to the lecture slides, there should be a series of questions the designer can ask himself when coming up with a concept. Asking these questions like what's the game play of the game, the target audience, genre, etc are crucial to understand what's the final product the designer is trying to achieve and whether it is viable.

What is the name of your game?

Answer: Ronin's Path

What is your game play?

Answer: The game play would consists of the player piloting a high-mobility mech trying to traverse platforms from the left of the screen to the right while destroying enemy mechs along the way. Players can perform maneuvers like dashing and hovering to traverse the platform quicker. The enemies can be killed by being stomping on, shot by the player or dashed into by the player. There will also be a time limit for each level so the player need to reach the end of the level as fast as they can.

Why will it be compelling?

Answer: I believe the fast-paced nature of the gameplay would hook players as it will give them a adrenaline rush while they try to make it to the end of the level before the timer reaches zero. Other than that, there would also be achieving players who would try to find the fastest way to clear a level to beat a record set by the game, others or himself.

Who is it for? Which type of audience would be the game's target audience?

Answer: I think my target audience would be age 16+ people who enjoys metroidvania like the Metroid franchise or Dead Cells, fast paced platformers like Sonic the Hedgehog as well as mech games like the Armored Core franchise. The rating of the game would be Mature as it has some heavy theming like violence.

What is the player’s role?

Answer: The player would play as a pilot, a military professional who are trained to operate high mobility prototype mech known as the Ronin.

How will you motivate the player? How will they be rewarded?

Answer: Players will be motivated to keep playing the game as they will need to try to clear a level as fast as possible which means learning the mechanics and how it can boost the speed of the player. The time required to clear a level will be linked to the rewards that the player will receive as well, for example clearing level 1 within 5 minutes will unlock the next level etc.

What genre?

Answer: I think the genre would consist of platformer, mecha, metroidvania.

What style?

Answer: I would go for a more industrial style with many of the levels taking place in factories or other places with frequent amount of machinery or steel structures.

What world / setting?

Answer: It would be set in the distant future where all countries on Earth have formed a couple alliances that fights among each other for the remaining resources on Earth. Mechs are introduced into the battlefield and is the combination of all the technological advancements made in the past 40 years in human history and humans hope that the deployment of mechs would bring the conflict to an end.

Elevator Pitch

After going through all the different questions, I believe I have a vague idea of what my elevator pitch should be, so here is my official platformer elevator pitch:

Ronin's Path would be a platformer that has the player trying to clear a level as quick as he can while doing advanced maneuver like dashing and hovering. The player can kill enemies along the way to increase its speed and clearing a level within a set period of time will reward player with new levels and mechs to pilot.

The X statement for this platformer would be:

Armored Core X Sonic the Hedgehog X Metroid

Reference Images

The following image will be a representation of what the in-game mechs would look like when it is completed that I generated using a free AI image generator named Craiyon.

Control Diagram

A key - Move Left

D key - Move Right

Space key - Jump (Press), Hover (Hold)

LShift key - Dash

Mouse1 - Fire weapon

Unique Selling Points

Ronin's Path is the only game in the market that combines mech combat together with fast-paced platforming.

Advance movement option which allows players to experiment different techniques to optimize their level clear speed.

Different mechs and weapons can be unlocked through out the game that provides different playstyle and movement option to the player.

That's the end of my platformer concept and elevator pitch blog. In my next post I will begin my experimentation with GDevelop in terms of creating the platformer prototype as well as talking about play-testing feedback from my classmate after they have tried my game. Stay tuned!

References:

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

[professionalvalkyrietrainer]

About Me

Hello Tumblr! My name is Zi Xuan Sean Ng and I am currently studying bachelor in Games and Interactive Environment at QUT. My interest in game development consists of designing engaging gameplay as well as narrative, which came to no surprise as some of my favorite video games are ones that has intuitive gameplay combined with deep narrative such as Bioshock and Halo.

My aim for this unit is to gain a deeper understanding on what is a game designer and what it takes to be a good one. Other than that, I also aspire to become a play tester that can give better and more knowledgeable feedback. I hope that at the end of the unit, instead of saying "Your game is good" when giving feedback, I want to be able to give more insightful feedback that actually provides the developers a direction on how designers can improve their game.

There are also a few objectives that I wish to achieve within this unit, the first one being to gain the necessary skills and knowledge required to began my profession as a game designer. Next, the ability to examine game behavior and evaluate game design issue creatively and critically. Other than that, knowing how positive user experiences can be created by understanding how game elements can be combined in a game design process. Finally, the ability to identify, discuss and justify opinions on major game design issues, especially in terms of the theory and practice of it.