We are still working on our Dredmor beta aspirations. My lungs are now full of coffee, and David hasn’t seen the light of day now for… okay, five years, but who’s counting?
While we wait for the last of the skills to be implemented, and for the eighty-seventh window closing button to get its new, fresh coat of gold paint, here’s another Dredmor gameplay trailer for your enjoyment. Music by Mr. Ludwig van Beethoven, lovingly arranged by Mr. Matthew Steele.
If you have been paying attention to gaming news recently, and, well.. you’re reading our blog so you probably have been, you may have seen ads for the Humble Indie Bundle.
First of all, let me say awesome job to the Wolfire guys et al. The indie gaming community constantly impresses me with its community-oriented and generous mentality; I haven’t been a member long but I’ll work hard to live up to it.
That said, if you’ve checked out the bundle, you would have noticed 3 payment buttons at the bottom: one for Amazon, one for Google, and one for Paypal. Well… we’ve been working on setting that up for ourselves, due to the oncoming beta release and being keen on offering some pre-order related deals, and being Canadian doesn’t really help things very much…
We’re finally putting some video footage of Dungeons of Dredmor on the web for you to take a look at.
There isn’t much gameplay here – mainly we’re attacking monsters – so we’ll put up another trailer in the next couple of weeks or so with more magic and lutefisk action.
So… workflow. The way we here at Gaslamp get things done has changed a lot over the last couple of years: our workflow system honestly, originally started with like 8 pages of nearly illegible blue marker on college rule thumb-tacked to a bulletin board, and is now, actually, pretty good. I blame/thank web apps.
Looks like I am the one with the late article this week. Hopefully it is worth the wait for some of you.
As mentioned in my article last week I’m going to go through how to setup a similar workflow to what I use here at Gaslamp Games. Before I get ahead of myself I should probably start at the beginning for those who might stumble on this post with very little previous experience with git. This article assumes you know your way around a Linux command line and can install packages on your system with no problem.
So what is git?
Git is a “free & open source, distributed version control system” and while that may be a quick blurb about what git is, it is exactly what it says. Every time you clone a git repository (more on that later) you not only get the entire repository but you get every commit, a full history, and my favorite part; once cloned there is no need to have a central server or even network access. This allows me to pull the latest changes, pack up my laptop and head somewhere excluded when I need to really get some work done. There is quite a bit to know about exactly how git works but that is well beyond the scope of this article. If you are curious how exactly how it all works I would suggest you get a cup of coffee and see the excellent video over at gitcasts I referenced last week.
It’s not my regular posting day, but what the heck: I have an article in Game Developer Magazine this month on the joys of multithreaded programming with Erlang, and how we can use message-based architectures to alleviate problems in multi-threaded environments. Go check it out and get your multi-core programming on.
First of all I have a problem I need to admit to you all. My name is Derek Bonner and I am a command line junkie. What is a command line junkie? Well it is someone who needs the sweet kiss of a terminal to get the day going. Nothing like firing up PuTTy and logging into a server with no X window system and getting things done.
As mentioned in David’s previous post, there is git usage in our current web development process. It all started when Dan pointed me to a video post detailing some of the finer points about how git actually works. The nerd in me loved the way it functioned and its decentralize nature. To finish it off there were a slew of command line arguments I could learn. I was sold.
My previous web development was the very bad practice of directly editing the file I was working on and then checking it live in the browser. Fast and it worked well because I didn’t really have any traffic but Gaslamp is a bit different; It needed to be always working, not sometimes or after I finally fixed a feature. Always.
After crawling the web I found a setup I liked. The workflow over at joemaller.com that resonated with the way I would like to do things. Sadly we have no second server that is constantly up to be our hub. Instead we use gitosis to create our hub. Gitosis provides the back-end and permissions to host multiple git repositories on a single shell account. From a shell user which runs the webpage can be our prime repository that will pull changes. The joemaller workflow has some details that I had to tweak to be used with the virtual repository setup. Overall I am very satisfied with the process and in my next article I will detail the steps I too to set this up including some tasty bits about SSH with my best practices using PuTTy.
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.
All content copyright © 2011 - 2025 Gaslamp Games Inc.
