Fidget Spinner RPG Interview

Ever heard of Fidget Spinners? Those tiny, amusing spinning toys? And I'm guessing you're no stranger to RPGs. But guess what? There's actually a Fidget Spinner RPG on Steam.

Bryce Summer is the sole developer behind Fidget Spinner RPG. In this interview, we delve into his unique journey as a developer, gaining valuable insights and knowledge about game development along the way.

Tell me about yourself. What is your background aside from game development? What are your hobbies? What aspects of your life are you aware of that have made an impact on your game development process or on the creation of Fidget Spinner RPG (FSRPG)?

I’ve been a solo indie developer since my teens, now 31. Apart from games, I enjoy origami, Arduino/robotics, and music. I cover all aspects of game dev, from coding to design. FSRPG began as a browser MMO in 2018, evolving through iterations. While not multiplayer now, I hope to explore that later.

My personal struggles with mental health affect update consistency. But my commitment to FSRPG’s long-term growth remains unwavering.

I started coding at 12 via Second Life’s scripting. Adobe Flash led to my first game, Assembler, in 2008. I learned Unity post-Flash era.

The thrill of sharing new creations with the world, regardless of reception, is my favorite aspect of game development

What are your preferred games? Do you manage all projects alone? Is solo development crucial for your artistic process? How much time did it take from age 12 to release Assembler?

My all-time favorite game has to be Portal 2. However, I’m into games spanning various genres: from Skyrim and Call of Duty to Runescape and beyond. I’m open to trying anything new! 😄 While I sometimes purchase third-party assets for my projects when it’s pragmatic, I handle everything else on my own. Even when I use third-party assets, I prefer giving them my unique touch through modifications. Assembler was launched when I was 16—a physics puzzle game involving stacking shapes to guide a green box to its destination.

For those interested, Assembler can be found on Kongregate: Assembler on Kongregate, though it necessitates the deprecated Flash plugin.

I find enjoyment in working solo because it grants me complete authority over the final outcome and allows me to work on my own timetable.

How much do you believe you’ve improved since the release of Assembler, which was around 15 years ago?

Haha, Assembler was a concoction of spaghetti code intertwined with blurry JPEGs, lacking even some fundamental features that should have been there. From a technical perspective, I’d confidently say I’ve made substantial progress since then. However, design-wise, Assembler was, in my opinion, thoughtfully crafted—the gameplay boasted an elegantly simple quality. I managed to capture that essence quite early in the process.

In your view, what would you say is your primary role or strongest specialization? Are you more focused on game design or programming?

Determining my primary role or most robust specialization is an intriguing consideration. While I engage in various aspects of game development, my main forte lies in programming. However, I’d also assert that I have a strong affinity for game design. These two components synergize, enabling me to bring my creative visions to life efficiently and effectively.

How did you approach the design of Assembler? Could you share your process and how you developed the concept?
What games were you drawn to when you were 12 years old?

When I embarked on my first game, I explored numerous concepts before landing on Assembler. The simplicity of Assembler, which contributed to its success, was partially driven by my relatively limited skill set at the time. Given my learning curve and the skills I lacked, I had to improvise. Surprisingly, these skill gaps inadvertently steered me toward more thoughtful design, if that makes sense. At the age of 12, I held a deep fondness for The Legend of Zelda series, embracing all its iterations.

Your first game comes across as quite well put together right from the start. Could you share how long you spent working on it before you released it?

I’d say the whole process from conceptualizing the idea to the first release of Assembler took around a year or so. I continued to iterate on it even after the initial release, resulting in several sequels and even a mobile version (though the mobile version requires the deprecated Adobe AIR for Android plugin). Additionally, I’ve got a few ideas in the back of my mind that I might want to revisit in the future, whenever I find a break from all the fidget spinning!

Compared to Assembler, Fidget Spinner RPG started with lofty ambitions that required some scaling down along the way. Given the ambitious nature of creating an MMORPG, were you initially confident that such a complex project would work out as planned?

Drawing that comparison is quite fitting! When I released the initial multiplayer version of FSMMO on Kongregate, I recognized the challenges inherent in achieving my ultimate vision for the game. Back then, I couldn’t have foreseen that I’d still be working on it nearly five years later and still some distance from that original vision.

In the initial stages, development of the game’s multiplayer aspects proceeded quite well. At one point, I even conducted a basic stress test with around ten thousand simulated clients actively engaging in abilities and interactions. Features like a chat system, auction house, and in-game feedback mechanism were implemented—a rather engaging setup. However, as I ventured to scale these components to a fully-fledged game, I came to realize the necessity of tempering some of my grand ambitions.

Do you think your experience as a developer played a role in making that decision? Did you ever consider abandoning the project during this process?

There were moments when I found myself frustrated by the issues in the prototype, leading me to set it aside on a few occasions before revisiting it. I even went so far as to restart everything from scratch at least twice. However, my determination to persevere remained unwavering throughout these challenges.

What factors fueled your determination to persist? Were there other game concepts that tempted your attention during this period?

I had a solid vision of what the game could be and knew that it could be successful if I could get it there, that was the carrot on a stick for the whole process. I also had a handful of beta testers playing it and that helped me stay motivated too.

