Units 5 6 7 - 2D Game Production

Unit 5-6-7 - Artwork

2D Game Project

29th Nov 2021 -  Intro to 2D Game Pre-Production + 2D Game Project

Today's learning objective was to understand the different game-design documentation and why it's crucial. We also had to show we could demonstrate our knowledge of game planning through our own pre-production.

First, we looked at what goes into the planning of a game. These are the items of note:

• Concept Sheet: A small, rough write-up of game ideas from the earliest planning stages. Generally includes sketches.
• Game Design Document (GDD): A document that details every aspect of a game. All of it. Generally includes a game flow diagram.
• Game Flow Diagram: A diagram that maps out everything the Player will encounter from the start/boot. Helps grasp the overall flow of the game.
• References: A visual mood board or mash-up of references that visually show what one aims to make.
• Scheduling: Track a game's development & team member's progress. It can also set milestones and/or make adjustments when necessary.
• Slice: A Prototype/small chunk of the game can be playtested to see if the core gameplay works and is actually fun.

Most of these I knew beforehand. I didn't know about the GDD or GFD, though, despite it being rather apparent that such documents would exist. Honestly, I think I would only be good at doing the slide/prototype. I could probably do the GDD, but I am generally too nervous to confirm what the team has 100% agreed on.

After we learned about each pre-production document, we were put into groups and tasked with a new project: Take what we have learned so far and undergo the complete development cycle to create an original 2D game. 

We began mind-mapping/brainstorming our ideas together about what 2D game we would like to create. Eventually, we narrowed it down to this: A cute n' cartoony 2D Platformer based in a "fantasy world above the clouds", with the main character being a heroic and angelic cloud who must save their fellow corrupted/brainwashed clouds from the clutches of the evil giant thunder cloud and foil its master plan to strike the world below with a powerful 'super thunderstorm' (or to simply take over the cloud kingdom, I am not entirely sure at the moment)

30th Nov 2021 - Introduction to Construct 3

We were introduced to Construct 3, a game-making software/game engine, and learned its basics in this lesson. While not close to everything, we went over numerous components that make up a 2D game. These include but are not limited to:

• Objects: Objects are the building blocks of Construct and include General objects like Sprites, Text, and Input types but also have specific object types like Monetization for adverts
• Layers: Layers are used to show groups of objects behind or in front of other layers/groups of objects. A typical example is a 'Background' layer at the very bottom, a 'Player' layer in the middle, and a 'Hud/UI' layer at the very top.
• Event Sheet: The event sheet is where all the 'coding' happens. Reminiscent of Scratch, it's a block-based visual style of coding. Fundamentally, events work by specifying a condition and an action that will only run if the specified condition is met. 
• Behaviours: Behaviours can be added to objects to add extra functionality/capabilities and essentially act as shortcuts. An example is the "Platform" behaviour, which immediately allows an object to move & jump like a 2D platformer character and interacts with objects with Solid or Jump-thru Behaviors.
• Instance & Global Variables: Instance variables can be directly added to object types to store booleans, text, or numbers for each individual instance of the object. Each instance tracks its own variable, so it's perfect for counting something like the Player or enemy health.
  Global variables are, simply that, global. Global variables store variables between layouts, and any event can access them. This is useful for collectable counters or timers.

Next, I experimented with Construct while following the "Epic Construct 2 Course" on Udemy.

John Bura. Epic Construct 2 Course: Complete 60 Beginner Games!. Available: https://www.udemy.com/course/the-complete-game-developer-course-build-60-games/. Last accessed 30th Nov 2021.

I followed the 'Platformer Shooter' Section for about half an hour to an hour. Honestly, I didn't learn much, except a few small things like tilemaps, scrolling text and functions. However, I researched most of the things I needed to learn later on during the production of our 2D game. Other things like making the title screen I knew already from my post-fmp extension from level 2 media.

1st Dec 2021 - Post-Production Processes

This lesson's learning objective is to develop our understanding of post-production processes in game development. So, first, we went over Debugging & QA Testing.

Debugging is the process of finding potential errors/bugs that could cause undesired behaviour. In terms of gaming, it is to detect and remove any errors or glitches a game may have to refine the game as much as possible. Therefore, debugging is vital in the game development process as it helps ensure the game is in a complete state. QA Testing contributes to this process.

QA Testing is the process of ensuring that the product in question is as best as possible.

In terms of gaming, it means playing a game to find bugs and break it as much as possible. Therefore, playing unconventionally and thinking outside what the developers intended is key to QA Testing.

