tameka05

[tameka05]

IA3 Asteroid. finishing development

This post will cover the implementation of the remaining features in our group project 'Asteroid.' After updating the player movement, I decided to focus on adding the ultimate ability - a blackhole. This ability will turn the player into a blackhole, where all enemies on the screen will be pulled towards them. It will kill all the enemies on the screen, so it is a powerful 'get out of jail' ability. To balance out its power, players will have to defeat enemies to gain the ultimate charge necessary to activate the ability. This will add more decision making for players, as they need to decide when they should use the ultimate vs when to save it.

I made the sprite for the ultimate, and then coded its functionality into GDevelop. The blackhole was added to be a big fun factor in the game. getting to turn into a blackhole and destroy every enemy sounds really cool, and can allow players to live out fantasies, which is discussed in chapter 11 of the textbook.

Next I worked on adding in 2 new enemy varieties: the laser enemy and the commander enemy. The commander enemy is basically a more powerful, smarter and quicker version of the basic enemy, with 2 guns. Despite its similarities, the commander feels very different to fight against than the basic enemy. If you just move head on into it, you will always get hit, so players have to try and dodge attacks and use the screenwrapping to hit it from behind.

The second enemy added is the laser enemy. This enemy will shoot out a continuous laser beam, and then rotate in a 180 degree arc. The attack does not stay locked on the player, so players have the chance to dodge the beam by moving quicker than it or using the screen wrap. To make up for the powerful attack, the enemy is mostly stationary, and is defenceless in between attacks.

While I finished working on these 2 features, and adding sound effects, other members of my group added all of the UI, music, and wave system into the game.

And that concludes the development of our prototype 'Asteroid.' Overall I am super happy with the end result, I added all of the main feature I wanted, and I think it turned out great in the end. I enjoyed the gameplay myself, but we will have to see what other people think of it.

[tameka05]

IA3 Asteroid. Development

Since I already had feedback from my previous playtesting earlier in the semester, I decided to focus on adressing these issues with the core of the game first. Chapter 10 of the textbook talks about ensuring the basic idea, or the foundation, of your game is strong before adding more features and polish. For our game, 'Asteroid.', the foundation of the game is the player movement. Since movement is the game core mechanic, and is also used for attacking enemies and dodging attacks, it needed to feel fun to use, and easy to learn.

From the feedback I got, players thought the movement was interesting but clunky, and was hard to understand and learn. This boiled down to 2 main things:

movement felt clunky, changing direction didn't feel smooth and was too slow

You could not tell what direction the player was facing

Too address the first issue, I had to change the movement system to allow for quicker direction changes, and also making the movement faster in general. Since the movement is physics based, this required lots of tweaking but the end result feels much smoother based on our internal playtesting.

I wanted to fix the second issue by only changing the player sprite, but i realised this could never be clear enough so I had to use a different approach. In the end i decided to add an indicator to the outside od the player that shows the direction the player is facing.

While it wasn't what I wanted, it definitley was the right choice for the game. With both of these changes, the movement should feel more fun to use, and much more intuative.

[tameka05]

Group Assignment

For our last assessment of the unit, as a group we will work on one of our previous prototypes and turn it into a more complete prototype. My group chose to work on one of my prototypes 'Asteroid.'

We will be aiming to add new features and fix issues from the prototype. these will include:

new enemies

UI

better tuned movement & direction indicator

A wave system for tracking progress

an ultimate ability

general balancing

These are the main things we want to implement, but more changes will probably be made as we go

[tameka05]

Asteroid. Sell Sheet and One Page

For our next project we had to choose one of our previous prototypes to design and creat a sell sheet and one page for. I chose to use my game 'Asteroid.' for this project, because it is my most complete game, and the one that I want to continue working on the most.

Because the game isn't complete already, I had to come up with different designs and mechanics which are not yet implemented, which you will see in the documents below.

Here is my Sell Sheet:

and here is the One Page:

[tameka05]

2P Racing Post Mortem

The design process of this game did not go how I planned. I did not end up with enough time to focus on implementing most of the features I wanted to implement. Adding in 2 player characters took up most of my development time, which I did not account for when I was planning my design process. I am happy that I got the 2 playable characters working together, so I did achieve my goal of making a 2P local game, just not a very complete one.

The actual design of the game also needs changes. It is using placeholder art which subtracts from the world of the game, and makes it hard for players to engage with. I would also of changed the design to include more features of interactions with the fact that there are 2 players. Something like different collision effects, upgrades, or things like that. These would make playing with friends far more enjoyable and interactive.

