First published on MSDN on Oct 13, 2015
The Big Idea: Plan deadline is coming up fast, and if you still haven't written your entry and submitted it, now is the time to sit down and start working! Today I'm going to go over the judging criteria for the Challenge, talk about what you need to do to win, and give some advice.
Don't forget to submit your projects from your
by October 28th at 23:59 GMT!
Let's go over
again, just like we did for Big Idea: Pitch.
The system is basically the same for all the Challenges: your entry will be reviewed by a team of judges, each of whom will score it on a number of different criteria, eventually generating a score from 0 to 100. You can review the specific criteria for the competition you've entered in the
If you don't cover one of the criteria, you'll get a 0 for that section, and that will really hurt your overall score. The best way to get as many points as possible is to cover every single one of the judging criteria.
Let's look at the three criteria sections more closely to see what you'll need to do.
In the concept phase, we're looking for the overall vision of your project. You've got plenty of room in your document to really get your ideas across, even if they're complex or highly original. Here's what we're interested in hearing about:
What is your project? Give us the full story of your idea. In the Big Idea: Pitch, we wanted something short and snappy. Here, we want to know more of the details.
What's the goal of your project? If you're not making a game, you'll need to cover the problem, need, or opportunity you're addressing, and how you plan to target it. We want to be convinced that your solution will actually address the problem or need.
Who are your target users? The more specific you get, the better. We've asked you to create 'user personas'; you can read more about the Persona concept in
John's guide to the Project Blueprint Challenge
. Personas will go a long way towards establishing your target market.
If you're making a game, you'll next be addressing Design. During this phase, we want to see that you've thought about the underlying game design issues, and you've got a plan. You don't have to give us a whole working prototype in your document, but you should at least cover the core system elements for your game.
Details. We want as many as you can provide in the space you have to work with. Is your game a puzzle game? Describe how the puzzles work, and give us an example puzzle. Is it a platformer? Explain some of the challenges the user will face. Is it an RPG? Tell us about the RPG mechanics. Is it a shooter? Describe the weapons and enemies.
Genre knowledge. If you're making a platformer, give us examples from games we've already played. Show us that you're experienced with the genre of game you're making. Tell us how your game compares to other similar games, and how it differs. If you're going to use the Diablo loot system, tell us that. If you're going to use the Bejeweled match-3 mechanic, tell us that.
More details. We want to see enough material in your game design to actually go out and implement the game. Imagine you're writing an instruction manual for a team of developers on the other side of the world. Could they implement your game with the detail you've provided?
If you're not making a game, your next task is to do some research. In this section, we want to know that you've investigated the problem you want to solve, or the need you want to address. This means going out and talking to people, reading real-world research, and giving us your findings.
Have you solicited early feedback? Go out and talk to people who are your target audience. Explain your ideas to them. Write down what they tell you, and use it to refine your ideas. Explore a wide variety of potential users, and find out what features they want, what features they need, and what features they hate.
If you're building a World Citizenship project, there's almost certainly research out there that's relevant to your idea. Making a health care app? Look for medical research that supports your plan. Building a tool for farmers? Look for agricultural research pertaining to your solution. For almost every problem you're thinking about solving, there's a research paper somewhere talking about that problem. Find them, read them, incorporate them into your plan, and cite your references so we can look at them, too.
Who are your competitors? Find all the other apps or solutions that address the same problem or the same market as your idea. Research them, explain them to us, and then tell us why your project is better, or what your project will do differently. There are very few markets that are totally unexplored; no matter how clever you are, there's someone out there doing the same thing. When you address them, you build credibility.
In this section, we want to be convinced that your project can really work. If you pitch a million-dollar game that will outperform World of Warcraft, we're going to be skeptical. You need to show us you've thought about the problems you might encounter, and show us you have a plan to address them.
How clear and useful are your user stories? If you need a refresher on user stories, head over to the
Project Blueprint Guide
. Your user stories should describe how your project will be used, and should refer back to your Personas. Be clear and concise; you don't need to write a novel, but the stories should cover all the major use cases for your project.
How will your project be funded? How will it generate revenue? Not every project is intended to make money, but every project should have a plan for the future. If you're using an Azure back-end, how will you pay for that in the long-term? Will you be selling your app, or offering it for free? Will there be in-app purchases? This is another place where you should do your research; what are your competitors charging for their apps? How large is your market? How much money do they typically spend on apps like yours?
What technology will you be using? Be specific and detailed, here; if your app requires a device with a camera, tell us that. If it requires additional hardware, explain the hardware requirements, and ideally provide links to examples of that hardware. Will you have a client/server model? If so, will your server software be hosted on Azure?
In a lot of ways, what we're asking for here is the same thing we wanted from Big Idea: Pitch. We just want more. More detail, more references, more research, more explanations. We're already excited about your project; now we want to translate that excitement into a plan of action. Show us that you know where you're going, and we'll follow you.