2 min
sam, homebrew-mingw, etc.
👋 This page was last updated ~12 years ago. Just so you know.
I want to write blog posts, but right now I have too much to do.
So instead, here are bullet points:
I wrote an ooc tool named sam, which helps you keep your git repos up-to-date, and helps to remind you what to push when switching workstations. It's pretty neat, and portable.
A while ago, I started working on homebrew for Windows, or rather, for MinGW+MSYS. Provided you have msysgit and Ruby in your PATH, it'll let you brew install most packages. I've tested a few dozen, send in your pull requests anytime.
Lots of work being put into rock 0.9.5, the next incarnation of our beloved ooc compiler. A quick look at the relevant milestone will make it obvious that lots of bug fixes and simplifications made their way into the compiler, along with a few new features. In general, partial recompilations are now much more reliable, which makes rapid iteration easier.
If you've missed it, Einat, Sylvain and me are doing OneGameAMonth. We've called our team nevargames, and our first project is inspired by lemmings :) Since you've read that far, here's a preview video.
Continuous integration is cool, if you were wondering if ooc played well with it, well, we have a few projects on Travis, and recently, I've been setting up nevargame's instance of Jenkins, and it builds our game for Linux, Windows and OSX on every push!
I've started developing a few frameworks in-house for nevargames, but they're all open-source and I'm happy to share: our current stack is dye for graphics, gnaar for level editing and UI stuff, along with chipmunk (just a binding) for physics. For now it's far from stable, but in the next few months I'll be happy to help developers who want to start using the same stack for their own projects.
Welp, that's it for now. Back to work!
Here's another article just for you:
1 hour 7 min
I've been banging the same drum for years: APIs must be carefully designed.
This statement doesn't resonate the same way with everyone. In order to really understand what I mean by "careful API design", one has to have experienced both ends of the spectrum.
But there is a silver lining - once you have experienced "good design", it's really hard to go back to the other kind. Even after acknowledging that "good design" inevitably comes at a cost, whether it's cognitive load, compile times, making hiring more challenging, etc.