fmpfmpfmpfmpfmp

[fmpfmpfmpfmpfmp]

Making changes based on feedback

One suggestion a playtester made when asked how to make the game less difficult was to make the enemy bullets slower, to give the player more time to react to them.

I first tried this with a 1 second increase in the bullet's move node, meaning they took 1 extra second to reach the player:

This made their projectiles too slow however as they could now build up and block off areas to the player much easier. I still thought this was a good idea though, and tried a much smaller, 0.25 second increase, which was much more effective.

Another playtester also suggested to limit the amount of grenades the player has, which I very quickly demo'd in my player's blueprint:

While this worked, I was more concerned about how to convey a limited amount of grenades to the player, and how they could refill them. I don't believe I have the time to make a high quality solution to this, so for now I will leave it as is.

[fmpfmpfmpfmpfmp]

Response to 2nd wave of feedback

These were just preliminary questions to make sure my game actually played well. I didn't expect a poor result here but it was good to make sure.

I understand that 8-directions of movement can be a negative thing to some players, but due to the limitations of the arcade cabinet I am stuck using this system- and I have made adjustments to accommodate help this style of movement work.

I'm happy player's understand the corruption mechanic- this shows that my changes I implemented over the half term actually helped player's understand the feature.

I was hoping player's would find it more impactful, but after watching them play I believe it's due to them not having runs long enough to fully utilize the corruption bar against large waves of enemies, which brings me to the next point:

Players found the game incredibly difficult, with most runs not lasting longer than a minute. I think some of this might be due to player's not playing for long enough to master the abilities given to them, however I don't want my game to be incredibly difficult, so I think some balance changes are in order.

Again another mention of difficulty, and the score showcase/grenade limits are something I will experiment with.

[fmpfmpfmpfmpfmp]

Reviewing my 2 week plan after the first week

In my 2 week plan I was a bit more reserved with my goals, and didn't want to over-stretch myself. With one week left before the hand-in week, I think I was correct in cutting the leaderboard and co-op features however after Implementing all my desired changes I still have some time left to make my game as good as possible- so I want to stretch myself.

I think the best use of my time, rather than adding new features I think are good, is to do another round of playtesting to get targeted feedback. I can use this feedback to more effectively improve my game rather than just adding random new features.

This will be my goal for today, and ideally I will get it all done today.

[fmpfmpfmpfmpfmp]

Creating a title screen

This is another last-minute addition I want to add to stretch myself. It wont be anything crazy, just something to stop the player from immediately jumping in to the game unwillingly.

For this title screen I created a new level to put it in and a custom gamemode to make sure the player doesn't spawn in:

In the Project Settings > Maps & Modes I made sure this was the first level, so it actually worked as a title screen:

As for the title screen itself I wasn't sure whether I wanted a simple screen or if I should put the controls on there, so I tested it with both:

After getting some feedback on both screens, the general consensus what that having the controls was better, it both added more to the title screen and informed the player before they loaded into a game- so this will be what I go with in my final build.

[fmpfmpfmpfmpfmp]

Making an attract screen

The arcade machine I'm putting my game on requires a 1500x500px banner to present my game, so I used some sprites already in the game (to reduce the time needed to make it) and designed this in Photoshop:

I chose this exact color of blue as it is the hex code of old computer blue screens:

windows blue screen hex code - Search (bing.com)

Not only is this a nice thematic link, the bright blue is a bright color that I hope will attract player's eyes to my game.

The text in the middle is also from computer blue screens:

Blue Screen of Death - Copypasta Database (copypastadb.com)

However I have edited it slightly to make it make sense for an arcade machine.

This was fine and presentable, but after looking at it, I thought it didn't scream "corruption" enough, so I went back and added some glitchy effects to it:

All in all, I really like the charm of this outcome- and it even helps build a small story to the game- something which I've never considered until now.

[fmpfmpfmpfmpfmp]

Unreal Engine: adding sounds

This isn't something I had planned, but I realized when finalizing my game that adding some sounds would take me next to no time, so there wasn't really a reason not to.

I found a retro sound pack on opengameart.org:

50 CC0 retro / synth SFX | OpenGameArt.org

And I didn't spend a lot of time deciding which pack to use, this is a quick thing I chose to add to improve the final outcome of the game.

After downloading and extracting the sounds, I dragged them into the content drawer and assigned them to different actions/events in game that I believed needed an associated sound.

This is the result:

A nice trick I used to make stylized sound effects is to change the pitch. For example, the explosion sound is a pitched-down death sound. This helps me get more out of the limited viable sounds I had.

Additionally, pitching down the sounds makes them sounds crispier and lower quality which helps them feel more retro and arcadey, so I'm really happy with this result for the time I put into it.

[fmpfmpfmpfmpfmp]

Fixing a really weird bug

