FLUX is a music rhythm game where players cruise down the streets of a retrofuturistic city on a motorcycle. Time key presses as you see fit and ride to your own rhythm by personalizing the game's music playlist. Players build up momentum by pressing one of the four arrow keys, triggering a cooldown that disables the key from being pressed again for a period of time, requiring the player to find a steady rhythm to maintain speed. There is no end to this road. Cruise along at your own pace, stop and go as you please and find your own rhythm. The end goal for this game is to allow players to simply chill, relax, and find a meditative state within the experience. For fans of 80s retro aesthetics, retro wave and cyberpunk themes this task will be easier to accomplish with Flux. Inspired by these components, the game mechanic is far from complete and will see a few iterations over the course of the next few weeks.
The goal was to make a prototype for a game concept that didn't have any challenge, allowed you to build and maintain momentum, and reach a state of Flow throughout the experience. To some degree I think I've accomplished that but with that validation also came a deluge of potential directions to take the project. So, what direction do I take?
Since I was able to create the game's mechanics and package it for testing, I went with my normal testing routine and put it in the hands of my students. I generally share my personal work updates on our Discord channel so students are aware of my goals and the progress I make. Coupled with a Google Form survey filled with general questions, bug reports and short answer questions, I was able to watch the players and their reactions to the game and get focused feedback in a short period of time. After, the completed forms allow me to quantify their responses with visual data and short answer responses.
One thing to note is how I phrased the questions in the survey. Instead of asking vague "on a scale of 1-10" questions, I opted to get short answer responses to begin a dialogue between myself and the tester. Often, it will be easier for someone to communicate more clearly through written word instead of discussing the matter in a group setting. It circumvents shyness or testers that may be more vocal than others. Requesting short answers about specific mechanics, like how I quizzed the players on "What are the game's controls? What do they do?" helps me see just how clear my instruction is and how much I need to convey to the player through a more subtle design methodology. I stray away from "Hit A to Jump" tutorial messages as often as I can, but if players simply aren't getting it I need to set that aside for the greater good.
Despite a brief discussion with the group after the test implying that Flow wasn't quite achieved, the written responses before that discussion said otherwise. 80% reported reaching a state of total focus, aided by the music and momentum they were building. The other 20% reported that they did not attain a sense of Flow but one of those cited that their audio wouldn't work. Considering the importance of blending both audio and visual stimulus to generate complete focus, I think this was understandable.
All of the responses both written and in-person favored the art style and choice of music. All of the responses also suggested introducing objectives, more impact with movement and key input, jumping or flipping, more backgrounds and obstacles.
I've found that the lack of challenge in the game is engaging on an experiential level. The audio and visual stimulus is enough to create a compelling experience, but I feel like I can take this concept further and create prolonged engagement. A reward, some form of build up, and a general sense of progression could elevate the experience even further without deviating from my original goals. Moving forward, the key here is going to involve taking momentum and its build-up even further to introduce a series of "leveling up" moments as players cruise along, earning something as time goes on.
Based on this feedback and my own considerations, future changes include:
- Removing the current 40-50 momentum limit and reducing the overall acceleration speed (at 100 the scrolling background is lightning fast, which is awesome, but hardly memory-friendly)
- Balancing that sense of momentum and testing new input mechanics like a global cooldown (one key will trigger cooldowns for all keys) or key combos (left, right, left, right in a timely manner will provide some form of score, score boost or visual stimulus)
- Juicy Particles based on player input, like light that streams from the wheels or building facades that light up the faster you go
- Updated environment art to include more randomization, variation and movement during both idle and mobile moments
- Additional backgrounds like a ride along a coastal beach, a tour down a rainy cityscape, and more!
- Musical feedback on key presses, fitting the general theme and allowing for some level of player involvement in the creation of the game's musical experience
FLUX has already been a fun experiment. Taking a break from Axis Descending development gives me an opportunity to explore new territory, acknowledge the skills I have, and build on the skills I'd like to develop further. All of my testers found the look and feel of the game to be captivating. They enjoyed the music, character, backgrounds and interface and simply wanted more. As always, I will continue to create new playable builds and share them with all of you. I'm fortunate to be a part of a community of students and professionals that provide critical feedback on a regular basis. Without that, I simply cannot validate my own design choices as a solo developer.
If you'd like to give it a go yourself, click the image below or click here to download it!
No comments:
Post a Comment