16 May 13
Nandrew

Alternative Interfacing

2013-05-16radialImage

 

Long story short: the above mouthful of a title is just our fancy way of saying that DD’s gonna get some cute little radial menus soon. Booyah!

This has been a long-time goal of ours for two reasons. One: we’ve always been meaning to build menu systems that are slightly friendlier towards touch interfaces (because, you know, we haven’t forgotten about that huge mobile fanbase awaiting us on release). Two: among the crew at QCF, I’m pretty sure I’m the only one who still insists on using pure mouse controls when playing the game. Seriously, I’ve broken the hotkey system about two or three times without even realising it because I really just don’t give a crap about that part of the game (very sorry, keyboard fans — one of the other devs will probably step in and give you those highly sought-after arrow controls before full release, though). More…

09 May 13
dislekcia

Getting shit done

You always have to be prepared to look at what you’re spending your time on during a game project and ask yourself: Is this really necessary?

This is doubly true of a project that’s got a budget and a limited runway in terms of when you can afford to still be working on this thing… So during a some recent time off during a public holiday, inbetween trampolining and exploring the mountains along our south coast, I had the chance to take a step back from the work-face and consider a few things.

The biggest question: Is the Kingdom worth it?

Specifically, is the graphical representation of the Kingdom in Desktop Dungeons worth it? It performs fine as a progression menu in the game, it gives players meaningful goals and manages quests, etc. That’s all great, but do we need it to look as detailed as we’ve been trying to make it?

The background on the Kingdom’s “new look” (which to us isn’t new at all) is that Lurk first drew a few Kingdom concepts back in the early days of us starting to work on ways to expand Desktop Dungeons into something better than the free alpha. His concepts were great and quickly got us thinking about a lush field, full of upgradable buildings and quirky little touches. The idea totally blew away the alpha’s ugly starting screen with its incomprehensible options, but the sad truth is that the actual Kingdom menu that had been in the beta for so long was the result of us crunching like mad to get the game playable before GDC 2011. It was, as many of you know, another ugly collection of (often incomprehensible) buttons…

We only recently managed to replace that menu with something resembling the Kingdom concepts of old, why did it take us so long? Well, it turns out that getting all that art to play nicely with progression is incredibly tricky. Finding an artist that could take on Lurk’s singularly detailed painted style was one thing (Hi Dorianne!), but we also had to do a lot of engineering to make it work the way we wanted it to.

I spent 4 months on a tool that would allow Dorianne to work on the Kingdom in a similar way to how she’d worked wonders with the tilesets. We had endless back and forth sessions on what individual buildings should look like and how they interacted with their neighbors from both a graphical and functional perspective as a sort of stealth menu. And it’s worth noting that this wasn’t an acrimonious process! We were all pretty happy with everything, it was just taking forever. It didn’t really matter that the buildings and their upgrades were all written up in the game’s design wiki years ago, things had to be concepted, painted, re-sampled to lower resolutions, touched up, polished, re-drawn, transferred to polys, integrated into display groups, logically tied to mouse actions and put into the overall progression before they were even viewable in the game. Yes, the LayerSet editor allowed us to do WYSIWYG edits, but that mostly resulted in tons of re-drawing and polishing, which took up tons of time.

Time which we’re starting to have problems affording.

So, the question burned away while I was trying to remember how to stop pulling to the right during backflips: If we don’t have the fully-featured Kingdom we see in our heads, what takes its place? Once I got back to the office, I lobbed the same question at Marc and we tried to be as ruthless as possible. We decided that we needed to have the Kingdom done and dusted by the end of this month. If that meant going with a simpler, less rich version of the Kingdom screen that was essentially a skin over simpler buttons, so be it. The deciding factor would be how efficient we could get with the production of the Kingdom we really wanted, so out came the big lists of stuff that needed doing and we crunched at that until we had a critical path.

We presented Dorianne with both options, the cut down Kingdom as a recovery plan if we didn’t get far enough on the full thing’s milestones this week and next. Dorianne told us how we could help it all happen faster too and a significant chunk of my time has moved from coding to managing art… How are we doing so far? Well, I’ll let you judge for yourselves:

magetower2-progress

 

03 May 13
Nandrew

