11. Feedback!

Developing our own game always sounds fun (and usually it is), but along the long journey, it is crucial to ask for feedback because it is a common mistake to neglect that part and only realize the missing features or inconvenient controls/navigation when negative reviews start flooding our email address (I guess I've never published any game).

Usually, it is best to ask for multiple rounds of feedback during the development process, starting with the prototype. The prototype should be the bare bones of the project, with no fancy graphics, just the minimum necessary to showcase the game idea. If feedback from the prototype is positive, that's the green light to continue the project. If not, that's fine (usually the case), and it's time to go back to planning and try again.

But as a student, it's common to do the feedback session at the very end of the development process, and I don't want to be the one to stop the tradition. Even if I'm unable to fix every issue before the assignment deadline, the feedback is still useful and teaches me a lesson.

After building the game and creating a Google form, I received 13 (so far) feedback responses about the current version of the game, which isn't a prototype but isn't a finished game either; I would say it's a tech demo.

The first question was to rate performance because I personally can't test it on other computers, and it's crucial to address any performance issues (there's only a better computer at the uni, but that doesn't help).

Fortunately, the feedback is mostly positive, with either a solid 60FPS or slightly lower, which could be due to the participants' lower-specification computers. There are still available features and methods to optimize the game, such as LOD, baking lights, optimizing models, and using GPU instancing for foliage.

The second question is about how they like the basic enemies, which, personally, is the weakest part of the project so far.

Again, the feedback is mostly positive, but reworking the AI and cleaning up the enemy-related code is still a must priority in the future.

The third question is the same as the previous one but about the Plane Guard (Boss enemy).

Overall, the feedback is still good, but it's a mixed bag. The boss mechanics are rather time-wasting than engaging, which is the result of not having enough time to work on the final year project but still needing something to showcase.

The fourth question is about difficulty, and it shouldn't be too easy or too hard to play through, especially because it's a tutorial zone.

The result shows that the game is indeed on the harder end, so it might need to be revisited to make it easier, such as nerfing the enemy's damage, spreading them out more, or simply removing a few of them.

The fifth question is about the environment, and the developer was confident about this part.

The result is a mixed bag, but mostly positive. It's a subjective question, but even the developer knows that it's too empty at the moment and needs some additional work to make it more alive.

The last question was about the controls, which is really difficult to judge on your own as a developer. It might feel good for the developer, but as it showed, it wasn't the case for everyone.

The controls need a serious rework. The developer tried to implement the same key binds as the Elden Ring one, but it turned out that not every participant plays Souls games, and jumping with space is confusing, which is understandable.

The essay part of the questionnaire is varied, but to summarize it:

• The controls should be changed to something user-friendly.

• The boss's enemy is confusing or not engaging enough.

• The environment and overall visuality of the game are good.

• More content (weapons, enemies, areas) would be a good future addition.

Overall the feedback session was successful and gave an understandable outline of the current version of the project and luckily the majority of them are rather easy to fix.

Thanks for reading!

-Bence (Oliminor)