chloridesalt

[chloridesalt]

assessment 3 postmortem:

Assessment 3 was alot more difficult, mostly because of the need to work in a group. Group communication was something that was lacking which resulted in lot more problems then there should have been but with time we eventually got the hang of it. Going forward in any further group/team projects and will put much more emphasis on talking with my team

[chloridesalt]

Conflicts in design (upgrades):

Before creating the game my team and i designed a bunch of diffrent upgrades that would be implemented in the game. The player could acquire any amount of these upgrades as they play these games. However i quickly ran into a problem, some of our upgrade designs were incompatible with each other . For example take Boomerang shots and homing shots, both are individually fine but how they work together? Because me and my team never thought about this i became stuck eventually making the choice to remove Boomerang shots. In the future i will make sure to consider edge cases like these in the designing phase.

[chloridesalt]

Assessment 3 (enemies 2):

Creating the enemies was surprisingly not the more complex part, rather balancing the enemies was. Well developing I had balanced the game around my skill level, which turned out to be way to difficult for our playtesters. See in developing the game i was constantly increasing the difficulty as i thought it was too easy. However i didn't realise that this was due to my skill from me playing it constantly rather then any problems with the game and as a result many of our playtesters couldn't even get past the first difficulty.

So i went about balancing the game to make it easier. Which turned out to be easy as i while observing our playtesters i noticed that the problem wasn't the enemies design, but rather there amount. Too many enemies were spawning overwhelming the player to quickly so i lowered the spawn rate and the difficultly was much better.

(Lowered from 4 to 2)

[chloridesalt]

Assessment 3 (Enemies):

Spawning enemies in at diffrent levels was surprisingly easier then i thought. I was determined to keep the spawning logic concise and importantly modular. in the end i came up with system that would use a variable to track and spawn enemies. Each enemy had condition that checked whether a variable was a certain number or higher and then spawn that enemy and At the end of each meltdown a point would be added.

[chloridesalt]

asteroids Game Postmortem:

The design Idea:

For this prototype i was mostly focussed on creating a tension and release mechanic that would serve as a good base for a future full game. I was able to get into upgrade mechanics as was making sure to keep in mind scope and didn't get overwhelmed.

The design process:

The struggles:

Building my second prototype was definitely easier then creating my first. Mostly because i had started to become familiar with how gedevelop worked. However once i started exploring more complex things like variables i once again became confused, but thanks to me keeping scope in mind it was easier to overcome obstacles in development .

The aim for improvement:

Moving forward i definitely still wanna make sure i keep scope in mind as it made the development process much easier to handle. But i also wanna place more emphasise on planning out designs before attempting them as i found myself attempting to solve problems before i even grasped what the problem was.

Improvement on the platformer game design:

I am pretty happy with how my core meltdown mechanic went all-though i would like to add upgrades in the future

[chloridesalt]

Platformer Game Postmortem:

The design Idea:

The idea of moment to moment gameplay heavily inspired my design process as i was designing this game. Moment-to-moment gameplay is where players will be spending 90% so while i was designing the game i wanted to make sure the player was still being engaged during the m2m gameplay through elements such as diverging paths and continued obstacles rather then a single segment.

The design process:

The struggles:

Building my first prototype was quite more difficult and tasking then i was expecting but at the very same time easier then i thought. While a majority of my struggles can be contributed to learning how to use GDevelop for first time i also suffered alot from scope. It gets really easy to overshoot, overthink and aggrandise the scope leading to sense of overwhelmingness and paralysis.

The aim for improvement:

So as i move on to my next game i'm certainly going to try and keep the scope simple and focus on development the core mechanics to the best they can be while keeping in mind that they don't need to be absolutely perfect.

Improvement on the platformer game design:

Looking back i would like to put much more emphasis on the core mechanics rather then the design of level. Making it so the level would compliment the core mechanics of the game rather then the core mechanics complimenting the level design

