All posts tagged with "teamwork"

Making The Cut

I just redid the character information panel again. I had to re-arrange all the info boxes then type out the size and position of every single textbox and tooltip hotspot. It was awful. Now Nicholas gets to update the code to my specifications, the poor bastard.

Dungeons of Dredmor, as some sort of RPG, and god-help-us, as a roguelikeish game, lends itself to a maddening excess of features, ideas, items, skills, spells, potions, special abilities, factions?, unique rooms, artifacts, vengeful gods, and and.. and … Well, one of the most important points of successful game development is knowing when to cut; no, being able to cut features so that the project can ever be completed.

We have done this. No, really! A bit, at least.

Dredmor Hero dodging a blade

At least you’ve survived with piles upon piles of unique items, silly skills, and an upcoming hellishly complex crafting system, dear hero!

{ read this article }

Posted in Dungeons of Dredmor, Game Design | Tagged , , , , , ,

Design Dialog

I’ve long since learned that it’s far better to present Nicholas with a fait accompli which he finds amusing to implement rather than a rational argument for a feature. Allow me to demonstrate.

{ read this article }

Posted in Dungeons of Dredmor | Tagged , , , ,

Creative Levity

Late one night, we set our scene:

David: Added dire asparagus and a crate of evil sprite. I’ll let you figure out what to do with them.
Nicholas: … “dire asparagus”?
David: I’m going with my gut on this one.
Nicholas: Probably wise.
Nicholas: I wonder what goes in the crate of evil.
Nicholas: I’ll do something for it.
David: Surprise me.
Nicholas: Will do. Maybe it releases evil.

Should I even try to justify this?

{ read this article }

Posted in Dungeons of Dredmor | Tagged ,
1 Comment

Conflict Resolution; Tools for all people

I’ve had this comic kicking around for a bit. From left to right is Daniel, Nicholas, and myself.

Click the image for the full comic.

All done? Okay:

The particular issue behind this comic is an ongoing matter of what versioning software to use, and behind that, how to choose what tools to use to coordinate work, and behind that, what makes which tools best for collaborative development. This is a bit of a mess of a question that I’ll wade through with the power of anecdote rather than some kind of comprehensive answer.

(I should add here that I am aware  that Git has a mac version with a GUI. Please feel free not to send me any more helpful messages.)

With Nicholas and Daniel off on some remote island in the Pacific, myself in a lovely northwest metropolis, and Derek in some dark place south of the border, we need software that harnesses the full power of The Internet to effectively work together. For communication we use some combination of IMs, Google Wave and Docs, a dusty wiki, email, and occasional face-to-face meetings when schedules permit. For project files we’re presently using SVN and there has been talk of moving to Git, as evidenced by the above comic.

Now the point of the original disagreement which led to the comic is that I’m an artist; While I do know some coding and technical tricks, I hate the idea of having to learn to deal with a new command line interface for versioning software (or  whatever it may be). I have plenty of work to do already and would like to avoid major investments of effort unrelated to my specialization in the whole enterprise. And this is to say nothing of what might happen when we bring more, less techy artists in on Gaslamp projects. Of course, as established, Git does have a GUI for my ilk. But there will be other software used in our future projects and I think that usability issues may arise, especially as we run a zero-capital startup and end up using a lot of open source software or homebrewed tools.

Teaching a particular command-line interface to an otherwise uninitiated artsy type takes important development time away from all parties. There is a balance to be found between finding/developing tools that make the work of the development team easier and the act of development itself. I saw just such an argument made for in-house tool development (down a few paragraphs) by Eskil Steenberg, the one-man team creator of Love. On the other hand, if I recall an off-hand comment correctly, Nicholas expressed skepticism at the viability of Eskil’s approach to tool development — just as it might turn out to be efficient to create one’s own 3d modeling suite, it might just as well turn out to be a tool too hopelessly personal to be useful to anyone but the maker.

(And I haven’t even started on our appalling sprite format that’s created a content pipeline through some ancient graphics software which causes me existential pain. Sacrifices have to be made for the team, of course, so I weather this. For the team!)

Balance in all things, and most important from my perspective: choose tools with good UI design. Good UI decreases the overhead of effort involved in both learning and carrying out the task at hand (and doing it well is even better).

As for teamwork, you could really just take the first two text boxes of the comic and fill them with the Gaslamp-conflict-of-the-week while making sure they’re between the two appropriate personalities. These things write themselves.

Posted in Gaslamp | Tagged ,
1 Comment