Doing something for the first time is always the hardest.
Hence no amount of planning can trully prepare the developer for a solution to the problem.
Planing/Design is a very subjective thing.
Sometimes just writing prototype code to see if a design works, can lead to understanding the problem better.
Rather than having talks with people of what could be and what not.
Correct. This is why almost all internships do diagrams and charts rather then pure coding.
This is contrary to my experience. Certainly I was working on the codebase from the start in all of my own internships. Most other people I've talked to also worked on the code during their internships and only used diagrams as prototyping or documentation aids. Maybe this depends on the company, but every place I've worked has preferred that I use my skills to actually write code and accomplish things rather than play with diagrams all day.
1 great programmer can not program nearly as good as a 100 moderately good programmers working as a team.
I don't think those are really comparable and I'm not sure I see what you're getting at beyond the obvious (more people = more man-hours). Sometimes you neither have nor need 100 moderately good programmers to do something and happen to have a great programmer on hand; would you advocate dropping the great programmer and hiring 100 moderately good programmers? Plus, those 100 moderately good programmers could have trouble communicating with each other, leading to much lost productivity. There is such a thing as too many cooks in the kitchen and adding more people beyond a certain point does not automatically mean more actual work being done.
I would much rather work with the person that needs the flow chart and communicates well with me than someone who is too good for anyone else.
The bold text is what I think is the real issue. You want to work with someone who thinks like you. But do you really need the flow chart or diagram if the person can explain an architecture or algorithm to you without it? Is a programmer who can explain how the code works without a diagram really "too good for anyone else?" After all, ultimately a flow chart or diagram is just a tool we use to communicate with each other. There are other ways of communicating ideas.
I personally prefer games without story, because if there is a story i will simply want to complete it as quickly as possible, since i see completion of the story as the goal. Although the story might be enjoyable and make the game last longer, it tends to feel like a grind of sorts too, taking so long to complete.
Maybe it would help if i didnt have such an important role in the story, such that my own actions dont drive the story but merely direct it or similiar.
Also story based games seem limited to me, while more sandbox/pure gameplay ones usually are somewhat neverending. So id rather play a game where the focus is on the non-story part.
That'd be interesting, a game where there is a proper story which you are part of, but you really don't have much impact how it turns out. You're a general who wins all his battles but you still lose the war, etc - like real life in other words!
The "Silent Hunter" series' career mode worked a little bit like this. In SH3 for instance you played as the Germans. No matter how many ships you sank, WWII would still end with a victory for the Allies.
Oh man, I remember 4e4. My (unfinished) entry was my first reasonably complex project, also an RTS. Good times.
The real-time strategy genre is still my favourite genre. Some friends and I still play old-school RTSs in our spare time. Age of Empires, Age of Mythology, and StarCraft are the main ones I play, but I know some people who still bring out WarCraft III occasionally. So yes, there are still people out there playing those sorts of games, but I think whether there would be a market for a new one would depend greatly on how well the game could distinguish itself from its predecessors without straying too far from the familiar gameplay that RTS players like me love.