Successful game development requires distilling your game down to a core experience and pinpointing the weaknesses in its design. That's why it's so important to identify and itemize the systems that comprise your core loop, and prototype them as soon as possible.
Dan Spaventa (lead game designer on the Game Insights team in Developer Relations at Roblox Corp.) has been thinking a lot about core loops lately, and shared his knowledge on the topic at the platform's Connect 2022 developer event.
What are core loops? Why is prototyping so essential? Spaventa laid out some key basic foundations of the game design process that will be help beginning developers establish the most important parts of their game, and test them as early in the design process as possible.
The core loop of a game can generally be described as its central conceit, the gameplay upon which the entire game is built. Fleshing out this core gameplay loop and testing it can help identify its weak links early in the process, and allow them to be addressed individually with minimal waste in terms of time and resources. If your core loop isn't fun, it doesn't matter how great your narrative or physics interaction or other features, if they are not having fun "minute to minute", they are going to drop off and stop playing.
Core loops, as Spaventa explains, can be broken down into the set of actions most repeated in the game. In RPGs, for example, this is roughly, "Explore, Fight, Upgrade". In the game baseball, it can be summarized as "Throw Ball to Pitcher, Field Ball, Return Ball to Pitcher". Breaking your game down into actions helps identify which ones may be the least entertaining to players, giving opportunity to address their design flaws. Often, those flaws are systems and features that compete for the attention of your players by conflicting with other goals or actions.
When new features are introduced, the question should be asked, how does that new system enhance a core loop? For each system you introduce, you "better have an answer as to which part of your core loop is going to be made better." And anything that stands in the way or bogs down the fun should be eliminated as early as possible.
Systems that directly conflict with that core loop interfere by dividing player's attention. Players, as Spaventa explains, do not split themselves evenly between competing systems in a core loop. If you have a system that competes with a central conceit of your game, you will find that players will gravitate more towards one than the other and in turn drive away players who were fond of the previous action.
Games live and die by how successfully they create a core loop and support it. Every system should be created specifically to support that core loop. If your core loop isn't fun, Spaventa warns, neither is your game.
Why should you prototype? As many developers have said, "finding the fun" is the most important part of the early game design process. Prototyping allows you to do this from the start, while allowing you to detect and address flaws and oversights, sparing you time and resources. It can also help with fine tuning before production.
Once you're ready to prototype, Spaventa suggests two ways to go about it. The first is to do so on paper, using whatever you may have around--gameplay pieces from other games, pieces of candy, whatever can be used as a stand-in for your ideas. The pros to this are that your prototype will be fast to create and easy to modify while giving you a wider view of your game. It's also good for UI and UX testing, which is key to game's playability, especially on mobile.
However, keep in mind that anything you build on paper won't be reusable and won't offer you the opportunity to test unique, video game-specific mechanics.
The second means is a studio prototype, a quick playable version of the game using its core mechanics but minimal art and other features. The pros of doing this include the early ability to identify technical issues that might arise (as some ideas can only be explored in direct context) as well as set a good pace for development.
There's also a greater chance the work can be re-used, as it's already implemented in a demo. The cons however are that it's a much smaller scope of testing and requires more time and resources to iterate.
What Should you Prototype?
Primarily, the core loop has to be prototyped. If nothing else, fleshing out your core loop gets your team on the same page in terms of goals and vision. UI and UX should also be tested, (on paper, in-person, so as to get the most organic feedback), along with any unique game mechanics that you may be unsure of, and your game rules (also on paper, as it will force you to answer key questions at a critical point in the design process).
Playtest Your Prototype
Spaventa finishes out the talk by identifying the most effective ways to test your prototype and get the most information out of it. As a game designer, you should iron out edge cases and ambiguous gameplay first. This will take a few cycles, he warns; your programmers and artists will be doing some of that initial work in R&D in the first few weeks, and your job is to address any ambiguity or questions that come up during this time.
Once you're in a good place, you can then playtest several sessions with your team. "Just because you might be the designer on the team doesn't mean you are the sole vision holder". It is critical that everyone on the team provide their feedback on what they think or want the game to be. It gives you a chance to keep everyone on the team happy by providing a middle ground for them to align with.
Once you and your team are confident about the prototype, you can test it in play sessions with your friends and supporters, who will often have valuable insight as first-time players and be able to identify further gaps in your gameplay.
And finally, iterate until you're truly happy with the final product--but don't dwell on your prototype too long. It doesn't need to be perfect, it just needs to demonstrate the bare bones of your game enough to test and refine.