#qutigb220

[vinniecameron]

Assessment 3 Development Progress

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 for chapter readings, this week`s focusses on the fun and accessibility and the types of decisions a player will be forced to make either to progress gameplay or the story, and how to avoid making these decisions hollow, uninformed or obvious. Many of the decisions players make in a game should be more reminiscent of dilemmas, and should act to surprise the player, thereby revitalising the gmaeplay experience and preventing it from becoming monotonous. Rewards when spaced out correctly, relative to the main goal should also help to reinvigorate the player`s enthusiasm towards the game and help to eliminate stagnation i.e parts in the game where it feels like nothings happening.

[vinniecameron]

Racing Postmortem

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...)

For playtester 1, the game controls were too clunky to get use to, as was the collision and accelerating. He also suggested to add powerups and more obsticles as improvements to the game, potentially unaware that after last week, the game is already dead to me (like how gamecube games are to Nintendo). Playtester 2 was even more critical (Granted, his playthrough of my game was immediately after I trashed his, but at that point maybe he should`ve thought about making a good game). His main criticisms stemmed from the lack of barriers for the track, and that I hadn`t playtested the different cars enough to make the game fair. While those are fair criticisms, I`m not exactly sure how adding AI would`ve improved a multiplayer game focused on track design, but again, “customer is always wrong” in no1 rule in game design, so I`m not losing any sleep over his criticisms.

[vinniecameron]

Racing Development Post

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. 

The game design textbook chapter this week talks about playtesting, which is relevent because I`ll probably have to do actual playtesting sessions soon, rather than the usual bribe someone with gobstoppers to sit down and roast my crap game. Real playtesting requires the developer to playtest the game themself with an open mind as well as getting the opinions of both people you know and complete strangers that make up your game`s target demo and are refered to as Kleenex testers, due to their one and done nature in the development cycle (also funni monkey beating reference hahah). The genenral structure of playtesting sessions is also explored, starting with the intro info, then delving into a warm-up discussion about the participant, the play session and discussing the overall game experience and getting direct feedback along with the notes taken during the play session. The idea of the play matrix was also introduced, which acts as a four way graph that plots skill and chance on the y axis and mental calculation and physical dexterity on the x axis to categorise the game experience.

[vinniecameron]

Racing Elevator Pitch

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

P2: Arrow keys to move

[vinniecameron]

Phrog Postmortum

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.

The textbook chapter this week focused on conceptualisation of a game, further delving into how ideas for games get thought up, sometimes by deconstructing already existing ideasand writing down every idea, no matter how wild on a whiteboard to be picked from later in development. Once an idea has been chosen, a 3 to 5 page treatment is written attempting to flesh out the idea by adding dynamic elements that keep in the spirit of what the original concept was meant to invoke emotionally.

[vinniecameron]

Phrog Development Post

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?)

Also I finally read more of the textbook (the CRA mercifully let me take a break last week), so I skipped ahead all the way to chapter 10, functionality, completeness and balance. As you could probably guess, it focuses on balance in games, along with if the sytems/processes are working as intended, along with the processes taken by developers to problem-solve if a mechanic is more overpowered then anticipated. Idk tho, most of the best games of all time, i.e. Big Rigs:Over the Road Racing, Chibi-Robo: Zip Lash, Anthem, Garfield Kart, League of Legends and the Atari ET/Porn Games probably didn`t get to be where they are from wasting money on “playtesting”. The chapter also dicussed assymetry in multiplayer games, where the players each have different objectives and how balancing affects games like that.

[vinniecameron]

Asteroid Elevator Pitch

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

3. Phrog

[vinniecameron]

guys help my game is bad

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. 

Since this post stretched over two weeks (again, what the CRA said), I had way more time to get some reading done from the textbook. The chapters I read focused on working on formal game design elements and what games would be like of you changed the rules of them. As well as how the rules of a game dictate the general user experience along with the win/lose conditions of a game and both the games overall objectives and what the player is expected to do to fulfill those objectives. Another chapter focused dramatic elements of a game, or put in terms someone who`s touched grass can understand, the context behind a game i.e story, characters, game world, motivations behind actions. Dramatic elements can also extend to gameplay, like how difficult parts of the game are, which dictate the flow of progress in a game or how a game`s feedback system rewards the player for completeing a certain objectinve, and how that reward relates to the ultimate goal. This chapter also defined the 4 types of play that apply to games, competitive (agon), chance-based (alea, or gambling), make-believe (mimicry, or role-playing) and vertigo (ilinx, or play meant soely to exhilirate the player). Major points in the story can also be classed as dramatic elements, as they have the potential to completely flip the context on its head (e.g. When the cheating A.I playing Jon won against me in Garfield Kart). The final chapter I read, working with system dynamics, focusing more on the relationships of all the elements from the previous chapter and how those dynamics can shift the whole game if changed. This chapter also introduces Bartering resources and how they impact a game (things the player/game owns within the game i.e money/property in monopoly), and how a change in bartering can also change the dynamic of a game.