I did have and still do have other ideas that are alluring, but I’m focused on getting FSRPG out of early access before I touch anything else. It’s a promise I’ve made to myself, and the game isn’t far off from being at that point.

How did you go about recruiting beta testers for your game? And once you had them, what strategies did you use to keep them engaged and involved in the testing process?

Initially, my beta testers comprised Patrons from my Patreon community, in addition to friends and family. Once I had a build on Steam and could distribute beta keys, I reached out through social media to find interested testers. Sustaining a solid tester base is crucial, and the key is to make them feel integral to the development process.

To maintain their engagement, I prioritize involving them actively. This includes incorporating their ideas and feedback whenever feasible. In cases where certain feedback isn’t implementable, I engage in open discussions to explain why or offer alternative solutions. By fostering this sense of partnership and showing that their input is valued, testers who are passionate or intrigued by the project continue to find satisfaction in their involvement. This not only maintains their commitment but also continues to yield valuable testing insights.

Do you have any advice or tips for fellow developers who might be struggling with completing their games?

When offering advice to developers grappling with completing their games, I’d suggest maintaining a comprehensive to-do list. This list can be as simple as a text document or more sophisticated using productivity tools. Break down the list into smaller tasks, encompassing bug fixes, identifying issues, and correcting errors in the UI or code. Likewise, include larger tasks like implementing new gameplay systems or devising solutions for intricate challenges.

Consistently strive to check off at least one minor task daily, alongside making some degree of progress on a bigger task. Recognize that productivity levels may vary, and that’s perfectly okay. The key is to advance toward your goal, and the satisfaction of crossing items off your list can sustain your focus. Personally, I often find starting a task to be the toughest hurdle. To overcome this, I begin with something from the easier section of my list, which often leads to finishing additional tasks as well.

Additionally, it’s crucial to recognize that game development is a marathon, not a sprint. While it’s tempting to ride the wave of productivity until you exhaust yourself, this approach can lead to burnout. I’ve personally experienced instances where overworking led to a state of aversion to a project due to prolonged, intense effort. Consequently, it’s imperative to pause and take breaks before reaching such a point. Although it might seem counterintuitive, incorporating smaller breaks within your work schedule can ultimately yield more sustained productivity, as opposed to short bursts followed by extended downtime due to burnout.

Awesome advice! How many hours a day do you usually work? Do you measure your work time?

The number of hours I dedicate to game development per day tends to vary quite a bit. I don’t meticulously track the exact hours, but I do keep a general estimate in mind. Some days, I might invest only an hour or two, while on others, I can find myself immersed for 12 hours or more. I aim to maintain an average of around 6 to 8 hours a day.

The flexibility of working from home has its pros and cons. It can blur the boundaries between work and personal time. However, it also allows me to tailor my work hours to my own natural rhythm of productivity and relaxation. This lifestyle might not suit everyone, but it aligns well with my preferences and needs.

Are you familiar with the idle/incremental genre? Have you played any games within this genre? Could you share your thoughts on the genre as a whole?

Absolutely, I’ve had the opportunity to play a few idle/incremental games myself. Notably, titles like “Cookie Clicker,” “Adventure Capitalist,” and a few smaller ones, though their names elude me at the moment.

Before I started working on FSRPG, I didn’t pay much attention to idle games. Initially, I considered them as a somewhat frivolous way to pass time. However, my perspective has since evolved. The genre is more intricate than I initially thought. Idle games can be vehicles for optimization, challenging players to identify the most efficient path within a predefined set of rules. Much like other games, the gameplay hinges on the choices you make. While more action-oriented games might involve moment-to-moment decisions, incremental/idle games spread those choices over an extended period.

The genre also encompasses the concept of having a clear objective and gradually progressing toward it. This process offers a slow, consistent release of dopamine as players observe their numbers grow larger. Many are quick to dismiss idle games as trivial, a sentiment I shared initially. However, I’ve come to realize that these games can possess greater depth than they appear. Well-designed idle games involve meaningful choices, strategic thinking, and ultimately a sense of enjoyment. When executed effectively, they stand as a valid and engaging genre, on par with any other.

Do you have a preferred game within the genre? Did the genre impact the design of Fidget Spinner RPG? Would you classify it as a game belonging to this genre?

My favorite idle game that I’ve enjoyed is Cookie Clicker. The genre did influence certain design choices I made in Fidget Spinner RPG (FSRPG). For instance, the concept of having RPM (revolutions per minute) as essentially infinite, along with the crafting proficiency system. In FSRPG, crafting items gradually enhances your skill at making them, leading to improved subsequent crafts. Additionally, I drew inspiration from the genre by implementing automated item filters. These allow players to specify desired item traits, making it easier to swiftly discard items that don’t meet their criteria.

Certainly, FSRPG resides within the idle game genre. However, it does possess a slightly more active gameplay element compared to some other games in the same genre. The incorporation of features like talent trees, skills, experience points, loot, set bonuses, and an action bar also draws inspiration from traditional RPG games, enhancing the overall gaming experience.

