ethanproto

[ethanproto]

Playing animations on room completion

During development, I wanted "The Parasite" to react when you cleared a room, but this was easier said than done due to how the original prototype tutorial had set up the room clearing code.

What would happen is it would keep playing the animation again and again even if a room wasn't being cleared.

I could've re-written the code, however I was very strapped on time and wasn't sure if I could do it (in hindsight I definitely wouldn't've managed to do this.) So instead I tried many things like changing the enemy code to track the enemy count, or using a game instance to track enemy count, but eventually I gave up and was just going to animate when the enemies died.

That's when I remembered 1 single node, the Do Once node. This fixed the problem which was probably caused by the enemy count variable being tracked room by room, so if you killed an enemy in one room, it would count down in EVERY room.

[ethanproto]

Time pressure and removing intended features

As mentioned in an earlier blog I have missed a significant amount of college work time and as a result it is now nessesary to remove large chunks of intended content from my dungeon crawler. On top of this the goals of my SMART targets cannot be completed, these removals include:

I will no longer add any more weapons.

I will only have 3 room types in the outcome (5 or 6 was originally intended).

I will only have 1 enemy type.

SFX and music may be repetetive and have irregular volume.

A lot of visual aspects are getting cut, like rooms changing the lighting colours and extra HUD elements.

I'm quite frustrated really, mostly because I had quite a clear idea of what I wanted to create and physically couldn't because I was too ill to focus on any work related activities.

Heres a removed enemy sprite that was going to be used for a sniper type enemy.

[ethanproto]

Illness

Unfortunatley for the majority of the development time we were allotted to expand on our initial protoypes I have been off college and not working due to 2 individual illnesses I contracted.

Because of this I have missed a significant amount of development and blogging time, meaning I now have a significant time pressure on me to at least complete an MVP and get my Tumblr blog into a presentable state.

This decision may result in me not producing the amount of work I had originally desired and thus will have me having a relativley bare-bones outcome for this project.

[ethanproto]

Setting SMART Targets

Specific: Adjust visuals to make detail more intelligible. Add more inconsistent visuals. Expand weapons and enemies.

Measurable: Increase the resolution of my pixel post-processing by about 50-100 units. Add more visuals of different styles until play-testers are satisfied. Add 2 more enemy types and 2 more weapon types to switch between.

Achievable: Use material instances and post-process volumes to adjust the visual clarity. Use the internet and photoshop to modify and create visual aspects. Design weapons and enemies in photoshop and implement both with blueprint code.

Relevant: Because I want to get across my visual aim, I need to make the game intelligible to players so they understand the visual style and what the point of it is. I need to add more inconsistent visuals so that the whole feel of the game is cohesively inconsistent and has actual depth to it. I also need to give the player a reason to play the game with weapon mechanics and varied enemies with different strategies and approaches.

Time-Bound: I expect to have the visual adjustments done by the end of the week (by 04/10/24). I should have by the beginning of next week (07/10/24) to add more visuals to the game. I expect to have new weapons and enemies added by a weeks time.

[ethanproto]

Playtesting results

[ethanproto]

Adding the best feature

During the HUD creation process I had a moment where I realized that it felt super empty and pointless, to remedy this I brainstormed ideas and theories of what to add.

In the end I decided to add a "reactor" in the corner of the screen that continuously reacted and observed your gameplay, it would cheer when the player does something good, and be angry when they do something bad.

When creating this abomination, I took cues from analog horror series like The Mandela Catalog and Kane Pixels' The Backrooms. I tried to use noise filters and monochromacy to convey a sense of near-featurelessness and uncanniness that would make the player feel a little uneasy. On top of this I decided to have them react through an old timey TV because I wanted it to clash with the HUD design.

I named it "The Parasite" (A very on-the-nose reference to react streamers often not transforming the content they react to, while making insane amount of money from it.) and created a bunch of unique animations depending on many factors like: player health, healing from damage and dying.

[ethanproto]

Basic Health System and Animations

Due to the way my enemies work I think it would be goo to have a 3 lives system similar to games like Zelda, but I want to display these lives in a unique way.

To do this I thought for a bit on what would look cool and decided on using semi-realistic hearts that pulsed and exploded depending on the health of the player.

Upon incorporating it into my HUD, I animated each individual heart to explode if damage was taken, and beat faster or slower depending on your HP.

