Reflections: Telepathic CATastrophe

I have many thoughts, but for now I want to reflect on the game I recently submitted for class: Telepathic CATastrophe.

After about two weeks of constant work, I am simultaneously satisfied and dissatisfied with the game I’ve created. When I finally submitted it with an hour to spare (which is a bit too close to the deadline for my tastes), I felt relieved. I felt I had created something worth playing, something really fun. After doing numerous playtests, I addressed the concerns of the players and even added things in areas I felt were lacking. However, as soon as I let other people play the finished project, I noticed multiple glaring flaws. Since then, my game has not sat with me well. It could be that I am just experiencing impostor syndrome, especially after watching the professors gush over simpler and very well-made games in class, but I don’t think my disappointment at my game is very unfounded. So, as a practice, I want to do what we had to when reporting on the playtests we did: listing what worked and what needed to work.

What Worked:

• The concept was spectacular. Players all expressed joy at destroying various objects, especially when feedback was implemented. I believe this is because, as a general rule, people like destroying things. In games, there are no consequences for destroying things; in fact, there’s usually a reward. There is just something satisfying about knocking over a lamp, and I feel the game handles that very well. This was because it was easy for players to destroy things, and the visual feedback was clear and immediate.
• The game was visually pleasing. I downloaded a lot of assets to save time, but the ones I chose worked well together. I will make a separate post reviewing these assets in case anyone wants to use them. I even made my own art for the GUI. My art was not as polished as I would have liked, but I feel it was cute and good for the time I had to make it.

What Needed to Work:

• The game was not at all polished. Well, it was to a point. However, there is a major problem when I realize after it was submitted that I misspelled the title. Between that and the sound-bugs, I am very upset with myself. These little mistakes happened because I rushed myself, in part because of my poor time management. In order to avoid such mistakes, I will be sticking to a stricter schedule when it comes to my work. Pushing it to the deadline, especially when I knew I was not going to have much time, was a major mistake that I will work to prevent from occurring again.
• The game somehow became a horror game. This was, ironically, a result of my trying to make players aware of the humanoid AI wandering the environment. This problem actually is a product of an even larger problem: The game did not have enough iterations of playtesting, or the playtesting was done at the wrong times. I am fully aware of how important playtesting is for creating a good game. However, I did not playtest at the right times, and I only playtested after two major iterations. As a result, I was aware of what needed to be fixed, but did not have proof that my solutions worked. As a programmer, I know very well how necessary it is to constantly test projects. I should have gone through more iterations more quickly as to playtest them as opposed to having larger groups playtest at once. This is definitely a mistake I will not be making twice. I will go through iterations faster, starting sooner and working on major parts first. As soon as it is playable, I will have at least one if not two playtesters. After, I will go onto the next iteration, refining what was already there and adding more content.

Those were the major points that I wanted to touch on. Clearly, I need to improve my time management. I have other subjects I want to reflect on, but that can wait until a later date.