I sat down yesterday and spent a solid afternoon polishing the way systems are displayed. For a start, the trusty old -1000 / +1000 habitability scale is gone — the underlying mechanic is the same, but systems now display their habitability rating via a color-coded category, something like inhospitable or idyllic. It’s a small change, true, but it makes it much easier to inspect systems at a glance.
Another minor tweak: the game now respects your localised currency settings. Again, a tiny fix that makes things look much, much nicer.
I’m also part-way through a major change to how Distant Star plays, and thought you guys might want a sneak peek. Right now all races start with all their possible ship types unlocked, and research (in the Defense and Combat trees, at least) just upgrades these ships’ stats.
Instead, each race begins the game with only one or two available ship types; you (and the AI!) have to choose how to develop your race through research in order to unlock new options. Want to colonise? Research Cryosleep in the Ecology tree, and unlock colonisers. Want to take over enemy systems? Research Large-Scale Genocide and unlock Bombard Cruisers. You get the idea.
I know it’s been a while since the last Distant Star update, but that doesn’t mean progress isn’t happening! Far from it: I’ve been meticulously re-working big chunks of the game over the past few weeks, rebalancing ships and races, improving the game’s early stages, and changing the way tech trees work. Oh, and adding in support for GameCenter achievements.
So, yeah. Progress? It’s happening.
My primary focus right now is on de-designing the way ships are designed and researched. I’ll admit it: pretty much every aspect of ships (and the automatic combat system in general) is horribly, horribly broken. I’d originally set out to build a really clever system where the interplay between stats was obvious, and where you could tweak your ships to counter those of a particular rival; what I ended up with is just a mess of opaque, confusing numbers.
So I’m working on re-designing the way ships work; streamlining their stats from a confused mess down into a more manageable handful. I’m also changing things around so that you acquire better ships by unlocking (through research) rather than having all ships available at the game’s start and applying a bunch of small upgrades. Trust me, it’s way more fun this way — the moment mid-way through the game when you finally unlock cruisers and go on a smashing spree until the AI catches up is really satisfying.
As for the rest: tech trees, the early game, system upgrades, achievments, &c? I’ll keep you posted.
Let’s make one thing clear: I’ve wanted to write a 4X-style space game since long before I learnt how to code. The genesis for Distant Star in particular, however, came about the day I bought an (original) iPad, brought it home, and thought: “Why aren’t there any good strategy games for this?”
I’d just finished up Levelheaded, so I knew I was up to the task of putting out a game for iOS. And while Levelheaded wasn’t exactly a stunning success from a commercial (it failed spectacularly to sell) or critical (it wasn’t, let’s be honest, any good) view, the process of writing it taught me worlds about game development. Plus, it meant that I’d actually designed, built, tested, released, and sold a game — for the first time I thought of myself as a game developer, albeit not a very good one.
So I sat down that night (30 May, 2010), ripped the more useful OpenGL guts out of Levelheaded, and coded up a quick scrolling starfield. Another hacking session later and I had randomly generated star systems, some atrocious text, and not much else.
It wasn’t exactly the epic 4X strategy game I wanted to write, but it was a start. Unfortunately, the idea of carrying it on into an actual, playable game was incredibly daunting, so I put the project aside.
That’s pretty much where things stood until Mike Kasprzak announced the October Challenge. I’d been a regular participant in Ludum Dare, a 48-hour solo game development thing; when Mike posed his challenge to the Ludum Dare community I knew I couldn’t resist. Besides, I had this half-baked idea all ready to go!
What I wanted Distant Star to be, at this point, was basically a touch-based version of Sword of the Stars sans tactical ship combat. At the time the project felt like a natural fit for a month-long game jam — I had a clear idea of where it needed to go and a core set of mechanics that absolutely had to make it in, plus a laundry list of cool features I could squeeze in if I got the chance.
Ship construction and fleet movement came quickly, followed by (idiotic) AI. By the time I had my first screenshots ready for The October Challenge community the game’s visual style had gelled into something very much like the retro/minimalist look it has now. I powered through October, squeezing in three or four evenings a week; by the 24 I felt the game was almost ready, and sent out beta copies to a dozen or so volunteers (shout out to the TouchArcade forums: you guys rock!).
Based on feedback from beta testers I added in the tap-through tutorial and the notifications system, not to mention fixing approximately seven thousand crashtastic bugs. Distant Star 1.0 for the iPad (only) went live on the App Store on 13 November, 2010 and sold 82 copies (at US$1.99!) that day.
For the next two months I polished the hell out of Distant Star. While the vast majority of players seemed to like the game, I’d taken some flack from for some of the game’s rougher edges. Sporadic crashes (mostly due to hard-to-find memory leaks), buggy rotation handling, and a non-helpful tutorial were the biggest culprits, though I also received a staggering amount of amazing feedback from players who enjoyed the game as it was but had big ideas about what it could be.
I pushed several updates during this period, adding lots of new content based on player feedback (a new race, research tree, and numerous technologies). In particular, I worked on improving the tutorial system and adding in popup help throughout the game — quite a few early players had complained about the game’s learning curve, and I wanted to alleviate that as much as possible.
Since the original beta the most common question I received regarding Distant Star was “Where is the iPhone version?” I had hesitated to release (or even develop!) an iPhone port after the release of the iPhone 4, with it’s larger Retina display — I didn’t like the idea of releasing the game for a device on it had never been tested, and (frankly) I didn’t feel like I could justify buying myself an iPhone 4 when I still had a perfectly functioning iPhone 3G. In January, a friend convinced me that this reasoning was, frankly, idiotic; I took a train over to Glasgow a couple of days after my birthday and picked up an iPhone 4. The train ride back took about an hour; by the time I made it back into Edinburgh I had the game up and running, in a manner of speaking.
Getting the game running across all three screen resolutions (iPad, iPhone/iPod Touch, and iPhone 4/iPod Touch 4G) turned out to be harder than I’d expected. From the beginning I’d envisioned Distant Star as an iPad-only game — I couldn’t really see it working well on a smaller screen, and hadn’t taken steps in the original design to make it resolution-independent. Lesson learnt.
Eventually I sorted out the resolution problems and released an alpha version of the game for iPhone/iPod touch to testers on 16 March. After much back-and-forth, including a second (beta) round of testing, Distant Star 1.3, now a universal app for iPad, iPhone, and iPod Touch, went live on the App Store on 20 April, 2011.
Since releasing Distant Star for the iPhone sales have picked up astronomically. As of version 1.5 the game includes all of the core features I originally laid out; consequently, I raised the price from US$1.99 to US$2.99. By this point it wasn’t the only 4X space game in the App Store, either — it has since been joined by 9 Colonies, Ascendency, and Vincere Totus Astrum. It’s good to have company.
My favourite insight from Distant Star’s unit sales isn’t from sales at all — if you look at the number of players downloading each update, it grows considerably with each version. Not only are people playing (and enjoying!) the game, they’re sticking around to see what happens next! The day the most recent update (1.6) went live it was downloaded by over 400 existing players.
So. freaking. awesome.
There’s also a shocking difference between the game being iPad-only and being a universal app. Make no mistake, I still think of Distant Star as primarily an iPad game — but it’s clear that I’m in the minority here. My efforts since releasing the game as universal have been directed mostly at improving player experience on the iPhone and iPod Touch. Everything is backported to the iPad version, of course, but Distant Star is now solidly a mobile game. Can’t say I ever expected that.
Before the iPhone release Distant Star was selling 3-5 copies per day. Don’t get me wrong; I didn’t write the game because I wanted (or expected) to make boatloads of cash. 3-5 copies a day was enough for me to call it a total success, and more than enough to keep me rolling out updates. After the iPhone release, however, Distant Star has averaged around 25 copies a day, with that figure increasing steadily with each update. We’re not talking Angry Birds-level sales here, but that’s not the point — I never thought I’d be working on a game with hundreds of active players and a small but growing community.
I’m getting more feedback from players than ever before, and each and every time I check my email and see a new bug report or feature request (or even just a “Hey, I love 4X games! You made one for the iPhone! Right on!” note) it literally makes my day. Keep ‘em coming!
I love you guys.
That is all.
There’s a lot going on right now with Distant Star — some of which I can talk about and some of which I can’t. Right now I’m adding in GameCenter support and production waypoints, both in response to specific player requests. The most recent update, 1.6, brought a ton of bugfixes and a respectable about of new content (a new Economics tech tree, graphical fleet management, smarter AI, &c.) — most of which also originated in “Hey, why doesn’t Distant Star have X?” emails.
I’ve got big plans for the short term, and even bigger long-term plans — keep an eye out on the App Store (and in game!) for updates, and on this space for news.
A day late and a dollar short, but Distant Star 1.6 is off to Apple for review. For the most part 1.6 is a bugfix-and-cleanup release, with a few new features stashed away. There’s a new tech tree for economics- and trade-related techs, plus a greatly improved fleet management screen. The main push of this release is under the hood, where I’ve revamped the AI system considerably in support of (eventually) implementing different difficulty levels. As a side-effect, the AI now remembers its current mission and progress across saves, and is considerably smarter about conducting research.
Unfortunately, two of my big goals for 1.6 haven’t happened yet: better zooming (i.e. zoom relative to the current position, not the galactic center) and a new trade ship for the Apparat. Next time!
Let’s start this off with a few assumptions: if you’re reading this blog, you’re probably a fan of 4X strategy games. You’re probably something of a space geek, and you probably have a soft spot for genre classics like Master of Orion. You also probably own an iPhone or similar.
If all of that sounds true, you need to check out 9 Colonies, a brand-spanking new 4X space strategy game for iOS. Where Distant Star takes after sprawling, grand-strategy-and-exploration games like Sword of the Stars, 9 Colonies is a more story-driven take on the 4X formula. All of the core 4X elements are present — research, colony management, turn-based strategy — but with each developed in a novel (and satisfyingly minimalist) way. It may veer a bit on the casual side (as does Distant Star), but 9 Colonies is an excellent take on the 4X space strategy for iOS. Go check it out!
I’m wrapping up the 1.6 update to Distant Star, which focuses on UI improvements. Big changes include a completely revamped fleet management screen, a more sensible ‘home system’ button, plus others:
A big thanks to Rorke and Daniel, whose ludicrously detailed (and unsolicited! So excellent!) bug reports/feature suggestions led directly to most of these changes. I’ve a couple more things I want to squeeze into this update (keeping the map centered on zoom, giving the Apparat a trade ship), but it shouldn’t be too long before 1.6 goes live on the App Store. Woot!
I’ve just submitted Distant Star 1.5 to Apple for review. In keeping with the general theme of updates so far, this version brings a mix of new features, new content, and bugfixes/improvements:
…and, hopefully, Distant Star won’t be either. In the last week or so I’ve made good progress on the 1.5 update, which will bring trade lanes, freighters, and (as a result) a more complex and flexible economy. Adding in trade affects almost every aspect of the game: new technologies, new ships, new stuff happening on the main screen.
There’s a lot left to go, though — I want to make sure that establishing and managing trade lanes feels like a natural part of the game, rather than something stuck in as an afterthought. Right now, only the human race has trade ships, and the AI remains blissfully unaware of their existence; obviously, this cannot continue. I also need to make it more intuitive to establish routes, and show how much wealth they’re generating. Whether this is through some sort of drill-down economy screen or something more clever I can’t yet say.
Just a quick note to say that Distant Star 1.4 is out. This update (finally!) brings pinch-to-zoom on the galaxy screen and a new spiral galaxy generator, plus some bugfixes and memory tweaks that should make the game run smoother on older devices (iPhone 3G and equivalent).
Last night I had a burst of inspiration. All this time I’ve been trying to implement pinch-to-zoom in Distant Star via various OpenGL tricks, like rendering the galaxy into a texture and mapping that texture onto a screen-sized rectangle — it works, technically, but the end result always looked just appalling. My burst of inspiration, of course, was that I didn’t need to scale any textures — in fact, I could totally fake it, and the result would be easier to render and look way better.
So, umm, that’s sorted.
Anyway, I’m testing pinch-to-zoom on all the devices I own, running it through a bunch of games and looking for bugs. One problem I’ve already found is that it causes a slightly slowdown in massive games with lots of AI opponents; it’s not game-breaking, just annoying.
I’ve also backported a spiral galaxy generator I whipped up last weekend as a proof-of-concept: large games are way cooler with legitimate-looking spiral galaxies instead of the rough grid they’ve used up until now. Take a look:
I’m insanely glad to be done with the iPhone port; these kinds of gratuitous features are so much more fun to write.
1.3 is (finally) out, which means that Distant Star is now a universal app for the iPad, iPhone, and iPod Touch.
57 commits, four months, two rounds of testing — it’s been a stupidly long road.
I’m still not done here, though. In the next couple of weeks I hope to take another look at zooming on the main galaxy screen and, if I’m feeling epic/ballsy, come up with a minimal diplomacy system. I’ll keep you posted.
The Distant Star iPhone beta is proceeding nicely, and I expect to wrap things up and get an update submitted to Apple within the next few days. For the most part, I’m receiving way more “Hey, it’d be cool if the game had…” suggestions than “So, this is broken…” comments, which is certainly nice.
In the interests of keeping folks informed on the inevitable feature creep, a few things that have been fixed or added as a direct result of beta feedback:
I’m forcing myself into feature freeze (no new stuff! None!) until I get this update out, as I’m aware that I’ve dithered forever over it and, really, this is getting unreasonable. A second round of betas goes out this afternoon, to make sure nothing’s broken before the release; a massive thanks to all who participated in the first round, and those now involved in the second.
Some folks in the Edinburgh gamedev scene (can I call us a scene? I think we’re a scene) are trying to re-found the long-defunct Scotland chapter of the International Game Developers Association. If you’re a game developer living/working in Scotland, especially a hobbyist/indie developer or a student, consider joining the IGDA and helping us get the new chapter off to a flying start. Membership in the IGDA is cheap, especially for students, and definitely worth the investment. Monthly meetings (like the weekly @GameDevEd), SIGs, demo nights, jams, you name it — help us get the chapter going and let us know what you’d like to see from a Scotland chapter.
Among other things, the IGDA runs the annual Global Game Jam — and for the last two years the Glasgow-based Scottish Game Jam has been among the largest and most successful jam site. I’ve been part of Scottish Game Jam every year since its inception, and it’s an absolutely brilliant experience; in fact, Levelheaded, an iPhone physics/puzzle game, is a more polished version my team’s 2009 jam game Jarhead (the rule for that jam was that a game had to take no more than a minute to play, hence the slightly ludicrous speed of Levelheaded).
Huzzah! Distant Star for the iPhone is almost ready to go — I’m soliciting beta testers for the iPhone version over at TouchArcade. Head over there and leave a post in that forum thread if you’re interested, especially if you’re a 3G or 3GS user.
*Technically speaking, this is Distant Star’s second beta; the first was for the original iPad-only version. Does that make this a delta test, then?
Because sometimes, you just want to play in Photoshop for an hour or two instead of writing code…
Also: new typographic buttons, but that’s way less exciting…
At last! I’ve resolved my long-standing issue with App Review — to make a long story short, don’t use developer preview versions of Xcode — and finished updating Distant Star to run seamlessly on the iPhone.
Distant Star for the iPhone will be released as a universal app, so if you already bought the game on iPad you’ll be able to download it for free onto your phone. I’ve just released an alpha version to testers on the 3G, 3GS, and 4 — once I hear back from them I’ll set up another beta on TouchArcade and we’ll see how that goes. Soon! Very soon!
While 1.3 works its slow way through Apple review, I thought I’d drop a little teaser for what I’m working on next for Distant Star:
Because Distant Star was designed with only the iPad in mind, making the UI work nicely on an iPhone (with and without Retina display) isn’t nearly as straightforward as I’d like.
I just released the 1.3 update to Distant Star to Apple. The big thing in this update, of course, is the re-worked tutorial & help system — but if you’re an old hand at the game (and, by now, there’s quite a few of those!) you won’t be disappointed, either.
In addition to the tutorial goodness, 1.3 brings another new race, the mechanical Apparat. The Apparat are a robotic race, which is reflected in their available ship types; they start the game with much of the Industry tech tree already researched, making them a formidable foe early on. Unfortunately, being robots they’re not terribly creative — so they’re slower to research new technologies than the other races; on the upside, they don’t need to breath, giving them an easier time when terraforming systems.
The research screen functions a little differently, too. Instead of tapping a technology to start researching it, now tapping merely selects, displaying a tooltip with more information about the selected technology. There’s a [Start] button down in the bottom right, which I think makes a little more sense.
Damaged ships now repair (slowly!) while in orbit over friendly systems; you can speed up the repair rate by researching in the Industry tree. Oh, and armor/shield status is displayed in the Fleet Management screen, so you can check to see which ships are healthy and which are in need of repair without having to throw your ships into combat. I’ve also polished several of the textures used throughout the game; it’s not much, but the whole thing should look a little shinier, somehow.
Hope you enjoy!
By far the most common complaint I've received about Distant Star is the inability to zoom out/in on the map. I can't argue with that -- it's a pretty obvious thing to be able to do, and certainly a feature that I've meant to include since the beginning. Unfortunately, it's taking me rather longer than I expected to get it working to my satisfaction. The experimental branch of the game has pinch zooming, but something about it just doesn't sit right with me. It's a little too finicky, a little to sensitive. So I'm still working on that.
That aside, it's been way too long since my last update to Distant Star, so I tabled (temporarily!) the map zooming project and spent the weekend grooming a less adventurous patch. This update brings a couple of critical bugfixes; in particular, tapping a [Ships Complete] notification should no longer cause an instant crash. I've also added a new race and made some modifications to the habitability system -- each race now has a preferred habitability rating, so we you should see more competition between players of the same race, which I think makes sense. Humans all want to live on relatively Earthlike planets, right?
The other big thing in this update is a major revision to the tutorial/help system. That sounds unexciting, I know, but I've noticed that Distant Star, like every other 4x game in existence, is pretty off-putting to new players. Lots of people seem to find the tutorial annoying, so I'm streamlining it by moving as much as possible into more unobtrusive, tooltip-style popups. Once the update drops, anytime you see a [?] icon you can tap it to get instant information about game systems, interface elements, whatever. This system is literally everywhere in the game; I've also added popups to the research screen, so you can get more information about what a particular technology does before you research it.
I still need a few days to go through and test everything, so I'll let you folks know when I push the update to Apple. Shouldn't be too long!
Apparently my last post alarmed a few people, who read it and immediately wrote me mildly annoyed/disappointed emails asking if I was really going to stop working on Distant Star so soon.
No! Of course not!
That really isn’t what I meant — all I meant was that I’m at a loss for what to do next. I’ve got a couple of other projects I want to work on, but Distant Star is definitely one of the more fun things I’m doing right now, and as long as six or eight people are still enjoying it, I’ll keep making it better. Deal?
Anyway, the answer to the ‘what to do next?’ dilemma was obvious, once I thought about it. Why don’t I just…ask? So without further ado: which features should I focus on next for Distant Star?
I’ll leave this up for a week or so, then I’ll tally up the results and get cracking on, you know, whatever wins.
After an initial rejection by Apple (apparently games aren’t allowed to use Game Center at all if they don’t have achievements or leaderboards?), the 1.2+ update for Distant Star is finally live on the App Store. It brings all of the updates I’d talked about before (a new race, color and game speed selection, usability tweaks) plus a fix for the autosave memory leak — meaning that it should crash much less often than it might have done in the past. Hurrah.
Unfortunately, I’m sort of at my wits’ end vis-a-vis Distant Star: I’m enormously pleased with the game, but I just don’t know what to do next. I’ve got quite a few projects on the horizon: the prototype for Polarity is pretty much complete, and getting rave comments from playtesters; my on-again-off-again collaboration with Drunken Monkey Games is still bouncing around; and I’m talking with barista-turned-XNA-ninja DriveByBaptism about putting together a clever little XBLIG platformer. So much to do! So little time!
Oh, and there’s that PhD I’m supposed to be working on…
In a shameless effort to avoid actual work, I’ve dusted off an old prototype for an iPhone game. It’s a quick little physics/rhythm/platform-y thing — can we use ‘Canabalt-like’ as a genre? — designed around a one-button interaction mechanic.
In other words, you tap. The idea grew out of my frustration with Levelheaded, an experiment into how short you could make a game and still have it be worth playing. It was basically a polished, iOS-ported version of my Global Game Jam game Jarhead from a few years ago. I might have gone a wee bit overboard with the rapid-play idea — games of Levelheaded take anywhere from two to fifteen seconds — but it was a fun little experiment. Unfortunately, it tried to cram in several non-obvious mechanics and a reasonably complex little simulation into those few seconds; obviously, it did a terrible job of communicating how it should be played, almost no one spent enough time with the game to really understand the mechanics. My bad.
Reverse Polarity is my attempt to return to the rapid play idea, but with greatly simplified mechanics and interaction. In fact, there’s exactly one mechanic (you’re attracted/repelled by things in the world) and one interaction (tapping swaps between attraction and repulsion). You can see where the name comes from (also, I was re-watching old SG-1 episodes at the time). Runs of Reverse Polarity tend to take under two minutes; the longer and faster you run, the more difficult it gets to continue. For the most part, gameplay is going to be mind-bogglingly shallow, with the focus on leaderboard-style competition. I’m tracking all kinds of stats for each run (e.g. speed, distance, air time, tap efficiency, &c), each of which will have its own distinct leaderboard. Mastered the art of building up crazy-fast speed? Ok — how about maximizing air time, or minimizing the number of times you reverse polarity?
Mmm, Game Center porn.
This whole not-owning-a-retina-display-device thing is getting ridiculous — this needs to be an iPhone game, instead of iPad-only. Poor little iPhone 3G — I love you, but you’re hopelessly out of date. Anyone got a newish iPod touch I could borrow for a few days?
So it’s been a few weeks, and the woefully necessary 1.1 update for Distant Star has long since live. 1.1 added a fleet management screen, an autosave feature, and the option to disable/enable the audio, plus fixed a number of distressing crash bugs. It’s been well-received (and the game’s average review rating on iTunes has certainly improved!), but definitely wasn’t the kind of content expansion to which I’d been looking forward.
1.2, which should go live in the next few days, is. It adds several gameplay features, including:
I’ve been on the hunt for memory leaks lately, and while I did track down several in time for this release I couldn’t pin down the largest two (on the build queue screen and, ironically, in the autosave system) before my self-imposed deadline. With my first meaningful update (1.1 shouldn’t really count) out of the way, my next focus is going to be solving the game’s crashtastic problem once and for all.
Well, that was exciting. Apparently I tagged the wrong version for my first release, and managed to send Apple a copy of the game as it existed right before I fixed all of the bugs. Ok, right before I fixed some of the bugs. But still.
At any rate, I’ve got it all sorted out now and a smoother, much less crash-tastic version of the game is currently writhing its (slow) way through Apple’s review process. In addition to not ceasing to scroll after loading from save (!) and not crashing approximately every 7.8 minutes (!!), this update adds a couple new features:
All that, plus a ton of bugfixes, patched memory leaks, and general slickification. It’s looking better now, folks. We’re good to go.
Distant Star is live on the App Store! Go give it a play and tell me what you think.
Now, if you’ll excuse me I’m off to go celebrate — where ‘celebrate’ means ‘add Gamecenter integration.’
Lots of progress on Distant Star — the biggest change is that I’ve added a tutorial, which was by far the most-requested feature the beta testers asked for. The map screen is a lot more informative now, too: fleets display their ETA and size (and, if you tap them, their composition), and the artwork for systems has been updated (as a system grows more habitable it looks increasingly Earthlike). That, plus a bunch of little bugfixes and minor improvements (AI is more aggressive, lots of re-balancing, a little more hand-holding in the interface design) — in fact, everything else that was left on my pre-release checklist. So, on that note:
Distant Star is off to Apple for review. Hurrah!
Tonight, we celebrate — I’ve finished enough of Distant Star that I’m releasing a copy to my beta testers tonight. I spent most of the weekend putting the finishing touches on a ton of polish — the game now has attractive victory/defeat screens and a framework for tracking and reporting gameplay stats, plus a really useful report that you can access after each combat showing you how well your ships fared in battle.
I’ve also put together a really solid Creative Commons-licensed soundtrack; the title track is “Two Swords” by _ghost. There’s some truly amazing stuff over on ccMixter just begging to be dropped into games. Free culture FTW.
Things are really cranking along now, which is good, because October’s almost over and my first-release deadline is almost here. I spent a good chunk of yesterday and today finishing up one of my last pre-release milestones, and as a result Distant Star now sports a functional, if somewhat limited, save slot system. You can access it via the in-game menu, which is another of those functional-but-terrifically-ugly systems (“Save!” “Load!” “Quit!”).
As part of the save/load system I also added a new game setup screen, where you can customize the game before starting. Right now it’s rather limited — there aren’t a lot of interesting customizations yet, ‘mfraid — but the interface is all there; it works and it looks pretty good.
Tomorrow and Friday I’m going to nail down the AI, and if I’m happy with the state of things I’m going to start passing the game out to beta testers over the weekend. Huzzah!
I couldn’t help myself. There are tons of important systems in Distant Star that still need a lot of work (like the non-existant save/load screens!) — but I spent most of the weekend putting the finishing touches on the research and technology aspect of the game. I’ve got four ‘trees’ — Combat, Industry, Defense, and Ecology — completely implemented. Every technology in those trees works; researching ‘Post-Keynesian Economics’, for example, actually improves the rate at which you gain wealth.
I also finished up the last of the combat mechanics (shields now actually work, and automatically recharge) and refactored some nasty code leftover from the prototype. Expect great things. Soon.
After a late night hacking I Distant Star finally has a tech tree. The research system isn't in place yet (so you can't actually do any research...), but all the interface for browsing the tree and selecting technologies is in place. The whole thing is totally data-driven, and insanely extensible. It actually supports multiple 'trees' -- each individual tree focuses on some aspect of your empire. There's a combat tree (better weapons and tracking speed), a defense tree (better armor and shields), and an industry tree (increased production and planetary efficiency). I've got ideas for a couple more trees (science, ecology, etc.) -- but the great thing about building the system in this way is that I can just throw the XML in later.
I'm incredibly pleased with the disparate tools I'm using to assemble trees. I start by sketching them out in a mind-mapping tool (the ever-awesome-and-surprisingly-free MindNode; that sketch feeds into a little Ruby script that spits out plist XML with some reasonable defaults for each tech. At this point I could drop the tree into the game -- but none of the technologies would actually do anything, so before I do that I go in and add an effect or two to each tech. It's surprisingly fun ("Hmm. What should 'Post-Keynesian Economics' do?"), and something I've wanted to do ever since I first played Civilization way back in the day. My very own tech tree!
I've been playing a lot of Civ V lately, which should come as no surprise to anyone. Anyone with even a passing interest in strategy games should give it a try; it's an interesting, albeit very safe, take on a well-established formula. What I like most about it, though, is the changes to the interface -- in previous iterations of the series large empires grew completely unmanageable in the endgame. Just hunting down all the cities and units that needed new orders in a given turn starts to feel a bit like work.
In V, they've introduced a nice interface element that greatly simplifies all of this management: at the beginning of each turn, a queue of icons appears, each representing some action or decision you should probably take during this turn. You can ignore them, of course -- but it's incredibly helpful to have the game tell you when, say, you need to pick a new tech to research or a unit is waiting for orders. It's not an original mechanic, by any means -- but it's incredibly helpful here.
Naturally, I've stolen it for Distant Star.
At the beginning of each turn in Distant Star you get a neat little stack of notifications along the left side of the screen. If something interesting has happened -- a ship was completed, a fleet arrived at its destination, a colony was founded or lost -- an icon appears to let you know about it and, if you tap it, give you more information. I'm finding that it completely changes the way I play, making the game feel like less of a chore. On each turn I scan through the notifications with my right hand, tapping any that I think need my immediate attention. With my left hand I take care of whatever needs doing, whether it be giving new orders to a fleet or queuing up another batch of frigates on an idle system. It's deliriously intuitive, at least to me -- and it completely does away with the tedious scrolling that characterized the game up until now.
A week ago I announced my entry for PoV's October Challenge, an old-school 4X space game (ala Master of Orion) for the iPad called Distant Star. I've made a fair amount of progress since that announcement; Distant Star has gone from a pile of half-finished tech and ideas to a rough playable prototype. Almost all the core features are in place: ship construction, exploration, colonization, combat. Of course, to be properly playable I needed a few basic AIs -- at the moment, you can play against two simple, deterministic AI players, each with their own play style (one colonizes recklessly, while the other builds up small fleets and attempts to capture one system at a time).
Introducing some simple AI players helped point out all kinds of multiplayer bugs I'd introduced so far -- turns out none of my fog of war code worked at all, and resource accumulation was completely borked. The first game I played the AI wiped me out almost instantly.
Based on some early, vicious usability feedback I've made some subtle changes to the map interaction, restricting scrolling outside of the galaxy and highlighting fleets or systems when they were selected. I also played around with a real-time version of the game, but quickly realized that, while it made the early game much more pleasant, things got way too hectic once the AI acquired more than a handful of high-quality planets. They started building ships far faster than the player, especially if the player's empire was quite spread out. Back to turn-based I went.
Up next: research management. Bring on the tech tree!
For the last few weeks, I’ve been hacking away on a medium-sized iPad game; I hadn’t planned on finishing it by October 31st, but (with your collective permission) I’m upping my deadline and making it my October Challenge entry. So, without further ado, I present, for the iPad-owning, grand-strategy-loving among you: Distant Star
Distant Star is an old-school 4x game (a la Master of Orion or Sword of the Stars) for the iPad. It’s a turn-based strategy game in which you explore the galaxy, assembling massive fleets to conquer your opponents and terraform their planets. Starting from a single system, you build starships, research new technologies, and colonize distant star systems — but you’re not alone in the galaxy. There are other races out there, with radically different needs, abilities, and psychologies.
Thanks to the couple of weekends and odd evening I’ve put in so far, the core of the game is more-or-less complete. You can build ships, assemble them into fleets, and move those fleets between systems. Obviously, there’s a lot of critical stuff left to write: the AI system is just a shell, the research/tech tree aspect is non-existent, and the entire thing is completely devoid of graphical shininess. I’ve also made my life significantly more difficult by attempting to support multiple orientations, but with some slight glTranslate/glRotate cleverness, this shouldn’t be too hard.
I have to confess: I’m not really making Distant Star for the October Challenge. I’m making Distant Star because I happen to have an iPad and I want to play an old-school 4x game on it. Unfortunately, such a thing doesn’t seem to exist, so I suppose I’ll just have to write it myself. Worse things have happened.
Anyway: Distant Star, coming for the iPad in early November!
Working with textures in OpenGL is a pain, for numerous reasons. Working with textures in OpenGL ES, where you have limited memory and a dearth of useful extensions (where art thou,
GL_ARB_texture_non_power_of_two?), even moreso. The biggest pain, IMHO, is the requirement that all textures be powers-of-two, i.e., the width and height of all of the textures you give to OpenGL must be a power of two.
32x32 is good, as is
1024x48 -- but
100x100 is right out.
I'm currently working on a project that involves a large number of small textures. At first, I was content to simply pad each of them out, adding extra space to size each up to the nearest acceptable size -- but I quickly realized that I was wasting a lot of memory doing so, and requiring OpenGL to manage an unnecessarily large number of textures in the process. The solution? Texture atlases.
And thus was born AtlasTool.py, a helpful tool for building texture atlases. And because bitmap fonts (another recurring frustration when working with OpenGL) are essentially texture maps in which each texture is a single character glyph, it was easy to extend the atlas tool into a more specialized version for creating bitmap fonts: FontTool.py. FontTool has some useful bonus features as well, like the ability to output font information as a property list-encoded NSDictionary.
…like everyone else I know who’s played the game, I want to remake it. It’s a shame, really — a couple of years ago I lived with a guy who was seriously into the game, and spent a fair amount of time working on a faithful remake (UFO: Cydonias Fall). If only I’d sat down and played it back then, I probably would have gotten seriously involved with that project.
But I didn’t, and that’s OK. Because playing X-COM causes me the same kind of frustration that other hybrid strategy/tactics games have always induced in me: after two or three battles I come to absolutely loath the tactical level. Which is saying something, because the battle mode in X-COM is, frankly, awesome — it’s deep and engaging, and it rewards intelligent play. Many times I’ve had my soldiers behave in certain ways out of a role-playing instinct only to have the game reward that behavior somehow. Plus, the experience of leading that squad into combat changes every time, with different weapons, maps, and mysterious, devilish opponents (goddam chryssalids).
But it just takes so much time!
My problem with this kind of hybrid design is the way it affects the pacing: at the strategic level the game moves relatively quickly, but as soon as I drop into a tactical level time stops completely. So I can spend five minutes playing at the strategic level, progressing the story by several game-days, only to spend the following half-hour fighting a battle that, relative to the world, takes no time at all. Do you see what I mean? Think of it as how much progression I’m getting from the game in exchange for my time — at one level, my time is buying me a lot of progress, a lot of story, but at the other my time is buying me nothing.
Eventually, actually fighting out the tactical battles starts to feel like work — it becomes something I need to get through in order to get back to the real game. Some games offer you a cop-out and let you auto-resolve battles, but usually with the odds of victory dramatically reduced (Total War:Whatever, Mount & Blade); this is a fine idea, except that it makes fighting battles — which is probably the focus of the game — the responsible thing to do.
See? It’s like work.
So how does my desire to make an X-COM remake fit into this? I’ll tell you — I want to make a high-level strategy game without the tactical component. X-COM or Mount & Blade, except instead of going out yourself to lead your troops in battle, you stay back in your secret base or secluded castle and direct the action from afar. In most of hybrid strategy games I’ve been describing, the strategic level feels like the unwanted stepchild — a part of the game the designers felt needed to be there, but about which they weren’t terribly excited. It’s as if the larger game exists only as a means of moving you from battle to battle.
But imagine how great that part could be if the developers had given it their complete attention — how much depth and complexity you could squeeze into that high level gameplay if you didn’t have to spend time on combat, on unit animations, on battle mechanics.
It could be awesome.
A few weeks ago one of my flatmates picked up my iPhone and started playing with it. She flicked through a couple of the games, but was totally stymied by whatever clever touch/accelerometer/virtual gamepad control scheme each used. Saucerlifter? Nope. Levelheaded? Not a chance. There were only two games she was actually able to play: Robot Reaction and Canabalt.
This was insightful for me because, as a developer and as a gamer, I really enjoy exactly the sort of games that she finds frustrating. Over years of play I’ve become (like any gamer) well-versed in the vocabulary of games — the metaphors, control schemes, and whatnot that define how players interact with the game. If I go out and buy Call of Duty N I can be playing (and enjoying) it in a matter of minutes. In terms of a tutorial all I need, as a gamer, is something that explains how the game differs from the Abstract First Person Shooter that I already understand. Gears of War is immediately accessible to me because I’ve played Halo, which was easy to pick up because I’d grown up playing Marathon, and so on. Dwarf Fortress is learnable (accessible might be a bit of a stretch) because I’ve played roguelikes and city-building games — but it’s difficult because the mental diff between these games and DF is enormous.
Non-gamers don’t have these internalized abstract games, though, which makes it incredibly difficult (I think) to design complex games for a traditionally non-gamer audience. For certain games you can get away with it; Smiles works because many of its players are already familiar with the match-three mechanic (thanks, PopCap), and it develops that core idea in interesting ways. If you haven’t played Bejeweled or Tetris Attack, though, it’s qualitatively no easier for a non-gamer to pick up than, say, Starcraft. Quantitatively, of course, it’s way simpler — I think it’s fair to say that match-three is a fundamentally simpler idea than the smorgasbord of metaphors that is real-time strategy. My non-gamer flatmate, for instance, has never played a match-three game and was unwilling to invest the effort to learn the metaphor in order to enjoy Smiles. So what’s different about Robot Reaction and Canabalt?
If you think in terms of background knowledge the answer is really obvious: neither one makes any assumptions about their players’ gaming history. Canabalt may be, in terms of genre, a platformer — but you don’t need to have played Super Mario Bros. in order to get it, and it won’t really help if you have. It takes a single idea (tap to jump) and explores that idea in interesting ways. Similarly with Robot Reaction, whose mechanic is so simple that it’s difficult to assign a genre label to it. Non-gamers can pick up these games and learn the metaphors they need to enjoy them, and they can do it in a single play. This last bit is important.
This is, I realize, was my biggest mistake in Levelheaded. To enjoy the game you need to understand several metaphors (using seed orbs to spread color, how orbs affect the water level, how orbs interact with each other), none of which is easy to learn in a single play. A glance at the leaderboards for the game shows that most people play it exactly once, fail miserably, and then never touch the game again. Looking at the OpenFeint profiles for these players shows that they’re a mix of gamers and non-gamers — why do both groups have the same difficulty understanding the game?
The answer, of course, is that in this case they’re the same group. The metaphors you need for Levelheaded don’t exist in most players gaming vocabulary, so when a new player picks up the game it doesn’t matter if they’ve been playing games since they were seven or if it’s the first game they’ve ever played — everyone’s a non-gamer when the metaphor of the game is novel. In order to get Levelheaded you really needed to have played Jarhead, which gives it a global audience of about twelve people.
The take-away lesson? Keep in mind what metaphors you’re expecting the player to bring to your game.
I’ve been noticing a trend lately, where my various personal and professional lives are bleeding into one another in awkward and uncomfortable ways. I’ve got several academic papers undergoing conference review at the moment, papers that are incredibly important to my grad student persona. At the same time I’m refocusing on game dev as I wrap up an update to Levelheaded and start work on a new project. Up until now I’ve been using my personal site for all of these things: it hosts the research data for my papers and the about pages for my LD- and jam-type games, plus various odds and ends that don’t really have a home, but need to be on the internet somewhere. Last week, a DNS goof on my part meant that all the traffic from one audience (conference reviewers) got redirected to the wrong page (the Levelheaded promo site).
So I’m setting up this as a space where I can focus on game development, Ludum Dare and otherwise. I’m pretty new to Movable Type (the publishing system that both this and Texas Expat are built on), so I expect to be hacking on this site regularly since it doesn’t quite do what I want yet. I guess we’ll see how this goes…