This will generally require the QA Tester(s) to play the game or even small sections of a game numerous times and then write down a detailed report about any bugs or crashes they encounter. This info is then given to the developers, who can then follow the information and debug the game accordingly to fix the issues.

Afterwards, we were tasked to choose a previously created game, conduct a quick 5 minute QA test and identify any gameplay, visual and audio issues we encountered.

This turned out to be much, much harder than I expected. While finding actual issues/bugs wasn't too tricky, explaining them and making sure they were easily understood was tough.

Finally, we very briefly started on our Concept sheet.

2nd Dec 2021 - Visual Experimentation

This lesson's learning objectives were to develop the technical knowledge for designing 2D game visuals and consider the opportunities for visual development for our team project.

We experimented with pixel-art through a practical exercise to give us more options for what art style to choose for our game. The program for this exercise is 'Pyxel Edit', an editor specifically for working with tiles/tilesets. While not exactly fitting for this experiment--it will suffice.

After going through the basics of using the program, we were tasked to pick 1 out of 4 characters and make pixel-art of them using the tools we have.

I'm not going to delay my opinion: I am not fully happy with the outcome--I didn't even complete it in time. Now, my problem isn't with the software (as I found it relatively easy to understand) or pixel-art as a whole. I have a massive bias for it and can just barely make pixel-art for specific game elements (see: Player Core/Base for a Tower Defense). Instead, it's my ability to make any humanoid art that I struggle the most with. 

With the experiments complete, we had a team discussion about our thoughts about the software and if we could use it for our game. What followed was the most divided opinions I've seen in a while.
Haya managed to get the hang of it rather quickly and was happy with their outcome, while Kani looked like they wanted to bash their head against the table. They absolutely despised it.

Their thoughts on using the program for the project also seem to conflict with Haya thinks it could help create the backgrounds, while Kani believes it would not fit the game's art style.
My opinion doesn't really matter here, but I think pixel-art does not fit our game project. While I think either style would work, having the game not be pixelated would allow for a softer, cuter, and more cartoonish style to be realized.
While leaving pixel-art out of the question would essentially make me unable to contribute to the visual development & production, I think it's for the best.

9th Dec 2021 - Visual Experimentation Part 2

Going off the previous visual experiment lesson, we were tasked to take our sprite and create an animated walk cycle. That simply wasn't going to happen, so I made a new sprite and animated that instead to show that I understood the process.

7th Dec 2021 - 2D Pre-Production Progress

Today, I filled out the character bios, started on the systematic breakdown, and refined the intro & plot a bit. We also came up with a name for the antagonist: Sir Storms-a-lot. Because he storms a lot.
The joke is so dumb and I love it.

8th Dec 2021 - 2D Pre-Production progress

Today, I worked on the systematic breakdown of the game's components. We also discussed how the Player's health system works and have decided on a health bar + Sonic hybrid. 

The Player's health works on a Health Bar system with some inspiration from Sonic the Hedgehog.

Droplets/Collectibles on-hand act as a temporary shield for when the Player is hit. For example, the Player gets hit from an attack that does 25 damage & the Player currently has 10 Droplets. The 10 Droplets are used to tank 10 of the damage, and the Player only takes 15 damage–but no longer has any droplets on hand.

13th Dec 2021 - 2D Pre-Production progress

Today, I started working on the gameplay slice.

I made a super basic animation to test some things but ended up being generally ignored for a while so I could focus more on the unique attack--the throwable halo.

14th Dec 2021 - 2D Pre-Production progress

Today, I did the logic for the boomerang/halo attack. I had zero clue how to code in a charged attack, so I searched the Construct forums for help or a guide and found a forum post for what I was looking for.

n/a. (2020). HOW DO I TAP (ON TOUCHED) FOR WEAK ATTACK AND HOLD FOR STRONG ATTACK?. Available: https://www.construct.net/en/forum/construct-3/how-do-i-8/tap-on-touched-weak-attack-149683. Last accessed 7th Feb 2022.

This was the hardest thing to code so far (and likely the most complex in the project overall), requiring me to work on it later at home. 

15th Dec 2021 – Art Reflections & Sound Planning/Recording

When creating my observational drawings, I used pencil and fine black liner.

I am gaining more confidence in using pencil as it's erasable and simply reliable. I used a pencil for crosshatching to show different shades/tones.

I used a combination of black pencil, black fine liner, and purple watercolour to make it look less 2D. I chose purple because it is a good substitute for black for antagonistic characters as black is extremely difficult to shade with. This would be useful to keep in mind when making the antagonist for our game.

Funnily enough, this is already the case--our antagonist uses purple tones for shading.

