Sunday, March 23, 2014

AndroidLovesKitty 1.0d


One more update brought on by reviews. There is a bug in 1.0c that causes the game to crash when the Vizier is defeated. He is the boss of the Hatching Chambers. The issue occurs because the game tries to create his special boss item at a position that does not exist. It was an easy bug to fix and I'm not sure how it made it through playtesting, but it has been fixed either way.

You can download it here (for Windows).

I encourage anyone playing through casually to download 1.0d instead of 1.0c. This bug fix is the only change. However, fair warning: it was definitely created outside of the 7DRL period. Reviewers will need to use their own discretion on which version is more "pure". Personally I would suggest 1.0d, but that's not my decision and it is worth mentioning that several reviews have already been created under 1.0c.

Minor (unrelated) administrative note: @Star Wars download links have been removed from the sidebar to reduce clutter. @Star Wars has not received an update in over a year and is a very incomplete experience (compared to Dead Man Walking & AndroidLovesKitty), but it is an important part of my forray into roguelike development. For that reason I'll be leaving the files in my public dropbox and anyone interested can peruse the blog for direct links.


AndroidLovesKitty Source [7DRL]


I was looking over some of the early reviews for AndroidLovesKitty and one of the reviewers pointed out the lack of source code. This was not a deliberate decision on my behalf - I have a history of providing source code and had every intention of doing so with AndroidLovesKitty. I just forgot in the midst of hammering out last minute bug fixes and the like.

Here's a download link to the "devkit".

This is basically just the environment I personally used while working on the game. You will likely need to acquire your own versions of Python and Libtcod. I use Python 2.7 and Libtcod 1.5.0.

The "hook" script can be used in conjunction with py2exe to create an .exe of the source.

Fair warning: reviews for AndroidLovesKitty have been quite positive thus far, but that hardly means I'm a good programmer. It's quite a mess, but I'm happy to try and explain any unclear elements. Feel free to hit me up here on the blog or on twitter.

Also worth mentioning that the source provided corresponds to game version 1.0d. It contains the recently announced bug fix from 1.0d, but is otherwise the proper 7DRL version.


Sunday, March 16, 2014

AndroidLovesKitty 7DRL 1.0c


I've just rolled out the 1.0b (now 1.0c) patch for the 7DRL version of AndroidLovesKitty. It's still within my 7DRL period, so I'm just going to replace the 1.0a link with 1.0c.

Spoilers below (download on the sidebar)
  1. Reduced the speed of Riftwalkers.
  2. Slightly reduced the spawn rate of Hulks.
  3. Added in a counter for bosses defeated at the end of the game.
  4. Slightly reduced the rate at which medkits are generated.
  5. Greatly reduced lag caused by enemies that demolish walls (e.g., Hulks).
  6. Fixed an issue where the game would crash if the player moved onto the stairs on the final floor.

AndroidLovesKitty 7DRL 2014 Release!


My 7DRL for this year is pretty much done. You can get a better idea of what it's like from my previous blog post.

It's a game where you play as an android and your pet cat has been stolen by aliens. Of course, being an android, you can't exactly go fisticuffs with the alien swarm - that'd be against your code of conduct. A convenient loophole is that you can use explosives to send the aliens back to the stars. You can also do other fun things with your bundles of boom, like carve out your own dungeon features or jump around!

If that sounds interesting enough to you, download it here (windows only).

I'm going to release a post-mortem soon, possibly tomorrow (no promises). I may squeeze in a last minute hotfix tomorrow if I discover any issues (I didn't start until Monday, so my conscience won't be too bruised). I may do additional work on it post-7DRL as well, like Dead Man Walking, but that depends entirely on how inspired I am in the coming weeks.

I welcome feedback. Feel free to comment on this blog post or send me a tweet.


Wednesday, March 12, 2014

AndroidLovesKitty 7DRL Preview


The annual 7DRL challenge is underway (and has been for a couple days now) and I'm participating in it. My entry this year is a game that is NOT inspired at all by Bomberman, Star Trek, or Metroid. Indeed, the game has changed titles many times but right now I'm calling it "AndroidLovesKitty".

It's a fairly straightforward game. Anyone who has played Dead Man Walking should feel pretty at home in regards to the aesthetics and certain other features (like dungeon generation). Perhaps the most startling thing is that bumping into enemies is a worthless exercise. You see, the hero in this story is an android and he is barred from engaging in direct physical combat. Thankfully, he's got a nice little loophole in that he can plant explosives. This is helpful when one wishes to defeat an alien horde and rescue a cat.

