Project Realisation – Assignment 1 blog: Critical Evaluation

I this assignment challenge my time management to levels that exceeded my expectations. I’m very sure I would have been challenged to the same extent possibly more, if I had not of needed to take time off my course for serious reasons.

I intially was going to state that my time management in this project was average and that the very big obstacles along the way showed up, were unfortunately concentrated towards to latter half of the project’s journey. With the biggest one, the enemy code happening, scarily close to my deadline. But, the fact that I did not factor in extra time into my schedule to act as a contingency for any problems that reveal themselves to me, in the production of the game. Is in fact bad time management and not an unfortunate mistake. I feel that the reason I did this was because of overconfidence as I already worked on and successfully produced a game similar to Adventures of Gus & his Bass Guitar in the past.

This lead to me having to omit key features from the game due to having to prioritise the time that I had originally allocated to production with the assumption that I was going to not run into any problems. However, the feature that I did omit where a part of what made Adventures of Gus & his Bass Guitar’s identity. The main thing I am talking about here is the music which is so essential to the game and it’s aesthetic. The visual style paired up with the music in such a complementary way.

To evaluated the things in the project that I am proud of and thought I did good work in, I have to bring up the assets. This the most visually interesting artefact I have produced. I chose the right style to go for but more importantly, I paid very close attention where I was designing the assets and font, making sure as I kept adding to the project that everything was congruent, visually and aesthetically. I paid a lot of attention to the music also, however it was excluded from the final artefact.

And although some of the animations were janky, I never felt I betrayed the presentation of the game I built up during the production of the project. The way the lack of music in-game admittedly did.

To conclude, this is a project that I’m very happy to put a project as the final product did showcase my strengths. However, I will only do this after adding the music. I feel like this project was a very close realisation of my final idea, just without one major factor (the music) and not quite the amount of polish I would have liked.

Advertisements

Project Realisation – Assignment 1 blog: Enemy AI: Major issues

The enemy have stop working very late in the production. I’ve look over the instances many times, I see now overlap, wrongly attach object or conflicted placements. It’s very bizarre and no longer have time to troubleshoot. I aknowledge my limitations with skills pertaining to AI, but have made a very similar code to this, previously on the course. The enemies are unresponsive when I load the page. I wanted to go back to fix the issue of music but I have to prioritize this situation now.

Project Realisation – Assignment 1 blog: Enemy AI: Collisons

Before moving on to the last enemy I work on enemy collisions, just so I can test if everything works. And the states for both Gus and the enemy work just as intended. With Gus receiving damage when not in the attack state and the enemy receiving damage when Gus is in the attack state and collides with him.

You can see a test beneath, I had to remove all ranged enemies from the scene temporarily to get it to load with out error.

Project Realisation – Assignment 1 blog: Enemy AI: Closed ranged enemy attack

Nearing to the end of the event sheet for AI. I start the event off by setting the enemy attack animation frames. Then I add a cooldown to the attack. This is a crucial part to keep the enemy from being overpowered and unfair, because if a player were to get stuck in any enemy attack loop till they die and round resets, it will lower the games playability and cheapen the experience. This also stops avoided enemies from staying in an attack loop when Gus is out of range. I also attach a timer to the chase state to give the player some more breathing room.

Project Realisation – Assignment 1 blog: Enemy AI: Detection & Movement part 2

Starting the code in the last post, I began on with the detection, now I can set the movements of the enemies. I do this giving the enemy different states much like the different states Gus had, albeit for differing purposes. I initially was only going to only program the short-range enemy for movement, as I felt it was redundant for the ranged enemy. But thought that this would be a way to potential nerf the ranged enemy as I felt she may be too difficult to go up against. But if you are close and a walk state is triggered instead of an attack state, it would give the player some time to react.

Project Realisation – Assignment 1 blog: Enemy AI: Detection & Movement

The first thing I did was program how and when I wanted my enemies to move in the scene. I want my enemies to be inactive whilst they are off-screen and only moving near the enemy (when facing them). The main reason for this is so I can ensure they the level doesn’t change each time it’s loaded. When I place an enemy somewhere on the scene they won’t be out of place when the player gets there. Another major reason for this decision was to avoid having enemies which are passive and essentially act like obstacles. My last consideration was the short-ranged enemy, feeling he would be too easy to without some movement.

Project Realisation – Assignment 1 blog: Character code: Life points and collisions

Expanding on what was explained in the previous blog. Gus has one state which dictates If he takes damage on collision or if the enemy does.  This state is called “attacking” if it’s false, Gus takes damaging on enemy collision and the opposite if it’s true. This set is automatically off from when the scene is loaded. And is only set sparsely throughout Gus’ attack animations. This concludes Gus’ code.