It happens all the time near the end of the independent and student game development cycle: your original design gets cut down to its basic premise due to a lack of time or coding resources necessary to embellish on it. Or you get all your designs in the game but lack the opportunity to test and tune them for balance, so all those complex systems you implemented are either ignored or unexplained, and either way, serve only to frustrate the player.
You can plan better or try to arrange for testing resources well ahead of time, but it's very likely that this will continue to a problem due to inexperience of the team and upcoming deadlines (on student projects), or growing lack of interest and motivation (on indie projects especially, but frequently student projects as well). Polish is difficult and time consuming, and even most commercial games don't get it right. When you're a passion-driven team of first-timers, it's nearly impossible.
So, although you should plan and budget time for polish in your project and make every effort to squeeze it in, your best bet is to plan for this eventuality ahead of time. This approach to design is about building your game around "guaranteed fun" -- using mechanics that are fun at their most basic implementation. It doesn't mean copying other proven designs, and in fact student and independent games should be doing the opposite, as discussed later.
Rather, finding guaranteed fun and therefore mitigating production risk is about identifying the elements of designs that hook a player immediately and require little resources or polish to execute well. If you succeed, you can work on your project knowing that whatever product you end up with (even half-finished) will be compelling. And at the final stages of development, you'll have the luxury of being able to choose whether to stick with what you have or add other mechanics, instead of still desperately trying to find the fun in the last few weeks before production ends.
This requires some work up front, with a willingness to be pragmatic and shoot down good ideas that you know carry too much risk in the scope of your project, but it can save you a lot of headaches when your deadline approaches. Your goal in this process is to get great gameplay right out of the gate, that doesn't need too much tweaking to be fun. With that in mind, the rest of this article will aid you in picking a design that leaps off the screen and impresses in the first pass (maybe even leaving time for polish!).
Get in the Right Frame of Mind
Before even thinking about what sort of game you want to make, you should identify your goals. If this is a student project, are you trying to showcase some particular aspect of yourself or your team, like art or design? Are you trying to win IGF? Knowing your goals for the game helps frame your design and identify risky design decisions immediately, from difficulty curve to input scheme.
From there, you can brainstorm like crazy, but don't get too attached to any single idea. Any worthwhile designer has tons of ideas anyway, and must be capable of identifying and building on good ones from other people. Explore promising avenues and abandon them when they don't seem to be working out. Planning and brainstorming like this takes very little time relative to the rest of the project, but has such a huge impact that there's no excuse for not making the most of it. Be sure to get a very wide pool of potential designs, and think long and hard about production risk before picking one.
All of this should be standard for making any game, but establishing a good process like this gets you in the right frame of mind to think realistically. This is important because you don't want to pick the design that could make the best game in an ideal world, but rather you must go with the design that strikes the best balance between what is fun and what is feasible with the available time and resources. Coming up with (and culling) ideas is the cheapest part of game development, whether it's 100 people or one, and so deserves mention as an easy way to minimize risk up front.
With some concepts in mind, you need to evaluate their feasibility from the usual perspectives, with art and programming time being the obvious ones that come to mind. But evaluating design risk is always a bit more nebulous and hard to nail down. The key is to focus on "guaranteed fun" -- designs that, even if not implemented to their fullest possibility will still result in an enjoyable, memorable game. All of the specific mechanics that guarantee a certain amount of fun, some examples of which will be given in detail below, can usually be generalized as:
The first two points relate specifically to minimizing the amount of gameplay testing required to make your game fun. It's difficult to make a deep game with lots of interactions between systems if you don't have time to test and balance them, so you need to make sure your basic mechanic is the game's big selling point and it works on its own. You can also save yourself a lot of time by keeping your controls simple from the start to reduce the amount of changes you'll make down the line, as refinements to control schemes can typically only come from lots of testing - which means time you may not have.
Death Worm - Rock solid concept and mechanic that's immediately entertaining.
The third point, however, should be in your mind from the moment you sit down and start brainstorming your concept. There are surely some great games to be made that are wonderfully nuanced with multi-layered stories to tell, but to maximize your chance of success, everything about your game needs to make an immediate impact. Subtlety takes resources and, more importantly, requires polish to succeed, and when it fails it fails in the worst possible way for any design mechanic to fail - it hides crucial information, meaning, or content from the player.
Guaranteed Fun Example: Think Big
In a way, the fact that indie and student games are invariably shorter than most commercial products works to your advantage: you can pull off big and crazy gameplay without having to find ways to sustain it or continually top yourself over 8+ hours. You can always plan for adding greater depth, but your first priority should be ensuring that the game is fun at its most basic level. Whenever you think of a gameplay concept, your first thought should be "How can I make this as impressive as possible?"
For example, let's say you have an idea for a brawler where you walk down the street and beat up thugs. This could be a fun game with a complex block and counter system that rewards players for really learning the system, and maybe you could even put together a great system on paper during pre-production. But if all you end up implementing are the basics - one punch, one kick, and a block that reduces damage, or if you implement more systems but don't have time to balance them, the game will be pretty forgettable.
So instead of being a normal guy fighting a street gang, you can make your game's protagonist into a super-powered spirit of vengeance, battling hundreds of goons at once, with each megaton punch sending a dozen of them flying 50 feet into the air. You could still design some interesting and complex mechanics to add greater depth, but if all you end up implementing is the basics (which likely have about the same cost in programming time as the above), you'll still end up with a pretty fun game.
Thinking big shouldn't just apply to the player's abilities; you should try to make every aspect of the game as big as you can. You can even create grand and epic environments without blowing your budget if you're careful. The key is to start with a layout in mind (preferably with a lot of verticality), or a shape, rather than a specific look or locale. Don't get stuck on details, because the goal should be to make the overall feel of the space impressive, and that comes more from planning and design ahead of time rather than hours of toil in Photoshop and Max. If you're willing to make sacrifices, focus on the big picture, and use some repetition in the models and textures, you can find a way to make impressive environments with limited resources.
Other Examples of Guaranteed Fun
So whatever you do, you will need to choose game mechanics that work and delight from the moment they're implemented. Obviously there are too many factors for any gameplay to be a truly "guaranteed" hit (you're rarely going to get by with sub-standard implementation), but here are some examples of mechanics that have a great track record while requiring relatively little balancing or tweaking:
Swarms of Enemies: As in the above example, this is a great way to immediately create a fun and frenzied game. If you're making a 2D game, it's especially easy to throw hundreds of enemies at players at once without affecting performance.
Geometry Wars - Screen full of enemies = fun.
Super Powers: Again, as seen above, this is a great way to give that "big" feeling relatively cheaply. Don't have your character throw rocks at enemies; throw trucks instead. If other games let you jump 5 feet in the air, your game should let you jump 100 feet.
Platforming: Although this mechanic is almost as old as video games themselves, it has recently become a template on which to deconstruct the entire medium. If your goals are to explore interactive narratives or showcase your art, platforming is a great mechanic to build off of that is naturally fun. It's also an excellent jumping-off point for experimenting with other, more unusual gameplay elements (see Braid, Don't Look Back, and countless other indie examples).
Arcade-Style Progression: High difficulty can be a great motivating tool for certain types of players, and the play-until-you-die approach of old-school arcade games guarantees a challenge for all as players of different skill levels set goals for themselves. This takes some of the balancing duties off your hands, but it's still important to make sure that players experience the core of what your game has to offer before it gets too hard. Luckily, you don't have to be subtle about it; just pick a tipping point at which the game should start getting difficult and let the challenge increase from there.
No Middle or End Required: Another advantage of an arcade-style game is that they easily do away with expectations of a traditional narrative structure. Any time you try to tell a story with a beginning, middle, and end (especially an explicit one with text and/or voice acting), there's a good chance that one of those sections is going to get cut, or implemented only weakly. For minimal risk, you should focus resources on highlighting your game mechanics instead of the narrative. The "premise" should be fun enough to be the whole.
Player Creativity: Any mechanic where players feel like they're actually creating something usually has instant appeal, even when it's something as simple as Line Rider. Giving players tools to play with rather than just a couple of levels to blow through also automatically increases depth and extends the life of the game as players create gameplay for themselves.
Visceral Theme: Not a mechanic per se but a dressing for one, having an impactful and satisfying theme behind the gameplay can add to a game's fun factor immensely. AdultSwim.com's games do this to great effect, re-engineering old game mechanics with new and amusing motifs. One way to pick a successful theme is to make sure that the results of a player's interactions are physical and immediate rather than abstract.
Violence is the most common example, and virtually guarantees this: even a match-3 game could be made about punching people in the face, and it would be more memorable and fun than matching geometric shapes. But there's more to physicality than just violence, of course. Zuma seems like a very abstract concept, but they made it very clear that it's a game about shooting weighty little balls at each other, and that visceral quality adds to the fun. When it comes to implementation, sound is key here, to the point where it's almost worth making sure you have the right audio files before settling on your design.
Zuma - Surprisingly visceral.
Keep in mind that this is only one method of development, tailored specifically to reduce risk in a short development cycle where polish is a luxury. Dedicated teams with plenty of time at their disposal can afford to play with their game balance, subtlety, and deep mechanics. But it's nearly impossible to get accurate time estimates from inexperienced developers -- proper game project management is an art form that takes years of experience to develop.
On indie and student games it's very unlikely that you'll have someone with that sort of skill set at your disposal (at least not managing you day to day). Immediately fun, basic mechanics ensure that you'll have something to be proud of at the end of development, and may even give you the flexibility to consider a proper polishing phase.
Of course, there are countless other mechanics out there that can be fun without a lot of polish necessary, and you should innovate whenever possible rather than picking your gameplay from a list of known successes. In fact, depending on your goals, it's quite risky not to innovate if you want your little game to stand out. But when you have a design in mind, you should compare it to mechanics like these and see if it holds up in terms being easy to implement and immediately entertaining. Happy developing!