#HilarityGame

[cgf-dev]

Sprint 22

After key updates surrounding the boss fight and bringing some aspects of combat up to date, this week I had chance to finish preparing the test build ready to send out. I got to work on the all-important combat test scene. To make things easier to set up, I simply cloned our existing Act 3 and sectioned off the beginning area, resulting in a small (already well themed) arena. I then created the NavMesh, thoroughly making sure to exclude all sizable objects/buildings that would naturally obstruct the agent’s pathfinding capabilities. Finally, I created the test build, which we went on to share through direct messages to friends, Google Drive and Twitter our accounts. All in all, I am extremely happy with the way this test build has turned out and we have received some useful feedback already. 

[cgf-devhilaritygame]

Sprint 17

This week I solely worked on my own again, concentrating on the boss agent Fillipe. I began by setting up his animator and importing his model into Unity. As his model is particularly large (in-game, not mb!), he reminds me of the Abomination boss from Killing Floor 2 and I intend to take a lot of inspiration from him gameplay wise. I have adjusted his stats to match accordingly; he has a slow turn speed, movement speed etc and is generally not very intelligent.

After I got all of the basics working - the chase, stagger, melee attack etc. I decided to set up his ability/attack ranges. I have chosen to use multiple gizmos as different coloured radii are much more intuitive to use in scene view and makes my life significantly easier. 

Then I got to work on fully implementing his throw attack. I began by creating a food prefab using the ham model and created a new script for it to use. It contains what you may expect - added force for the ham to fly through the air, gives the ham a life time, deals damage to the player on collision etc.

To truly smoothen out the visuals and give the boss an attention to detail, I created an animation event so that the ham is instantiated at the precise time when Fillipe would throw it. This was my first time using animation events and I am very happy with the result. Here is a video of the boss in it’s current state:

https://twitter.com/charliegfrost/status/1240020964630552581

[samstablercvg]

Sprint 1

For our first sprint my first priority was to get the whole team on the same page on what the experience of our game is. To assist with that I created a game outline of the first five acts. This is more than we plan to make for our project but eventually we hope to complete all 8 acts. This outline simply highlights the key game play moments without the narrative.

To expand on this document I put together a sheet that shows each weapon (including real world reference, damage and details), character and enemy. For the enemies I included their background and attacks.

I also created a Scrumwise to help organise the team and maintain an Agile methodology. This is software we have used countless times and each time it has proven to greatly improve productivity within the team.

Finally to allow members to collaborate easily from home I set up a discord server.

[cgf-dev]

Sprint 21

This sprint was a huge one!

Since last sprint’s work was focused on getting the test build ready, we realised there was some more work to do before releasing it and therefore this sprint I focused on polishing Act 3 (the act with Fillipe, our boss in) whilst other members of the group took care of some necessary additions to the other acts.

Firstly, there were some new/fixed animations to implement. This improved orientation problems (the boss facing sideways when attacking etc.) and noticeably made the boss move around smoothly. After this I brought in the new boss model and textures and was reveling in the fact that I am working on this boss! It looks amazing. Afterwards I remembered to re-add the animation event to the new throw animation (the event that spawns in the projectile) and adjusted which animations were being looped, as well as finely tuning all of their transition timings and speeding him up, further improving both the visual and gameplay aspects of the boss.

Next it was time for some more technical amendments. I updated his code to override the AI script and remove staggering code as we have decided his stagger animations aren’t necessary - they cluttered his animator too much and disrupted fluidity. Additionally, I fixed his melee attack - it would sometimes only occur once and wouldn’t loop, I did this via altering the conditions for if-statements. Next up, the melee attack would either not hit the player at all, or be dodge-able through jumping. I moved the origin of the raycast slowly, testing along the way using Debug.DrawRay. Now if Fillipe is in range of the player and facing them, the melee attack is unavoidable (as we hoped). 

After this is was time to work on one of the main mechanics for the boss - the obstacles. I added functionality to destroy them upon collision with the charging boss and instantiated a debris prefab that I had made (with help from Josh). Sometimes these prefabs would spawn in the wrong place, however, such as in mid-air, upside-down. After much deliberating I realised that there were spawning at the pivot of the old object - I fixed this by using their natural position and rotation rather than the obstacle’s. Furthermore, I created a dust particle system which is also instantiated when the obstacle is destroyed. This not only adds to the visual aspect of the fight, but encases the boss in a cloud of dust upon collision, making it slightly more difficult for the player to shoot him whilst he recovers.

Here is Fillipe in his current state:

https://twitter.com/cgf_dev/status/1262140270306635777

Finally, I worked with Kyle to add functionality to the ammo system. The ammo pickups are now working and I helped supply him with pseudocode for ammending the player’s ammo supplies - the correct ammo will be taken from reserves for reloading etc.

[cgf-dev]

A Brief Reflection

I have learnt a lot over this semester, and many of these lessons have been from making mistakes. The most gleamingly obvious ones would involve the NavMeshing process and I definitely won’t forget them. I have learnt that creating clear UML Class Diagrams and conceptualising Finite State Machines can really help me remain organised as a project develops, but on the contrary that keeping ideas and implementations as simplified as possible is also the key to an effective outcome when faced with limited resources (i.e. not millions of pounds!). 