Here's an example of our beloved hero in a bit of trouble. Thankfully, he's set up a bomb (the orange asterisk) and it's just about to blow up that horrifying alien. Hopefully, at least. Bombs have a limited blast radius (just one tile surrounding them) and so a bit of planning is required in order to setup adequate bombs.

Looks like it worked out for him. Sure, bombs are dangerous and they require a bit more timing than just hacking and slashing, but they do quite a bit of damage. In fact, by design, many enemies in the game will fall down to a single bomb.

One of the goals of the game is to avoid simple, flat items. Each item should provide some level of interactivity. Here the hero has a pair of boots on and is able to get a nice jolt of speed after running in the same direction for a while (thanks, Sil).

What's going on here, you might ask. Good question - our hero has setup a bomb (the 3 below him). Bombs are "animated" in the most basic sense and will automatically switch between the asterisk and the number (which represents how many turns it has left until it explodes) occasionally. Now, with that out of the way, one might ask why our hero has chosen to place a bomb there when the alien (the "h") is clearly more than 3 tiles away. Well, our hero is attempting to bomb jump - a simple enough tactic based on the fact that bombs have immense and predictable knockback. Someone willing to take a little bit of risk can cover a surprising amount of ground with a bomb jump.

Here's the result of the aforementioned bomb jump. It allowed our hero to cross a whopping 8 tiles, although at least part of that is thanks to a different pair of boots: the "high jump boots", in this case. Still, even without fancy jumping boots one can cover a surprising amount of ground with a bomb jump. They can also be used to knock enemies around, which can be a useful tactic against heartier foes. Of course, it can also be used to knock them towards you, which is maybe less ideal.

In this picture our hero has acquired the legendary "hockey stick", a fairly simple tool typically used when playing hockey. A little known fact is that it can also be used to set bombs up to 2 tiles away (typically the player can only set bombs in the tiles immediately adjacent to them). The trade off here is that bombs do slightly less damage, although the upside is likely worth it (at least in this case).

One common downside to bombs is that they tend to cause some structural integrity. Wait, downside? Not so much. Here our intrepid hero has carved out a nice hallway for himself which conveniently connects to what looks to be a fairly large room in the normal dungeon. A watchful reader may note that a substantial number of bombs were spent in making this hallway. Indeed, making full sized rooms will likely not be a common thing. Still, even the most resourceful player will likely seem some use in "wasting" a bomb to blow up a hallway.

So that's the end of my little preview of "AndroidLovesKitty", which should be done by Sunday (at least the 7DRL version). A beta version maybe released on Friday.

The game is based on the framework of Dead Man Walking, which itself was based upon @Star Wars. As one might expect, all of the content is new and all of the gameplay mechanics are new or have been altered substantially.

If you've read this far, I apologize for lying to you in the first paragraph. The game may be partially inspired by Bomberman, Star Trek, and Metroid, amongst other things.


Monday, February 17, 2014

2014 7DRL Challenge


We're just about due for the annual 7DRL challenge. It starts on March 8th and runs until March 16th. I've had some ideas bouncing around and I've decided to participate for a second time. I won't reveal too many details just yet, mostly just because I'm still ironing them out.

I feel like now is as good a time as any to step back and consider what I gained from the previous 7DRL challenge and why I want to do another one.

First off, 7DRLs by their very nature have pretty straightforward deadlines. You either release a winnable game within 7 days time or you don't. Pretty simple. The subject of whether or not development on a 7DRL is a bit controversial and one I've covered briefly before. But it's also pretty irrelevant to the main point: the original 7DRL release of Dead Man Walking was a complete and winnable game. That seems like the natural goal of a 7DRL or any deadline for a video game, really.

Having to release something in 7 days time, even working with a code base I'd written for a previous project, was not the easiest task. But it was an important one - it forced me out of design. I didn't have the time to waste constantly redesigning core game mechanics or I would fail the challenge. On a personal level, I wanted to succeed more than anything, so failing was not an option I considered valid.

Dead Man Walking itself did pretty well, even just as a 7DRL release. According to the Rogue Temple evaluation Dead Man Walking scored a bit above average. It wasn't a standout success, but that's okay. In terms of retained popularity, it also did fine (at least according to blog analytics). Some of the Dead Man Walking posts here take some fairly high scores in terms of view count for the blog as a whole. Still, overall I'd be lying if I said it was super popular - but that's deserved. I didn't do a lot to advertise it or network or anything fancy. I posted it to a few places I regularly visit, but I didn't really try to "sell" the game at all.

