Programmin, Coding, without going crazy, how do you do?

[Santiago]

Hello, I have a conceptual query. 

It happens to me, when working with large projects, that there comes a time when however tidy everything is, there is a complex system of functions, files, modes, methods, variables, which is difficult to be aware of everything you have done.

The amount of files and functions that I have are many.

one to update the menu, another to create it, another to delete it, another to load the data of the pilots, another to modify them, another to save, another to the data of the planes, create, delete, pilots, humans, etc etc etc .

And to all that, we must add the fact of when one should and in what way one should do those steps. since order is crucial for things to work.

I use notebooks, with diagrams, texts, programs, excel, Trello, even so, there comes a time when one gets a little lost due to the complexity that all this adds up to.

The other day, cleaning and putting the code in order, I decided to make a flow chart of the game, and it's endless and complex ...

so if I am working non-stop, I get used to quilombo, but if I stopped working for a few days, it takes me a while to go back and understand everything I did before.

my question is, how do you do?

[Skaven]

the way we do it on large projects is usually to do everything modular
so say for example youre making a game
then you would have the rendering engine as a completely separate project/module/library
the menu system would be a separate thing
and sound system a separate thing
etc. etc.
so you work with only the logic and problems for that library and do not worry about anything else
then when youre done with a library you do not look back at it and just expect it to work going forward
when you have your libraries done you can then focus on the final project and only have to worry about the logic behind that

it also helps to use something like github and work on things in branches that you eventually marge to the main branch
github also keeps tracks of your issues and you can have your wiki where things are explained in detail
for large projects today where you work with multiple people this is almost a must
so it helps if your integrated development environment has github support like visual studio code does

what i personally struggle with is motivation as i find it very hard to work on something for months without having something to show for it

[3DzForMe]

Don't do it for a living And a hobby, my big10p 😁

[grindalf]

I use B3D and the way I do it is once I'm finished making a specific section of code(menu for instance) I turn it into an include file that goes into a separate folder and then I can just forget about it. Occasionally I need to reopen these Includes to make modifications and then I normally have to take a while to read through and see how I was doing things.
It keeps my main code simple(at least it looks simple to look at)
Plus the good thing with this is I can change a system by writing a new file and then just switch the include command line for testing changes

[STEVIE G]

I never really use includes myself as unless you're working with a detailed spec, rather than winging it you'll invariably have to go back to certain functions. I always use a consistent naming convention and group functions by name, GAME, MENU,  PLAYER, SOUND, MUSIC, OPTIONS etc and most have an init, reset and update variants. If you use a good IDE then all functions sit nice and neat and are easy to maintain.  I also use alot of constants and store all global vars in a global Game type (the poor mans option  explicit) to keep everything nice and neat. I have OCD when it comes to programming in terms of neatness and structure so I always find it painless to manage current code and pickup older code when I stick to these rules.

Like you I also have spreadsheets with ideas, calculations, to do lists and loads of squared and lined pads filled with menu structures, program flow and lots of scribbles, some of which I can't read 10 mins after I've written them.   

[cpsmith0191]

All good advice, as I started out in electronics I try to stick to the black box concept (I think Skaven was referring to this).
I try to keep all functions to a screens worth or less and sprinkle with many a rem (\\ etc) but frequently fail.
The biggest problem I face is with the game loop where I keep adding functionality on the fly. IE not thinking of the need for such functionality at the concept stage.
Maybe the old system of concept, algorythem, flow chart, before coding has value? as opposed to 'that's an interesting idea, lets code..'
I'm an novice who thinks code is only limited by ambition, Have fun cps.

[gosukiwi]

the way we do it on large projects is usually to do everything modular
so say for example youre making a game
then you would have the rendering engine as a completely separate project/module/library
the menu system would be a separate thing
and sound system a separate thing
etc. etc.
so you work with only the logic and problems for that library and do not worry about anything else
then when youre done with a library you do not look back at it and just expect it to work going forward
when you have your libraries done you can then focus on the final project and only have to worry about the logic behind that

it also helps to use something like github and work on things in branches that you eventually marge to the main branch
github also keeps tracks of your issues and you can have your wiki where things are explained in detail
for large projects today where you work with multiple people this is almost a must
so it helps if your integrated development environment has github support like visual studio code does

what i personally struggle with is motivation as i find it very hard to work on something for months without having something to show for it

That is a great answer

Try to make small modules, each doing one thing, and try to communicate between them as little as possible, also try for communication to be one-way when possible. There are whole books written on this topic, complexity, software architecture, design patterns and whatnot, but those basics can get you a long way.

Also, having automated testing helps a lot with mental sanity, so one change doesn't break some other random thing, but in gamedev, tests are not as common as in, say, webdev, so maybe you can skip that for now

Also, I'd say eventually learn about git, github and version control, it helps a lot working in a branch, and if something breaks too much, just drop it and start again.