Build systems are certainly not the sexy parts of software development. However, no part of the development process impacts your team so much as it’s build system. Build systems that perform poorly, regularly break, or generate inconsistent or confusing output files are one of the fastest ways to introduce bugs, slow releases, and bring a whole team to a screeching halt. That’s why automated reproducible builds are a keystone of agile development.
Out-of-source builds are one way to improve your build system. Out-of-source building is a practice that keeps the generated/compiled intermediate and binary files out of the source file directories. Traditionally, most build systems would generate object, binary, and intermediate files mixed right next to their source files. This leads to a confusing hierarchy of files that made getting a consistent picture of your build and source nearly impossible on big projects.
It turns out CMake can help you create our of source builds with just a few little tricks. Unfortunately, there were few examples and many of them were overly complex. So, to help get folks started, I wrote up a very simple sample. It’s the perfect starting point for your next project. It works with both Linux and Visual Studio builds.
Here’s some fascinating footage from Resident Evil 8 – The Village. It shows just how far game development has come from it’s early days. We used to have little 8×8 pixel characters, now we have fully live-acted scenes.
When I was getting into computer science and gaming in the 80’s and 90’s, programmers were the rockstars of game development. They were the only ones talented enough with the limited resources of early computers to get games done. They were the ones that developed all the key innovations and gameplay mechanisms. They even created most/all of the art, characters, movement, stories, etc. In the early days, animations were hand-edited pixel sprites done one frame at a time.
Starting in the early 2000’s, indie developers started to slowly crop up. Technology finally reached a technical and price point that more and more people could start making games – often by using basic 2d engines like Shockwave 3D. There was also a slow but steady increase of indie developers from big studios/boring day jobs that sometimes spent years on a hobby game. Sadly, in a world in which most games flop, many would find their game wasn’t actually fun/didn’t sell and had to go back to their day jobs after having run through all their money. So the mantra then became “fail as quickly as possible”. Which means to do just enough to prove out your game idea and quickly discard those that didn’t work. Many people suggested the idea of ‘A game a week‘ in which you develop a game in one week – laser focusing on the gameplay/fun. The gameplay idea was then either good enough to continue, or you moved on to the next idea. In this way, you never lose more than a week on a bad idea. This was the first push away from games that simply were what was technically possible to a focus on gameplay itself before the technical questions.
As the decade continued, technology increased and so did the engines people used. Unity, Unreal, and many game engines were became more powerful, easily licenseable, and easily accessible to beginners. The engines worked on many platforms, making them much more attractive than the cost, difficulty, and time of developing your own engine for all the platforms you wanted to support. With tools open to designers and artists with just a little technical know-how, the focus then became to make a game FUN before developing the graphics engine pipeline. This reached its crowning moment when the game Journey won the 2012 Game of the Year – and was largely created and developed by designers. The democratization of game development by engines that could be picked up by non-programmers flipped the game dev world on its head.
“Make games, not engines” is the new mantra. Content and design is now the new king. The vast majority of game development staff, and cost, is now content: music, art, modeling, actors, and design. Programmers are usually a tiny minority on most game studios, and they often work together as a core engine team that moves from one game to the next.
When you’re young in the midwest and want to make some money – this is how you did it. Bailing hay and straw.
There’s an art and science to working together like this. How you stack, carry, and work together in a group really matters. This guy does a decent job giving you an idea of just part of the job.
Not shown is the job of stack behind the tractor, using elevators to get bales up into hay lofts, the dangers of hay loft flooring (often just lots of planks thrown around willy-nilly with holes everywhere, and the unbelievable amount of chaff and crud that you end covered in by the end of the day (and in your lungs to hack up the next day).