i've been an at least semi-successful indie game developer off and on for 35 years now.
the project should define the tools used, not the other way around. FIRST you decide what to build, THEN you decide which tools within your budget will get the job done most efficiently. So right off the bat, throw away that assumption that you'll want to use Unity. Once you figure out what to build, then yes, maybe unity will be the tool of choice. But you won't know until you've decided what to build.
As you know, for indie game developers, game design is everything, especially game design that can be sold!
the aspects of indie game design that are important are exactly the same as those that are important for a big studio making the same type of game. the number of employees has no effect on what's important for a good game. whatever makes a good game in general is whats important, to both indie and big studio alike.
It is problem of life or death, key point of divider whether wasting 6months~years of himself or few developers and thousand of money or successfully withdraw money big more than investment and time invested.
this is true of any game project. but design is just one aspect. a game needs good: market appeal, design, code, graphics, audio, game play mechanics, MARKETING, PR, etc. marketing and sales is almost as much work as building the darn thing in the first place!
I think All is up to [Game Design(Game planning)], isn't it? So what game should be maked? and can be maked? within few months?
what to build will define how much competition there is. as a general rule of thumb, for any game you choose, odds are there are 3 other indies / teams / studios somewhere working on a similar product. but many of those never get finished and released.
there are 2 basic strategies:
1. compete in a genre where you have little / no competition. this is usually easier. since there's no competition, you set the standard for minimum quality level necessary.
2. become the superior product in a genre that has competition. the competition's products already set the standard for minimum quality, and you must exceed that.
as to the specific type of game, first and foremost, it must be a gametype you're into. if its not, to you its "just another app" instead of a "cool game", and you should probably get into something like database or web development instead, as there's probably more money in it. Working on a gametype you like also helps keep you motivated to work for months/years with no pay.
i myself tend to build what i'd like to play that hasn't been made yet, or hasn't been done recently. IE has potential appeal and low/no competition.
once you have a game type in mind, then you do research online to determine popularity. usually, you'll have a few game types in mind. each should be evaluated for expected sales vs how much work it is to make. You want to go with the title with the best expected sales for a given amount of work (perhaps measured in months of development time).
"within a few months" may be a major design constraint. especially if you have to add in time for learning new skills. within a few months, an experienced dev might be able to do something like "angry birds" or perhaps one level of a AAA quality FPS game.
also, the time required to get a game to release state is more than just the time required to build it. You have to do things like installers, docs, etc. and then you have to market it. Actually, you should be marketing it from day one. Setting up websites with screenshots and blogs, etc, building "buzz" about the product. Just remember you're building a game, not a website.
you might build a simple game in about 3 months, take another month getting it to release state, then spend 3 months marketing after you release before the dollars start rolling in.
Or should I approach at business level, and get investors or funds, hiring game designer first? Yes this is maybe more good way, but, you know, getting funds is hardest way.
believe it or not, almost no game project has a dedicated "game designer". usually the designers are also the coders. sometimes they're the artists, and get a coder to work with them. the only famous title i can think of with a dedicated designer was Di-Katana. There, Romero (of ID fame) left ID, and setup his own studio. he designed the game, and others built it. As is usual in the case of game projects lead by a dedicated designer, it was the designer himself paying for everything upfront. As i recall, Romero blew something like 45-65 million dollars on dikatana. or maybe it was 4.5 to 6.5 mil.
getting funding will be difficult with no proven track record. it also tends to tie your hands creatively. you are no longer an independent entrepreneur and inventor, you are now just a "developer for hire" producing a specific hunk of code, graphics, and audio files that you've been contracted to create. and worse, if you fail, you're in debt to your investors as well (depending on the nature of the funding). On the other hand, you may have an idea for a cool new type of game (like tetris was when it first came out), and it may be popular enough to fund via kickstarter etc.
here's what i would do:
1. what do i like to play, and its not out there yet?
2. how long would it take to build?
3. might it be popular enough to be worth the time?
if seems popular enough to be worth it, do a simple version, release it, and see what happens.
if you can't think of a gametype with no competition, you expand the search:
1. what do i like to play, that's already out there, but they all suck, and "i could write something better than THIS!".
this is actually how i accidentally got into game development.
one night back in 1988, me and a buddy decided to download and check out Star Trek games. We downloaded 14 different games. All the same old top down sector quadrant thing that i was playing on the mainframe in high school back in 1979. EGA Trek was the best, as it featured 16 color text mode display ( ooh and ah! <g> ). that's when i said, "Man, i can write something better than THIS!". in six weeks i had. showed it to my friends. they said "looks cool! needs more explosions!" so i added more and better explosions. then i contacted the sysop of the biggest BBS at OSU about how to package it for downloading and sale. this was right about the time of wolf-3d. he recommended an approach similar to ID, some for free, and pay for the rest if you like it. so i made my zip file with docs, order form, etc, and posed it on the local BBSs. Someone downloaded it and re-uploaded it to AOL. it then became a top ten download on AOL (10,000+ copies downloaded the first week), checks started pouring in , in the mail, and just like that <snap>, i was making 60K a year as an indie game dev.
i only see 3 potential errors in you line of thought:
1. choosing unity before you've even chosen game type. forget about tools until you have a gametype. then let the tools fit the game.
2. a few months development time. probably not happening for anything that would make any kind of decent money. perhaps a remake of an old classic for a new platform, the way angry birds is "artillary for the iphone". almost any game that would fit this description would by definition have to be a casual game for casual gamers. mobile devices aren't really up to doing hard core games (take a look at age of empires or the sims on the nintendo 3ds). also, a hard core game just isn't happening in a few months. they're simply too big to build that fast.
3. hiring a designer and getting funding.
you should design it. if not, you should instead join an exiting team as a coder etc, if your not into design, just implementation. to be a really good gamedev, you should be a gamer first, a coder second, an artist 3rd, and a soundguy 4th. code, art, and audio are means to an end, its the game that matters. and gamers tend to make the best game designers, 'casue they don't get as distracted by stuff like cool graphics engine code, killer canned animations made in 3dsMAX, or getting the "WHOP WHOP WHOP" of chopper blades correct in a 3d audio environment when the chopper flys behind the player.
getting funding will require a good game idea. good enough for other people to bet their money on. and they bet not only on the idea, but your ability to deliver on time, on target, and on budget. from an investments point of view, you're a new company with no track record, and no killer product waiting in the wings. one would probably be better off buying EA stock.
figure out what you'd like to make most.
then evaluate it for potential sales vs development time. if it looks good, go for it.
if not, figure out your #2 choice and evaluate it.
repeat until you have a choice that seems worth pursuing. then pursue it with vigor, passion, and obsession.
once you decide on a game type, then choose the tools that will get the job done most efficiently, taking into account learning curve time based on your current skill set.
then rapid prototype your design to confirm that it works, is potentially cool, and therefore worth pursuing further. The first time i accidentally blew up my own hanger in Airships! with a 20Kg bomb, i knew i had a winner on my hands. OTOH, i have't touched Armies of Steel II (alpha version) in months, as it seems to be lacking something in the game play of the prototype (fog of war most likely). also, it has hard coded missions and balancing the Orders of Battle to be not too hard or easy is a very fine line. or perhaps the real time war game has evolved into the first person tank shooter, etc, and the older game type no longer has the same basic appeal, as user's tastes become more sophisticated.
once you get a rapid prototype that passes muster, then sit down and figure out exactly what will go into the game. this gives you the start of your todo list. every feature to be added, every bug to be fixed, every section of code to be tested, put it on the todo list. kill bugs first. your code should compile and run with no warnings, errors, or crashes in release mode build at all times.
remember, all programs start with something like:
void main()
{
}
any bugs in the program are ones you put into the code between the open and close squiggly brackets. that's a paraphrase from a lecture at CGDC'97 about writing bulletproof code.
keep working away at it. once you get to stable alpha stage, get some testers. only keep the ones that give good feedback. one can usually find a few fans of any given game type willing to beta test for a free copy of the final version. they tend to make good testers, as they fit the demographics of your "target user".
Once you get it whipped into shape, release.
marketing is a whole 'nother ball of wax.
development and marketing should really occur in parallel. with a web site for the product, and all the usual game website stuff: chat boards, screen shots, blogs, etc.
and nothing beats free PR. SIMtrek getting posted on AOL was free PR. i didn't even have an AOL account back then. Ironically, withing a few years, AOL gave me my own free forum on AOL.
I think the key to SIMTrek was two fold: first, it was a vastly superior product: a true 3D starship flight simulator - the first of its kind. mouse driven graphical user interface back when the OS was still DOS, and it TALKED! like a Cylon voice: "by your command" through the PC speaker. this was before sound cards. Second was the file description i wrote. you only get something like 100 characters to convince the user to DL your demo. i probably spent a week on those 3 or 4 sentences. The description got their attention, the quality got their dollars.
back in 2000, my CAVEMAN game made the local evening news here in washington dc as a last minute xmas gift idea. more free PR. it only took 24 hours to exceed my website bandwidth (about 2000 downloads). and my webhosting reseller was closed for xmas! took 3 days to get the site back up. but free PR is not something you can really make happen on your own. the key there is to "build a better mousetrap".
"build a better mousetrap, [TELL THE WORLD ABOUT IT], and the world will beat a path to your door."
note that if you make a game type with no real competition, by being the "only mousetrap", you are by definition also the "better mousetrap".
