StarWright - Weapon Ammunition

As in the original prototype, weapons now require ammunition in order to fire. Each weapon can store a small amount of ammunition for itself, but once it runs out, additional ammunition must be delivered by the ship's crew. Individual crew hand-carry ammo bullets from a nearby ammo supply to the weapon.

Notice how in the above screenshot, some of the crew are carrying ammo to the weapons.

The purpose of this mechanic is to further emphasis the importance and role of the crew on the ship, and to make designing a ship for maximum crew efficiency a priority. If the closest ammo supply is too far from the weapon, then the weapon won't be able to fire as often. It will also be important to prevent narrow corridors from getting congested with too much foot traffic. Wider corridors and/or more ammo supplies may help if foot traffic becomes an issue.

The Conservative<->Liberal Programming Spectrum

Well-known programming blogger Steve Yegge just posted a long but interesting article about the spectrum of programming philosophies ranging from "conservative" to "liberal". Conservative programmers are typically risk/change-averse (often for good reason) and very performance-conscious, while liberal programmers typically favor flexible systems, concise/elegant expressions, and rapid iteration.

I'm definitely a "liberal" programmer (I don't think anyone would ever call me a risk-averse programmer), but I do favor some traditionally-conservative programming practices, though for decidedly liberal reasons. For example:

• I strongly favor static typing over dynamic typing, but I don't believe that static typing is really any "safer" than dynamic typing. The unquestionable advantage of static typing (which the article admits) is that the programming tools are far, far better. And great tools make me a faster programmer.
• I like compile-time checking and static analysis not so much because it makes my code safer (it probably doesn't), but because the more problems (or potential problems) that can be brought to my attention before even running my program, the more time I save.
• I like strong encapsulation, again not because it makes code safer, but because strong encapsulation *usually* simplifies mental models of programs, meaning its easier and quicker to think about the program as a whole. Plus breaking down problems into small, discrete, self-encapsulated parts is just a good problem-solving technique.