How do you plan how to make a game?

Danimal The more I learn about the pipeline of making a game, the more I realize the little I know.

A feeling that will never go away, so better get used to it.

Have you made a small game before? Like, nothing fancy, Tetris or Super Mario Bros or something like that. If not then you should do that first.

As for tools: Krita is pretty good.

Danimal i suggest start by making components, test them first, test your abilities to do stuff.. if youre a knob like me, who has pretty much no bg in education, programming, high maths, skills, money, then i suggest you try out your luck by training to make what your dream game would need..

Imagine, how would you start to make a game, what game needs in order to function?

Main menu?
What kind of options would you want user to change? How do i change settings in game and make changes on the user pc accordingly.

Networking? How to create multiplayer game? Lobby system? Ranking system? How to calculate stuff in order to assign rank based on properties?

Controls? What controls? How to create control bindings for user to change on the fly?

How to save game? Load game? Persistent user data.

After you got the hang of how to use the godot tool, to solve these essential problems, then you would start exploring the game mechanics, because many times you will find yourself re-writing whole code base because you structured the game code in such way that it needs to be re-written in order for something to work as you want it to work.

Examples would be inventory system, minecraft mechanics for placing blocks, generating procedural worlds etc..

After you got the hang of how to create the things you want in your game, you could start looking at the visual/art style aspect. Learning the tools like Blender and other tools to create the things you want

And then you get it all together and you have yourself a game.

This is how i see and how i approach my workflow.

Its important that you record your doings, create simple example projects that deals with certain problem with a solution. Clean up that code, for later use. Otherwise when you get to the point of implementing some feature and looking back you wont remember how things worked unless you have left yourself clues.

OFc the most important is having a clear vision of what you want and you have to know/see (minds eye) how the game should look/feel/play. Without that youre like a blind man at an orgy.

Working in teams could increase productivity and thus getting to your result faster. But working alone you have to divide your time and focus on tasks you can achieve and know how to achieve. Fly fishing is not productive, and then you will lose motivation and energy to move forward and will get stuck in a vicious loop of, Im a failure, nobody loves me, die.

As for software, there was a thread
https://godotforums.org/d/28944-free-software-for-content-creation

Danimal i Hate single player, because the "AI" is still not human like and very predictable, and it feels like you just wasting your time and ther is not much variety..

Also you can have great narratives in multiplayer games too.. portal2, grounded, it takes 2... and its much more fun playing with something that is unpredictable..

And be sure to mix up the template to the point its unrecognizable, otherwise it will have that "unity asset flip" feel.

First of all, planning? I think most indie game devs don't plan. The smart ones just try to actually finish something small- closest thing imho I see as at least decent planning (for unpaid work hehe).
You don't need some master class tutorial. Ask AI to break down the project for you if need be, then take some small bites out of it. The first few steps will be painful.
Actually, go ahead and write down the completion steps if you're new. That'll at least help you realize early on how much work even a small game takes.
As a programmer, when I plan I am mainly thinking about how the code will interconnect so I can write the least amount required as I go.

Here's the best advice I can give:
Something happens on the screen Rinse and repeat baby
Tiny game YES! Make lots!
Small game DANGER! DANGER!
Medium sized game Never

I've got a couple of different angles on your first bullet about writing things down: firstly, as a first time indie dev, and secondly working at a studio for hire, where we predominantly help AAA games build out their multiplayer and live services.

From the indie angle, I did various experiments, decided on what I was going to tackle and then I wrote a 2-page conceptual design doc. Definitely not a full GDD, but enough to get me started, and once I'd worked out various things, I then proceeded to a) develop in Godot, and b) write a full GDD.

While I know docs are often frowned upon, for me the conceptual and GDD docs kept me on the path, and stopped me from running off in all manner of directions, which would've been fun, but would've elongated development.

In the AAA side, I've seen everything under the sun from shelves of design docs, through to absolutely nothing. My takeaway from that is docs clearly aren't always necessary, although usually having your core ideas, design and plans written out helps a lot.

Danimal That depends on the players tastes and game genre (I´m a single player supporter); it also add lots of complications, makes the scope way bigger and gives the game a "caducity date", which is when you can´t find anyone else to play with. There migh be bots with the very same defect you exposed to prolong it´s life, but creating a multiplayer game with players 10 years later is impossible for most indie developers. While a single player game can be enjoyed 20-30 years later without any problem.
Thanks for the teamplate tip, will do.

you dont have to create mmo multiplayer game, just have an option to play with people - coop/pve pvp.. there are plenty games that incorporated this. and they are still playable years later..

kuligs2 Well, you don't just flip a switch and your game magically supports multiplayer. Depending on your game MP support adds a bloody lot of hassle and complications and you can't just slap it on later but ideally know it going into it. And ultimately you have to judge if all of that is worth it and I'd say: for most indie games the answer is a clear "hell no". Unless of course you want to make a real MP game like Among Us, but a MP mode for let's say The Talos Principle, Spelunky, Hades, Disco Elysium or Stardew Valley wouldn't add much to the experience or make sense or be something that a lot of people would play. That time is better spend elsewhere.

kuligs2 Exactly, there are games like Left 4 Dead, Overcooked, and Rocket League offer multiplayer experiences and remain popular over the years so you can just incorporate these modes into your game

Honestly, I've had to learn as I go. The horror title I've been working on has taken a while. But I've gotten a "flow" to it that works for me, especially in Godot. It boils down to three steps in this order.

• Make it work
• Make it work better
• Make it pretty

To go in more detail, make your "core loop" first. All games revolve around this. Graphics, you have to see, are window dressing for what code is saying. It's easy to get those somewhere. For instance, if I were making a shooter, I would make a little test arena, make code for my player walking around and make sure that "core system" works first. In my horror game, I made my main player and enemy first and built a "skeleton" of the world before even starting eventing and such.

Then, once the code is doing what I want it to do, then I optimize. Does this bullet need to move faster? Are the controls sticky? Does it feel good? How is the camera handling? Optimizing is easier when you have something working and know what it should do and what it should not do.

Worry about making it pretty later on. There are tons of artists out there who can help or will sell you assets. It's much easier to drop something in later when it's all functional, especially on the graphic/sound side. And by that time, you should know your system/code so well that you're less likely to break something if you add a feature.

I realize I am an amateur and this is MASSIVELY watering down this process (bug testing, loading optimization, etc) but it's what works for me.