What motivated you to release Fidget Spinner RPG on Steam? Are you familiar with your competitors or similar products in the market? Currently, do you view your game as successful? And how do you differentiate between its current success and commercial success?

Unity’s HTML5 performance can be limited, and I found that the game exhibited better performance as a standalone .exe. This allowed me to incorporate more visual enhancements and features. Naturally, I opted to distribute the game as a native application, with Steam being the logical choice. While there are other fidget spinner idle games available, including a few on Steam, I believe my game distinguishes itself through its polished presentation, intricate mechanics, and visual quality.

At present, I do perceive the game as successful. Its potential for significant success hinges on the forthcoming non-early-access launch. The feedback and reviews have been highly positive, and the sales figures have been encouraging. Regarding commercial success, I view it as a component of the broader picture. I’d even venture to say that financial success alone doesn’t necessarily define a game’s overall success.

How do you personally define success, particularly in the context of game development?
For me, the primary gauge of success for my games revolves around reviews and ratings, along with the level of engagement from players. If users are actively providing feedback, even if the ratings aren’t stellar, I still consider that a success. It indicates that there’s potential for improvement, and with some effort on my part, the game could reach a more successful state.

While I do aspire for commercial success, it isn’t my utmost priority. My motivations in game development extend beyond financial gain. It’s the creative design process and the sense of accomplishment when a project is completed and embraced by players that drive me. There’s a certain “Christmas morning” sensation associated with that moment.

Ultimately, my happiness stems from pursuing what I love – crafting games and sharing them with the world. Success, to me, translates to fulfilling my creative aspirations. Monetary gains, while important, come second to maintaining that passion and drive. I believe that if I were to lose that enthusiasm, it would lead to a personal sense of failure.

The game features a rapid pace of unlocking features and upgrades, along with offering players a wide degree of choice in focusing on different aspects. Was this design approach present from the project’s inception? What inspired you to adopt this gameplay design?

I’ve aimed to strike a balance between maintaining player interest, offering choices, and preventing overwhelming complexity. My goal has been to create an engaging experience without inundating players with an abundance of new elements. As I mentioned earlier, I perceive idle games as experiences centered around optimization. The journey toward optimization becomes more engaging when the optimal path isn’t entirely transparent and presents challenges along the way.

Rather than focusing on a specific upgrade path as the sole optimal choice, I prefer to approach it as providing players with a sandbox of interconnected game mechanics. This allows players to discover their unique optimal pathway by experimenting with the rules. I view it as an opportunity for players to uncover their optimal strategies, potentially even ones I hadn’t anticipated during development. This approach fosters a sense of discovery and personalization, contributing to a more engaging gameplay experience.

How do you feel about your decision to opt for early access? Could you share the frequency of your updates during this period? Do you have any advice for effectively managing player expectations? Were there any particular challenges you faced, or aspects you would handle differently in hindsight?

Certainly, the early access phase has been a positive experience for me. The game has undergone significant development since its initial early access release, largely due to the invaluable feedback from an expanding player base. Concerning updates, I’ve typically aimed for a major feature update every 3 to 5 months, complemented by a series of smaller bug fixes and quality-of-life enhancements in between.

When it comes to managing expectations, a key approach I’ve found effective is listening to players and acting upon their feedback. This fosters a noticeable connection with the player community, resulting in increased feedback, improved reviews, and overall game development alignment with player desires. This positive cycle contributes to meeting or even surpassing expectations.

The early access journey proceeded quite smoothly for me, with no regrets or major adjustments in hindsight. Perhaps, if anything, initiating the store page a bit earlier in the process to accumulate more wishlists before the early access launch could have been beneficial. This strategy might help generate more interest and anticipation before the game becomes accessible in its early access form.

Given your role as a solo developer, what approach do you follow to test your early access updates? How do you ensure thorough testing to identify any potential issues or glitches in the game?

In terms of testing, I employ automated tests that I execute before each build to detect potential bugs. These tests involve simulating player actions, such as crafting an item, and validating that the outcomes match expectations. However, automated testing has its limitations. Therefore, I’ve also established a public experimental branch that operates independently from the primary live build. This allows players to opt into experimental builds to access new features ahead of time, with the understanding that these builds might contain more bugs.

If you were to offer three key pieces of advice to fellow developers, what would they be?

For Designers: Prioritize making significant changes when adjusting game balance. When aspects of balance don’t feel right, opt for substantial adjustments rather than incremental ones. Don’t hesitate to double or halve values like enemy health to gauge their impact on gameplay. These big changes offer clearer insights into the overall impact and expedite finding the right balance.

For Programmers: Focus on code readability during the early stages, deferring performance optimization. Emphasize clear and maintainable code over premature performance enhancements. It’s common for performance assumptions to be inaccurate, and early optimizations can lead to complexities that hinder future development. Wait until your code is largely feature-complete before delving into performance tuning.

Lastly: Involve friends and family in early playtesting. Observe silently as they navigate your game, noting any moments of confusion or struggle. Pay attention to their actions when they encounter obstacles. These fresh perspectives can unveil potential issues you might have missed. As development progresses, seek honest feedback from a broader audience, including those who won’t hesitate to provide constructive criticism due to their proximity to you.