Sunday, October 19, 2014

Turn-based Speed

Speed in turn-based games is a rather heavily abstracted concept. This isn't a big surprise in Roguelikes which are effectively defined by abstraction. Still, I think speed in Roguelikes has a tendency of being unusually spoilery for something that is relatively significant. This is because the way speed works is rarely something that is spelled out for the player and must instead be inferred through gameplay.

Many Roguelikes that implement a speed system for movement essentially just make it so characters lose or gain a free turn based on relative speed differences. For example, in Dead Man Walking, a character with a speed value of 20 will get to move twice per single move of a speed 10 character. Some Roguelikes choose to take this even further and include numerous, less obvious speeds (like the difference between speed 11 and 13). Some also choose to incorporate an element of randomness into the movement (Dungeon Crawl Stone Soup).

In general I do not have a problem with speed systems in Roguelikes as a player. But, as mentioned, I do find them to be relatively spoiler-y in many cases (i.e., understanding them fully requires external assistance). This is especially true if the game uses the aforementioned granular speed differences and random speed boosts.

One of my goals with Dungeon Brawl (the now-official title of the new project) is to avoid unclear mechanics. Movement and positioning meant to be very important. In my mind that means a speed system designed for it would need to be so complex that it demands spoilers or so insignificant that it might as well not exist. Or it could instead be redesigned to become a much more explicit concept that also conveniently fits the theme of fighting games pretty well.

The speed system in Dungeon Brawl is effectively an abstracted form of acceleration. Characters moving in a single direction for several turns will begin to move two tiles in that direction. Currently this just applies to player characters, though I intend to expand to apply it to enemies soon. The basic idea here is still the same as traditional speed systems in Roguelikes, but it is deliberately designed to function on a much more interactive level.

In my (limited) playtesting thus far, the acceleration system offers a lot of intimate tactical decisions. For example, I might run into a room with full momentum. Now I have to face the decision of whether to keep that momentum alive or switching directions to improve my position or aim at an enemy. This is a fairly basic example, but hopefully it's clear how the new system can have definite applications in regards to how to retreat, how to approach enemies, and just generally how to engage in combat.

As a teaser/example, here are the basic characters' "minimum momentum" scores:

Lily: 1
Norm: 2
Fat Mac: 3

The number refers to the number of turns a character needs to spend moving in a direction before they start to move two tiles per move. The "last direction" arrow I showed off in a previous post will update to show when the player has surpassed that point (compare above, bottom left of the screen).


Saturday, October 18, 2014

Interface Intricacies

Working with the new game and trying out a variety of Roguelikes over the summer has made me far more cognizant of the importance of UI, colors, and the symbols themselves in Roguelikes. Thus, I've tried to incorporate a variety of new ideas (for me) into the new project that help create a more responsive, interactive dungeon crawling experience.

In the bottom left corner of the above screenshot is the core UI. The blue diamond represents the player's shield, the red heart represents the player's hit points, and the green club represents the player's ability points. The idea here is to create an almost Zelda style information depot that gives an accurate, quick report of the player's most important stats. This section of the UI is still undergoing constant revision to make it look better and include more stuff (without being bloated). Eventually it will support at least one more stat (cash on hand) and feature a status effects area.

On the dungeon map I've been tinkering with the idea of using the wall colors to communicate information. By default the walls will display a limited variety of mundane colors that are deliberately designed to avoid calling attention to themselves.

However, when something interesting happens, the wall colors will shift to grab the player's attention. In the above screenshot, I got punched by a lonely gnoll and the visible walls shifted from mundane to bright pinks and purples. This is a consistent effect that occurs any time the player takes damage.

Other effects can occur too, although I'm still working on them and don't have screenshots. For example, some enemies can entangle the player and prevent movement. This causes the walls to take on primarily green colors while the player is stuck.

This is a relatively new system and I'm still trying to work out color values, frequencies, and what exactly should trigger it. It's worth mentioning that I plan on adding a toggle to disable the color shifts for players who'd rather not have them.


Thursday, October 16, 2014

@ or @

So, roughly last week (early October), I came back to Roguelike development with fighting games on the mind. Images and discussions of the new Super Smash Bros. began to overtake my regular virtual watering holes and it was hard to resist inspiration. And thus, my latest project was born. It's designed to be a kind of "zany", fast-paced Roguelike that takes a lot of cues from fighting games.

Each one of the player characters is being designed as a personality instead of as a class or race. Each one of these characters has unique stat distributions: speed, damage, weight, and hit points. Beyond that, each one of them comes with three unique abilities (ZXC) that are designed around a system of positioning and momentum.

I didn't want to make a game that was inspired by fighting games to feature an unhealthy level of menu surfing, so I needed a way for the abilities to work. Abilities in the game come in two flavors: aimed and dumbfire. Dumbfire moves can be tapped and they'll generally affect everything on the screen (or just the player character). Aimed moves look at the last direction the player moved or attacked in and go in that direction.

In the above screenshot, I'm the sea green "@" and I just punched the red "d" below me. The "d" (fightbot) is normally white, but has a simple animation to flip to red after being hit. In the bottom left region, there's an upside down triforce. This is not actually a triforce, but a directional arrow showing the direction that the player last acted. These two relatively basic (and still under development) features help the player keep track of the battle and aim abilities more easily.

