IDKWhatToCallIt

Liam Korver, n12360155

[idkbutheresmyname]

Another Interesting Book Chapter

Another interesting book chapter I should talk about is chapter 6: Conceptualization. This chapter after reading it and using some of its strategies I found it easier to lay out my ideas for my assignment 3 which I believe allowed me to develop a less buggy and better game than it would have been without this chapters help.

Its Idea of "Putting it on the wall" was also really helpful as I did this my assignment 3 when deciding what I had to code it allowed me to see all my ideas in one space and link them together in an easy way, especially the quote "This helps spark even more ideas and facilitates collaboration", which was extremely true as when looking at all my ideas layed out it allowed me to come up with new ideas not in the original design which is how the explosive shot and faster fire rate upgrades came to be, which were loved by play testers.

Another part of chapter 6 that helped is the mind map section instead of sitting there and meticulously doing it just putting words on the mind map and then coming back to cut allows for a much bigger range of ideas to be on the mind map, which was very similar to "Putting it on the wall" except i was able to connect all my ideas together in to multiple cohesive strings.

Sources used in this post are:

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

[idkbutheresmyname]

Assignment 3 postmortem

With assignment 3 now completed a postmortem will now be done.

With Assignment 3 many different chapters of the readings helped me specifically chapters 3, 4, 6, 9 and 10 which all provided different aspects for both the game design and report writing. With chapter 3 its resources subheading gave me ideas and allowed me to think of different resources that could be added to the game, this in turn gave me the idea to add a gold pickup. Furthermore the quote for the "Lives" section "More is always better, and there's no downside to earning lives", helped me decide on whether or not the lives upgrade would be kept from the original prototype, ultimately resulting in them staying. Chapter 4 helped with its distinguishing a clear goal which prompted me to add text on the game play screen telling the user how to shoot and what score to get to. Chapter 6 helped with showing me different strategies to brainstorm down my ideas, which helped significantly since I was the only person developing the game and helped me structure my thoughts, The reasons for why is explained in the interesting book chapter post for chapter 6. Chapter 9 helped by giving me an understanding of playtesting before we actually partook in it which allowed me to develop the game in a way I thought the play testers would understand, with this being explained more in-depth in the interesting book chapter post for chapter 9. Finally Chapter 10 helped me with the balancing of the game, with it being the guide to the changes I made in the game such as lowering the health upgrade and the speed of the asteroids on level 2 being nerfed as many play testers found them un-rewarding and annoying respectively.

After going through assignment 3 one thing I would change about how it was developed would have been starting the part B report earlier in playtesting as it would have allowed me more insight into my game design and the problems in it, as me and the group would have been analyzing the playtesting data earlier possibly providing a better gaming experience for the further play testers. Also I would have for the game tried to release more versions of the game then just 4 so we could have the play testers test more bugs in the game instead of repeating the ones found by previous play testers.

Along with this one thing I would like to change about the design process of assignment 3 is specifically adding a boss level at the end of the game as after playing 3 levels the play testers felt like they had not really accomplished anything and were unsure of what to do now, as there was no "you win" or "game done", which made the game feel kind of boring or lackluster in my opinion. The reading that would have helped here is chapter 4 with it discussing how you should try to make the game engaging as most play testers were not upset/wanted to keep playing after we said to stop.

After this post I will have one final post being an interesting book chapter I would like to discuss.

Here are some images from our game Solar Bastion:

Title Screen

Playing Level 1

Upgrade Screen

Level 2

Level 3

Sources used in this post are:

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

[idkbutheresmyname]

Assignment 3 Iteration and Changes

All the playtests have been concluded and I will now discuss some of the changes and Iterations that have occurred as well as info on playtesting, as most of the data will be put inside of my assignment 3.

Play tester 1

Didn't know what to do one since there were no instructions

Found 2 bugs which were high priority as they made him play against level 2 and 3 enemies on level one and that the player health was actually 3 instead of 10

Changes made because of the playtester

Added instructions to every screen on what the controls are and what to do (This was found very helpful by play tester 2 and 4).

Fixed bugs that broke the game

Play tester 2

Had to be told what the controls were despite them being on screen

Found Bugs that the hitboxes weren't registering, level 2 instructions were appearing on level one and every level completes at 150 score instead of increasing with each level

Changes made because of the play tester

The instructions to say "wasd on the keyboard" instead of just "wasd"

Fixed all 3 bugs as they all broke the game it ways that would be frustrating with further play testers

Play Tester 3

Found Bug that he could play level 3 without beating 2

