Albertus's Potion Quest
A unique approach to the classic “Match 3” game genre. This project was part of a requirement for a graduate degree minor in Digital Media: Game Design.
-
Responsibilities:
- Game mechanics
- UX/UI
- Coding -
Challenges:
- Limited coding experience.
- Very short development cycle.
- Tardy team member contributions. -
Tools & Software:
- Adobe Photoshop
- Game Maker Studio 2 -
Duration:
- 10 Weeks
Design ProcesS
>
>
>
Design ProcesS
Brainstorming & Planning
Keep the game simple (10-week dev cycle).
Incorporate color into mechanics.
It should be designed for mobile devices.
Find other games from which to draw inspiration.
Determine individual team member responsibilities.
Create a design document and pitch.
Create a timeline to adhere to project milestones.
Game CREATION Agenda:
Game Concept & Pitch
The team decided on a “Match 3” game with an 8-bit pixel art style.
Puzzle Quest and Potion Explosion inspired the additional game mechanics.
A project design document detailing the story, wireframes, mechanics, team member responsibilities, and concept artwork was created.
A short game pitch presentation was given.
Document & Presentation
GAME DEVELOPMENT & PLAYTESTING
GAME Development
Game Maker Studio 2 was chosen as the development platform due to its onboarding and ease of use.
Three development cycles were set as milestones: Alpha Release, Beta Release, and Final Release.
A playtesting questionnaire was developed for player feedback during each phase.
Alpha Release
Beta Release
Final Release
GAME MECHANICS
“The Grid” - The core of the game where players “Match 3” (or more).
The Time - The level is completed by reducing enemy HP to zero before time runs out.
The HP - Albertus and his enemies have HP that should increase or decrease depending on what potion mechanic is performed.
The Mixing - The potion mixing mechanic for mixing potions for additional abilities."
Skulls - Matching skulls will reduce the players’ HP, requiring them to be mindful of what they match in the grid.
PLAYTESTING
Each iteration (Alpha, Beta, and Final) was sent to all testers along with a follow-up survey to give feedback about their experiences playing the game. The following prompts were given in each survey:
In your own words, please describe what you liked about the game.
In your own words, please describe what you did not like about the game.
In your own words, please describe any problems you had with the game. This can include observations about something that didn't work, something that didn't work as you expected, or anything you think was a "technical problem."
What, if anything, would you change about the game's difficulty?
Please give us any other feedback, comments, questions, or concerns.
FINAL RELEASE
last-minute FINISHING TOUCHES
Game Intro Screen/Menu.
Two types of gameplay: Story Mode and Continuous Play.
In-game game instruction manual (How to Play).
Game Over screen.
Game Finished screen.
HP Adjustments for abilities, enemies, and Albertus.
final Deliverables
A mock video advertisement and final game development slide deck were presented.
Compiled binaries were distributed to other teams for in-class gameplay, followed by in-person peer player feedback.
The final design document and development blog were submitted.
REFLECTIONS & FEEDBACK
APQ was a great idea; we have a solid foundation for a good game. The game concept and execution, despite having bugs, have a pleasant interaction and are easy to understand as you progress. There are a lot of changes that we could have added to make this a better game, both coding and artistic-wise.
Looking Back
It might feel more engaging if the game included consistent animation and art styles.
We could not implement something we imagined, such as an Enemy AI, a more fine-tuned grid, and visual indications of damage dealt, as we did not have a strong enough development team.
Downsides
Adding more abilities and indicating what's happening to Albertus and his enemies.
More realistic animation to essentially make players more invested in the game and the story.
We were tackling the coding issues we faced with more knowledge of game development.
Feedback & Suggestions
Swiping “too fast” will cause the game to crash. The grid must perform its calculations before receiving the next match, so swipe, ensure the match runs, and wait for the grid to update (new potions fall) before swiping again.
The grid does not solve itself – meaning that if a match three is in a horizontal or vertical position, it won’t solve until a new swipe is made.