If I tap "z" in the screenshot shown above, then I will use an ability based on my character. In this case, I'm playing Lily - a lightweight fighter with a plant theme. Lily's "z" just so happens to be an aimed ability called Flower Whip, which hits a foe "in front" of Lily and sends her backwards.

In total there are four "complete" characters available, one of which is a secret character. The other three characters are designed to fit into a fairly basic fighting game archetype.

Lily, the lightweight champ. Doesn't hit very hard, highly susceptible to knockback, and moves substantially faster than the other characters.

Norm, the jack-of-all-trades. Effectively the "human" of this game, Norm has no notable weaknesses or strengths.

Fat Mac, the heavyweight slugger. Moves slower than all of the characters, but is exceptionally good at throwing enemies around the battlefield.

Jet, it's a secret to everybody.

There's also a lot of more traditionally Roguelike-y stuff going on, even more than what I did with Dead Man Walking and AndroidLovesKitty. I plan to go over some of that stuff in the near future. I also have plans for at least two more cast members, some information about unlockables, and other cool things.

I'm going to push an alpha release out the door in a week or two when there's a bit more content. Currently I'm quite satisfied with the character designs, but I want to get some more items and enemies in before I go public. Keep an eye open!


Monday, August 11, 2014

Resource Management

Managing your resources is one of the core gameplay elements of most Roguelikes. Resource management in major Roguelikes typically involves keeping a close eye on one's hit points, spell/mana points, ammo, scrolls, and potions. Both of my previous games have featured very limited resource management and I think this is one of their major flaws. Thus, in WWRL, I'm working on creating more interesting and valuable resources.

In Dead Man Walking the only real resource to manage were hit points. However, thanks to a combination of passive regeneration and the willpower system, players could just simply retreat from most fights and the one resource solved itself. That was an interesting system, but overall flawed because it never really imposed a permanent cost on the player. Resource management in Dead Man Walking was very transient, its impact could only be felt for maybe 20 turns.

In AndroidLovesKitty I tried to make resource management slightly more interesting. There is no willpower and no passive health regeneration, so damage has a lasting impact. Unfortunately, AndroidLovesKitty was very generous in giving out health packs and it was very possible to avoid ~90-95% of all damage in the game. Both of those are arguably acceptable, but not when its the only real resource the player has to manage in the game. There was also the bombs "resource", but the player had 99 bombs for every level. The limitation was only really put in to prevent the player from blowing up every wall of every floor - it does not function as a resource nor was it really meant to.

In WWRL I'm trying to find a nice balance of both games plus adding in more resources overall. There are currently five core resources in the game: hit points, stamina points, money, bombs, and arrows. Hit points currently function pretty similarly to how they work in AndroidLovesKitty: no passive regeneration, health packs, and the player can avoid most damage with clever positioning. Stamina is a new resource for WWRL that is deliberately meant to be transient - the player can easily spend an entire pool of Stamina and regenerate it back in ~20 turns. Stamina is required to attack and the cost goes up as the distance between the player and the target increases (think of it as a cost for lunging). 

Money will primarily be used at randomly discovered merchants that will sell bombs, arrows, miscellaneous things, and a variety of equipment. Bombs function as they do in AndroidLovesKitty - they can be used as a burst of high damage and as a way to destroy walls. Unlike in AndroidLovesKitty, bombs are actually quite rare and the player starts with few of them. Arrows (along with a bow) give the player an attack option if the foe is out of melee range. Because of the game's focus on positioning and melee arrows are incredibly valuable as they can simplify dangerous situations. Arrows are, deservedly, quite rare - players should not expect to be able to play as a fully ranged character.

The goal of resource management in WWRL is to reward the player for being adaptive and create unique situations for each playthrough. Consider the hypothetical player that has been playing quite well in melee until recently - they encountered a dangerous enemy they weren't prepared for and are now one hit from death. However, thanks to this player's melee ability and a bit of fortune, they have a considerable number of bombs available. If the player now adapts to the situation, they should be able to recover their run by defeating the next several foes with bombs while searching for health packs. Thus, the resource management in WWRL will allow for tense situations to arise and also allow for crafty players to defuse those same situations.


Saturday, August 9, 2014

New Project & Weapons

Over on my twitter I've been teasing at a new Roguelike project I'm working on. It seems appropriate to also announce it here on the blog and discuss some the ideas going into the game. I plan on writing a couple of these posts to go over the design of the new game (temporarily named "WWRL").

For this post I'm going to go over some of the new weapon designs that are going into WWRL. Each weapon in WWRL is meant to provide a distinctive style of play and feel genuinely different.

  • Swords: the most basic weapon type. Functions identically to how most weapons work in Dead Man Walking (i.e., 1-tile range, no area-of-effect, no special effects).
  • Spears: similar to the sword, but with an extra tile of range.
  • Flails: Now things start to get a little more interesting. Hits up to 5 tiles around the player, excluding the three "behind" the player (based on the direction they swing).
  • Axes: Abandons the traditional bump to attack and instead attacks enemies as the player moves.
I'm still working out some ideas related to weaponry (movesets, ranged weapons), but the above four are solidified as far as design goes and just need testing. In the next post I'll go over the scope of WWRL and what my goal with it is.


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.