Posted on

How to program independent games

How to program independent games.

On April 1, 2011, I was invited by UC Berkeley’s Computer Science Undergraduate Association to come give a speech. This was pretty interesting because that’s where I went to school, and I was once a member of the CSUA. I approached it this way: if I were going back to speak to my undergraduate self, what would I say to help him be most effective at making video games, programming-wise?

Posted on

How to Write a Book in Three Days: Lessons from Michael Moorcock | Wet Asphalt

How to Write a Book in Three Days: Lessons from Michael Moorcock

This article is the first part of a series about one of my favorite writers, Michael Moorcock, which will culminate in an interview with the man himself.

In the early days of Michael Moorcocks 50-plus-years career, when he was living paycheck-to-paycheck, he wrote a whole slew of action-adventure sword-and-sorcery novels very, very quickly, including his most famous books about the tortured anti-hero Elric. In 1992, he published a collection of interviews conducted by Colin Greenwood called Michael Moorcock: Death is No Obstacle, in which he discusses his writing method. In the first chapter, “Six Days to Save the World”, he says those early novels were written in about “three to ten days” each, and outlines exactly how one accomplishes such fast writing.

via How to Write a Book in Three Days: Lessons from Michael Moorcock | Wet Asphalt.

Posted on

A Git Primer | danielmiessler.com

git is a wicked-powerful distributed revision control system. It is confusing to many, so there are myriad tutorials and explanations online to help people understand it. This one will focus on the fundamental concepts and tasks rather than trying to compete with the documentation.”Im an egotistical bastard, and I name all my projects after myself. First Linux, now git.” ~ Linus Torvalds

via A Git Primer | danielmiessler.com.

Posted on

from the penguin

Linux 2.6.39-rc3.

Why don't we write code that just works?

Or absent a "just works" set of patches, why don't we revert to code
that has years of testing?

This kind of "I broke things, so now I will jiggle things randomly
until they unbreak" is not acceptable.

Either explain why that fixes a real BUG (and why the magic constants
need to be what they are), or just revert the patch that caused the
problem, and go back to the allocation patters that have years of
experience.

Guys, we've had this discussion before, in PCI allocation. We don't do
this. We tried switching the PCI region allocations to top-down, and
IT WAS A FAILURE. We reverted it to what we had years of testing with.

Don't just make random changes. There really are only two acceptable
models of development: "think and analyze" or "years and years of
testing on thousands of machines". Those two really do work.

                   Linus