(Difficult to show in image form, but the hearts beat faster when on low HP.)

I also added some extra post-processing and effects as you got lower in health.

(The world gets more red and pixelated the lower your health is.)

(Widget code for the playing the heart animations)

[ethanproto]

Undertale Visual Approach

When researching for my visuals I remembered a quote from the Undertale art book:

There are also other examples of Toby Fox removing some art because it looked too good (though I can't seem to find these, I swear they exist!!!!)

And while I believe this quote is at least half-ironic, it's a philosophy that I want to adopt into my game, that of a semi-ironic cohesive mess that is so consistently bad and incoherent that it ends up being a cohesive and recognizable game.

[ethanproto]

Baldi's Basics Visual Research

Baldi's Basics is an incredibly unique game that has a similar visual approach to my game. Using low-res textures, "poor" quality models with no antialiasing to name a few features that make up the visual feel of this game.

I intend to take inspiration from BB when designing my game, specifically using things like a pixel filter, low quality fake stock images, poorly made 3d-esque UI elements etc.

BB was influenced by old educational games made in the 1990's and early 2000's such as sonic schoolhouse and Mario Teaches Typing.

These games are notable mostly for their LACK of visual design, purely focusing on bright, cheap, semi-appealing and superficial visuals purely marketed towards kids.

[ethanproto]

Get hit result under cursor by channel

To create my projectile aimer, I needed to find out my cursor location and continuously update it.

To achieve this I used the "Get hit result under cursor" node. This node basically tracks my cursor and retrieves data from it like Hit Time, Distance and what I'm using; Location.

After setting my aimer sprite to look at the hit location I fire the LookAt event off Tick.

[ethanproto]

Macros

Macros are structured with an input and output node, in-between you can customize and edit the input data with code and output it once the code has completed.

The macro in my dungeon crawler essentially just creates a line-trace to determine if there is a room already spawned where the player intends to go, it then outputs a Boolean off which I can spawn (or not spawn) a room.

[ethanproto]

Break and make vectors

When setting up the camera and its movement in between the rooms in my dungeon crawler I used a break and make vector nodes, these basically make it so I can modify a vector before I use it in code.

For example in my game I used it to grab my actor location then offset the endpoint by -300 on the Z axis, this sets the camera position (This is done on tick, which is not ideal but the tutorial told me to do it and I didn't have time to come up with a not stupid alternative.)

[ethanproto]

AI move to

A new node that I used in the tutorials were AI Move To nodes, this is an expansion of the Simple Move To node that incorporates an advanced AI-Controller system that can make use of Invokers, different pawns and execute code off movement success and failure.

In my dungeon crawler I used to create moving enemies and health pickups that move towards the player every tick.

[ethanproto]

Game Inst and variables

When developing each of my prototypes, a common type of blueprint we used was a "Game Instance", this acts as a sort of save file that only saves in the current game session and can be used for carrying variables across levels and having a centralised location for core game variables.

For example, in my block breaker I used it for storing the brick count, as well as the lives and the level.

[ethanproto]

Splines

During my block breaker development to program my player I used a Spline to constrain my player movement to the playable area, I did this using timelines with set transform nodes as well as a semi-complex input handling system pictured below:

Timeline and Set Transform code:

Mouse Input handling system:

[ethanproto]

Fixing Bugs and Recoding various things #2

During testing I noticed that the collectables that spawn in don't de-spawn after they have been passed and not collected. To fix this I first over-engineered it really badly, making a box collision attached to and behind the player that on collision with the collectables, would destroy them. However this also collided with the stage obstacles and would kill you no matter what lane you were on, so I then moved on to my lesser engineered, more practical resolution which was to simply add a delay on the collectable's spawn code to destroy them after a few seconds.

[ethanproto]

Fixing Bugs and Recoding various things

One of the first bugs I encountered happened because I increased the base walk speed of the player, Because of this I would spawn platforms faster and they would take ages to de-spawn, this resulted in having well over 500 actors in the level my the time you reached top speed.

To fix this I created a variable that stored all of the spawned in platforms and in the function that spawns in the platforms I simply perform a brief check to see if there are greater than 20 platforms, if so it simply doesn't spawn in the platform and waits for the next time the function is called.

And as soon as the platforms de-spawn after a few seconds (after the player has passed the platform) it decrements the active platform variable.