Free Lives and Game Dev in South Africa

2013-05-01freelivesImage

When parts of QCF Design went to good ol’ San Fran for this year’s GDC, I opted to stay on my home continent due to a combination of local life admin and an extreme hatred of sleeping in airport lounges between flights.

I spent a lot of that time working in the office of another South African game dev studio known as Free Lives, the chaps responsible for the ever-excellent BROFORCE. They’re a great crew and I really like what they’re doing for South Africa’s presence in game development (Evan Greenwood – God King And Ex Chief Beard Cultivator of Free Lives – just recently presented a talk at A MAZE in Germany). But although this blog post was originally going to be about them, I realised after a draft or two that my time spent with these guys has inspired me to talk about the broader dev scene in our country and what I consider to be our primary challenges as a group of developers trying to build momentum in Africa. More…

25 Apr 13
Aequitas

GDC postmortem

GDC awards

So what exactly did we do at GDC? Among other things, we went to the IGF/GDC award shows (look, Journey won Game of the Year!), and got to congratulate all our fellow devs on their wins/nominations. Watching Tim Schafer and Andy Schatz MC the two shows was a treat as always, and it’s the event where you’re most likely to meet some of the big names in AAA development. And yet, it’s not the highlight of GDC. Not for me at least.

So in San Francisco, there’s a hostel where practically all the Indie devs stay during GDC. This is fantastic. Meeting people at formal events is nice, and grabbing lunch with a random katamari of devs is great too, but heading down to the hostel common room at 2am (because time zones!) to do some browsing, and running into 20 devs in various states of panic/denial is amazing. The casual atmosphere lets you really get to know these awesome people, and learn that they’re all having the same struggle as you: Making a game. Making games is hard.

It was a whirlwind week of meeting people though. I’m just gonna list off some of the favorite moments from the conference now. Going to Supergiant Games to play Transistor. Hanging out with DannyB and Grant Kirkhope, chatting about DD’s music. Meeting Kert Gartner, and asking him to help us make a trailer for DD. Chatting to Lucas Pope about game design. Having dinner with the guys from Cipher Prime, and playing something new from them. Touring EA redwood shores with Paul Barnett. Going to the MoMA to see Robin Arnott exhibit SoundSelf. Meeting Steve Russell, and playing Spacewar! on an actual PDP-1. And about a million other things.

There really is no place quite like GDC

21 Mar 13
Aequitas

e-mail!

madrillLast year around this time, we ran a promotion. We let anyone and everyone register an account for DD, and play for free during the week of GDC. This was pretty cool, got us some nice exposure, and made us some sales … it also completely killed the e-mail service on our host for two whole days. We managed to write a mail queue system that would send out 100 e-mails per hour (the limit set by our webhost), but before we got that running, mails were getting lost left and right.

We’ve spoken to our webhost about raising the limit, but they don’t seem to understand that we send out mail ‘on request’ not in mailing lists, but we still need it to be automated. Searching around the internet for a bit turned up Madrill, an offshoot of MailChimp. Mailhimp does newsletter stuff, and they extended the business to do transactional mail. Madrill is nice in that it has an hourly limit, but that limit gets shifted up as your needs increase and as your reputation becomes better (no spam, no bounces, etc).

Switching over to Mandrill means we can open the tap on our side of the mail process a little more, letting through 100 emails every 10 minutes instead of 15 every 10 minutes. Once we have some more  time on our hands, we’ll switch our mail sends to direct through Mandrill immediately, instead of sitting in our queue. What this should mean for you is faster e-mails for password changes, and faster replies when buying copies of the game. Also fast e-mails when next we do a “free for a while” promotion … ;)

14 Mar 13
Nandrew

Revised puzzle designageism

2013-03-14puzzlesImageSo far, the puzzles in Desktop Dungeons have been an odd sorta peripheral to the main game – they’re hooked into the experience, but they’ve always stood apart as their own special mode and people generally don’t pay much attention to them until they realise that one or two item unlocks happen to be puzzle-dependent.

This isn’t too bad on its own. We wanted to focus on puzzles primarily as tutorials and learning experiences distilled into small, pure sections of educational monster-thwacking. Such situations don’t have much mileage by nature (at least compared with the infinite possibilities of a randomly-generated dungeon run!), but the lessons last for a lifetime. At least when they’re done properly. More…