After I opened the project settings, my controller face buttons stopped receiving input. I hadn't changed anything in the project settings and the analog stick still worked so I was really confused and had no idea how to fix this.

I tried:

resetting everything in the project settings to default

changing controllers

adding breakpoints to the button inputs (they didn't fire)

making sure no actions consumed input:

None of this fixed my issue, so after asking for assistance I was shown how to use the newer version of input detection, Input Actions.

IAs are stored in Input Mapping Contexts, and every project template has one by default which handles moving, jumping and looking:

I can create my own IA's in the content drawer for each of my actions:

And then add them to the default IMC, where I can bind them to the necessary inputs:

Finally, I had to change my player's blueprint to fire the IA flags:

This hadn't neccesarily fixed the bug I had, rather I'm now using a different approach to circumvent the issue. I'm fine with this however, as IAs are just as, if not more practical as the normal inputs I had been using before.

[fmpfmpfmpfmpfmp]

Getting my game ready for the arcade machines:

To properly show players the controls I cant use the Xbox inputs, as they wouldn't mean anything.

Instead I had to base it off of this image as this is how the inputs are translated:

To do this, I created a basic sprite sheet of different button presses:

And replaced the Xbox inputs in my HUD:

Additionally, every game on the arcade machine must have a quit button bound to Special Left, and must quit after 30 seconds of inactivity. The code for this was really simple as Unreal just has a Quit Game node and looks like this:

[fmpfmpfmpfmpfmp]

Adding the last few sprites into my game

At this point everything is functioning, there are just a few visual things that need adding:

enemy bullets

player bullets

explosion

For the explosion, I reused the same explosion that my enemies use, using the same flipbook actor method.

I quickly made 2 bullet sprites for my player and enemies:

I made sure to use 2 distinct colors to help the player differentiate between their bullets and enemy bullets when the screen gets cluttered.

This is the result:

I now believe that I have a presentable vertical slice of my game- I've not implemented everything I wished to add in but I think now that I should stop all development (minus fixing any bugs I find) and focus fully on presentation.

[fmpfmpfmpfmpfmp]

Unreal Engine: increasing enemy spawns

This blueprint is in my enemy spawner, and it's similar to my last project where each enemy spawn will reduce the time between spawns:

gradually increases the spawn rate and creates a swarm of enemies when the timer is low enough, before resetting and doing it again.

This gives the game a good amount of difficultly while still keeping the early-game calm enough for a new player to learn the controls. Additionally, the increased amount of enemy spawns gives he grenade more usefulness- up to this point it seemed like a useless feature.

[fmpfmpfmpfmpfmp]

Unreal Engine: importing my enemy sprites and making them work

My goals for the enemy sprites were to have them:

Look in the direction their facing

face the player and then shoot after a small delay

have their sprites change based on the player's corruption

play an explosion vfx when destroyed

Going in order, the sprites rotation already followed their movement so that was already done.

To have them face the player I used the Find Look at Rotation node to get the rotator that would have the enemy look at the player and then set it:

To achieve the delays I simply put in a delay node right before they fire, this gives the player some time to react and stops the enemies from firing unfairly quick:

It was here I realised I would need another cast to the player to read the value of the corruption, so I changed to getting a reference on begin play:

For the varying sprites I used a switch on the player's corruption:

This would set their sprites when they spawned in. This was OK, but it felt weird having 90% of the enemies having the same sprite all the time.

There were a few ways I could improve on this, such as having them flicker through different sprites quickly, or warp their colors, but I decided to have them re-pick their sprite every time they generate a random position:

This event is called at a different time for each enemy, so it feels random, but the sprites are still consistent with different levels of corruption. This is a good balance and I'm really happy with the effect it provides.

And finally, for the VFX I used the same approach as my last project, a "flipbook actor" spawns with the enemy's transform:

This flipbook actor then destroys itself after the animation is finished:

This is the final result of everything:

It's much better than no sprites, but I think changing the projectiles to sprites as well is a much needed change. I think I'll also change up which sprites are at each level of corruption.

I initially planned for the enemy's LED to change when they were about to fire to better indicate the attack, but due to their small size in-game and how much the post-processing effect alter their appearance, I don't think this would do anything.

Aside from that, I'm really happy with the result here!

[fmpfmpfmpfmpfmp]

18/04 goals

Today I want to get my game onto an arcade machine, to see how it feels/runs.

There is some prep work I have to do before that though, namely making correct button prompts that are correct to the arcade machine.

If I have time I also need to get my enemy sprites working in-game, and I'd also like to implement the same "enemy horde wave" system I had in my last project.

[fmpfmpfmpfmpfmp]

17/04 reflection

Today I was able to get in all my half-term work, which puts me in a good state for tomorrow, however I failed to realize that my enemy sprites still need to be implemented in-game, which might take a lot of work.

After that is done, I believe I can put all my focus into presentation and slide making.

[fmpfmpfmpfmpfmp]

Unreal Engine: having things actually affect the score

Something I should have reflect on in my last project is that not a lot of things actually changed your score. This made the goal of the game (getting the highest score possible) a bit dull, as it really boiled down to "shoot things fast".

In this project, the goal of the game is the same and I want to make it more fun and challenging to do so. In all honesty, this really just meant I needed to have more things give you different amount of score. I also reduced score when the player takes damage, even more so if they damage themselves.

Everything that changes score uses this custom event in the player blueprint:

Below is everything that gives/takes away score:

This approach to the highscore objective is a lot better than my last project: there's a lot more moving parts here that result in the highscore being more than just "I shot more things than anyone else", so I'm really happy with how I've improved on this system.

[fmpfmpfmpfmpfmp]

Unreal Engine: Implementing my corruption changes

This code changes the color of the corruption bar when it hits 100%, weather the player is transformed or not:

I think this will really help alert the player to their ability to transform, along with this HUD instruction:

I initially planned for the HUD element to be a one time thing when the player first maxes out their corruption, but having it constantly on the screen will ensure the player never forgets they have this ability/how to execute it.

This blueprint triggers on enemy kill, and sends an event that increases the players corruption.

I like doing it this way as I believe this portrays the corruption bar as a positive thing. If it increases as you kill an enemy, it seems like more of a reward compared to a slow and foreboding increase like I had previously.

I also gave the bar a title of "Harnessed Corruption" to further frame it in a positive light:

To go even further with this, I decreased the speed of the gradual corruption increase from 0.05 to 0.09, which is an 80% change. This makes the player rely a lot more on kills to grow their corruption, again feeding into that idea of it being a good thing:

This is what a quick run of the game looks like with these changes:

Im really happy with this result, all of these changes really help make the corruption mechanic feel more like a part of the game rather than a side feature.

[fmpfmpfmpfmpfmp]

Planning for the next 2 weeks

From today, there are only 2 weeks left until the hand-in week, so it's really important to reflect on how close I am to achieving everything I set out to in my proposal.

I've stated previously that some features were only there as stretch goals if I had time, such as 2-player co-op and a leaderboard system, so these are not going to make it into my final result.

While I have been able to create the pixellation post-process effect in unreal engine, it has proved impossible to add in mid-game. Unless I can find time to look into this more than I currently have, this wont make the cut either.

I also don't believe I'll have time to make the wave-based system I decided on in my proposal, and I will instead be relying on enemies spawning in on a timer.

After these exclusions, I'm just about on track with my plan. the most important thing for me to do now is to get my game onto an arcade machine, as that is a big part of my final presentation.

All I have left to make now Unreal-Engine-wise is a few changes to my corruption mechanic, which is absolutely achievable in the time I have remaining. After doing that, all my time needs to be spent on presentation and slide making.

[fmpfmpfmpfmpfmp]

Unreal Engine: implementing my new sprites

The biggest difference between my first sprite and my second is that I don't want my second sprite to rotate. However, I can't just remove rotation from the actor because rotation is used to aim the player's projectiles.

I first tried to just lock the rotation of the sprite:

However this didn't seem to do what I thought it would: there was no change to the sprite's rotation.

After thinking about it for a while, another student showed me that I could attach a SpringArm component to my sprite to achieve the effect I was going for:

These settings gave the sprite it's own rotation, which I set to nothing.

This worked well, and now I needed to implement the other sprites that the player changes into based on their corruption.

I gave this code a lot of thought before designing it. My first idea was to use my CorruptionState Enumerator, but I initially decided against it as I was worried that it would break, based on how my last attempt at using it went.

Instead I went for a tree of IF statements that checked the corruption value and if the player had triggered their max corruption:

This was the result:

This was changing the sprite, just not entirely how I wanted it to. As I'm changing my game to allow the player to choose when to go into their max corruption state, I decided I needed another sprite to show "full corruption, but not transformed".

That looked like this:

I thought this looked too similar to my transformed sprite though, so I revised it a little to differentiate the two and show how the corruption powers up the player:

I was really happy with this look as it's a good way to show that the player uses the corruption they build up to increase their strength.

After making this, I decided to at least try using a enumerator approach as it would be a lot more efficient.

As it turns out, this was really easy to implement! This time I was using the enumerator for something it was built for and the result was some really clean code.

This blueprint checks the percent of the player, and sets the sprite accordingly. If they're at 100%, the sprite depends on if they have transformed or not:

I just had to set the ennumerator in the corruption logic again to get it to work:

This is the result:

I'm really happy with this outcome as I believe it both looks nice and further helps the player in understanding the objective of the game and their current state.

However, a really small change I made after this video is I added a cone with no collision or shadow in the direction the player is facing:

This was really easy to add but helps to direct the player so much, I'm really glad I spent the time to add this in.