Browsed by
Month: May 2021

Out of Source Builds

Out of Source Builds

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.

https://github.com/mattfife/BasicOutOfSourceCMake

De-kernelling Corn

De-kernelling Corn

Handy Geng built himself a ridiculously over-engineered machine for getting the kernels off of corn cobs. As someone from the heart of Midwest feed corn country – I approve.

Incidentally, this is how it’s done in normal industrial settings (from How It’s Made video series):


How your games get made

How your games get made

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.

But as they would say on Reading Rainbow, you don’t have to take MY word for it:
https://gist.github.com/raysan5/909dc6cf33ed40223eb0dfe625c0de74

Yamaha Motoroid

Yamaha Motoroid

How about motorcycles that balance themselves? How about going forward/backwards on their own?

If you’re interested in some other crazy motorcycles, check out this video out. Some interesting concept ideas coming:

  • All electric bikes
  • Self balancing bikes so that getting stuck in traffic isn’t so exhausting.
  • Bikes that can hover
  • Heads up display goggles