[tameka05]

2P Racing Development Post

I spent most of my time trying to implement the system for 2 players to play the game at the same time. The textbook and lecture content have talked about how to add conflict into your games, and the way I wanted to implement it was with player vs player gameplay. That was the main reason for this decision.

implementing the 2 seperate players took some time to get working properly. Both characters had physics behaviours and properties that had to be tweaked, and balanced to interact with each other.

Doing this took up most of my development time on the project, but I did manage to add walls that would stop the players from moving through them, and with these I could make a quick mock up of a level to test:

[tameka05]

2P Racing Elevator Pitch

2P Racing (placeholder name), is a top down racing game where you can play against another player locally, to see who can reach the goal first.

Both players will use keyboard inputs to control their spaceship racer; WASD for player 1, arrow keys for Player 2. These ships will be able to collide with each other, to allow for player interactions while racing. To give the game a unique feel, the characters will be physics objects, so that dynamic and more realistic/intuative collisions can occur. Players will also be able to collect pickups and power boosts to give them different advantages and ways to slow down the opposing player.

The game is set in a space racing arena, where the barriers of the track will be made up of various bits of space debrie. 2P Racing will be a quick and casual game, which is super easy to pick up and learn, but where you can test your skills against your friends. The target audience therefore is anyone who wants a game that is quick and fun to learn and play.

[tameka05]

Asteroid. Postmortem

Compared to my last project, I am way happier with how 'Asteroid.' turned out. I attempted lots of new things and managed to create a complete prototype this time, which is fun and has lots of room to develop further.

Chapters 7, 8 & 9 of 'Game design Workshop, fourth edition' (Fullerton, 2018) inspired my design process. These chapters talk about prototyping and playtesting your game. I was prototyping and playtesting my game all throughout the development process, which helped me tweak and adjust features, and identify issues early in the process. This also directly led to the creation of certain features, like the dash mechanic, which improved the game significantly. Additional, the process of getting others to playtest my game showed what worked and what needs to be tweaked in the future, like the player movement.

If I was to change how I developed the prototype, I would of spent more time researching how to implement features before trying to add them. This slowed down my development process, as I wasted time trying to add features when there were simpler options I could of taken. I would also spend less time polishing in my prototype, such as trying to make text not blury, or tweaking art assets. While these things are important, they are not necesary for a prototype, and I could of spent that time adding new features instead.

If I was to change the design of the prototype, I would definitely add sound effects. In my lectures we talk a lot about 'player feedback', and rewarding players when they do something. Adding sound effects is a simple and effective way to do this: they destroy an enemy, a sound plays. It would also increase immersion and communicate information to the player; such as when they get hit or when an enemy spawns. Apart from this, I would add more content, such as different enemies and more player abilities. I would also tweak the player movement, as that was the main thing i got feedback about.

That's 'Asteroid.' done for now, but I definitely hope to continue working on this game as my final project for the unit.

[tameka05]

Asteroid. Development and Playtesting

To add the last finishing touches to my prototype, I added a 'start screen' (which explains the player controls) and a 'game over screen' (which shows the players score and lets them restart), to my game.

Start screen:

Game over Screen:

Before playtesting, I fixed a frequent bug I was encountering, where the player would get stuck in the side of the screen. This was done by tweaking some values regarding the screenwrapping.

Playtesting:

After finalising these things, I got some other people to playtest my game. Here are some of the common pros and cons:

Pros:

people thought the movement was cool

screenwrapping was good

very satisfying to run through enemies and destroy them

fun concept and idea, executed well

no bugs

pretty polished and smooth to play

Cons:

Lots of people struggled to get a grasp of the movement on there first time playing

The movement had clunky elements, like turning and moving in an opposite direction was slow

Overall I am super happy with how my prototype turned out, and I think there are still so many ideas I can implement into this game

[tameka05]

Asteroid. Development Post 2

After implementing my character movement, the next thing I wanted to add was enemies. I wanted to try and learn how to add enemies with AI elements, which is not something I have done in GDevelop. The enemies for my game would be the spaceships that you play as in the original Asteroids game, to keep the theme.

After working on these for a while, my finished enemies turn to face the player, move towards them, attack when in range, and move away from the player if they are close to crashing into them. Overall I am super proud of these basic enemies, because they feel good to verse, and since they also are physics objects, they will go flying before getting destroyed when the player hits them. Having this basic enemy will also make adding different enemy types easier later on. I scoring system was also implemented so the player gets points whenever they kill an enemy.