Didnt know what each of the upgrades did

Changes made because of the play tester

Fixed the bug to prevent players from bypassing levels

Added descriptions to each of the upgrades, explaining what they did

Play tester 4

Did not like that everything reset after one game over

found level 2 way to hard

Found bug that the planet shield stays even after being used

Changes made because of the playtester

Fixed bug quickly by updating a broken line of code

Play tester 5 was done immediately after 4

Play tester 5

Also did not like game over screen

Also found level 2 way to hard

No bugs were found

Wanted an end screen that shows you were you get you gold/upgrade points from

Changes made because of the playtester

Nerfed level 2 as it was deemed to hard after changes made after playtest 3

Game over will be scraped and might be play tested with a 6th person

Thinking about adding end screen if there is a 6th play tester

Currently this is were the play testers end if more are done in the future this post will be updated to add there bugs and information and the changes made from them.

[idkbutheresmyname]

Playtesting On some of my older games

I have realized I never went over any playtesting data for my asteroids or racer and am going to be discussing it here.

Asteroids Playtesting

I play tested with two people during this and with them it was found the the robots were to slow and extremely easy to kill if you just stayed in the middle. It was suggested that the speed should be raised for each of the robots to make the game more enjoyable. With the second person he said that the robots speed felt manageable and fun to play against but also said that the players movement speed was too slow for this new robots. I decided to only raise the speed a little bit and still focus on the shooting aspect of the game as the main way to counter the robots

Racing Playtesting

I only play tested with one person during this game and they found that the game did not have a clear objective and were lost on whether they had to do something or just survive. I then updated the game by adding the instructions 'Survive and reach 5000 score' however I was unable to test whether or not these instructions worked as I did not have another play tester.

[idkbutheresmyname]

Interesting Book chapter

The specific book chapter I wanted to talk about was chapter 9 because it was so important to my Assignment 3 specifically the subheading Conducting a playtesting session). Chapter 9 goes over Playtesting and the method you should take to do it which was used during Assignment 3 (Conducting a playtesting session section) which was to introduce the player with a script allow them to discuss some info such as games they play or what they like most about game (questionnaire and survey in the case of our assignment) and then they would play the game while talking out loud and people would record there events and speech . Since I was the game designer and the event taker It allowed me to find so much bad balancing, bad mechanics and bugs. Specific examples of this would be the asteroids movement speed which I over looked but every single of the first 3 play testers found them to fast so I tuned them down and there was not more complaints and they enjoyed the speed they were at. Furthermore, was instructions, at the start there were no instructions but with each play tester I discovered that every screen should have instructions on how to move and what to do as it was easier for them to pick up and more enjoyable to play.

Without reading this chapter before hand and learning this information I would not have been prepared for many things during assignment 3's playtesting such as the method and the amount of information that can be gained.

Sources used in this post are:

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

[idkbutheresmyname]

Assignment 3 Playtesting

Assignment 3 playtesting has began and useful information has already been documented. As a group we have play tested one person and me myself have play tested one.

Roles:

We have me and Jordan documenting events, Tamika documenting comments and Joseph being the script reader and prompter for the play tester.

Playtesting so far:

So far I have found this way of playtesting super helpful as the main developer, many things I looked over were seen as 'bad' or 'disliked' by the players and since they were explaining the thoughts I found out why.

In the first 2 playtests mainly 1 game breaking bug and 2 somewhat bad bug, with play testers going against stronger enemies on level one, the player lives upgrade using 10 gold instead of 6 and health being the number 3 instead of 10. These bugs were fixed after the second playtest so that the third, fourth and fifth required playtest can find new bugs.

There will be an assignment 3 iteration and changes coming soon and will discuss a small amount of what each play tester found and the changes made because of them.

[idkbutheresmyname]

Assignment 3 Development Progress and Group Formation

Main Information

