I SMOULDER WITH PROGRAMMER RAGE II: ESCAPE FROM NEW SOGWOOD

(He's holding a C++ manual.)

That’s Donald Knuth’s “The Art of Computer Programming” which Nicholas is holding.

This summer’s blockbuster sensation:

PROGRAMMER RAGE II
ESCAPE FROM NEW SOGWOOD

IN A POST-APOCALYPTIC CITY, VEINS WILL EXPLODE OUT OF YOUR HEAD!

So let’s talk about what I’ve done recently like a man of action… uh, okay, what have I done recently? Well, here’s a short list of improvements and debugging tasks that have gone into Revisions 38A, 38B and C that represent the work of  PEOPLE WITH SHOTGUNS (or debuggers) IN A DARK CITY OF PANDEMONIUM (otherwise known as a codebase):

– Autosaves! We now have autosaves. At first, this was good, but then it was bad because autosaves would occasionally crash while saving. GRAAAAAGH! The solution, to be deployed for Revision 38C is that we now have two autosaves, and they rotate; that way, you always have one working autosave to work from. The end goal, of course, is to not have save games crash – an intermediate goal is probably to save the new save game to a temporary save, then once the save process has completed to delete the old save and overwrite it with the new one. AESTHETICS ARE FOR THE WEAK!

This is what we see when save games crash.

Pictured: players after a save-game crash.

So why are the save games crashing? Well, when I’ve been able to reproduce this, it’s been due to a couple of issues, and it ties into another issue that has sometimes vexed us in beta testing due to a total inability to reproduce it: sometimes a work crew will get stuck on an assignment that is completed and will refuse to give it up. Conversely, sometimes a work crew will finish an assignment and it erroneously hangs around on the renderer. The reason for this is that there is a NumJobsBeingDone counter on assignments that indicates how many people are working on them. When a job is taken from an assignment, it’s incremented; when a job is removed from an assignment, it’s decremented. IT IS PUNY AND INEFFECTUAL! Therefore, assignments now track two piles of jobs: those in the assignment that are currently being done, and those in the assignment waiting to be done. The hope is that we can now figure out which jobs are not correctly moving themselves from pile to pile, and therefore sort out some of this logic. Refactoring until you have solved a problem is a bit of a last resort as far as debugging strategies go, but this code could use a clean up anyway. Hopefully we can kill two birds with one stone. ULTRAVIOLENCE!

Nicholas debugging code.

Nicholas optimizes C++.

– Containers. We put these in Revision 38B and sent them out to the world; the reaction was very positive, other than that they caused the game to lag. I’ve now rewritten all the container management code to run in C++, and they’re now faster. I’m a little bit worried that simulation performance is creeping up past our budget (90 msec/simulation frame); right now an active colony runs at about 70 msec on my office machine, which is a bit too slow for my tastes, so this needs to be investigated in future builds. BURN IT DOWN WITH FIRE!

Daniel skulks in the shadows; only a progress report will satisfy him... until the next sprint.

Daniel skulks in the shadows; Only a progress report will satisfy him… until the next sprint.

(There is also a certain amount of messing about with container heuristics that still need to be worked out. For instance, if I have some lingonberries and a stockpile, I should put the lingonberries in the stockpile – but the decision about whether I should put lingonberries in a stack in the stockpile, and whether I should put lingonberries in their own pile, requires a certain amount of poking and testing to make it feel “natural”.)  I CAN’T LISTEN TO BACH ANYMORE! Similarily, when is it appropriate for containers in a stockpile to be moved around in the stockpile and concatenated? Experimentation is needed here.

THE BUILDING CREATION INTERFACE IS PUNY AND WEAK! A casual survey of our Steam Forums reveals BARBARIAN KNIFE FIGHTING and also that a major turn-off for our users is the inability to move and delete modules and buildings. While building deletion has existed for awhile, it has user interface issues that have prevented it from working as well as it should (also, bugs.) Module deletion has existed, but has not had a clear interface. Now, when you click on a module in Module Placement mode, a little Box of Icons will show up inviting you to move, or delete, the module if the module is not yet built; it will invite you to delete the module only if the module is built. OUR INSURANCE DOESN’T COVER THIS! There are probably still bugs to be fished out, but right now we’re pleased to have taken care of these strangely important issues.

– Small icons on the character panel now correctly indicate the colonist’s health, sanity, and morale. SMALL ICONS WILL BE CRUSHED UNDERFOOT!

All this and more in this month’s summer blockbuster – I SMOULDER WITH PROGRAMMER RAGE II: ESCAPE FROM NEW SOGWOOD!

GRARGH!

A typical design meeting.

(A typical design meeting at Gaslamp Games.)

5 Comments

5 Responses to “I SMOULDER WITH PROGRAMMER RAGE II: ESCAPE FROM NEW SOGWOOD”

  1. Yeol says:

    In C++11 they’ve replaced the optimization dagger with a machine covered in spinning blades and pointy appendages. It takes care of a lot of things for you.

    Sometimes it lops your arm/leg/head/torso off.

    { reply }
  2. Bob says:

    I, too, program fueled solely by unbridled fury.

    { reply }
  3. Jabberwok says:

    I appreciate your gratuitous caps. They help my sieve-mind hold thoughts better.

    { reply }

Leave a Reply

Your email address will not be published. Required fields are marked *