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.
The Evolution of Workflow: Abandoning Failures and Being Adventurous
Posted in Gaslamp |
Leave a comment
Git Web Development with gitosis
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.
Iconoclasm & Nomenclature
I’ve been drawing icons for skill abilities in Dungeons of Dredmor. When creating your character at the start of the game, you choose seven skills for yourself. As you advance these skills through use, you gain new special abilities. Today I’ve drawn up some abilities for the axe skill and will discuss icon images and giving the skills their names.
To quickly take up a tangent on the design decision to have these skill abilities: In RPGs mages have traditionally had the most diverse abilities which translates to having more enjoyable game-choices to make. Do you cast fireball? Teleport? Ice shield? Do you “paralyze nerves, shatter bones, set fires, suffocate an enemy or burst his organs”? Meanwhile, a warrior can choose to either attack or not attack. And why would you ever not attack? Yes, the warrior is ideally more of an item-driven class, but why deny certain character archetypes whole swaths of gameplay, be it special abilities/spells or item management? Compare Diablo 1 with Diablo 2 and you see the solution Blizzard took: Give every class spell-like abilities. (And give every class useful item progression.) New editions of D&D, even, have taken up the spell-like ability for non-magic classes. The lesson is clear: It is important to give the player important decisions to make in the course of playing the game.
And now for the icons:
These are the sub-abilities of the axe skill. Each gives a unique combat effect or shaped area-attack. As originally planned, these icons are displayed at 32×32 pixels in-game, the smaller size in the above sheet, but it does the painted icons some harm to shrink them so much. It might be more appropriate to draw these as native pixel-art at the target resolution (as I did with the spell icons), but I feel it loses some character — and takes a lot longer. Time is money, friend.
As for naming, everything in Dredmor is rightly a bit silly. If a name can contain a pun or a joke, I’m all for it. If it sounds awesomely overblown, it’s good. If it just sounds like it belongs in a cheesy fantasy game, it’ll do. At some point a name feels right, it’s like writing a gag in a comic strip or coming up with a good zinger. This is not to say that everything in Dredmor is really all that good, I’m just trying to do my best with what I can deliver in a reasonable timeline. To borrow a line from Hemmingway, “I write one page of masterpiece to ninety one pages of shit.” … And that goes for the art, too.
Let me take you on a tour of my thoughts about each ability icon.
What’s in Your Toolkit?
Another day, another late blog post. I probably owe other Gaslampers some kind of savory pastry or something. Maybe a delicious soy-based iced confection? I don’t know.
Most of my day was spent putting together the finishing touches on the accompanying source code for my Game Developer Magazine article. (Yes, I’m pimping the article again. If you like it, tell the good folks at Game Developer to keep the hits rolling.) I spent five hours fixing a race condition, which is ironic because the article is about how to *avoid* race conditions. I still managed to create one in the code for the message-passing architecture mentioned in the article, and it’s taken me a good long time to figure out what the heck was causing it. Hopefully my learning experience will save somebody else – maybe one of you! – some trouble down the road.
Posted in Uncategorized |
Leave a comment
Why they just don’t make games like they used to.
Well, not all “they”s have stopped making games like they used to, but things have definitely changed.
Personally as a gamer, there are a lot of things about the way things are changing that I don’t like. Take the RPG for example: a medium which began with Gary Gygax giving the escapists of the world a way to be a beefy barbarian who gets the ladies in, back then, probably their parents basement with some junk food and no girls:
- Courtesy of Westworld Blogs
And sometime in the last 25 to 30 years, console and computer gaming has gone from being something that kids at school felt self-conscious about because they were uncool, to being an industry with yearly revenues to rival video television and music.
But we’re not all sitting around tables rolling dice and drinking mountain dew. The reasons? Creative direction, cost, profitability, and marketing.
I should say that I actually do play pen&paper RPGs. My group gets together once a week to play Pathfinder, a derivative of D&D 3.5.
The good reasons why we don’t play games like that anymore? Storytelling, for one. The technology available to a game developer these days allows us to decide from a vast array of possibilities exactly how the player should be capable of interacting with our worlds, and in doing so one can provide storytelling elements such as theme, setting, and style. Also, you couldn’t play D&D by yourself when it’s 3pm but all your friends are at work and you have the late shift.
Video game designers of the past were, in essence, all lobbying for that period of time that you don’t really know what to do with, because they couldn’t really compete for the time that you did know what you wanted to do with, be it D&D, drinking with friends at the pub, watching a movie, or whatever. Games just weren’t capable of delivering an experience rich enough to compete when all that was available was pong in 1972 or pac man in 1980. The evolution of our technology, allowing for more creative direction, has made games like World of Warcraft capable of solving this issue.
But there are other reasons why games have changed, and they’re not nearly as good for the consumer.
Producing a video game was once the same for everyone as it is for small startups today: you work in your spare time to produce something that you think people will like and hope you run out of things on your to-do list before you run out of time or energy or money.
That model has been seriously overshadowed by large companies which started out as the small ingenious companies above, but have grown as the market has grown into billion dollar corporations which collect terabytes of data on where people click, what people buy, and what makes people buy more: a finely honed machine on cutting under-utilized and over-wrought resources so that in the end the ROI will improve.
This is why Final Fantasy doesn’t have towns anymore. This is why Rock Band has 12 iterations that all cost 3 thousand dollars and the core game is exactly the same.
I’m sure there was a time, once, when someone was writing a video game like Oregon Trail and thought, “Man, won’t it be cool when we have the technology to make it possible to actually make all the decisions: how does one ford a river, for example, or what happens once you get to the Ozarks? These are the kinds of things that RPGs did way before video games were on the scene – and still do. You want to run a used mop store? D&D can do it, Pathfinder, Palladium, Rifts, Heavy Gear… they all can. But can I not kill Ares in God of War? Can we talk things out? Hell no, that would just be too expensive.
Now, this is RPGs I’m talking about here. If you could do anything in Bejeweled it would just be weird and confusing; there is a time and place for everything. But is video gaming doomed to this downward spiral of disappearing player-driven freedom? I hope not, and I honestly see no reason why it should. Occasionally, the indy game developers and small companies still make great products, not tied to their budgets like the big guys, and they can make towns and yogurt makers and whatever they want. And, with the right group of fans to support them (and remind them of why they like their games), they will keep making them.
Posted in Games |
Leave a comment
Game Developer Magazine Ahoy!
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.
Posted in Gaslamp |
2 Comments
Getting Going with Git, or How I Learn Not Directly Edit Webpages
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.
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.