Assignment 3 has began with a steady start. The game we have chosen to for is an asteroids wave shooter, where you protect your planet from waves of asteroids and then buy upgrades before going into the next wave (Jordan's Idea (Group member)).

Group Formation and Roles:

I am the lead programmer for the game and have began programming the main gameplay loop of selecting a level, fighting the wave of asteroids, buying upgrades and then repeating the loop with Jordan who will be helping me by providing the base of the game as it was his Idea. The second group member, Tamika has began drawing assets for the game so that there are better visuals for the game. The final group member, Joseph has began writing the scaffold for part A and will fill specific details when me and Jordan have completed the first prototype of our game.

Game Progress:

I have received Jordan's game as a part of previous workshop's which has the main wave loop done but I will need to add a level select, a shop and working health bars for the asteroids, player and planet.

UPDATE:

I have completed the systems that were needed for the game, there is a level select for 3 levels so far. The shop has 3 upgrades so far with extra player health, extra planet health and faster firing speed. The health bars have also been fixed so the planet, player and asteroids can all take damage. This prototype that has been developed now will be the one sued for the first round of playtesting.

[idkbutheresmyname]

Racing game Post mortem

During this specific design process no specific new readings helped inspire this design process mostly just the reuse of information from chapter 10 and 4 to have a balanced game and a clear goal for the game, with a quote from chapter 10 "In single-player games, it means that the skill level is properly adjusted to the target audience." being of specific use Before this there was no text telling the player what they needed to do to win. But after I added text that stated you most survive for 5000 score, which I believe would help the target audience to understand the goal. While also upping the intervals for the cars as they appeared too fast if you didn't know the code to how they spawned, so that the skill level did not have to extremely high as the target audience does include kids who might find it to difficult while also keeping the spawns just fast enough for the older people of the target audience.

Description of the game:

For this game, a top down view was used as the POV. With cars spawning randomly on an interval between 1.2 and 2.6. The difficulty of this game was seen during playtesting where it was found that the turning speed of the car was far to slow for the intervals given above. This was then fixed by upping the turning speed of the car allowing for more fluid switching between lanes. For controls the left and right arrow keys where used to move left and right respectively.

If i was to redevelop the prototype I would have done more brainstorming and design before I began coding as through coding it I found many oversights in my design that could have easily been stopped during the planning phase. The main example of this is not knowing how I wanted the cars to spawn in.

If i was to redevelop my design i would game there is only one thing I would change and that would be the spawning mechanic for the cars. Due to how this game was coded you where able to just switch between 2 different lanes every second and would avoid any of the cars that spawned to to an oversight in the random car generator. This made the game extremely easy and unfun in certain aspects if you knew about it. I would also add multiple levels to the game as after a minute you would win the game but then that would be it.

This picture is the final design of the game:

Sources used in this post are:

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

[idkbutheresmyname]

Racing game development post

Game development for the Racing game has been proceeding smoothly, with little difficulties. This week i wanted to learn more on the coding side of GDevelop and specific instances where code can be really useful. During this week I learned that Develops coding side is fairly easy compared to other programs I have used (mainly unity 6) and that brainstorming what to do for the game with a mind map is very useful.

Currently the Racing game has

The main gameplay loop complete of racing in-between cars

Score has been completed

All the animations for players, enemies and environment

Other UI elements have been completed

Above shows the basic layout of the game with the red car being the player and in this example black and pink being the enemies

There are two plans for future development

Add trails behind each of the cars so it looks more 'spacey'

Multiple levels increasing with difficult

The readings this week were helpful as chapter 6 allowed me to start brainstorming possible ideas for what I want my upcoming Assignment 2 and possibly assignment 3 to look like by "Putting it on the wall" and the mind map method as with the quote "This helps spark even more ideas" in chapter 6 it allowed me to come up with the idea to put a death barrier off the road as when writing the ideas of winning down I found the flaw of being able to stay off the road.

In my next post i will be going over the post-mortem of the racing game.

Sources used in this post are:

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

[idkbutheresmyname]

Racing game elevator pitch

The final prototype I will be making in IGB120 is a racing game in GDevelop once again. To make an elevator pitch, I will need to consider what I want my game to be.

What is my gameplay?

Dodging cars in-between 4 lanes and racking up score.

Who will play my game?

The target audience will the ages of 10 - 18

How will the Player be motivated during the game?

The player will be motivated by attempting to reach 100,000 score to move onto the next level before reaching level 10 and winning

What is the genre of the game?

Top down racing game

Where is my game set?

This game is set in a space highway where you are on the wrong side of the road dodging cars as you try to escape from the police that are chasing after you.

From these answered questions the elevator pitch is,

'Space Racers' is a top down racing game where the player is driving and must dodge cars while trying to escape from the police that are in hot pursuit. The cars have different lengths being either short, standard or large. In Space Racers, the player will attempt to cross 10 toll highway booths to escape to there home planet to evade the police.

This game is PG and suitable for ages 10-18, due to it containing themes of crime and escaping custody.

In my next post I will update you on the development process of 'Space Racers' and the playtesting, challenges and success during that development process.

[idkbutheresmyname]

Asteroids Post-mortem

The readings that helped inspire the design process was chapter 10 which was talked about in the development post but after that post chapter 3's role of players made me realize having more than one choice of weapon would be good as it allowed the player to have more roles and options in the game and allow them to play how they want. However, due to time constraints I was unable to add this before the post mortem.

Description of Game:

For this game, Asteroids a top down view was used as the POV. Robots where randomly spawned between the interval's of 0.5 and 1.4 with it spawning a little robot, standard robot or large robot depending on the random number. The difficulty of this game was seen during Playtesting where it was reviled similar to my first game the platformer that the hitboxes for the robots and the player where awful. They were then redesigned to accurate to the sprite images. For controls this game worked by having the player follow the mouse where ever it went on the screen.

If i was to redevelop the prototype I would have done more playtesting before finishing the game cause many problems were found during playtesting. This also could have been fixed by more planning but I feel like playtesting would be better.

If I had to change the game, there would be many things I would change. First I would have liked to have added some from of weapons that each did different things such as higher damage but lower fire rate (chapter 3, role of the player). Second I would have liked to try designing more of the art myself instead of using assets in the Develop store. Thirdly I would have liked to add more than just 3 waves and 1 boss battle, instead maybe having that be considered 1 level before moving onto the next. Finally I would have taken more time to try and fix the 'Janke' with the boss battle as the movements and shooting were very lackluster to my liking so that the game is balanced which is important as explained in chapter 10.

Here is an image of what my game looked like upon completion:

Sources used in this post are:

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

[idkbutheresmyname]

Asteroids Development Post

Game development for my Asteroids game has been continuing at a steady pace. This week i have tried to achieve a basic game of what I want my asteroids game to look and feel like. This week I learnt about game balancing and how important it is to make sure you game is fun and not extremely hard.

Currently my asteroids game has

The programmed robots that come to attack the player

The players movement and shooting are complete

The win condition has been implemented where the player must reach 5000 score

A game over system has been implemented which allows the player to restart the game

The UI has also been complete which allows the user to see there score and lives

Above shows the game over and win screens after 5 seconds it restarts the game so the user can play again

Future plans for this game

To have gun upgrades be rewarded with each consecutive win. Such as the gun will shoot faster or do more damage.

To program the tank/glass canon robots.

The readings this week were extremely helpful as chapter 10's balancing allowed me to find that a first prototype of my game was very imbalanced, with the section Balancing the Dynamics helping me see this as the enemies movement speeds were to fast for someone who had just picked up the game with this being "types of imbalances that can ruin gameplay", which was seen during my Playtesting, in which it was said the robots were too slow. It was then immediately fixed after the playtest was completed.

In my next post I will go over the postmortem of this game.

Sources used in this post are:

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

[idkbutheresmyname]

Asteroids Elevator Pitch

The second prototype I will be making in IGB120 is a asteroids game in GDevelop once again. To make an elevator pitch, I will need to consider what I want my game to be.

What is my gameplay?

The movement of the original asteroids game with slight tweaks where the player will follow your cursor instead of arrow keys

Who will play my game?

The target audience will be teenagers between the ages of 13 - 19

How will the Player be motivated during the game?

The player will be motivated by attempting to reach 5000 score to win the game.

What is the genre of the game?

Top down action shooter.

Where is my game set?

The game is set in a post-apocalyptic planet where robots have taken over it. With the "asteroids" being robotic drones. With different variants such as fast weaker drones or slow tanker drones.

From these answered questions the elevator pitch is,

'Ensuing Frontier' is an top-down action shooter platformer where the player must fight waves of robots and attempt to destroy them all. The robots have different variants with some being fast, slow, tanks or glass canons. In Ensuing Frontier', the player will attempt to shoot down enough of the robots to be able to escape there seemingly endless onslaught.

This game is PG and suitable for ages 13 - 19, due it contains small amounts of violence, with mature themes.

In my next post I will update you on the development process of 'Ensuing Frontier' and the challenges/successes found during the development processes.

[idkbutheresmyname]

Platformer Postmortem

First off Specific readings that helped inspire my design processes were Chapter 3 and 4. Specifically on how to add conflict and Clear goals. With the quote "They play a more important role in single-player games" (referring to obstacles in games) and "When a game has clearly defined goals, the players know what needs to be done to win" basically telling me I would some sort of enemy in my game to meet both of these with the enemies providing a obstacle to prevent the players from reaching the goals and when they reached the goal it was clear that had done that, which is why I added flags and text saying you completed the level and went to the next level and adding slimes to add obstacles to the game.

An explanation of mechanics in my game:

As the title says this game was a platformer, so I used a side-view viewpoint. I added enemies the word move back and forth between 2 points to add challenges to the player. If they touched the enemy they would respawn at start of the game. The difficulty of this game was found out during playtesting where it was said that the hitboxes were unfair for the player. They were then redesigned to be smaller so that the player could get past them easier. Another thing considered where controls. I used the arrow keys and the space bar for controls, since this game was a basic platformer I did not want complicated controls. Also during playtesting, the jump was said to be to small for the size of the enemies, so on top of making the enemies smaller the jump height was adjusted slightly to be a little higher.

If i was to redevelop the prototype I would have tried to add more planning before hand because in all honestly this game was not very good and I would have liked to have a more planned out idea. (Edit: Chapter 6 would have been good if it was in my assigned reading at the time).

If I had to Change and redevelop this game, there are many things I would change. First I would add a form of collectable to the game like coins to give the player more incentive instead of them just needing to reach the end of the level, giving them more clear goals (chapter 4). Second I would try and use my own assets/animations instead of the ones given to us in the workshop. Such as adding different types of enemies and the animations that would go with them so the gameplay would not be as mundane as there was only one enemy in the game. Thirdly I would have liked to play around the idea of a way to kill the slimes or some form of double jump. If there was a way to kill slimes, it would give the player more options when interacting with the game and allow them to enjoy it more. This is the same with double jump which would have allowed me to add more in-depth platforming with harder jumps. Finally, I would have liked to have added a health bar or a system of lives to add more difficulty to the game so that the player would have to more more careful instead of just trail and erroring the game (chapter 3, resources).

Here is a picture of what my Platformer Looked Like:

Sources used in this post are:

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

[idkbutheresmyname]

Platformer development post

So. Game development is hard.

Learning GDevelop for the first time had a lot of challenges. I was looking to achieve a basic understand of GDevelop as in how to make a character move, word building and enemy ai. With my workshops and online tutorials I was able to Learn how to add character movement, grid level building and enemy ai.

Currently in my platformer I have

A player with platformer movement (wasd and jumping + gravity)

Enemies that cause the player to die if touched

A playable course for the player to navigate and reach the finish

3 levels, each increasing in difficulty

A respawn system for if the player falls into the void or touches an enemy

The first level in the platformer game

Level 2 and 3 respectively for the platformer game

Future plans for the game I will attempt to implement before I post a "postmortem" and explain the prototype in full and the design choice's within.

Research papers for the players to collect (like coins)

Updated hitboxes for enemies (currently they are very bad)

Updated animations for the players and enemies

The readings this week has been helpful and I can see how they apply to my game specifically chapters 3 and 4 with theme showing me how I should add obstacles but clear goals to my game, which i used during my design process to add the slimes seen in the level and the flags and level text to show a clear goal and that the player had completed the goal.

In my next post I will go over my postmortem of this game.

Sources used in this post are:

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

[idkbutheresmyname]

Elevator Pitch for My First Platformer Game

The first prototype I will be making in IGB120 is a platformer game in GDevelop. To make an elevator pitch, I will need to consider what I want my game to be.

What is my gameplay?

The movement will be of any generic platformer, running and jumping will coins that the player can collect

Who will play my game?

The target audience will be kids between the ages of 10 - 18

How will the Player be motivated during the game?

The player will be motivated by trying to collect all the coins on the given level before reaching the end

What is the genre of the game?

Action-Adventure platformer

Where is my game set?

The game is set in an abandoned research facility on a distant moon. The Player is tasked with navigating the facility will dodging the ghouls (enemies) while collecting important research documents (coins).

An elevator pitch should be a three sentence or 30 second long statement that explains why a company should care about your game and why they should give you money to develop it. Thus my elevator pitch is

'Astradiora' is an action-adventure platformer where the player must traverse an abandoned research facility on the moon, Astradiora. But the journey will be tough the facility now broken down and shattered is filled with ghouls, the once living scientists. In Astradiora, players will platform around the facility collecting research documents and dodging the ghouls, attempting to find a way to escape this moon for good.

This game is PG and suitable for ages 10 - 18, due it contains small amounts of violence, with mature themes.

In my next post I will trail GDevelop, the platform I will be using to develop my platformer prototype.

[idkbutheresmyname]

About Post

Hello my name is Liam Korver and I am a first year university student and this blog will be used to document my igb120 elevator pitch's, development posts, postmortems, playtesting and many more topics throughout the weeks. I look forward to writing ever week and documenting my process as I start igb120.