I also added a spawing mechanic and difficulty scaling. The enemies will randomly spawn on the screen (after a warning display), and the longer you last in a run, the more enemies will spawn. The difficulty scaling will challenge players who are trying to beat there high scores, while also rewarding them with more points based on the difficulty.

After playtesting my game for a while, I also decided to implement a 'dash' feature, because turning and changing direction in my game felt quite slow, and the dash gave an instant boost in whatever direction the player is facing. Adding this also made my game way more fun, as there was much more opportunity to dodge attacks and hit enemies.

[tameka05]

Asteroid. Development Post

I have started development on my Asteroids style game: 'Asteroid.' Chapter 6 of the textbook: 'Game design Workshop' (Fullerton, 2018) talks about conceptualising ideas and the importance of coming up with a strong idea for your game. With this in mind, I spent more time fleshing out and developing a full idea for my game before starting production. The idea of 'Asteroids but you are the Asteroid', has lots of potential, so I chose to work out what elements I needed to keep from the original game, and what new systems and mechanics I could implement into my game.

So the main thing I wanted to achieve in GDevelop was 'Asteroids-like' movement. To accomplish this, I focused on learning the basics of Gdevelops physics 2.0 system. I chose to use this system because it would allow for me to implement acceleration, deceleration, rotational acceleration, as well as some more dynamic collisions. This worked and I know have a movement system implemented in my game. The other system I wanted to implement has a 'screenwrapping' effect, where moving off the edge of the screen will place you on the opposite side.

The other thing I worked on for the game, as can be seen above, is art for the player character. I created this myself, but struggled to work out how to show plyers clearly which direction the player is facing, which is why there is a placeholder red arrow to show this. So this will be a design problem to come back to later, but currently is not a high priority for me.

References:

Fullerton, T. (2018). Game design workshop : A playcentric approach to creating innovative games, fourth edition. CRC Press LLC. from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[tameka05]

Asteroids Game Elevator Pitch

Now that I have finished my Platformer prototype, I am moving on to my next project: an asteroids style game. Here is the elevator pitch for my game:

The title of the game is 'Asteroid.' This is an intentional play on the name of original game 'Asteroids', because this game is Asteroids, but YOU are the asteroid. It is a role reversal where instead of being the ship trying to survive against the asteroids, you are the asteroids trying to destroy as many ships as you can and not be broken into pieces. As the game progresses you can also upgrade your asteroid and unlock more abilities.

The main mechanics of this game will be movement similar to that of the original Asteroids game (up arrow to accelerate, left & right keys to rotate), but tweaked to suit the changed goal of trying to hit the enemies, not avoid them. The game will also have a 'screenwrapping' effect like the original game, where instead of flying off the edge of the screen, you instead appear on the opposite side. I also plan on adding combat features, such as potentially being able to throw rocks, but these will have to be tested.

The setting of the game will be a the black empty void of space. I aim to replicate the aesthetic of the original arcade game, so the whole game will be black and white, and pixelated. I want players to feel like they are playing the original Asteroids game, but with completely new gameplay, mechanics, and objectives. Arcade style sound effects and UI will also be implemented to build on this effect.

The intended audience is anyone who at least knows what the original Asteroids game is. That being said, the gameplay will be simple and quick to pick up, so anyone can get into the game.

Thats the pitch for 'Asteroid.' I'm super excited to work on this game, I think the idea is super fun and has lots of areas I can build upon, and the scope of the game is definitely manageable for the time I have to work on it, so hopefully I will have a more complete prototype finished this time.

[tameka05]

Platformer Postmortem

This is the Postmortem for my first prototype, a platformer game called 'Blade Quest'

The Design Process:

Both the lecture content and the textbook: 'Game Design Workshop' by Tracy Fullerton helped inspire the design process for my first game. In particular chapters 3 and 4 of the textbook helped me when creating my game, as these chapters talk about the formal and dramatic elements that make up a game. This helped me go into the game making process with a clear vision of what I wanted to achieve. I wanted my game to be interacted with a 'single player versus game' structure (talked about in chapter 3), where the gameplay is only focused on the player versing the videogames obstacles and enemies. The rules of the game where simple: hit the enemies to kill them, but if they hit you, you lose. While all these concepts are very simple, having a good grasp on them before I started making my game helped streamline the process.