Myself and the rest of the team are very proud of our project and I am particularly fascinated by the scope of game we have managed to produce during this time frame. There are three large acts, complete with objective-based gameplay, somewhat tactical combat, cutscenes, interactive menus, settings options, a loading screen and a boss battle amongst many other features. The game brings feelings of uncertainty, fear, mysteriousness and is extremely immersive, which are all things we were aiming for. In my opinion the aesthetics are impressively detailed, the game is themed tremendously well and the combat is quite good. The downfall of a lot of single player game is their replayability - to battle this, we have incorporated many pickups as well as hidden secret items/areas. I have thoroughly enjoyed working on this project as it is definitely the most impressive one I can put my signature on.

[cgf-dev]

Sprint 23

Welcome to the final sprint breakdown (for now)! After allowing some time for our test feedback to be gathered and analysed, the rest of the group got to work on making improvements in these areas - there was not much negative feedback relating directly to the AI in the game and I shall talk about the minute things later. 

This sprint, half of my time was spent completing any necessary tasks related to our boss, Fillipe, whilst the other half was spent NavMeshing the whole of Act 3, in which I have only just conceptualised the true scope of our map! 

First of all, there were some serious additions to make to the Fillipe fight. The first one was to implement his death animation. I did so and then tweaked some settings, such as playback speed, to create a dramatic ending to the fight (think Cuphead level of dramatisation). Secondly, I incorporated his health bar’s functionality. The bar was implemented by Jed, however I linked it directly to Fillipe’s health value, by converting his current value into a percentage. Accompanied by the recently added music, it has really added to the “epic” feeling of fighting in the boss tent. Last but not least (when it comes to Fillipe), I added in his meat cleaver model, making his melee attacks all the more terrifying and justifying his larger damage output. The cleaver’s size was even scaled up to give a more menacing vibe. 

After applying these updates to Fillipe, I got to work creating the NavMesh for the whole of Act 3. This was a huge learning curve for both me and the group as a whole, as we have learnt the lesson of putting any objects that need to be made non-walkable, into either a prefab, or having meticulously organised game object hierarchy. I had to bake many of the objects in the scene (hundreds, if not thousands) individually or in small groups, as so I have definitely had time to reflect upon this! I am happy with the end result, though; the enemies move through the intricate buildings and fenced-off areas exactly how you would expect them too, whilst retaining their functionality properly (shooting etc.). 

Here is a screenshot of the NavMeshing process:

https://twitter.com/cgf_dev/status/1271093870592393217

[cgf-dev]

Sprint 20

It’s been a while since my last post however I can proudly present lots of progress! This sprint was actually completed a short while ago, however I have not had time to blog with everything else that is currently going on, namely the virus.

This particular sprint was focused around starting the setup of our combat testing. I was anointed to sort out the majority of this build and so to begin I set up 3 scenes - The Act 1 Test scene, a “Text” screen (simply a “press E to continue” screen that instructed players about controls and let them know they are about to go into combat) and the CombatTest scene.

The CombatTest scene simply spawns in lots of enemy prefabs around a section of the map and lets the player go to town on the gauders. When (ironically) testing this scene, I had found that it was rather difficult to sustain and eradicate all enemies and so I decided to add some medkits throughout the level to aid the player.

[cgf-devhilaritygame]

Sprint 16

Sprint 16 was another heavy week of working with Kyle on the PlayerMove script, applying a few fixes and upgrades to the player’s shooting mechanics. Note: for the sake of consistency, I will call the shotgun shells bullets!

First of all, we changed the code so that you can no longer hold down the mouse button to shoot the pistol, as this makes no sense (to be blunt) - the pistol is not an automatic weapon. 

Secondly, I read up on each of Unity’s collision detection methods and we have ammended both the bullets and the enemies to use the correct methods - ContinuousDynamic for bullets (they move extremely fast) and ContinuousSpeculative for enemies (the bullets will collide with them and they are kinematic and is cheaper than Continuous). 

Next we fixed the shotgun so that multiple bullets come out and actually do damage to enemies. After this I was able to implement a bullet spread and launch multiple projectiles out each click. I did this using an array. We loop through the array and just before each individual bullet is fired, alter it’s direction slightly (using random integers) to veer off-course from the center of the screen. This has worked brilliantly and is a fairly resource-savvy way of implementing a shotgun bullet spread, therefore I am extremely pleased with the result.

[cgf-devhilaritygame]

Sprint 15

While sprint 15 is a relatively short one in terms of my blog post, what we achieved took a significant amount of time to work out how to implement properly. For this sprint, me and Kyle worked on swapping the player’s shooting system over from raycasts to bullet collisions (invisible line vs bullet prefabs with colliders). There are multiple benefits to using this system, although it is more resource-intensive (checking for collisions constantly). One benefit is that we can later use the point of collision to add better AI feedback such as crippling the agent when they are shot in the leg, applying headshots etc. as the ragdolls have a collider for each body part. Another benefit is the most obvious - the player can see their bullets leave their gun and zoom through the air. 