07 Mar 13
dislekcia

Game design? Nope, Chuck Testa!

TaxidermistDesktop Dungeons has rather a lot of back-story and the game’s story itself is something we like quite a bit. It’s not all just allegory for our socialist-pinko-commie-brutalist-feudal economic agendas, there’s real artistry there (or so Rodain tells us). It just so happens that economics is one of the major ways that players experience that rich story, and the Taxidermist is the main driver of progressive events in the Kingdom.

Except players are rather steadfastly ignoring our humble stuffing merchant! The Taxidermist is one of the least visited buildings in the DD beta right now and, frankly, we can understand why: It’s not as much fun as selecting races or classes and heading back into a new dungeon. This meant that new players weren’t aware of the story progression a lot of the time, often being completely stumped as to why their monster-head-selling business was tanking and having no idea how close they were to finishing the main story arc!

We spent a lot of time brainstorming how to fix this, suggestions ranged from tying Kingdom progression to monster trophies directly (like it used to be before the beta was actually available to anyone outside QCF) to introducing more in-game story events to make players more aware of the existence of a Big Bad™ as they came closer to a confrontation. We even have ideas that might tie preparations to specific trophies or grant specific trophies minor abilities/boosts that could be applied to buildings – both of these are extra systems though, so our anti-feature-creep immune systems have kicked in really hard at those. Mainly though, we’re looking for ways to make the Taxidermist more relevant to everyday players, have his information be more conversational and emphasise his usefulness as we start upgrading the actual building UI as well.

5 Tiles
Optional extra:
Poison animation concepts, woo!

27 Feb 13
Aequitas

Optimised Saving

We noticed recently that many players were reporting long load times (over 30 seconds!), which is not ideal. I’ve written about the save system before, and until now it’s served pretty well.  We decided to investigate and came away with some neat optimizations, and some insights into the meta-game.

After running some tests on culprit save files, we found that there were way more lockering events happening than anything else. Players seem to love going into a dungeon and converting their locker item, they also love coming out and reclaiming it, but will often just go find that item again and re-locker it over the reclaim slot. It didn’t make sense to keep two matching ‘destroy’ and ‘restore’/'relocker’ events, so we wrote a save game pre-processor that can go through the file removing matching statements like this, and some other odd edge cases, like an item being lockered over the same item.

What this did is gain us some big savings in file size, and a fair reduction in  load times … but something still wasn’t right. After some more investigation, we realised that there was a graphical element that was being re-drawn every time the locker status changed, and that was eating up load time as well! That little hole was soon plugged, and now the graphical reset only happens if the game isn’t loading.

One nice thing is that we now have the pre-processor in place, and we can add to it if we ever find another way to save space/load time.

20 Feb 13
Nandrew

All the small things

This past week, we introduced the first draft of our new, graphical Kingdom. While fan reception seems to have been favourable (at least when compared to the tedious ol’ button system), there’s been a lot of concerns about readability, ease of use and overall practicality.

Don’t panic, we’ve got you covered!

We understand that turning words into pictures isn’t the only thing that needs to be done with the new Kingdom layout, and over the next few weeks we’ll be working on some of the little tweaks and adjustments needed for a smooth and logical interface. Here’s a couple of things that are in the pipeline: More…

13 Feb 13
dislekcia

Design Vocabularies and Slippery Slope Problems

One of the really interesting parts of running a rather long beta is watching players interact with each other and with developers over time. After a while, something seems to happen whenever a particular kind of problem is perceived in the game: Everyone tries to design their way out of the issue.

That’s great, new ideas are never a bad thing, but often player input is tempered and mangled by what they perceive as the responses the developers are likely to take. That’s the Design Vocabulary that ends up informing the majority of conversation. Different games have different design vocabularies. Desktop Dungeons has a vocab that focuses heavily on the idea of balance, player skill progression and dungeon completion. Players tend to talk about specific classes or gods being over- or under-powered in specific situations and motivate for the tweaking of numbers accordingly.