I would say that level of success is about where most of the successful 7DRLs wound up, though there was some notable exceptions. Perhaps the biggest success to come out of that challenge was Michael Brough's absolutely fantastic 86856527.

Another thing I learned while doing the 7DRL is a thing I had been slowly converting towards on @Star Wars and that is the concept of having simpler mechanics. I'd say it's quite an important element of most successful 7DRLs, though perhaps not a literal necessity. I enjoy the game design process quite a bit, but it can be a bit of a trap. It's pretty easy to take a neat idea and convolute it to the point of worthlessness. This is where simplification helps. One of my goals with Dead Man Walking was to try and distill the mechanics down to their bare bones and let the challenge emerge out of interesting scenarios. It's debatable how well this actually worked, but it was a definite goal. And it's a goal I will pursue once more when making my second 7DRL, because I think it's a big part of why Dead Man Walking was not terrible.

I suspect the new game is going to end up being a bit more ambitious than the original Dead Man Walking was. Hopefully I can use whatever ability I've gained over the past year to manage that ambition and trim it down if needed. To wrap this up, I plan on releasing a few more details over the next couple weeks as I get more details finalized.


Friday, December 13, 2013

Roguelike as an adjective

Lately I've noticed an increase in the amount of discussion surrounding the use of the term "Roguelike" and how it should be applied to games. Now, I've been aware of the Roguelike scene for approximately four years now (small fry compared to some, I know) and the topic of the name of the genre itself is something that comes up arguably too often. It is, at its core, an entirely semantic discussion and not necessarily one worth having - certainly not one worth alienating people over. Still, to completely ignore that, let's go over it real quick.

First off, a Roguelike in the strictest of senses is a game that is like Rogue. To go even deeper, Rogue is a dungeon crawler and a dungeon crawler is essentially a focused role-playing game. I like to describe Rogue (and roguelikes) as stripped down RPGs and I mean that in the best way possible. They typically forgo elements such as a gripping story or immense graphical fidelity and instead focus on gameplay mechanics. This is almost certainly the main reason that Roguelikes are pretty common amongst hobbyist game developers. You can make a traditional Roguelike and essentially just worry about programming. Still not a small task, but definitely simpler than programming plus art assets plus music plus writing. Anyways, it's generally pretty easy to spot these traditional Roguelikes. ADOM, NetHack, Angbang, and Dungeon Crawl, along with many more, are all fairly straightforward in the sense that they are definitely Roguelikes and you'd be hard pressed to find someone who disagrees.

Once you start to look past the traditional Roguelikes things start to get muddy fast and people disagree heavily on what "counts" as a Roguelike and what doesn't. Some will compromise and try to use terms such as "Roguelikelike" or "Roguelite", though I personally am not a huge fan of either term. The term "Roguelike" is already pushing the border of clunkiness, no need to stretch it further. The controversy here seems to be from certain games such as the Binding of Isaac, Spelunky, Rogue Legacy, and FTL using the term Roguelike or having it associated them without literally being a traditional Roguelike. Is it wrong that games with Roguelike elements use the term even though they aren't literally ASCII turn-based dungeon crawlers?

If we look at the mechanics surrounding a typical Roguelike, I think we can conclude that it was inevitable for more and more games to eventually pick up on Roguelike elements. As mentioned, Roguelikes tend to forgo aesthetics and focus heavily on mechanical depth. Without strong mechanics, a traditional Roguelike has nothing - so developers try to create that out of both necessity and tradition. Roguelikes, in a lot of ways, were ahead of their time - some types of AI design and procedural generation first gained real traction in the Roguelike sphere. These types of mechanics are not things that are uniquely desirable to Roguelikes - being able to generate a world with an interesting ruleset is something that could be interesting in basically any genre. For example, the Binding of Isaac can be seen as a top-down shooter incarnation of Roguelike mechanics and Spelunky can be seen as a platformer incarnation of those same mechanics.

Basically, I'm not convinced that using Roguelike as an adjective like some of the aforementioned games do is a terrible thing. While they aren't strictly Roguelikes as according to the Berlin Interpretation, I don't believe that is such a terrible sin that we as a community should excommunicate all games that don't meet a rather strict definition. These games definitely share in Roguelike design, at least in a mechanical sense, and that's something that can benefit Roguelikes as a whole. In conclusion, try not to let your world be rocked by genre names and how they're used - at the best of times they're opaque descriptors, at the worst of times they strangle design and send fans into a frenzy.