I guess I'll eventually have to learn toolchain files.
Note that this is abuse of toolchain files, normally those are just to specify a specific compiler and cross compile setup.
You could also do this straight in the CMake file. But I put it in toolchain files so I have it separated per target. For example, the android toolchain file sets up the android SDK if it cannot find it.
Mostly I don't know the best practices for low level stuff like makefiles, compiling and which files to include.
I want to link my open source Blokaroka against a physics engine thar is also open source, box2d but just how to organize it is boggling my mind. I like download and go: include every file in the build, but it seems a lot of open source people disagree.
The "standard" method is having your makefile just link to the libraries and assume they are there. More advanced systems like autotools (avoid it like the plague) and cmake can find libraries for you. And, offer enough other functions that you could actually download the libraries.
However, I choose to have this folder in my repository:
https://github.com/daid/SeriousProton2/tree/master/extlibsSources for the main libraries I use, except for SDL2. As most of those do not provide binary packages for windows, it's a hell to setup your dev environment otherwise.
Linux purists are against this. But who cares, it works, it's reliable, as you know what version you have, and it's easy to setup an development environment. No problems with "oh, you need version 2.4 and your package manger only supplies 2.3", or "your package manager installed version 3.5 which changed an API call and now your code no longer works" and the worst "the package manager does not have this package"
You won't make it into the debian package repository like this. But is that your goal? Most likely not. Seeing the question of this topic, "use what is easy, quick, and reliable".
I guess I would want a script for windows that downloads all the additional code and then generates the VS project file, that would be the best result.
CMake can do just that, it has a generator for visual studio projects.
Back on the main subject of this topic. "What methods help in making a game quickly". I have a few things in my engine that help. For example, in debug mode, sprite animation definition files get automatically reloaded if they are changed. So I don't need to quit&restart to see changes in things like animation frame order animation speed and other things. Just edit the file and save while the game is running.
https://github.com/daid/SeriousProton2/blob/master/src/graphics/spriteAnimation.cpp#L62Same goes for my GUI definition files, which you can setup with auto reloading:
https://github.com/daid/SeriousProton2/blob/master/src/graphics/gui/loader.cpp#L31(however, that contains some pretty hefty limitations at the moment)
Both allow for quick iterations. Which speeds things up. For example, yesterday I judged the size of a spritesheet wrong, it had 32x32 sprites instead of 16x16. So when I finally found the enemy that used that sprite it was messed up. Opening the data files, changing the size, save, and 30 seconds later I could see it was looking proper now. But the animation speed needed some adjustment, another quick change. And it was right now.
Both could also be done with WYSIWYG editors, but editors are complex to make and maintain. And the text files offer a lot of flexibility that would be hard to capture in a visual editor.
Scripting certain behavior like enemies also falls in this category. I have scripts setup for enemies now (just did this yesterday) and those scripts get loaded every time an enemy is created. So once again, I can change things without restarting the game.