Later in the day, we planned out the game's audio and recorded the voice lines and foley sounds for our game. Unfortunately, I arrived a bit later as I wasn't needed and was working on the gameplay slice, so I had to trust their judgment on the chosen microphone.

After recording, I opened up the recorded lines/sounds in Audition, split them into separate audio files, and renamed them for convenience.

Here are a few notable sounds from the bunch:

Adding the music & sound into Construct 3 was surprisingly simple.

First, add an Audio object by right-clicking anywhere.

Next, right-click the Music or Sound folder and select import.

Then drag & drop the audio file and select import.

Finally, the sound/music can be added to any event and play when triggered.

16th Dec 2021 – 2D Game GDD

4th Jan / 6th Jan 2022 - Game Production Progress

This week, we started production on our game, and a fair amount of progress was made on it, considering we've never done this before.

Inconveniently, Haya was sick, so Kani was tasked to do some art & backgrounds in her absence while I continued using placeholders.

For starters, we have a working title screen now--albeit unfinished. Currently, there are no options. It's a low priority and will be done if the time is available.

Second, a lot of game events/logic was added. These include:

• Health System + Bar

The Player has 300 health and enemies deal 50. The collectables function as a shield that tanks some of the damage when hit but is lost/used in the process. I forgot how to correctly add a health bar, so I briefly looked at a YouTube video for help.

Xanderwood. (2020). Construct 3 Health - How to add a health bar. Available: https://www.youtube.com/watch?v=ePsewYpjghA. Last accessed 7th Feb 2022.

• Immunity Frames (Both Player & Enemy)

Whenever the Player or an enemy gets hit, they are invincible for 1 second. This is because immunity frames are standard in most games. This was achieved through an enemy instance variable and a global variable. If "enemyhurt" is 0, attacks can hurt it. Once hurt, set the variable to 1 and wait "Immunity seconds" before setting it back to 0. The immunity timer is a global variable so it isn't hard-coded.

• Sword Hitbox

The sword's hitbox is disjointed, so the collision box had to be a separate object and pinned to the Player using an Image Point. Getting it to line up correctly was incredibly tedious and was essentially just trial and error.

• Enemy AI 

Enemies will move towards the Player on sight and randomly wander around if they lose sight of the Player. This was achieved with the help of a Construct tutorial.

OnyOxis. (2015). [PLATFORMER] A.I: ENEMY FOLLOWS AND JUMP. Available: https://www.construct.net/en/tutorials/platformer-a-i-enemy-follows-986. Last accessed 7th Feb 2022.

• Enemy Raindrop Particles

Raindrops fall from the enemies. It's a simple visual thing that stumped me for a lot longer than I want to admit. But, in the end, this is all that was needed. Damn.

• Player Set Animations

Finally, actual player animations. These were done by Kani--I just had to add them in. I still need to make separate ones for when hope has thrown his halo and no longer has it on his head, but it's also a low priority. Of course, I don't want animations constantly overriding each other, so I had to create some form of preference, with the attacking animation having the highest.

• Music (https://www.fesliyanstudios.com)

Because we aren't exactly capable of making music, Kani found a site that hosts royalty-free music with a convenient policy (https://www.fesliyanstudios.com/policy). As we are using it for a Non-Commerical project (It even states it's allowed for school use), all we have to do is credit the site. They request to add the text "Royalty free music from https://www.FesliyanStudios.com" So, I credited the website on the game's title screen. I even added it to the game's itch.io description for good measure.

At some point, I want to figure out how to teach the Player the basic controls. Maybe button prompts for individual controls or list all the controls on the main menu/beginning of level 1. I'm currently not sure.

Despite being a teammate down, I think we've made good progress so far. The only major gameplay elements that need to be added, to my knowledge, are level 2's layout and the boss stage + attack patterns.

10th Jan / 14th Jan 2022 - Game Production Progress

We needed an enemy sprite, and I didn't feel like waiting any longer, so I made one myself. I took the player sprite and moderately edited it to look corrupted/evil. 

The first level finally has a layout, temporary background, and enemies with their new sprites. The ground & platforms also got new colours to fit the unique background. Some things are still unfinished at this point, though. There is also the addition of a mushroom that functions as a spring a la Sonic.

I didn't know how to make an object function as a spring, so I looked at a Construct forum post for help.

n/a. (2017). HOW TO MAKE A SONIC STYLE SPRING. Available: https://www.construct.net/en/forum/construct-2/general-discussion-17/sonic-style-spring-124859https://www.construct.net/en/forum/construct-2/general-discussion-17/sonic-style-spring-124859. Last accessed 7th Feb 2022.

