What Makes a Game Well-Crafted?
On the "About" page for #inddev in>D:\development, I talk about our quest to deliver #WellCraftedGame experiences and accomplishing that by balancing gameplay, production value, and polish for the games we release.
I don't elaborate much there about the details of what this means, because I could ramble at such length the most patient of you would fall asleep!
Instead, I thought I might break up my thoughts on the topic over more bite-sized blog posts to expound on what I mean by a well-crafted game. For the first appetizer, here are some thoughts about each of those three aspects that I think need to be balanced for the best chance at a successful game. Note that not all successful games have all three of these; I'll even talk about one of my personal favorite exceptions when I muse about #Polish below!
Games Need Gameplay
Defining what makes a "game" is actually pretty hard.
I think Bernard Suits got pretty close by defining a game as "the voluntary attempt to overcome unnecessary obstacles", but I also think player agency, strategy, and entertainment all ought to be attached to those "attempts". The child's card "game" War fails to provide any agency - the winner is determined by the deck shuffle. Choose-your-own-adventure books may be interactive, but there are no rules for what may happen in a given choice at a story branch, so they fail to provide any strategy. Many gacha games subvert the degree to which player skill and strategy are forces in overcoming obstacles based on the luck and rarity of the MacGuffin draws, which in turn also subverts the entertainment for many players.
In the end, games need to have gameplay, and even if none of us can agree on exactly how to define it, I'm confident that we can all feel the difference when it's not there. I can really appreciate a great book or an excellent movie, but when I sit down to play a game, I'm after something with a different "soul".
I think idle games are a great place to see the distinction between soulful and soulless game play. (#futureblogpost) One of the most common criticisms I see of new, early-development idle games is that unfolding doesn't happen soon enough before players get bored of a non-interactive start. Idle games that are missing interesting unfolding mechanisms eventually fail, because if the players eventually "see through" all the mechanics, the game stops feeling entertaining and starts feeling like watching a clock run. The water clock in the Indianapolis children's museum is the most interesting clock I've ever seen, but watching that still only entertains me for about 15 or 20 minutes.
Managing the Medium
Every game has a medium in which its experience is conveyed. The range of these mediums is enormous, varying from abstract human imagination to concrete computer code to physical paraphernalia like dice and cards.
Properly tending the medium of play is an important aspect of developing a game. If a game relies on fair die rolls, then the die must be properly balanced. If a game relies on hidden card information, then the card backs can't have manufacturing flaws that act as a covert channel for the information on their fronts. In a game like Dungeons and Dragons where the medium is the imagination of the players, hundreds of pages of guidebooks and source material are available for players to learn how to cooperatively contribute to a cohesive, shared experience and suspension of disbelief.
In a video game, the medium of play is software, and that provides both advantages and challenges.
Games blend so many aspects of software development that theirs can be some of the most challenging code to write: algorithms, data structures, operating systems, networking, security, graphics, databases, asynchrony, and so on. Every game has production and quality control challenges, but this is especially true in this electronic medium. One small bug in a printed game might be as simple to fix as publishing an errata online for a particular game token. If that same bug causes an unchecked exception in a software implementation, it might halt the whole game.
Those kinds of errors are easier to address with good development practices, but this manifests at the architectural level, as well. Many aspects of software games, such as how to handle communication of multiplayer commands, can be handled in various ways with various tools, all of which are imperfect and have trade-offs between capability, complexity, and cost. Small independent studios like in>D:\dev are particularly challenged by this, since developers on these teams must be responsible for multiple specializations and have less time to devote to developing skills and toolset familiarity with each of them.
Promising Potential
The game market belongs to the players right now. Veritable armies of developers in small studios like this one to large teams at blockbuster studios are all trying to compete for the players' attention. The competition is so fierce that some truly amazing games are even genuinely free to play.
As a gamer 15-20 years ago, I would say that I would be interested in playing any game that was mechanically interesting in the genres I liked, even if the medium was stick-figure art held together with duct tape and bubble gum. That's not true anymore, for very practical reasons. It's not that I wouldn't still play a stick-figure art game. Dream Quest, for example, was amazing; it launched an entire niche genre of games, but it also exemplifies the modern problem: it was years before this game was widely recognized for its genius.
No, my problem as a player now is curation, because there are simply too many games coming out to keep up with them all, and it's hard to judge a low-effort work I wouldn't be interested in from Peter Whalen's amazing game that only looked low-effort. How do I solve that now? I do use the polish of a game as a heuristic. I would never play Dream Quest now without a really strong recommendation from someone else... which is exactly how I got into that game in the first place.
I don't want my games to lose any momentum from not being sufficiently polished. If the gameplay system is unique and fun, and if the production quality of the code is up-to-snuff, I don't want their contributions being leeched away because I fell down at the finish line. Perhaps once upon a time in gaming, this wasn't as important, and perhaps even now, a modern game might succeed on the basis of monumental contributions to the art like the one made by Whalen, but why stack the deck against myself? I think the right strategy is to accept that this is an important aspect of a successful development plan for a modern game, and earmark the effort accordingly.