Therefore whilst we did not achieve a long list of things, this sprint was vital for the success of the enemy/combat systems within the game.

[cgf-dev]

Hilarity Reflection

As it has come to the end of the semester, I want to write a short blog to reflect. I feel as an individual and a group we have planned this project much more effectively than in the past. I have programmed AI and some game mechanics. I spent a lot of time creating spreadsheets, planning out my code hierarchy and communicating with the other members of my team to ensure each script is easily readable by others and there were no clashes between AI scripts/scripts created by other team members. This has been invaluable and has not gone unnoticed. I have progressed very far in terms of designing AI state machines via scripting and I must say even I am impressed with the result! This means next semester I can rapidly start creating different enemy types and add as much or as little functionality to them as needed. I feel AI is an integral part of this FPS game and I have done a decent job overall. I have commented my code clearly throughout to avoid confusion (or confusing anyone else) and was happy with the demonstration showed during our presentation. Well thought-out class members have helped simplify the AI, for instance we have a very simple animator considering the intelligence of the npcs. I have also taken great pleasure in helping (and recieving help from) Kyle with some of the game’s mechanics. We added the weaponwheel code with help from Rod and this vastly improved the performance of the game via the use of Arrays. My programming understanding has improved brilliantly during this semester and I could only hope for the same next semester. 

[cgf-dev]

Sprint 12

I know I posted earlier today, but here is a short update! Since posting I have implemented two new enemy types, the melee gauder (which uses a whacker weapon) and the ranged gauder (which uses the pistol).

The melee gauder uses similar code to the unarmed gauder, however wields a spiked club and deals extra damage. Here is a video of him:

https://twitter.com/charliegfrost/status/1227703437862883330

The ranged gauder shoots at the player when he gets into chasing range and as a result is slower. I used two sliders - Shoot Probability (the chance for him to shoot each interval), and Shoot Accuracy (the chance of the shot hitting the player). This randomisation improves gameplay because the enemies are less predictable and more realistic - less robot-like. There is no video for them at the moment because I am waiting on the shooting animation and have yet to fully implement proper line of sight functionality. 

These enemies have taken me less time than I thought to implement, which means I get to work on the boss soon! Very excited for this as I have never coded a real boss with complicated phases etc. 

[cgf-dev]

Sprint 12

Many weeks later and we are back working on Hilarity! Apologies for the break, I will be constantly working on the AI for the game in the coming months, with the end result being multiple enemy types and a boss battle. Over the last few weeks, I have achieved the following:

Ammended code to stop using our complicated unnecessary state machine

Organised and simplified all AI code - includes removing/adding comments

Created AI superclass to enable easy creation of multiple enemy types deriving from it

Fixed AI states updating properly & AI attacking behaviour

Created AIUnarmed - the script used by the first enemy type - the unarmed gauders

Smoothened all AI animation transitions - especially the attack

Player now only takes damage during the AI attack animation

I have been playing a lot of Killing Floor 2 lately and realising the incredible quality of the AI has inspired me to essentially restart (using code already created) to organise everything. This will make it easier to upgrade our AI and make new enemy types (something that really improves the gameplay / strategic elements of KF2). 

As most of these changes are behind the scenes, I will be working on the new enemy type and a video should be uploaded very soon! 

[cgf-dev]

Sprint 9

Oops, forgot to mention, ragdoll vid coming soon!

[cgf-dev]

Sprint 2

During this sprint I have been limited time-wise due to a family emergency, however I understand how integral our AI system is to ‘Hilarity’ and therefore have taken a step back to analyse state machines as a whole, look at other examples, and attempted a simple case-break state machine to see if this is a possibility (and to get some experience creating one, honestly). I got half way through and a particular Reddit post caught my attention. After reading it I realise our AI system would need to be more complex, especially if looking at future progression of the game outside of University. Due to this, in the upcoming sprints I will endeavour to create a more advanced AI system template.  Here is the Reddit post:

https://www.reddit.com/r/Unity3D/comments/1lzt3w/state_machine_switchcase_or_delegates/

[cgf-dev]

Sprint 1

First update of newest project - 'Hilarity'. Created a spreadsheet to roughly show stats/abilities (not set in stone). This should speed up future coding exponentially; once the numbers are all adjusted, this saves us having to add in placeholder values and should reduce testing time greatly -  I will report back on this in the coming weeks/months.

I have also added in a piece of code I have previously worked on - The ‘FollowAI’ script. I have adapted it to suit our needs (simply following the player using a NavMesh with the opportunity to attack the player if we want to test that).

[cgf-dev]

Sprint 11

Sorry about the break, been focusing on some other work recently. Here is a short blog showing off my latest work on Hilarity - an ammo system. Firstly I have added an ammo counter to the UI:

Of course, this ammo counter goes down as you shoot your gun. 

I have also added in our pistol reload animation, called for it to play when ammo count reaches 0 and whenever the player presses ‘r’:

https://twitter.com/charliegfrost/status/1204504445201125377

Lastly, I have added an extra condition for one of our ‘if’ loops so that the player is not able to shoot whilst reloading (the raycast cannot actually be drawn)!