Week 9
This week I worked on preparing the game for the play-test.
Work of the Week
The first thing I did this week was work on the pitfall tiles. First I animated the tiles I had already designed, then after thinking about how I’d go about placing them in the game itself I realized I needed a third row of tiles as these tiles were 2×3, I decided to make a 3×3 tile in case we needed a larger pitfall. I got to work on that relatively easily and reused a lot of aspects from the 2×3 tiles with minor changes to accommodate the extra row.
I also worked on the tutorial level tiles, using the original hub tiles I had created as a sort of basis for what they should look like. I also watched a video about how to create a pixel art grass tileset that inspired the design of the tutorial tiles.
I also worked on the “tera shards” of the game, as for some reason it was decided that it was appropriate for the environment artist to work on something that has more to do with UI than environment, but nevertheless I accepted this proposal as I was tired of only working on tiles anyway. I also believed I would create an effective artwork for it in any case. I created two designs, a white one and a green one. I created a white one as that way it would be linked more to the hub world than any other realm in the game and I thought it fit the game best. The green one was created as that was what was specified in the GDD, however I felt with the direction I had gone in at this point in developing the distinct realms’ colour palettes (see gate designs) that green was not fitting. However my groupmates insisted on a green design and thus I created both, by the end they had preferred the green design and thus I assented and would go on to implement it in the game.
I worked on implementing all the tiles I had made. I created a rule tile for the pitfall tiles that allowed me to easily implement the pitfalls. I also added in all the tutorial level tiles, the title tree animation, and I implemented in the tera shards. Lastly, I implemented our character artist’s animations for the new enemy.
Bizarre Communication Breakdown
Notably, I had been informed that the placeholder audio I had put in was replaced with some finalized audio, although while play-testing I failed to observe the new finalized audio I was told about. My groupmate (who was not the one who put it in) insisted that it was in the game and implied that it was an issue on my end. I looked into the github changes history and only found that the audio had been put in the game files but that no one (including the aforementioned groupmate) had actually implemented the audio. I was thoroughly confused on this matter as I did not understand why my groupmate mislead me, but nevertheless, I relearned how to implement audio and accordingly added in the final audio tracks, as well as some extra ones that had been neglected to be added in (such as music and hub sound effects).
I did not bring up the fact that my groupmate had practically lied to me as they would likely take offence at such an insinuation. This experience just reminded me to always double-check the game’s progress and changes, and to not rely on this particular groupmate’s words as they were wont to be incorrect, misinformed, or just generally abrasive in a manner that did not lend itself well to group synergy or productivity. This specific lie did lead to me feeling a touch of rancour in regards to this groupmate however I decided the best course of action was to disengage from communication and focus solely on being productive and not letting such behaviour affect my output, or at least limiting its effects on me as much as possible in the future.
Play-Test
On the day of the play-test myself and my groupmate E-Jay worked on the game as much as possible before the play-test itself. The game was rife with bugs and issues unfortunately and I lamented that I had not play-tested it the day before and instead was preoccupied with implementing the tutorial tiles and pitfalls; as those two aspects would transpire to be the bane of this play-test.
The pitfalls had been coded in a way that the player, when walking over them, would take damage and be teleported to a specific spot, not the spot they had walked into the pitfall from, but just a random chosen spot E-Jay had picked. Not to throw shade on E-Jay, it was both of our mistakes, as my responsibility was to implement them, I should have tested them more thoroughly. The issue with this is that they behaved more like damaging portals than pitfalls. As well as that there was no delay on the damage or teleportation, the player would simply touch the hitbox and just be transported and hurt. This, combined with my tactless addition of making the hitboxes much wider than they should have been resulted in play-testers constantly running into the pitfalls, taking a lot of damage, and essentially immediately dying. Just in totality, the pitfalls were a failure whose only effect was causing the play-testers either annoyance or genuine anger. While myself and E-Jay found this rather humorous in the moment, we realized the pitfalls would have to be fundamentally changed, or at least heavily altered.
Another issue that arose, thankfully prior to the play-test, was the new enemy’s behaviour. The enemy was completely broken, the sprite of the enemy would disengage from the enemy itself and it would essentially turn invisible and track the player. This issue was so egregious and difficult to fix that we completely removed the enemy from the play-test.
Post Play-Test
There were also just general issues with how the new pitfall levels were laid out and just general gameplay issues and bugs. I created a list of everything wrong with the game that would have to be fixed:
- Need to fix not being able to move
- Enemies pick up health
- Complete tutorial
- Fix pitfalls
- Enemy delays
- Enemies should fire at different rates
- Fix pause screen
- Balancing needed
- Whatever direction you’re facing should allow you to dash in by just pressing space
- Should have some I frames during pitfall respawn
- Rearrange pitfalls
- Maybe add a minimap or just some way of keeping track of how many rooms you’ve gone through
- Enemy shouldn’t be able to attack when being attacked
- Speed up player attack
- Make the tutorial room more of a path, add invisible walls
- Tutorial movement glitch
- Player turns invisible when walking into pitfall
- Spike hitbox needs to be fixed
- Attack animation needs to change
- Fix the door
- Depression gate should be open when restarting
- Item should spawn in after death animation
- Add loading screen
- Ability to cancel attack by dashing
- Closed room is offset
- Pitfall does too much damage
- Player collider is a bit big?
- Main menu freezes
- Hitbox should be lower body
- Door doesn’t close every time in the rooms
- Fix pitfall dash invincibility problem
- Invisible walls
- Navigate menu with arrows and enter key
Feedback:
Rage inducing
Collision needs work
Enemy shoot slower, player move faster
People can tell where everything is, it’s clear
E-Jay and I got straight to work on fixing these issues after the play-test and were able to fix several things that day including preventing enemies from picking up health, adding a delay before enemies become aggressive, increasing player attack range, and tweaking the new enemy’s movement.
Reflection
Overall this week acted as a sort of wake-up call. I was reminded that I could not depend on all my groupmates and that there was quite a lot of work that was needed to be done on the game. I was left with a determination to try to fix the game’s current issues as quickly as possible so that our group may be able to move on and get back into adding in features. I realized I would need to assist in coding and just generally work beyond my prescribed role as I was determined that we had a finished product by our hand-in date.