Well there are a lot of factors. This is coming from my mindset as an independent developer, not a massive company where they get a budget assigned.
A lot of new developers fall into the trap of thinking what they like is what others will like, which isn't necessarily the case. First you need to research if your idea has a lot of competition, and analyse that competition. Play their games, examine their style of graphics, read their reviews to find what players are looking for or enjoying, etc. You also then need to determine the market, if it's flooded with similar games your idea will have a much harder time of standing out.
Once you've worked out if it's feasible as a genre, you need to determine what will make your game different, you cannot just make a 100% clone, you need something people will enjoy more or want to try that's a bit different. Once you nail an idea, you need to determine if you can handle developing it all yourself or what other team members you'll need, what sorts of expenditure you're looking at - audio/visual assets, writers, level design, social media manager/s or moderators, advertising allowance, engine license (see below), etc.
If you've plotted that all out and you think your expenditures minus the engine license costs are within your budget and that the game will have a decent chance of standing out amongst the competition, then you determine what engine you'll write it in (or if you're like myself and some others, if you're planning a series of games, you might make your own engine to handle each iteration). Each has strengths and weaknesses to determine, as well as different licensing which plays into your budget determination. Then you'll have an overall idea of your budget, marketability, and idea and whether they'll all work.
That's all part of a feasibility study. Once you've determined all that, if it's feasible to run as a project, then design starts.
You need to conceptualise all aspects before you code, else you're going to repeat a LOT of work and lose a lot of time. GUI storyboarding and prototyping, visual asset concept art, story planning, game logic flow, all of that occurs in this stage of the project. You should aim to start this stage from earlier parts of your game, with the menu design, UI flow and some initial visual assets and writing as a focus. Level and audio design work well hand-in-hand and should be done together while others are working on the aforementioned aspects.
Then comes level prototyping. It's time to throw your assets into a playable level prototype, sort of a 'demonstration ground' of your assets and mechanics. Keep in mind that this is the first part of your development stage, so it should just focus on one single level with demonstrations of mechanics, as menus and options can be handled progressively throughout the project fairly easily. This is NOT a game prototype, just a level prototype so you can test mechanics and assets. Getting a feel for how your levels will flow and how they will play will help to give the rest of your project direction. Start with basic assets, even some primitives, and focus on object movement, interaction, collision and other basic mechanics of your game (as an example, gravity is kind of important). Much like the prior step, this will help you iron out mechanical wrinkles in the play style before the bulk of development ever starts. The last thing you want is to get 50% into your game and realise some mechanics feel clunky and have to rewind and lose time.
Once your level and mechanics prototype starts to gel in a way that feels quite fun, get some unbiased (non-involved) people to test how it flows. Preferably people who have played games before, as they'll be more indicative of the people you'll attract. Don't get your 87-year old grandmother to play your FPS concept.
Then the rest becomes more iterative. With your basic mechanics sorted, and a working prototype level, you'll have an idea of how to approach other aspects of your game. Now you can hit design and development heavily, following the logic and flow you've decided will work, testing levels and functionality along the way, with new assets each iteration. There will always be times when creative direction changes a little, or you decide to scrap certain mechanics after having had them tested repeatedly but receiving average or uncertain feedback. But for the most part, this stage should be about following an iterative loop similar to:
- use design concepts to create a level storyboard
- use design concepts to create asset prototypes
- create a new prototype level using existing mechanics
- test prototype level flow
- add new design assets to prototype
- retest prototype level flow
If you plan on flashy skills and effects, those are what I call 'bonus' mechanics, as to me they're not really a core mechanic of the game, they're what helps set your game apart. As an example, if you can have an epic 8-hit combo skill with effects generated but still cannot move a character, your priorities have been backwards since there's no real gameplay. When you've created enough levels to get a good chunk of gameplay developed, then you should consider splitting a quarter or so of your time on conceptualising some skills and creating the assets for them (animations, particle systems, etc). That way you know your core gameplay loop is solid, the game itself is playable and feels fun, it's just about more aesthetic polish now or adding some fun bonus mechanics.
Happy reading! If you're really interested, why not give Unity a go? It's pretty approachable to newcomers and is quite powerful, it'll let you get your feet wet while learning along the way.