[chloridesalt]

Asteroids development 3 (Core meltdown):

Goal:

Create an Combat event system designed around tension and release

design idea:

I wanted a tension and release system for this game as it would allow me to create an intense gameplay loop without exhausting the player.

design process:

The tension and release system would have have two phases. The first phase (Core stabilized) would have little challenge to the player allow the player to rest and recuperate. Then after set period of time the second phase would start (core meltdown), spawning difficult enemies for the player to fight. finally after another set period of time the game would return to phase 1 .

Design implementation:

First i created a combat event which would periodically spawn enemies, this would only work though if the variable combat was true

Then a scene timer would trigger the Core meltdown event. The event would disable the asteroids ability to spawn and delete all existing ones before setting the combat event to true.

The additional events like the time scale and text are there to inform the the player a Core meltdown is occurring and make the event more dramatic.

Finally the combat event would also start/restart another Scene timer called core stabilised. Which upon activated would set the combat variable to false, reenable the astroid variable, restart the Core meltdown timer and kill all existing enemies.

[chloridesalt]

Asteroids development 2 (Simple enemy ai):

Goal:

Create an Enemy with simple shoot and move Ai

design idea:

Starting my game i figured it would be good to have extremely basic enemy. One that could provide small amount of pressure for the player in the beginning while the player was still learning, and then supplemented in later on with tougher enemies. The enemy would be less of a proper Ai and more of an environmental hazard (player vs environment) as the enemy wouldn't react to what the player was doing.

design process:

The enemy ship would move towards the player before stopping, it would then shoot at the player for a set amount if time before resetting. It would only have one health point and would only deal one damage. Its main purpose would be to distract the player from larger more dangerous enemies.

Design implementation:

Using the turret behaviour i made the enemy face the player at all times, then a object timer would count down for random amount of time. Once the object timer triggered the pathfinding would stop and then enemy would be allowed to shoot for 5 seconds. after the 5 seconds was up the enemy would have its pathfinding returned and the timer would be reset.

Thoughts (Player vs environment):

[chloridesalt]

Asteroids development 1 (Player movement):

The first main goal

[chloridesalt]

Astroid: elevator pitch

Title of them game: Core meltdown

Absolute meltdown is the idea of what if risk of rain met asteroids with A lot of anxiety. Core meltdown is an action-roguelike, shoot em up, you play as stranded inter-dimensional space miner salvaging whatever you can to escape you're predicament. You're Galaxy Core prevents dimensions from leaking into you're area allowing you to mine valuable resources to upgrade you're ship. However you're core is unstable and will randomly meltdown allowing the horrors of the universe to leak in an attack you. The longer you stay the greater the resources you can get however the core will become more and more unstable so you must decide the risk vs reward.

Some unique selling points for the game are:

risk vs reward gameplay loop: A exciting risk vs reward gameplay loop that encourages the player to take risks for further gains

Tension and release : Combat events are triggered by core meltdowns which lock the player into combat with no escape until the core stabilises leading to high tension and euphoric release.

Unique upgrade synergies: Every upgrade the player gets will synergy with each other providing a plethora of unique combos for the player to enjoy.

[chloridesalt]

Platformer Game Postmortem:

The design Idea:

The idea of moment to moment gameplay heavily inspired my design process as i was designing this game. Moment-to-moment gameplay is where players will be spending 90% so while i was designing the game i wanted to make sure the player was still being engaged during the m2m gameplay through elements such as diverging paths and continued obstacles rather then a single segment.

The design process:

The struggles:

Building my first prototype was quite more difficult and tasking then i was expecting but at the very same time easier then i thought. While a majority of my struggles can be contributed to learning how to use GDevelop for first time i also suffered alot from scope. It gets really easy to overshoot, overthink and aggrandise the scope leading to sense of overwhelmingness and paralysis.

The aim for improvement:

So as i move on to my next game i'm certainly going to try and keep the scope simple and focus on development the core mechanics to the best they can be while keeping in mind that they don't need to be absolutely perfect.

Improvement on the platformer game design:

Looking back i would like to put much more emphasis on the core mechanics rather then the design of level. Making it so the level would compliment the core mechanics of the game rather then the core mechanics complimenting the level design

[chloridesalt]

GDevelop(Event system)

Goal:

Add animations and play sound for my character

Event system:

As stated in one of my earlier blogs the event system is the most important system in GDevelop for making games along with behaviours.

The event system kinda works like an 'if' statement, you add conditions like the player jumping and then action that occurs if that condition is filled like a jumping animation.

The image above demonstrates how i achieved the animation for my platform character in the event system. While this system may seem simple and restrictive i quickly learned that with some clever thinking you an achieve a surprising amount with the event system.

[chloridesalt]

GDevelop(Adding animated sprites)

Goal:

Add animations

[chloridesalt]

GDevelop fundamentals (Behaviours):

Third blog and first time using GDevelop

Goal:

For developing a platformer my basic starting goal would be to set up a fully functional character with animations and movement.

Basic movement:

Setting up a basic movement for the character was extremely easy thanks to GDevelop behaviours feature, which allows you to easily add pre-existing behaviours like platformer movement. Behaviours are extremely flexible as you directly change the values of the behaviour to you're liking and then easily manipulate them GDevelops event system. I quickly learned the behaviour and event system are the bread and butter of GDevelop and despite there simplicity can you achieve a lot just using them.

Behaviours:

Once you add a behaviour you can easily change certain values like jump hight for platformer character:

[chloridesalt]

Platformer Game: Elevator Pitch

Second blog and first pitch, it took abit to get my creative brain turning but Here's the pitch below:

Title of game: Descending the dark

My game is based on the idea of what if horror found its way into platformer game.  Descending the dark is 2d platformer where rather than acceding, you descend deeper down into an endless void in search of source behind the endless darkness. As you explore the void, you’ll uncover ancient lore which will teach you more about the void and how to survive its hostile environment. This lore will also allow you to learn different spells that help you to navigate and fend off myriads of hostilities the endless void provides, as within the void you’re the prey and must use every trick in the book to avoid becoming another lost soul.

Some unique selling points for the game are:

Interconnected gameplay and lore:  As you explore the void, you’ll find tombs that give lore about the void and world it exists in, but it also provides crucial information on how to deal with the various hazards in the void

spell-based system: You’ll find different spells that aid you’re journey which can be mixed and matched to players contempt

avoidance based Combat: There will be no direct way to fight back, rather you’ll have to use your knowledge and spells to avoid death.

Student contact info: bilal.qarri@connect.qut.edu.au

Draw up of concept and ideas:

[chloridesalt]

About me

Little bit about me:

Hello, I’m Billy Qarri and just started university studying game design. I’ve always had special place for video games since I first played cut the rope on a mobile phone in 2010 and since then I’ve been an avid gamer.

Brings back memories

My interests in game development:

However, my relationship with games goes beyond just playing them as I also have keen interest in game development. As person with an extremely creative mind, I’ve enjoyed exploring the creative process behind how certain media was made. How a director achieved a certain shot or how a plot was conceived for tv show but especially exploring the creative minds and ideas that go into creating a video game. Video games have always been my favourite form of media I've poured thousands of hours into hundreds of different videos games an the shear uniqueness and variety that video games can achieve has always astounded me and as a result it’s always been my dream to develop my own video game.

When I say hundreds I mean hundreds

My goals for this unit:

While I have explored game development before in years 11 and 12 of high school where I took an ICT course which featured a unit that explored the Godot game engine. I’ve never explored further than just simple projects, so my main goal for this unit will be to create full protype that fully involves proper game design and functionally is more than a simple scene. Along with learning how to manage scope and cooperate with other students when making a game

Small test scene I made in Godot