fmpyear2kb

[fmpyear2kb]

Feedback from google forms

There are a couple trends within this feedback form, 2 of the 3 people made a comment about the sun being too bright and that the second level was better. It's not a surprise that our playtesters preferred the second level as it had the most amount of time put into it. Admittedly the sun is a bit too bright, especially if you move as far as you can towards it, all of the things mentioned will quickly be looked at and tweaked before the game is built out.

[fmpyear2kb]

The final touch to Da'Car 2

With submission week now here, it was time for both me and my teammate to submit our contributions to the project.

However, due to me coding the entire game, I'm required to upload it to itch.io and not my teammate who had the first Da'Car on his account. I know he would secretly prefer to have the sequel on there too but unfortunately that's not the case.

I decided to cut out the first level as players do not need to play it again, and only include the new levels, with Da'Car 2 being uploaded as its own game. Originally I thought that we were just going to update the existing file on the Da'Car page, but plans change.

I originally thought this would be straight forward though this isn't the case. Due to how the code is set up, the menu is having a hard time functioning properly as there is a few strains of code it is attached to. Despite changing all of the open level by name nodes to the correct level, and setting the default level it isn't behaving.

In theory this should've worked, however it is apparent that there is more work that needs to be done. For every 'DaCarFuelling,' I changed it from 'ThirdPersonMap' which did successfully load the level we need, though the widget is still a work in progress.

To fix the widget, It was as simple as removing one open level. With the first level now entirely unplayable in Da'Car 2, a certain strain of code no longer functioned the way it used to, instead, it reloaded the level when you clicked start game, locking you on the menu widget.

With this now completed, I can now build out the game and submit it to google classroom.

To Clear up any confusion, in the blogs where I said 'the first level,' that is referring to the original Da'Car, not the new first level.

[fmpyear2kb]

Targets for week of 29.4.24

Feedback on project (QUICKLY) -done

Finish slides from beginning of project- almost complete

Write Evaluation

Try your best

Relax when the work is submitted

Build Game- done

Record Game-done

Screenshot Game-done