Except oftentimes it’s not numbers that need to be tweaked and adhering to the design vocabulary that has so far governed the conversation is actually a bad thing! The classic example of this is the old saw of the players who complain that a certain gun in Random FPS Game is ineffective and useless, so they suggest new numbers for damage output, fire rate, etc. None of those values seem to make any difference and actually make the game less balanced as the gun cycles through being buffed and overused to nerfed and hated, until one of the designers simply changes the sound effect that plays when the gun fires and adds more bass. Suddenly everyone is happy with the gun at its original values and it turns out the balance was fine, everyone was just framing the discussion poorly due to a blind spot in the design vocabulary around the game.

I raise this concept because there’s a big change coming in how we as a design team approach issues in Desktop Dungeons. It’s been brewing for a while now, but we’re finally at a point where we feel that tweaking numbers and effects is essentially navel-gazing in an already well-balanced game experience. The new definitions we’d like to see making their way into the vocabulary of the discussion revolve around strange-sounding terms like information-load and richness of feedback. Essentially, we’re focusing on making the game easier for people to pick up over time because it conveys better and more useful information to them as they play it. We know the game CAN be played, we just want to make that play experience smoother. There’s no end of situations in DD that can benefit from more information: Everything from players learning about bonus experience or wasting regeneration space to the effectiveness of poison on enemies and their current debuff state can (and should!) be displayed graphically.

Interestingly, that kind of “at a glance” information is something that DD beta players have lacked up until now, so us changing to focus on that puts a lot of strain on their comfortable design vocabulary. Then there’s another concept that strains how our players talk to us about design:

The problem of skill estimation and slippery slope prevention:

Locker

There’s been a lively thread on our forums about the in-game item locker functionality. The short version is that a core group of experienced veterans (players who have typically injected over 100 hours into DD so far) feel that they would like to be able to access every item in the game at a moment’s notice for their next run. Ideally, this would let them plan out strategies without having to go and find items in the game world.

This is a specific sort of slippery slope problem that Aequitas wrote about quite a while ago, but it’s made worse by the fact that us humans are pretty damn bad at estimating the difficulty of a task once we’ve internalised the skills needed to be proficient at it. Take driving, for instance: Once you’ve learned to drive, you no longer actively think about the complex co-ordinated actions you’re using every second, instead you think in the broader terms of driving like changing lanes, slowing down, making that turn, etc. The same thing happens in game development all the time when a developer shows off their game for the first time and discovers that new players can’t even get past the first obstacle, which the dev has made harder and harder as their skills have grown through familiarity.

As it stands, we’ve changed how the Adventuring Locker works quite a few times now: We’ve added more storage space; We’ve made items lost or destroyed in dungeon runs easily replaceable; We’ve even added a temporary backpack for items that you carried out in your last run but don’t want to “waste” a locker slot on. The design vocabulary around the locker is one of space. Players always talk about space and wanting more of it. Except the actual complaint is that they have items in their locker that they don’t want to replace. We’ve approached this problem in a couple of ways, most notably by making most items require a single dungeon run to re-discover (granted, you have to win that run) and by allowing players to tailor random item drops by saying which items they never want to have appear.

The problem is that players are never going to be happy with a limited locker space. Ever. It doesn’t matter that an infinite locker would essentially scare new players away with unnecessary complexity (compare DotA2′s hero selection to the limited roster of LoL, for instance) or that a “late-game” infinite locker wouldn’t solve the desire for more space either – it would just be wished for earlier and earlier. Hiding the “true” locker behind some incredibly difficult quest would end up not feeling fair… Seeing as this seems to be a situation that players are probably always going to be complaining about, no matter what particular phrases of the current design vocab we implement this week or the next, we have to make the hard choice to simply say no. No, the locker isn’t going to expand unless we see a way to prevent the same complaints from cropping up yet again once people have had a month to start taking the change for granted. Every single limitation or cost proposed for an infinite locker so far has this slippery slope weakness, so the only way to prevent sliding down it is to stand fast.

Personally, I think that losing carried items on death or conversion would solve the “can’t bear to replace existing items” conundrum quite nicely, but I’d have to motivate pretty hard to get the others to be OK with that change…


Copyright © 2013 QCF Design
Powered by WordPress, theme based on one from Themelab.com