I’ve been playing a bit of Minecraft lately. I remember playing it a long, long time ago at some early Alpha stage and thinking it was some kind of block building game with really crappy graphics. Not too interesting. However, the developers kept adding features and now it has become an addictive, amazing phenomenon…with really crappy graphics. Somehow that doesn’t seem to matter much.
So why is Minecraft so successful? It has evolved into much more than just a building game.
I think part of the answer is that it incorporates several different game styles. In the book “Challenges for Game Designers” they call these the “game core.” Here’s a list (comprehensive, I think, if my notes are correct) of different game cores, and how they are incorporated into Minecraft (specifically the Survival mode):
- Territorial Acquisition – as the player explores and builds, he claims a bit of the world and makes it safe to live in and carry out other activities.
- Spatial Reasoning (a la Tetris) – you need a good sense of geometry to build giant structures out of blocks that don’t all look like cubes. Some people even draft out their creations first in CAD programs.
- Survival (FPS) – when night falls, the monsters come out. You need a shelter, or some really great combat skills and a lot of arrows, to survive until dawn.
- Destruction – to create in Minecraft, first you need to destroy. The whole world is made up of blocks that can virtually all be collected and placed elsewhere. Sometimes players like to destroy their creations just for fun (or those of others on multi-player servers – this is called “griefing.”)
- Building – the main core of Minecraft, if we can call it that. Giant statues, working CPU’s, digital displays, railroads … lots of creativity out there.
- Collection – players collect different types of blocks and items. There are also special, hard-to-obtain items like music CDs that are part of a set.
- Chase / Evade – kind of similar to Survival. If you are without shelter and night falls, you had better start evading all those mobs!
- Prediction (a la Rock, Paper, Scissors) – this one is a little bit of a stretch, but predicting where specific minerals can be found deep in the earth could fall under this category.
- Trading – not a part of the single player game; might be present in multi-player. Not sure as I haven’t ventured there yet.
- Race to the End – not really present in the game, unless players want to race themselves. I have tried to see how far away from my home base I could explore into the unknown in a day’s time…guess that is kind of a race.
Making a game is easy. Well, at least compared to making a fun game. That’s a challenge.
This book is really a textbook used by the authors in their game design course. But it’s still useful and readable for hobbyist game designers.
I thought the first few chapters did a good job of decomposing games into their “atoms” – theme, mechanics, strategy, randomness, etc. The rest of the book was ok, but didn’t seem quite as useful.
Each chapter ends with a series of “challenges” – really homework assignments for the students in the authors’ classes. While they definitely could get the creative juices flowing, I wished there were more case studies of actual existing games. For an introductory text, I would rather learn about what makes specific games fun and worth playing rather than develop some crappy game prototypes of my own.
But then again, it seems like there really isn’t a set formula for “fun.” It’s even hard to evaluate your own creation…hard to grasp difficulty, balance, and fun without a lot of play testing.
I’ve been thinking a lot lately about game ideas and possible projects to explore. It’s become obvious to me that game creation can be very time consuming – especially for someone not in the game industry and pursuing projects on their own time. Also, the scope of a game (features, different windows, gui, required graphic / sound assets, …) can quickly mushroom when the game design moves from intial idea to detailed plan. A game idea may sound simple at first, but once you get down to figuring out exactly what each window will look like, and planning out what the user can actually do and what they will see, it is soon apparent that even simple games require a lot of planning and programming.
On the pygame website are hundreds of game projects posted there by pygame users/developers. Virtually all of them are in an unfinished state. I don’t necessarily think this is a bad thing (even unfinished games are good sources of ideas and code), but it is likely a testament to the difficulty of actually pulling together a fun, workable game.
So, all that said, I think that first and foremost, before any programming begins, it is crucial to have a solid game design. Ideally the entire game is planned out. At the very least, all of the user interface windows should be described and all gameplay features and interactions are thought out.
Focus on fun gameplay first. It would be unfortunate to spend a lot of time on a game only to find out that the concepts that seemed so perfect at first really don’t work well or provide a fun experience. Also, especially for a one-man game studio, 3D rendered worlds and the like are probably out of reach. Graphics will be simple; they are not going to draw people into your game like they may for blockbuster titles.
Try to do something that hasn’t been done before, but don’t be so different that your game is so unfamiliar that no one invests the time to try to figure the thing out. Maybe familiar genre + new setting, or new genre + familiar setting would be a good formula?
I suppose all this sounds like I am a wise old game designer giving you some advice…actually, all of this is for myself! Most of my game ideas don’t make it through the “fun” / “workability” tests, which I think helps save me a lot of time in the long run. I still try to keep the ideas in my head or down on paper (yes, I have a game design notebook where I jot down ideas…most bad), so maybe they can mature and reappear as really good ideas. This is where the creativity in game creation comes into play!
Meanwhile, I have been exploring some other Python projects. I added an “Other Projects” page for those, to separate them from the games. The projects I added are Smart Dots, discussed in a few posts from May, Receipt Whiz for tracking purchases, and Stock Tracker, my get-rich-quick scheme that proved unworkable…or did it?? 😉
Braid has been out on the PC for about a month now. (You can download a demo or buy the full version on Steam.) A lot of praise has been lavished on Braid since it was developed; I just got the chance to play it recently for the first time, and I must say it is great! It’s kind of like Mario Bros. with better graphics and music, but really it’s more of a puzzle game than a platformer. The all-important twist in Braid is that you can reverse time by holding down the Shift key. Such a simple sounding ability has vast gameplay ramifications! The solutions to many of the puzzles in the game, such as collecting some seemingly impossible-to-get puzzle piece, rely on you using some lateral thinking skills along with the time reversal ability. Sometimes I actually caught myself grinning and laughing out loud (for real) with gamer’s delight – the puzzles are simply that unique. Trust me, go download it and give it a try.
I think there are many things to learn about good game design from Braid. First of all, small, indie games can be great successes. Braid was created by (I believe) just two people. The watercolor-style, 2D graphics and orchestral sounding music are awesome, and they didn’t require a team of tens or hundreds of people to create as in some big name developer games. Not every game needs 3D models and photorealistic graphics.
Second is a comment on the gameplay. Braid takes an established, familiar genre (the platformer) and adds a simple twist (time reversal), which makes all the difference. There are no complex controls, but the gameplay is complex, and interesting, and fun! This underscores the need to have a solid gameplay foundation. On the Braid blog, you can read through the development history over the past few years. Many ideas were prototyped and thrown out before the final gameplay iteration was more or less created. Only then did work commence on making the game pretty and giving it polish. Gameplay first, then graphics/sound/whatever!