Hi im new to game development but not new to 3d graphics, animating.. Etc

Would this plan work?

Basically i want to create kind of 3rd person fighting game.

Would it work if i ignored the programming part at first and created every single 3d model, texture, logo etc (every visual thing) where all i have to do left is like

Ok (making this by programming / unreal engine blue prints) let this be my main character, and let those be the ai enemy, and let this be the weapon i have to pick up

Etc.

Not really. Design the large-scale things, then start implementing as you go.

If you try designing everything to the smallest detail, it's very likely you'll encounter something when you code it up that makes you go "Huh, this didn't really work at all as I had thought. I'll need to change this and everything related to it".

Have a plan, then create small tasks (say 1-2 weeks of work), then implement as much as you can. After the task is done, look at where you are and create new tasks. Repeat until done.

Games are never made that way. It's an iterative process.

How do you even know what final art you want if you haven't tested your core mechanics and verified which actions you find fun? It's literally impossible to make all your assets up front without a finished design, and it's impossible to make a finished design without playtesting, and it's impossible to playtest without working code. And it's impossible to finish code without a finished design, or to determine the limits of the design or code imposed by art, etc.

You have to work in iterations of minimally-viable stages. e.g. you know for phase 1 that you need the core fighting mechanics working in an engine, you need to know what those core mechanics should be, and you need some test art to see what you're doing. Then you can playtest, make sure you like the core loop. Then improve the code with the next phase of features (combos, or whatever), design those features, and implement art to visualize them and UI. etc.

There's a reason why "real" games are made by dozens or hundreds (sometimes over a thousand) people over the course of several years.

There's a reason why "real" games are made by dozens or hundreds (sometimes over a thousand) people over the course of several years.

And it's the same reason that some games just aren't that good/fun.

It's not that the game wasn't meant to be bad, it's just not as easy as writing "and here there's going to be an awesome battle with a dragon capable of destroying villages with its awesome fiery breath".

Thanks for your explanations

Do you guys have a link with an explanation of the stages i have to go through

Like the correct steps organization so i don't fall into errors or problems?

There are a couple things here.

First, unless this is something you have done multiple times it is something YOU CANNOT PREDICT. No matter what systems and modules you think you need up front, YOU WILL BE WRONG.

So plan for that. Think about the general systems you know you will need, plan for them as parts of the whole, and call it good enough for now. When you need something more from one of those systems, add it. When it does too much, split it. If it gets to complex, simplify it.

If you have experience in the systems you can guide the growth into common patterns, but if you don't have the experience it is unrealistic to guess too much in the details.

Don't worry, you aren't alone here. Many people --- including experienced developers and project managers --- get confused about the level of planning to do.

This is an area of Agile development that people hotly debate. The Agile Manifesto includes among the values: "We value ... Responding to Change over Following a Plan"

I interpret this to mean we should all make our own plans, but we should begin with a solid understand of the goal.

In a more real-world example, I might give the overall goal "Be at the wedding reception on 8:30 on Thursday, 123 Maple Street." As the organizer I do not make plans such as driving directions, outfits to wear, or time to leave their locations. Instead I trust that the individuals involved can make their own planning as needed to reach those goals.

Perhaps a group of people may discuss a carpool and have their own pickup times. They may give a bit of buffer for traffic knowing they want to arrive by 8:10, so work backward for the times saying we pick up Bob at 8:00, Joe at 7:50, and Fred at 7:45. Then they work backward for how long it takes each person to get ready, and so forth. Each group attending the event can make their own plans, allowing enough time in their own schedules to accomplish the clear goals.

For software, you should know what it is you are trying to build. You should know where you want to go, when you want to get there. Then you can work backward to the things you know you will need. Allow enough time for unexpected elements, and build up the schedule as best you can to accomplish your clear goals. If you don't have enough experience to know what those items are, then finding out those things should be your first set of tasks.

There is no best plan, no universal template of what to build and schedules to build them with, just like there are no universal plans to get to 123 Maple Street by 8:30. Some people travel north, others travel south; some travel on trains, airplanes, cars, or simply walk. Whatever plan you build and path you follow should be unique to you. My plan for me almost certainly won't work for you.

Before you start. I recommend reading this article