In order to make the game fun and appealing to players, Dramatic elements (talked about in Chapter 4 of the textbook), and a concept called 'Moment-to-moment gameplay' discussed in my lectures where things I wanted to implement. Dramatic elements include a wide variety of topics, but all are focused on engaging and investing the player. The main element discussed from the textbook that I focused on including was the element of 'premise', which is basically the story or world you want your player to feel apart of. Instead of my game being just squares or placeholder assets attacking each other, I wanted to include a capable looking player charcters and some dangerous enemies to attack. Adding animations to the player and enemies made the game feel more fluid, and made the game much more enjoyable to play, even if nothing technical was added. Seeing your character move, or attack; or enemies dying after they are hit by an attack made the game more engaging and interesting for a player to interact with. I also wanted moment-to-moment gameplay in my prototype, where there is always something 'fun' in each moment of gameplay for the player. I specifically focused on interating this into my combat, by allowing the player to combo attacks, 'hitstun' enemies, and recquiring careful timing to avoid getting hit by enemies while striking them yourself. This made the combat feel fun to engage with as a player.

Takeaways and things to learn and improve upon

If I were to redevelop my prototype, there are a few things I would change about my design process. Firstly, I would of put more time into devoloping more gameplay elements of my game, instead of hyper-focusing on a couple. By the time I had finished implementing the combat system of my game, I did not have enough time to add other important features, such as player health, win and lose conditions, goals for the player to achieve, etc. While I am super pleased with the combat system in my game and all of its nuances, the fact that I wasnt able to include all of these extra systems in my prototype meant that these weren't able to be tested, and so I can't get feedback on them. Protoyping and playtesting game features is a key part of the playcentric design process outlined in chapter 1 of the textbook.

If had a chance to change the actual design of my prototype, I would have added more lof the core gameplay feautures, to try and have a more complete prototype, even if it is less refined. Another part of the prototype that I was not happy with was the level design. I wanted to create an expansive world that players could explore and adventure through, with platforming elements and world obstacles throughout. However, in the prototype the level is only a flat platform, with enemies preplaced throughout. There is no platforming obstacles, or anything for the player to journey through or towards. This hurt the moment-to-moment gameplay of my game, as doing anything other than combat was very boring and tedious. So if I were to spend more time on this project I would improve the level design and add more core features to the game

Conclusion

For this being my first game, I am very pleased with the final result. Even though it is missing features and game elements, I am very proud of the combat system I implemented. I look forward to working on more games in the future!

References

Fullerton, T. (2018). Game design workshop : A playcentric approach to creating innovative games, fourth edition. CRC Press LLC. from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[tameka05]

Platformer Progress & Playtests!

So I made lots of updates to my platformer, Bladequest, to add the melee combat system I wanted as well as some enemies to attack and kill. I am proud to say that after following the advanced melee combat tuturial (Wishforge Games, 2020), every other mechanic I added was done without following a tuturial.

GAME FEATURES & PROGRESS

The combat system I implemented had a 'combo' system in it, where pressing the attack button again after an attack would cause a different animation to be played for the next attack. This happens 3 times, but will reset back to the first animation if too much time passes, or the third animation is completed. While currently there is no mechanical difference in these attacks (except for hitbox positions), this system would easily allow for changes to specifc attack variables - such as damage, or more advanced hitboxes - in the future. The other main feature of the attack is a 'hitstun' mechanic, a feature which will interupt an enemies attack when they are hit. This was one of the more challenging things to implement, since the enemies would frequently stop functioning if the sequencing or conditions of the code weren't correct.

The other main feature implemented was the skeleton enemies for the game. These were coded to take damage if the player hit them 3 times with an attack, and to die and disapear after there death animation finished. The skeleton enemies also are able to turn to face the player when approached, and attack the player if they get in range. The attack currently can't hit or damage the player, because only the animation is coded in, but the hit system will be identical to the players system. The affirmentioned hitstun is also applied to these enemies, so that their attack animation can be interupted if the player hits them.

Here is a demonstartion of the player and enemy attacks, and the hitstun interupting the enemy:

PLAYTESTS & FEEDBACK

So with a prototype completed, I could get people to playtest the game and give feedback on its current mechanics. This is a crucial part of the playcentric design process, and the earlier playtests can be done, the easier it is to change and update elements of your game (Fullerton, 2018). Here is the feedback I got from people on my game:

Pros:

The hitstun mechanic was impressive and made the game feel better

the attack combo was cool

Good choice of sprites for player and enemies

Cons:

Attacking while mid-air stopped all horizontal movement, which felt jarring for players

Lack of features such as player health and damage, levels, challenge, win/lose states

And some feedback of things to add was for a different attack to play if the player attacked while mid-air.

I was glad players enjoyed the mechanics that were featured in the game, and the way attacking works while mid-air is definitely something I would change in the future, ideally with the addition of specific arial attacks as suggested. Also more features and content to make the game actually feel like a game are features I would add next, but my time working on this project is finished. I might revisit it in the future, but for now I need to move on to making a different style of game; a top-down shoot-em-up. Expect a post-mortem on the platformer project soon.

REFERENCES:

Wishforge Games. (2020). How to Create an Advanced Melee / Sword Attack in GDevelop (Free 2D Game Engine) - Tuturial [Video How to Create an Advanced Melee / Sword Attack in GDevelop (Free 2D Game Engine) - Tuturial]. In YouTube. youtube.com/watch?v=3XT40kDRp8g

Fullerton, T. (2018). Game design workshop : A playcentric approach to creating innovative games, fourth edition. CRC Press LLC. from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[tameka05]

First progress!

I have started learning the basics of GDevelop, and have begun work on my very first game - Blade Quest (see elevator pitch in previous post)! I spent last week doing some basic GDevelop tuturials and getting used to the software, but now I have started putting in my own work outside of the workshop tutorials. Here is what I am working with currently:

This is just basic character movement, camera controls, and animation switching, but I am very happy with how it is looking! I found a great character asset on Itch.io (rvros, 2018) which suits the look I want for my game perfectly.

Currently I am working on adding my main feature, the combat system, to the game. To do this I am following a video tuturial about adding advanced melee attacks to GDevelop (Wishforge Games, 2020). I am also going to be adding some enemies, using more assets that I have found on Itch.io (AstroBob, 2021):

All of this work is to create a prototype that can be playtested. This is a critical part of the 'playcentric' design philosophy that Tracy Fullerton talks about in chapter 1 of their textbook: Game Design Workshop: A Playcentric Approach to Creating Innovative Games (4th ed.) (2018). This process focusing on involving the players as early and as much as possible when designing games. And one of the best ways to do this is through prototyping and and getting others to playtest your game.

So the current goal is to finish a prototype and get the core gameplay elements tested out, and then I can decide where to go from there. Thats all for now, cya!

REFERENCES:

credit for the character assets goes to rvros on Itch.io: rvros. (2018). Animated pixel adventurer [Digital Animated pixel adventurer]. On itch.io. https://rvros.itch.io/animated-pixel-hero?download

Credit for the skeleton enemy assets goes to AstroBob on Itch.io: AstroBob. (2021). Animated pixel art skeleton [Digital Animated pixel art skeleton]. On itch.io. https://astrobob.itch.io/animated-pixel-art-skeleton

Wishforge Games. (2020). How to Create an Advanced Melee / Sword Attack in GDevelop (Free 2D Game Engine) - Tuturial [Video How to Create an Advanced Melee / Sword Attack in GDevelop (Free 2D Game Engine) - Tuturial]. In YouTube. youtube.com/watch?v=3XT40kDRp8g

Fullerton, T. (2018). Game design workshop : A playcentric approach to creating innovative games, fourth edition. CRC Press LLC. from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698

[tameka05]

Platformer Elevator Pitch:

The first game being made in my IGB120 course is a platformer prototype, being made using the GDevelop software. Here is my elevator pitch for it:

The title of the game is: Blade Quest

Pitch: a combat focused platformer game, where players will be able to journey through a dangerous forest full of enemies and obstacles.  The primary mechanic of the game is its combat system, where players will be able to combo attacks and mix melee and ranged combat, for fast paced and dynamic action.

Audience: Blade Quest is being designed for a young adult age demographic, but its gameplay will be easy to pick up so anyone can jump into it and start playing.

Game controls: WASD / keyboard controls for movement, mouse controls for combat

Unique features:

Blend of ranged and melee combat

Combo system for melee combat

Expansive environments to run through

[tameka05]

About me:

Welcome to the start of my journey as a Game Developer! My name is Tobias, and I have just begun my studies at QUT, to learn how to make video games! I have always wanted a job relating to video games , and what better job than to actually make them! I can't wait to get started and put both the creative and logical sides of my brain to the test!

My goal is to, by the end of my first semester, is to learn the fundamentals of game design and programming, and to make some functioning games/prototypes!

Thanks for joining me on this journey, and expect updates soon!