#qutigb220

Now that one of my major assessments is over with, I have to start assessment 3, i.e the reason they`ve been making us do gdevelop class work for the past 2 months. Even cooler is that assessment 3 is a team assessment and I`m been chosen by the council (Tom, Theo and Francis) as a meme to be team leader, despite my reluctance (likely because of my astute social prowess of not speaking uness someone speaks to me first). For the game we will be making, we each decided to work on Tom`s idea for an asteroid game:

Zero Patient Elevator Pitch:

The population is fighting a deadly pandemic outbreak currently circulating in the body’s bloodstream, as a blood cell your objective is to destroy any virus that enters the bloodstream, if the diseases collide with the blood cell, then it becomes weaker through visual indicators such as the cell turn to a darker shade of green.

The game will feature asset design around the blood’s cells, viruses, and vaccines

The game will play similar to the old school arcade top-down shooter inspired by Asteroid, the player will spawn in an empty red background and their goal is to survive as long as possible while destroying the enemies which take the form of disease before it collides with the player. There will be a power-up in the game which will give the player a temporary shield in the form of a vaccine syringe. The controls are WASD for movement and right mouse click to fire projectiles

His idea takes a more relevent, biological aproach with the asteroid template, focussing on a strand of the AstroZeneca vaccine fighting off covid cells, which contrasts heavily with my semi-sh*tpost passing off as a game. As of right now we only have the prototype ready, but considering it works just fine as a standard asteroid game, thats perfectly fine for now. In the future, we plan on adding more levels, sfx, a difficulty curve, more enemies that act in different ways, both permanent upgrades and powerups to help fight of the coronavirus hordes and an information screen, containing facts about the coronavirus. 

As subtly expressed last week(hour), the final product of my “sled” game was less than ideal when compared to the idea I had in mind from the elevator pitch, and as a result, the playtesting feedback was more negative overall (maybe I needed to give out more gobstoppers this time...)

Just like with my platformer design pitch and the game devs behind anthem, hoping people would play it for more than a week, it seems I was too ambitious for my own good.

I wasn`t able to get multiple levels, or more than 2 characters in the game,, however I was able to implement UI and a Character select screen, admittedly also unfinished but still

Along with that, (although not explained anywhere in the game) both cars have different stats, with the red cars being faster, but with a bigger hitbox and the blue car being smaller and faster when recovering from crashing. In addition, I also created numerous stage objects that do various things when contacted by the player, like ramps which grant invulnerability and a speed boost for a limited time (they also turn your character model around because growing and srinking characters in size is too far out of my expertise), gravel that slows the player character to a crawl when driven over and oil slicks that “blow up” the player, stopping them from moving for a limited time.

With those, however I also forgot to add in any barriers to the track, so the cars can just avoid all the obsticles and the obsticles arent explained at all what their function is. However none of these blunders compare to the fact that absolutely none of this is at all sled themed, absolutely desecrating Club Penguin Sled Race, by even incinuating It had some involvement in the inspiation behind this botched final product. 

For this game, I decided after how satisfied I was with Phrog, that it was time for me to ‘take inspiration’ from a real AAA artistic experience, Club Penguin Sled Racing