Later, I looked into adding sound effects that were picked out by another teammate, but some of them were actually unusable as they had "audiojungle" in them. Hmm.
So, I decided to just make some myself in BeepBox. I created the jump and collect sound effects, while the sword sounds were from the foley sound session. The sound effect for bouncing on the mushroom is just a modified version of the jump sound.

Later on, Haya was finally back, and she did new drawings for the mushroom spring and the flower enemy. She also made a fantastic graphic for the main menu.
(I also added a super big flower at the end of level 1, acting as a mini-boss.)

Production for level 2 began and subsequently finished. As all the gameplay elements were completed, level 2 essentially turned into something akin to Mario Maker, moving game elements into place.

The unique level gimmick is the thunderbolts falling across the entire stage that hurt the Player on contact. This was achieved through an off-screen particle object that follows the Player's X position.

The level geometry is also not flat, as seen in the above image. It wasn't exactly intentional, but it's so lovely having a level that isn't flat.
Still, a new platform needed to be created.

At my request, Haya created a new cloud platform. Unfortunately, it was not grey enough and didn't fit the level's dark aesthetic, so I quickly edited it in photoshop.

17th Jan / 20th Jan 2022 - Game Production Progress

I focused on making the boss for the first half of the week.
The boss has three randomly selected attack patterns: Charge at the Player, unleash a barrage of bolts, and summon bolts from the sky. After the boss is defeated, he simply flies away, and the Player is sent back to the title screen.

I mainly did some QA for the second half and found that I'm an idiot and should have used tiled backgrounds. Turns out that having 2 background images 5000 pixels in width with a toon effect applied absolutely destroys the game's performance, so I cut them to 1/3rd of their original length and turned them into repeating tiled backgrounds.
This also eliminated a separate issue where the engine warned that the game won't work on specific devices with sprites bigger than 4098 pixels in width or height.

Next, I remembered that I never put anything in the game that taught the controls, so I added text in crucial locations across level 1. 

Then, while playtesting, I found a bug that if the Player has enough raindrops, they can actually heal from taking damage. This was because the calculation was (50 - RaindropCount  * 2), which meant that having more than 25 raindrops resulted in the Player tanking more than 50 damage and gaining health back as a result.

A simple fix was to check if the Player had over 25 raindrops upon taking damage, in which it would just deal 0 damage and remove 25 raindrops.
This unintentionally created a rewarding system where the Player could tank multiple instances of damage if they have a significant number of raindrops.

This is what I get for creating an overly complex system for the collectibles.

Lastly, I coded in the beginning cutscene, using illustrations created by our talented artist.

This is the last week of production, and thankfully the game is in a somewhat completed and playable state. I was debugging / QA testing the game constantly throughout development, so hopefully, there shouldn't be many things broken aside from the very obviously missing options menu and certain visual/audio oddness that I didn't have time to code in. Specific bugs/exploits like moonwalking or jumping over the flower mini-boss were intentionally kept in "as a feature."

24th Jan / 26th Jan 2022 - Game Post-Production Progress

This week, QA Testing has been successful, with the game receiving numerous minor tweaks--too many to reasonably list. The significant changes/additions include:

• Sound Effects for Player & Boss taking damage
• An alternate set of Animations for when the halo is currently out (Therefore, no longer on the Player's head) 

This was done by creating duplicates of the animations but with the halo removed from the sprite.

Then, I found all the code blocks related to animations and added new checks using "Else" conditions.

Is the halo out (from holding attack)? Use the haloless animation. Else, use the animation with the halo. 

Tedious, but surprisingly simple.

• Balance Changes
  
• Boss Nerfs
• Player Health no longer fully heals after a stage & heals for 1/3rd max instead.
• Halo is much faster, and enemy immunity frames are much shorter when hit by the halo to make it easier to double-hit
• Enemies drop raindrops on death.

Later in the week, we cycled around and tested each group's games, and we got some excellent feedback.

The comment on the background is valid. Unfortunately, Haya was still sick, so she could not do the backgrounds, and placeholder ones had to be created instead.

The visual bug for the halo attack I am unable to replicate.

Going outside the map by going too high is intentional--A lot of Mario games have it like that.

The confusing title screen is absolutely true (as well as the options selection doing nothing), so this was the best time to finally change it.

The title & selections were moved, 'Start' was made smaller, and 'Options' were removed entirely.

I also added the ability to click 'Start' if the Player tries that first instead of pressing Enter.

There was also some feedback obtained from a teammate stating that "there are too many thunderbolts" and "the health bar is confusing".
So, I nerfed the rate of the thunderbolts in level 2 and fixed the boss's health bar as it turned out to be miscolored.

27th Jan 2022 - Game Project/Clouds Demise Final Outcome

Game:

Feedback Part 1:

Today, we uploaded our game to itch.io and let other media students play our game and write down feedback. The summary/breakdown is in the last slide.

Taking this feedback, numerous changes to the game were made:

• Level 1 Overhaul

The design and layout of the first level have been overhauled entirely. Haya drew a new background for level 1, and it looks fantastic. In addition, the level's layout was drastically changed to be more like a tutorial, having obstacles that require learning the controls to get past.

• More Balance Changes

Overall, the Player is stronger, and the enemies are weaker. For example, the Player's halo attack charges faster, raindrops now heal the Player very slightly, the enemy clouds move slower, the enemies' immunity frames are shorter, etc.

• Shield Bar

I finally added a bar for the shield. When maxed out at 25 raindrops, the shield bar will visibly be the same length as the health bar, and the next hit will be ignored entirely (at the cost of 25 raindrops).

The game is essentially in a finished & polished state now. No more changes will likely be made.
The level 1 overhaul should make it much clearer to players what the mechanics & controls are.

1st Feb 2022 - Audience Playtesting & Feedback (Part 2)

The 2nd wave of feedback we received is more diverse than I expected. Still, it's beneficial.

Overhauling the first level paid off, as all of them said the game made it clear how to play.
Most mentioned that they would add more levels to improve the project, which I expected. However, we kept the game plan initially short to not overextend ourselves.

The boss stage is still divisive, and I think I've done all I can. Unfortunately, I've been playing somewhat difficult games recently, which subconsciously translated into the boss's (and the game's) difficulty.

Overall, I'm happy with the feedback we've received.

2nd Feb 2022 - Project Evaluation

For this project, we were put into pairs of three and tasked to go through all stages of game development and create a 2D game using Construct 3. As I have difficulty with animation/art, I was glad we were in teams as I could take the role of coding and focus on working with the game engine instead.
After multiple discussions with the team, we settled on a 2D action/adventure platformer where the main character is a cloud who has to fight off an evil thundercloud that has converted the other clouds into thunderclouds and is attempting to take over the kingdom in the sky. 

Time management issues plagued the project throughout. First, the planning phase was rushed so many story/gameplay elements were conceptualized, changed, or outright removed during development. Next, one of our teammates was sick for 1-2 weeks which meant the game's visuals were unfinished/unpolished for a while. They did create new art for level 1 when they finally came back though. Finally, we ran out of development time and many miscellaneous elements like a settings menu and the ability to pause were never added.

On top of this, game difficulty was also a reoccurring issue and was primarily my fault. Throughout development, the player was buffed and the enemies/boss were nerfed numerous times--but the difficulty of the boss was still an issue that kept coming up in feedback. I didn't want the game to be so easy that it was boring and I wanted to do something more ambitious with the boss, adding multiple attack patterns. I attempted numerous times to fix the difficulty of the game--to no avail.
Some people will find it too easy and some will find it too hard. From this, I realized it's nearly impossible to please everybody and all I can do is take the feedback and hope to improve for my next project.

The coding of the game itself was a stressful, tiring, and lengthy process as I got a bit too ambitious in some places. An example is the player's halo toss attack, which is done by holding down the attack key instead of pressing it. That attack could easily have been a separate key/button, but I wanted to do something more involved.  Another example was the boss, which took around half a week to create. If it weren't for time constraints and me holding back, I might've added even more attack patterns.

Whenever I wanted to add/code something in but didn't know how to, I checked the Construct 3 forums as it has its own dedicated "How do I?" section. I also checked Construct tutorials and YouTube videos if the forums didn't help with that specific issue.

In general, I found coding the game to be both somewhat difficult, and enjoyable. The program's language is visual-based, like Scratch, so it isn't insanely difficult/complex to understand.

Looking back at the finished game, I should have paid more attention to the game's difficulty, as well as not over-complicate certain game elements like the collectibles. I should have also worked on the game at home more so certain mechanics like pausing made it in the final outcome.

The feedback we got from other students was generally positive and incredibly helpful. A common complaint during the first wave was not fully understanding the controls. It helped push me to completely change the first level to act more like a tutorial which paid off during the 2nd wave of testing as everyone said the game made it clear on how to play it.

Overall, I'm happy with the game's final outcome and my contributions to it. I could've developed my artistic skill more, but we had our own dedicated roles. 
Regardless, I feel like I've gotten better at using Construct 3 and I feel somewhat more confident in the possibility of making something greater in the future.