Arenalchemy - Playtesting and Postmortem

Project Post Mortem Blog Post:

Arenalchemy was an eye opening experience for everyone on our small student dev team. Our team consists of: Caleb, our lead programmer who was in charge of the bulk of scripting including player and enemy movement etc. Lily, our sprite artist who was in charge of creating and implementing various assets and animations etc. Jorge, who was in charge of UI/UX design and implementation as well as sound track composition. And Ankie, our environment artist who was in charge of creating and implementing assets for our procedurally generated map. In the end, even despite difficulties regarding version control, scoping and time management, we were able to properly communicate, collaborate and come together to create a finished product. In this devlog we will reflect on some development postmortem thoughts.

Our initial plan for “Arenalchemy'' was rather ambitious. However, students often encounter issues with proper scoping for large class projects- we as game designers come up with these elaborate stories or ideas we wish to convey that do not account very well for the time period for development and the other commitments members will have. So, in terms of changes from the initial plan, most of our changes would fall into the category of simplification of things, such as player abilities or enemy NPC complexity. We had to cut many enemy ideas and the scope of abilities we wanted our player to have. However, as simple as it may sound, we did it. We were able to create a charming game that met all requirements, and had fun doing it.

If anything went wrong with the project, it would largely just fall into the "too much to do and not enough time" category, but another BIG recurring issue would be that SOMETIMES 3D box colliders would be accidentally applied to objects and this would cause a huge loss of time consistently due to the inherent assumption that issues with OnTrigger logic were probably due to the script. In other words, something to build on is DOUBLE checking objects in the inspector before going insane. Additionally, it may or may not be obvious, but there is an inherent delay to the SFX at times due to for some reason during audio exportation and importation later on a few seconds of silence would be added to the SFX at the start of the clip, and due to randomization of the pitch in Unity the clip could be delayed (because pitch and speed of the clip are directly related in Unity).

Looking back on the project, we can say that fortunately, there is not really anything we would qualify that we would do differently other than better project scoping. As we mentioned previously, reasonably accounting for availability during a project work period is a bit of a struggle. If we could have one more week of development, rather than adding anything new, we would likely focus on refinement of what exists at the moment. Perhaps adding sprite flipping, as well.

Below we will be attaching some feedback documentation given by our playtesters that we will use as takeaways for future projects and possible future iterations of Arenalchemy.

Playtest Feedback

Playtested by: Team Gigahuman (Miles Anderson)

• Was able to figure out how to play (had to double check)
• Enemy behavior seems pretty simple
  • Good for just starting out
• Surprised at the first death
• High and low hit sfx make the game a little confusing
  • Was able to get used to it
    • Would have been better if the pitches were consistent to the associated action (player, enemy, attack, etc.)
  • Thinks the timing might be a little off (slow/behind the actual action)
  • Was not clear which cues belonged to the enemy or the player
• Wondered what the lights were for
• Was able to identify that the game is a roguelike
• Thinks that the flashlight radius should be adjusted
  • Larger so that the player can see where they’re going
  • Would run into the enemies unintentionally
• The goal of the game wasn’t clearly stated within gameplay.
  • Would have helped if there was a cutscene or UI scene that explain the goal of the game and basic controls
• Overall, concluded that it is a good concept for a roguelike

Playtested by: Troika Incorporated (Michael Quinn)

• Wondered if the controls were WASD were because arrow controls didn’t work
• Was confused bc the credits menu was not voiced over like the trailer was
• Forgot the controls after reading them
• Thought the lights were collectable
• Wanted the sprite to flip based on direction
• Was not able to figure out how to shoot
• Was not able to determine the goal/objective
  • Clues from the trailer was the only clue
• Thinks that the music should be more adventurous instead of explorative
  • More tense and fast paced
  • Thinks that we should add lore/more substance to help frame the game and give players motivation.
  • Likes the random sound effects
• Indicate what rooms do what/add variants

Playtest Takeaways

After conducting the playtests, we learned that it is really important to provide a space that can be accessed within gameplay that detailed player controls (i.e. in the pause menu; alt. Have an entire tutorial). The first major hurdle that playtesters encountered was remembering the controls/not knowing them at all. The only way they were able to figure it out was that we used very common controls for a game.

Another thing we learned was that context and motivation should have been more clear. The second most encountered feedback was that there wasn’t a clear reason the player had to be running around in the dungeon shooting old ghosts.

Finally, we learned that the game-player feedback was too confusing. As much fun as our original SFX were, their variation in pitch being more consistent would’ve helped the player identify which sounds were coming from the enemy and which sounds were coming from the player character.

Overall, our team learned that we need to more effectively communicate the intended player experience to our players through game to player feedback and direct instruction.