cgf-dev
cgf-dev
Game Stuff
60 posts
I publish updates to any projects I am working on!  https://github.com/cgf-dev  https://twitter.com/charliegfrost  cgf-dev.com  https://www.linkedin.com/in/charlie-frost/
Don't wanna be here? Send us removal request.
cgf-dev · 4 years ago
Text
Update 9 - Rooms closing & opening, Enemies spawning gradually, Enemy range mechanic added & scrapped
I began by implementing a range mechanic for the enemies. I then realised it wouldn’t be necessary, because enemies should only be spawning on a room-by-room basis. This taught me to plan ahead more carefully (also to laugh at myself!)
Then I added the room closing and opening feature. It works by instantiating a wall prefab upon the player entering a room, which then spawns the enemies. A count is kept of how many enemies are currently in the room that the player is in, which is then used to open the walls back up when all enemies are defeated. 
Here is a link to the tweet/video:
https://twitter.com/cgf_dev/status/1438097590646620169
0 notes
cgf-dev · 4 years ago
Text
Update 8 - Special Attack /w UI, Larger rooms, Enemy spawn system, Bug Fixes
In the past update I added a special cluster-grenade like attack that fires a larger bouncier bullet, that then splits into several normal sized bullets. I have improved the code to shoot at the smaller bullets faster, and made sure there are no physics bugs involved with them hitting the player/enemies and knocking them backwards. The damage of this attack scales smoothly with player stat upgrades, too!
I have improved the room prefabs to be significantly larger (2x the previous size). This will enable me to customise/randomise them more and will improve the feel of the gameplay/exploration elements of the game.
I have added in randomised enemy spawning at the beginning of each level. In the near future I will add a detection radius on them, or make it so that the enemies are only spawned into a room once the player enters it. This will help save on computer resources, but also prevent many enemies charging towards the player. Another option could be to add closing walls once a player enters a room that would last until all enemies in that room are dead. 
Here is a link to the tweet/video:
https://twitter.com/cgf_dev/status/1437754422755483652
0 notes
cgf-dev · 4 years ago
Text
Update 7 - Revamped minimap, special attack, camera follow and end of level transition
In this sprint I have completely remade the minimap. It now has a clearer design, with a black background and white border. I made an effort to keep it simple and feedback-rich, to save the player’s time viewing it and potentially save them from a nasty comeuppance. 
I have added a placeholder transition to a new scene when the player exits through the portal at the end of the level.
I also added camera follow scripts and linked the main camera to the minimap camera. It took a while for me to realise I should have put the main camera code within the ‘LateUpdate’ function (it’s been one of those days!), but it was simple enough.
Finally, I have added a special attack, which is a larger version of the normal bullet. I have added a new physics material to this attack and changed it’s stats/shape. In the near future I will create a cooldown for it and display it on the UI clearly (most likely using a bar).
Here is a link to the tweet/video:
https://twitter.com/cgf_dev/status/1436258089892786176
0 notes
cgf-dev · 4 years ago
Text
Update 6 - Added portals/Minimap
I have further improved the random room generator:
- Rooms rarely spawn closed wall to open door
- Levels are never unfinishable
I have also implemented portals as a means for the player to move on to the next level.
I have implemented a simple minimap (unfinished) that features a top-down view of the action and has a simple border surrounding it.
Here is a link to the tweet/video:
https://twitter.com/cgf_dev/status/1435625173416353794
0 notes
cgf-dev · 4 years ago
Text
Update 5 - Fixed and Improved Random Room Generator
Short update here (probably more time-costly than the other though!) The room generator has been fixed, and I have implemented a simple weighting system so that if I desire to instantiate certain types of rooms more than others, that is a possibility.
I have also fixed a bug, which would essentially lead to the odd dead end, however there are a few more things to tweak before I am fully happy with the system.
In the future I’ll look at adding obstacles etc. as well as look at how the player is going to transition between rooms.
Here is a link to the tweet/video:
https://twitter.com/cgf_dev/status/1431296022626570240
0 notes
cgf-dev · 4 years ago
Text
Update 4 - UI improvements and Random Room Generator!
I have spent the majority of the day working on my roguelike project, and I feel I am making great leaps towards finishing the game - nothing is without failure, however. I am ending today on some errors, as I could not get my random room generator to work properly, however I am still very happy with my progress...
I have added some new stats to the game, including firerate, and have updated the game’s HUD to reflect this. I have created two large scripts to begin my room generator (arguably the most difficult part of the project in my opinion, so far at least).
I’m sure within the next few days I’ll be able to get it up and working and all of my time spent will be well worth it! 
Here is a link to the tweet/video:
https://twitter.com/cgf_dev/status/1429831019419549703
0 notes
cgf-dev · 4 years ago
Text
Update 3 - A Multitude of Things
I have been very busy recently, however I have added a reasonably large update to the game. I have managed to upgrade the combat system, providing the player with feedback for when themselves or an enemy gets hit, adding bounciness to projectiles (and walls to bounce them off), adding health/collectible systems with accompanying UIs, deaths and improving the player’s crosshairs!
Here is a link to the tweet/video:
https://twitter.com/cgf_dev/status/1428369079451013127
Updates made:
https://twitter.com/cgf_dev/status/1428369466841190403/photo/1
0 notes
cgf-dev · 4 years ago
Text
Update 2 - Shooting Mechanics
Today I have played around with shooting mechanics that enable the player to shoot enemy projectiles out of the air to defend themselves. I have also added some colours for quality of life purposes, and implementing player/enemy health (will add healthbars and damage feedback soon). Finally, I have added some walls to create somewhat of a room.
Here is a link to the tweet/video:
https://twitter.com/cgf_dev/status/1415716309753552899
0 notes
cgf-dev · 4 years ago
Text
Update 1 - Roguelike practice
To begin my project, I have created a player script, a point and shoot script and an enemy script. I have set up basic 8 - dimensional player movement, as well as multiple behaviours for the enemy. The enemy is created in such a way that I can simply modify it’s stats to produce different enemy types - e.g. setting it’s retreat distance to 0 to create a melee enemy, which I plan on doing in the near future.
Here is a link to the tweet/video:
https://twitter.com/cgf_dev/status/1409906148904419328
1 note · View note
cgf-dev · 4 years ago
Link
I have just finished creating the test build for my latest solo project! It’s a small endless runner game that I may end up porting to mobile. Please feel free to try out the game for free and give me some feedback! Thanks.
1 note · View note
cgf-dev · 5 years ago
Text
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.
2 notes · View notes
cgf-dev · 5 years ago
Text
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
2 notes · View notes
cgf-dev · 5 years ago
Text
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. 
4 notes · View notes
cgf-dev · 5 years ago
Text
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.
3 notes · View notes
cgf-dev · 5 years ago
Text
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.
2 notes · View notes
cgf-dev · 5 years ago
Text
Sprint 19
Spent the past few days continuing programming work on Filippe! After fighting the Butcher in Diablo 3 numerous times, I was ready to create an entertaining fight by finishing off the remaining few methods.
I began by tweaking the transitions in his Animator to create a smoother aesthetic overall... this resulted in better gameplay as he is behaving less unpredictably strange.
Then I created methods and coroutines for stunning and slowing the player. The now occurs when the player gets hit by Fillipe’s charge ability, and renders them unable to move for a few seconds. The slow occurs when the player is too slow when dodging the poisoned food thrown at them. Using coroutines here was justified and sufficient for this smaller project/boss fight, however if I had to program multiple of them I would’ve created/adapted a player state effect controller. This would make the code more easily readable and organised in the long run.
Next I removed the food’s instant collision damage and turned it into a poison DoT (damage over time). This was fairly simple and was achieved in no more than 10 lines of code (after some trial and error). Combined with the slow, the throw damage is no longer something to be scoffed at!
Finally, I have altered Fillipe’s variables to ensure the fight is entertaining / more fairly balanced, although after the upcoming playtesting session, I will inevitably be re-tweaking these values. I am still happy with the progress being made on this boss and will keep you updated (the end is not too far away).
Next week I should be looking at updating the aesthetics of Fillipe and might play around with some particle systems / VFX!
Here is a video of Fillipe in his current state:
https://twitter.com/cgf_dev/status/1247932197404901376
2 notes · View notes
cgf-dev · 5 years ago
Text
Sprint 18
This sprint was a hugely productive one for me (and the group). My week began with baking the new map (for act 2). I applied settings for various objects depending on their proximity to the Boss battle, so that he doesn’t run straight into them. 
Next I implemented a Coroutine called “Charging”. It simply uses some new booleans to pause the rest of the code, whilst Fillipe’s charging animation plays. During this time, the “chargeStats” bool alters his NavMeshAgent’s values, so that he moves faster, has a slower turn speed, etc.
Shortly after this, I noticed a problem - he was charging from melee range! To fix this I have added another radius range to him, that can be used as a condition for charging. This only enables him to charge when the player is a small distance away from him, making for no awkward moments during the fight. 
Next up I got to work on the consequences of his charges (with the Butcher boss from Diablo 3 in mind). Firstly, I have used an OnTriggerEnter to determine what happens when the player gets hit by the charge. The code is not implemented yet, however the player will become stunned, take more damage for a brief period and a stunned effect will be shown on their screen. Secondly I worked on what happens when Fillipe charges straight into an ‘Obstacle’ (clever!). This now triggers his ‘isFailCharged’ animation, which knocks him onto the floor. After this he resumes to chasing the player. Of course, there is more to add/improve, but I am very happy with the progress being made on this so far.
Here is a clip of the updated charge:
https://twitter.com/cgf_dev/status/1246113359344349184
Note: This week I also worked with Kyle to smarten up some player script code, organising variables and disabling shoot functionality whilst the shotgun is reloading.
4 notes · View notes