The name of this game will be ‘untitled sled racing project (working title)’ and the main three differences it will have from the masterpiece seen above are multiple characters with varying stats and attributes, a top down camera angle instead of isometric and multiple stages with different themes to increase variety. The game will feature 2 player coop alongside what`s known as a Lizard, Frog and Rabbit approach to coop play balance, where each of the racers with have different stats that make them more useful in certain maps and conditions. In addition my game will have more varied hazards and obsticles, so the differnt characters can have more varied abilities to make them stand out, unfortunately I won`t be able to compose a theme as slappin as sled racing in the og club penguin (or any costumes as drippin as the ones in the promo images that you can`t even wear in gameplay, but I guess no game is perfect). The selling points of my game is that its a simple coop game to play in a class/work environment, it utilises the frog, lizard, rabbit method of game balance for each of the characters and the game has multiple characters/stages to play through and as

Controls

P1: WASD to move

For Phrog, I finally bit the bullet this week and had other people playtest my game for feedback, mostly I just wanted to show off the amount of effort I put into the game`s artstyle. Also it`s worth mentioning that these reviews were made during development, rather than after, so some of the criticisms of phrog ended up working their way into the final product (My way of saying the game deserves way more than a 2/5 on balance and strategy, Tom)

As mentioned before, many of the complaints leveled against Phrog were resolved once development had finished, notably the bullet size was increased, the UI colors were changed to stand out more from the background, a reset/start screen was implemented and the difficulty of the early stages was reduced for new players to get a feel for the controls. The remaining criticisms regarding the singular enemy type and lack of gameplay variety were more complex issues, that would`ve been harder to implement at a time when development was wrapping up. I have no clue what stationary was critiquing, but the frog and pads do indeed move and the request regarding reduce rate of raining fire respectfully reeks of rotund roomy rumpus rhino droppings. If EA, Nintendo, Blizzard, Konami, Bethesda, Ubisoft, 2K, Game Freak, etc. have taught me anything, its that the consumer is always wrong anyway, so I decided the bullets in the final product should still travel 3 seconds per hour in order to preserve my original artistic vision that prioritises playing games over making them.

For the most part, I think I was on the right track last week, in that ripping something off completely is far easier to make a game out of than taking inspiration and actually trying, might be why the actual games industry does it all the time...

As you can see, I made a few changes from the elevator pitch, as I didn`t want to make the same mistake as last time and stick to my original idea too much. Most notably, the jumping mechanic was too time consuming to figure out how to implement, so instead I implemented a diving mechanic that serves the same function of making the player invincible for a limited time, while still allowing the player to fully control the frog unlike the original jump idea. Included alongside the new mechanic change was a at the bottom left corner that started at 5 and counted down to when the player could use the dive feature again. 

This was partly to compensate for the second biggest change, in that the arrow controls of the pitch were swapped for a much easier to implement, yet less fluid in execution control scheme. 

Because I still wanted to stick to my original promise of modernising asteroids I changed the score system so that killing 30 enemies would net the player an extra life, so that achieving a high score had in-game benefits as well as netting bragging rights. 

In addition a new difficulty scale was added, where the speed of the lily pads increases after 15 seconds, and I also created seperate start and game over slides, with the start screen giving instructions on how the controls work and the game over screen allows the player an instant chance to restart

I don`t mean to gouge on my own McSpicy, but I am definitely the Lebrone Jahames of making mediocre arcade game bootlegs (that`s the name of the Space Jam guy that did baseball, right?)

After reflecting on the less than desireable outcome of my previous game, I came to the conclusion that where I went wrong, was that I didn`t rip off the source game enought. So this time, I`m going full dodgy bootleg, the kind of game that would havd me slapped up by Pheonix Wright himself in human form for copyright infringement if it were ever to hit store shelves. In case you have trouble reading words in a font size larger than 12, the game in question this time is the arcade hit, Asteroid, which surprisingly has very few instances of up and coming devs attempting to make their own version of...

...so yeah, the market for asteroid-inspired games is a little saturated, so to stand out, my new game has to both look and play completely different from what people expect out of an asteroid-like game. The name of my game is 'Phrog (I like phrog)' a standard game of asteroids, but where he sprites have been swapped with hyper realistic sprites of frogs for the player, lily pads for the enemies and water for the background.

Concept art:

In addition to the visual update, many of the outdate controls of the original have been modernised, like the famous tank control scheme being subbed out for a simple arrow key movement. The player will alos be given the ability to jump in the air, giving them a moment of invincibility from lily pads, however this ability needs to recharge before being used again.

The three biggest selling points of my game over ther asteroid clones:

1. Updated Mechanics

2. New Mechanic in jumping

So last week`s elevator pitch didn`t translate over to the coding aspect as smoothly as I`d hoped, and after spending a whole Maccas sesh designing it too =(( (tbf, the lack of progress still wasn`t as disappointing as the McSpicy chicken sandwich, sh*t was worse than rat poison).

Since this prototype was mostly constructed to test out how well the gravity changing mechanic would work in the Gdevelop 5 engine, all of the art assets are stock and generic, and many of the animations are left unfinished, as I was focusing mainly on getting the mechanic to work

The issues came in three parts, one being that the gravity value could only be changed to positive or negative, meaning I could only figure out how to move up and down rather than the four edge gravity switching I conceptualised.

Secondly, I didn`t know how to regester an upside-down player as ‘standing’ rather than ‘jumping’ as the game always thought he was hitting his head on the celing whenever gravity reversed.

The last major issue I encountered was that the gravity values did not change instantaneously like I hoped they would, but instead kept rising incrementally. In the air this wasn`t such a problem, as it added weight to the gravity change, but on the ground, there was a significant delay between when the gravity change keys were pressed and when gravity actually switched, leading to the player basically needing to predict the exact moment that gravity would become a positive/negative value.

While I was playtesting the game, I also realised I needed to set a limit on how many times the player can change gravity mid-air before touching the ground. If spending 30 hours a day pouring through Kirby lore has taught me anything, a platformer, where the main character can fly infinately doesn`t make for the most challenging game.