Create 2 more mindmaps and moodboards for idea generation (you've only done one.) -done

[fmpyear2kb]

Voxels within the games industry

I'm researching voxels in the games industry as I used voxels to model my gas station asset in this project.

Games:

Minecraft Is the first game that comes to most peoples minds when you think of the cube modelling software. Voxels are used in every aspect in this game with the surrounding environment, mobs, player model, tools etc.

Minecraft is a key example of how games can be uniquely modelled. I've always thought modelling with voxels looks unprofessional but then think of how Minecraft has utilised voxels.

Teardown:

Teardown is another fairly popular voxel game where the multiple levels it offers are entirely built out of voxels, just like Minecraft, however every bit can be destroyed/interacted with.

Yet again every model in the game is modelled using voxels. I have not yet tried level designing with voxels but due to me having used the modelling engine so it's definitely a possibility in the future.

Bonfire peaks:

Bonfire peaks is a voxel puzzle game that is also completely modelled using voxels. Your aim is to navigate puzzles to let go of your past and burn your belongings. I can't say that I have heard of this game before but after researching it, it has been recognised as another influential voxel-modelled game.

GIF by indiegamelover

After researching these three games I cannot wait until I decide to use voxels to model the entire game. This will of course need more research but hopefully I am able to achieve this.

Voxel artists:

Mari:

Mari is a voxel artist I found on the website ArtStation. She has made an overwhelming amount of fantastic landscape scenes and recreations of amazing architecture whilst combining the use of shaders and voxels. Whilst viewing these pieces of artwork you can see the amount of detail and effort put into each of these pieces. Voxels can be used in many instances with art being one of them.

John Kearney:

John Kearney is another artist I found on ArtStation who appears to be an Art Director. He has a mixture of both voxel and regular artwork with some being for a game called fire fu. He also has a few 3d model art. Focusing on the voxel side of his art, He mainly does voxel art set in a cyberpunk setting. Yet again his work is inspiring through the use of shaders and skillful modelling.

[fmpyear2kb]

Using Magica Voxel to model the gas station.

With the new information of the second level being set in a gas station where you fill Da'Car up, I needed an asset for the station. However, I cannot 3d model using MAYA and Blender so Magica Voxel is always my go to. It's not as detailed, though it'll do.

Before I used Voxel, I went onto Cgtrader and found the perfect abandoned gas station asset. However, when it was put into the level with all the textures applied, it overloaded Unreal Engines textures, making all of the existing assets very blurry and low detail so the texture of the station could be high quality. I was very surprised to find out a free asset had this level of detail to it's materials, though it was too good.

This is when I opened up Magica Voxel to model the gas station as this was the only option left. I didn't continue looking for more gas stations as the ones I would consider using would be payed models.

Here are the assets from the downloaded model and its materials.

The second level wasn't going to have as much care or time put into it than the final level, so the magica voxel assets were made very quickly.

The top image is the actual station, the second one are the pillars, the third is the pillar base, the fourth is the support for the pillar bases, and the final one is the gas pump. These were modelled using the previous model as a reference. I enjoy using voxels to model as I learn something new every time, in this instance, I modelled everything in the same file despite them all being separate. I achieved this by creating a new sub assembly and then modelling like normal.

Here's what it looks like in game:

I didn't model the roof of the station as it would obstruct the camera, instead, I dragged in a cube and made it not visible but still able to cast shadows, tricking the player into believing they were under the roof. The gas station was vital to the story of Da'Car and it is also referenced in the comics that were unable to be finished in time.

[fmpyear2kb]

Targets for week of 22.4.24

Change first two level zombies. -done

Balance audio -done

Catch up with development blog work -done

Randomisation? -done

[fmpyear2kb]

Quick changes to audio.

Due to there being a lot of music and sound effects in Da'Car, I must balance them perfectly so that the player doesn't get overwhelmed and can hear everything. After playing the game I noticed that Frankie's voice lines were way too loud and the music could use a very minor alteration.

All of his voice lines were turned down from 1 to 0.5.

And the music was turned down from 0.75 to 0.7 as it was almost perfect but just a tad too loud over other sounds.

These may not be final as the audio of Da'Car may need to be monitored more, though this is okay for now.

[fmpyear2kb]

Development post #6

Due to my teammate constantly changing his mind about how he feels with camera's position or angle, We made some slight changes to how it works. In my opinion it was fine how it was, but I quite like how it behaves now.

These few nodes of code were added just before the timeline's code, so that the camera would always begin first, which is a must. The camera keeps its original x axis value so it doesn't move forwards or backwards, whereas the y and z axis follow the player. This code doesn't manipulate the values of y and z, it just locks the x. Setting up the camera like this allows the player to stay on screen but also feel less claustrophobic, making the player think they have more space to move around whilst eliminating all issues my teammate had with the camera previously. This code then allows the player to move the car up and down without the camera moving.

As the game is supposed to be a PEGI 12, we have had to make some changes to the zombies in the other two levels to meet this requirement. We had already finished the designs but with the handful of setbacks it was looking unlikely these were actually going to be in the game. Luckily, I have spent a lot of my own free time to catch back up to where I should be and was able to do this.

These are the new zombie assets compared to the one below. We had to remove the red blood so that the game didn't all under "realistic violence."

My teammate had already premade the two variations at the start of the project, although they had been forgotten until I checked in with him to see if there was anything he wanted to be added before I submitted the project.

For the variation of zombies, I did the exact same thing as I did for the zombie cars. First I duplicated the original zombie actor so that they would share the same code.

I then imported the files, applied paper 2d textures, and then created a sprite from the texture. After this, I created a flipbook out of the two frames of the zombies.

Once the flipbooks were created, I inserted the animated zombies into the corresponding actor. I opened up the Da'Car actor as this was where the spawning code resided. For the three actors to be accessible, I created an array for the actors under a class reference, this makes it compatible with the spawn actor of class node. One thing I noticed whilst blogging about my development processes was that the framerate of the new zombies was not set to 5.8, the preferred rate. Instead, they were set to Unreal's default framerate of 15. This was quickly changed.

You need to compile otherwise you won't be able to add anything to the array.

As there were only three actors again, you need to set a random integer in range with the range being 0-2 as unreal engine registers the first variable as 0 and not 1. Plug the now-filled variable into a get node, which will give the class access to the contents. After these steps are completed, the spawn actor will now spawn a random actor out of the three I created.

Once I completed this, it was important to change the death niagara effect colours as they resembled the old zombies' flesh and blood.

All I needed to do was change the colour here, and the material reference for the effects would immediately update the Niagara effect system. As you can see from the screenshots above of me and my teammate's conversation, I did originally get these colours wrong, I kept the teal blue the same by copy-pasting the XYZ values across and the dark blue was made by increasing the contrast of blue.

Here's the blood particles once I altered the colours:

[fmpyear2kb]

How I create my GIFs

For the FMP, I considered creating GIFS of mechanics in the game that are unnecessary to have uploaded as a video to Tumblr or YouTube, and plus in my opinion it would loom worse appearance-wise on my final outcome slides. After finding a reliable method I began creating gifs of 10-second videos that didn't need to be videos.

The first step was to record the video. I use OBS studio at both college and home to screen record my videos, and I've always used this software throughout the course.

Secondly, I clicked record and quickly recorded a short amount of footage for where it was required (development blogs.)

Once the footage has been saved to my downloads, I open Adobe Premiere Pro to shorten the video and cut out my clicking start and end recording. This helps keep the gif, containing only the necessary information about a mechanic I coded that needs to be showcased. After the video is trimmed, it is saved to my downloads again, but overwriting the original file with the shortened one.

When I've successfully captured the required content and edited it, I search https://ezgif.com/video-to-gif as this does the converting from MP4 to GIF. I select the file and the website takes a couple seconds to process the video.

Once the video is processed it loads at the bottom of the page where you can edit the gif and save it.

Here you can change the framerate of the gif, cut the video (I wouldn't recommend doing it through the site,) edit it, and save it. Finally, I save the gif, go onto Tumblr and then insert an image select the gif, and voila.

[fmpyear2kb]

Why did we introduce different enemies?

Me and my teammate came to the conclusion that at every level having the same enemy over and over would not be very engaging for the player.

We couldn't do anything too ambitious as time was starting to take its toll. The first bit of variation we did was for the cars on the third level. We were only able to create another two assets, leaving three in total with one of them having special sound effects and animation to spice up the gameplay a little bit. The other car asset did not have any special sound effects or animations.

For the first two levels, they share the same enemy type which needs changing to follow the rules of this project. The assets to do this were always on standby and were only just implemented. Originally, when we designed the first Da'Car, we were not able to add different enemies due to the 5-day length of the game jam, though we have a lot more time than that for this project, and our skills have improved since the first game. The zombies also had only another two assets added to their variation, however, these did not feature any custom sound effects, though they were all animated.

The zombies' blood particles had to be changed to match the new requirements so they're now also blue.

The idea to add more was a very quick decision made by my partner, and I agreed knowing how easy it would be to achieve.

Reflecting on a few conversations we've had, it appears that my teammate may have always intended to have more variations within the enemies though this was not clearly communicated to me.

I do agree with the addition of enemy variation as it makes the game slightly more unpredictable and makes the zombies/zombie cars more unique.

[fmpyear2kb]

Hastily developing the fuelling level

It was obvious that the fuelling level wasn't the main focus of Da'Car 2, though it will be developed further in the future. To begin this level I inserted two cubes, one being the desert landscape, and the other being the concrete the gas station would be on.

From here I quickly dragged Da'Car in and a few zombie spawners from the first game.

It was important to understand how the layout of the level would affect the gameplay, so I took a slight break and did a little more development on the car chase level. When I came back to this one, I added the bounds box after considering a few options.

These boxes essentially creates the play area where both the player and zombies are able to move around. A navmesh was also added so that the AI actually could navigate the area, depending on the size of the mesh.

The green area is the navmesh, allowing the AI to move around the box as I see fit. With the basics complete, it was time to insert the gas station model I found online.

However, the textures imported with the model were surprisingly too detailed for the texture sample in unreal to withstand. The model was perfect, though despite the materials being unusable, the model stuck out like a sore thumb as it was a regular 3d object in a mainly 2d based art styled game. Here's the station in the editor with no textures.

After the voxel gas station was modelled, it was swiftly inserted into the game.

Due to how the camera worked, I couldn't include a roof to the station, instead there was a floating cube that was hidden in game to cast a shadow as if you were underneath the station.

This is where it was left until we received feedback from people playtesting saying that there were too many zombies and the car was becoming an obstacle. Firstly I deleted some spawners and decreased the maximum number of randomised zombies that could spawn per wave.

I reduced the spawners from 7, to 3 and decreased the maximum range from 9, to 6. These changes helped balance the amount of zombies spawned, allowing the player to not be overrun by enemies too easily. The collision of the car was also changed so you could shoot through it as the car being an obstacle made it difficult to kill zombies on the opposite side.

With the collision now ignoring the world dynamic collisions channel, the bullet could now pass through the actor but still block the player from walking through.

These changes would conclude the development on this level, there's a lot more that needs to be done to it, however I need to make the hard decision on what needs to be cut and what needs to be added due to the small amount of time left.

[fmpyear2kb]

Development post #5

With the end of the project getting dangerously close, it was time to knuckle down and get an MVP (minimum viable product.)

I still did not have the asset for the player's car, which took longer to retrieve due to my partner's technical issues with photoshop at home. Coming back to college meant i was able to get the last of the assets, assisting in an MVP.

For the player model, I chucked the car sprite and Frankie on top of each other for now due to the time left.

When the car was inserted into the viewport, it needed resizing and rotating for reasons I'm not aware of. It took a couple minutes but it was finally the correct size and my partner wanted the camera to be tilted upwards a little bit more to meet the perspective of the car. Here's a look of it ingame:

Next up was to make the car change sprite when the player moved it left or right.

To begin with I created a function that gave the sprite required when the necessary input was pressed with the compare float and set sprites. On the right arrow, the right facing sprite was selected, on the left arrow, the left facing sprite was selected, and the forward used the front facing car asset seen in the screenshots above.

This function was then added onto the custom pawn movement the player had so whenever the pawn went left, the left sprite played etc. After the sprites were sorted, it was time to attempt to get the tire audio working as I had tried this out before but I quickly gave up.

The branch here allows the code to understand if the movement is 0 or not, with no movement being true, no audio would be played and the code would then reset and check again. If movement was true, then a random pitch between the values 0.9 and 1.2 would be selected.

The audio was also put into a timeline so that the audio would decrease, allowing the audio to feel like they loop more seamlessly. The tire audio is then used as the target for a volume multiplier that increases the volume when the player turns to the left or right a lot. Here are the turning sprites:

By the time this was done my teammate had an idea. He wanted to see if I was able to create a sun to use in the background to add even more atmosphere to the desert the player drives through.

I created a new actor called 'SUN' which only consisted of a sphere. Looking back on it now, there is not much reason as to why it is an actor as I've realised it will still work perfectly fine if it was just an object with a custom material.

I then created a custom material for the sun. Luckily I have used glowing materials quite a lot throughout my projects so I was able to do this fairly quickly.

I set the colour to be an orangey yellow, matching the temperature of the level to give it a yellow hue. I then multiplied the colour by 1250 which is the value me and my teammate settled on after experimenting. Here's a screenshot of when the sun was too bright:

This is what the sun looked like after I was done manipulating the glow values. Once this material was complete, I slapped it onto the actor and manipulated its size so that it mimicked the sun at the end of the road.

After putting it in it was a bit surprising to see how well it had turned out. And eventually we were able to see how it was in game.

We were both very pleased with how this turned out and it will stay. It may have been a last minute addition but I can't imagine the game without it now. Here's a gif of when it was too fast:

However, the sun being an actor proved useful in the end. Despite how cool it looked, it was a bit boring for the sun to stay in one place, so I made it slowly move over time. This code here has added the sphere into the scene which is now being rotated on the Y axis at the value of 0.0001. This now means the sun is able to slowly arise as the game progresses. I did experiment with the Y value as if it was too fast then there would be no sun for half of the level, so it was made just slow enough that it would move, but also remain on the screen for the duration of the level.

With a majority of the necessary work done for the MVP, my teammate was asking if I was able to add a couple things that have some priority but aren't necessarily needed. One of these things was enemy variation which mainly involved him drawing the different cars, he believed that we should do this so that the enemies were not the same every time and to add a slight element of surprise to the player.

I started by duplicating the original zombie car actor so that the other two would retain the important code of being able to be destroyed and target the player. Before the assets were sent to me, the cars were different coloured rectangles. I then went into the zombie car spawner actor and created a new array for the actors to go into.

In the original car's code, the spawn actor of class was just set to the default car, so I plugged in the new variable so that there was more than one actor that was capable of spawning.

To ensure randomisation, I attached a random integer in range, allowing me to set two numbers and the float draws a number within the range between these numbers. I was able to recall all of my randomisation work from before which is why I was able to do this so quickly. After the 'GET' node had the information of the zomvariations variable, it was then set as the class of the spawn actor, allowing all three classes to be spawned in.

With the police zombie car, we decided it would be best to include siren sound effects. To make the audio not sound like it was in your head, we used an attenuation so that the sirens got louder the closer the car got to you. I was luckily able to transfer my skills over from the previous project where I did a lot of audio work to achieve this swiftly.

Here's how our conversation went.

The taxi zombie car does not have any sound effects as we believed there would be too much going on in the level and to prevent overwhelming the player, the taxi is silent.

The sprites had paper 2d texture applied before they were turned into actual sprites to ensure the quality was sublime.

With the enemy cars being able to ram into you from any direction, it didn't make sense for Frankie to be facing forwards when shooting backwards. In the first level of Da'Car, Frankie would change the direction he was facing according to whereabouts the mouse was placed on the screen.

Having done this previously, it seemed a lot easier to gain an understanding of how it was achievable. In the car player pawn there was already a custom event for the mouse lock which was used for previous mouse tracking, we could just use this for the front and back facing sprites.

The mouse lock only sets the x axis which only records the up and down movements of the mouse, so the greater than is able to distinguish the top and bottom half of the screen whilst also getting the world location for specifically the x axis. The select then helps distinguish between whether or not the front or back sprite is displayed, regarding the position of the mouse. Once the mouse passes a certain threshold on screen, it finally sets the correct sprite for the direction the player is shooting.

[fmpyear2kb]

Reflecting on my 2 week plan.

It's now a week later from when I made the 2 week plan. I have made some steady progress towards my goals. Cuts have been made to ensure an MVP is achievable with today being the last day I code just to finish it off. It is a massive shame I'm not able to bring this game to its full potential but these things happen when working on a project unfortunately.

As for slide work, I burnt myself out a lot over the past week, so I gave myself the weekend to rest before going back at this project, so they haven't been started yet, but they have the highest priority at the moment.

[fmpyear2kb]

Development Post #4

I perfectly understood how camera shakes worked which was perfect a I wanted to add a camera shake when the cars exploded to add to the action.

I created a new camera shake component and immediately manipulated a couple values inside it.

I increased the necessary values for some intensity and then moved onto adding it into the code where the zombie cars blow up.

I added the play world camera shake and changed the values of the inner and outer radius. It had been a while since I had used a camera shake however, so I experimented with the values of the node. I eventually was satisfied with the camera shake after dialling down the shake as I did accidentally make the camera look like there was an earthquake, which was definitely not suitable for our game. Once all was done, I made sure to place it just before the sound effect of the car blowing up was played, producing a very satisfactory result.

After some consideration, we decided that it would be best for Frankie to used a different gun as a pistol surely would not blow multiple cars up, so we settled on a machine gun.

When the left mouse is clicked, a camera shake is played and the bullet actor is spawned every 0.05 seconds. This firerate was crucial to get right as the weapon needed to have the machine gun feel. As for the shake, it's a very short burst that should represent a bullet being shot which was mastered when we originally made the first Da'Car. We just reused this asset. The floats on the bottom half of the screenshot give the bullets what is referred to as 'bloom' making it so the bullets aren't just shot in a straight line, instead there being some variation as it randomises the roll, pitch, and yaw.

And at the end of the code, I made it so the bullet shot noise plays from the same gunshot audio bank that was created for the original Da'Car. The pitch of the audio is then randomised even further than just the random bank, allowing for variation of the played audio so that it is slightly ,ore unique than hearing the same 7 sounds over and over as the player will need to be shooting quite a lot in the third level.

At this point I decided it was time to find a model for the gas station in the second level. I had found one however, the assets were too high detailed that it affected the textures on the player and the zombies, making them appear blurry. To prevent this I then modelled the gas station within magica voxel as I'm not confident with proper 3d modelling.

There was an issue with Unreal Engine not being able to find the correct music for the specific level the player was on.

First I created an array that contained the music for each level, which was then plugged into a find node that would help select the correct one.

I've also got a custom event that helps load the next level as there is three levels meaning that the simplicity of changing levels the same way is now more difficult. This event gets the current level name, finds the level from the level array and adds one to the list. There is an equal to 3 node that allows the menu and first game to be loaded upon completion of the third level, if the number added is not equal to three, it just follows the regular code and opens the level by name. If the levels value is 1, its the first level, and if it's equal to 2, it opens the second level, and if its value is three it opens the final level, but when one more value is added, it just reopens the first.

I had to put in a big box that wasn't visible in game as when the player's cursor was over the sky when shooting, it would just shoot at the original coordinates of the level. This proved to be an irritating feature when playing the game myself. There's no coding for this box, I put the bounds material over it so I knew it was an object that had a purpose, but was not visible in game.

Once this was done, the player is now able to shoot at the sky without the bullets redirecting to a completely different position.

[fmpyear2kb]

Another issue regarding swift development.

This project has proposed the most issues I have ever had with any project within my time at West Suffolk College. My partner now has an issue with his home laptop not allowing him into Photoshop due to some IT issues with his school email. Because of this, I am currently not able to implement any of the main character assets/frames to achieve an MVP. Not only will this have to wait, but all of the other setbacks have made this project fall incredibly short on our expectations and I'm personally quite irritated that I've let my teammate down as it is partially my fault for entering the competition and losing the project.

[fmpyear2kb]

The addition of the Fueling level

Following the sudden information of there needing to be another level in Da'Car 2, I needed to act hastily.

The easy part was copying all the code over from the first Da'Car, as this level would function the exact same. However, I immediately ran into a problem. The act of copying everything over would take absolutely forever, and there was no time to waste. I created a copy of the project to test migrating a level over before realising it wouldn't work. I deleted the copy but, it deleted the other project meaning that not just the progress for the new level but the entire game was gone. I've gone into more detail about losing the project in another blog post.

Recovering from the project deletion did help us out in a way though, as the game was rebuilt from scratch within the old game project meaning that we had all of the existing code from the original level, eliminating the need to copy everything over manually. Making Da'Car 2 within the old game benefitted the fueling level immensely, it only took a while to re-code the car chase.

Luckily, due to the code now all existing within the project, it was significantly quicker to code the fuelling compared to the car chase level. Admittedly the first level of Da'Car 2 is less taken care of in regards to content, but I was able to not disappoint my partner with having to cut even more content

[fmpyear2kb]

Why is there now another level in Da'Car?

Mid-way through development, I was made aware of there needing to be a new level before the car chase. My teammate is positive he mentioned it but both me and the teacher helping me restart the project after it was lost, reckon that he never mentioned it.

However, losing the project did benefit from this sudden information, as the new level was almost a carbon copy of the first, but you were fuelling the car instead of repairing it and with the project now being in the original Da'Car file, we had access to everything, so no more hassle of vaguely copying what was necessary.

Despite there needing to be a new level, we both agreed that most of the development time we had would be used on the car chase level, with the fuelling level being worked on in my free time.

The fuelling level does make sense if we tie it into the story of Da'Car, I just wasn't made aware it was happening.