How to Play Dungeon Dual

4 min read 7drl7drl2014dungeondualroguelikesUncategorized

My successful 2014 7-Day Roguelike entry is Dungeon Dual!

You can read some of the unexciting progress here on 7drl.org.

So, now that I’ve had a few hours to recover, here is

How to Play Dungeon Dual

Co-Op

You can play with a friend! This is accomplished through the wonderful magic of WebSockets. You don’t need to play with a friend, but you may want to.

After you start a game, you can send the URL to your friend. It will also show up on the main page until someone joins.

Each game is totally asynchronous, which means you don’t have to wait up for the other player. This is one thing I hate about other attempts at “multiplayer” roguelikes. In Dungeon Dual, the classic turn-based roguelike mechanic is unbroken.

However, if you have an ally certain tactics are available:

  • You will regain stamina faster
  • You can trade items
  • You can chat and share knowledge of items/levels (e.g. “hey don’t drink this one, it’s poison”)
  • Certain abilities can be used cross-realms:
    • The Apprentice can shoot fireballs and cast entanglement onto the other screen, affecting your ally’s enemies (hopefully you don’t set your friend on fire in the process)
    • The Apprentice can banish monsters to the other screen
    • The Squire can use Warcry and Defend on the other screen to aid his ally
These features will only be possible when you and your ally are “in sync”. This is determined by a fuzzy algorithm that takes into account both spacial distance (how far away are you on the grid of the same dungeon level) and time, which is determined by turn count. The game will try to help you out and give hints when you are out of sync such as “Hurry” or “Wait” or “Change levels”.
From a technical perspective, the WebSockets server needs to be running for co-op to work. It runs on my webhost, but seems to die every now and then. If you notice it is offline, try to reach me via e-mail, over IRC on #rgrd, or via twitter. Server status is displayed on the main dungeondual.com page

Basic Mechanics

There are two stats in the game: Health and Stamina.

Stamina

Stamina is used to cast spells and abilities. It recharges over time, but not if you are in combat or are poisoned. Flasks of Vigor will instantly refresh your stamina and increase your maximum by 1. Stamina also scales damage of certain spells like fireball and forcebolt.
Stamina is also used up when you take damage in combat. Be sure not to take on too many enemies at once or you will not be able to recover!

Health

Lose all of your health and you are dead. Once your stamina is gone, any damage will go directly to your health. Health does not recover naturally, but can be restored using Flasks of Health. Flasks of Health will also increase your maximum health by 1. 

Abilities

Both classes have unique abilities. You can quickly toggle them using the 1-5 number keys. You can also access them from the ‘z’ menu. Abilities are activated by pointing and clicking with the mouse. Clicking on your ally’s screen will use the ability on their screen instead.

Fireball
Apprentice ability. Engulfs a 3×3 grid of enemies (and potentially you) in a ball of fire. Damage scales with maximum stamina. Can be used with allies.
Entanglement
Apprentice ability. Stuns a 3×3 grid of enemies for a short period of time. Can be used with allies.
Forcebolt
Apprentice ability. Casts a powerful bolt of force at a single target, with damage scaling with maximum stamina.
Banish
Apprentice ability. Sends a single enemy across the realms for your ally to deal with. It might be a good idea to warn him or her in advance!
Charge
Squire ability. Enables you to dash across the screen and attack an enemy in a single turn, as long as they are at least 1 square away. This is great for hunting down pesky archers and spell-throwers.
Warcry
Squire ability. Unleashes a terrible roar that scares all enemies in sight, causing them to flee for a short period. Great for clearing a room or cornering a troublesome enemy. Can also be used with allies.
Defend
Squire ability. Temporarily boosts your (or your ally’s) defense, protecting you against damage. Can also be used with allies.

Flasks

You will find a few (six? seven? I forget) types of potions (or “ye flask” as I call them) scattered across the dungeons. Some are bad, most are good. In standard roguelike fashion, you will not know what they are until you try them for the first time.
Vigor
Also known as flasks of stamina, these will refill your stamina and also boost your maximum by 1. You will almost always find a flask of vigor or health on each level.
Health
These flasks are critical to survival in the dungeons. They will refill your health and also boost your maximum by 1. You will almost always find a flask of vigor or health on each level.
Fire
Drinking from this flask will cause you to burst into flames. Generally speaking this is a bad thing.
Weakness
The contents of this flask will drain you of your stamina. Try not to taste it during combat.
Might
Doubles your melee damage for a few turns. Time the use of these wisely.
Invisibility
Temporarily makes you invisible to all enemies. Great for getting out of a sticky situation.

Other Equipment

You will find armor and weapons in the dungeon as well.
Armor
At this point in the game, armor doesn’t do much other than subtract potential damage from monster attacks.
Weapons
You will find an increasingly deadly array of weapons in the dungeon. Some have special effects such as piercing (attacks an enemy behind your target), smashing (attacks all surrounding enemies), and stunning (stuns enemies 1/3rd of the time).
Hats
They don’t do anything I just wanted to have a game with hats!!
PS If you’ve read this far, e-mail me or make a comment and I will add your own personal hat to the game. 😉

Thanks for playing. Always happy to hear feedback, good and bad. And congratulations to all other 2014 7DRL participants.

Roguelike Animations using Javascript and ROT.js

3 min read robocaptainroguelikedevroguelikesrot.jsUncategorized

I am using javascript (CoffeeScript, actually) and the excellent ROT.js library to build the next version of RoboCaptain. ROT.js is great; it makes easy stuff really easy and hard stuff much more straightforward. It allows you to break away from messing around finely tuning your Field Of View algorithm or your AStar pathfinding routines and spend time building actual game content.

I am something of a roguelike traditionalist (you can find me calling out non-roguelikes in a hopefully non-obnoxious manner on reddit) but while I do love my ASCII, I also think looking nice is important. Once I started building ranged weapons into my game I realized: I need animation.

In most programming languages, animation is straightforward. Start an animation, wait, continue where you left off. In javascript, this is less straight forward, because javascript is a single-threaded non-blocking language. The appropriate way to do delays in javascript is to use setTimeout. However, if your code looks like this:

player.shoot(monster, weapon)
game.drawAnimation(player, weapon)
game.damage(monster)
if monster.is_dead() then
     game.kill(monster)

Then your game will not work like you think it will. As your drawAnimation function starts firing off setTimeout events and drawing (for example) the path of the shot across the screen with 20ms delays, the javascript machine continues chugging along. This means while your player is watching their bullets fly across the screen, javascript has already moved on and is now calling your damage() and potentially kill() functions. Even worse, depending on how you write your code, it will keep going and eventually start moving other monsters, potentially even the one that just got shot.

Despite the cries of anguish from javascript purists, my first idea was to implement a delay() function, forcing javascript to wait until my animation drawing was done before continuing. Javascript purists hate this because you will be blocking the entire browser (or tab?) while this is happening. I figured when programming a game, this was OK, because it’s not like anything else is happening on the page other than the game.

Unfortunately if you use this method ROT.js will not ever get a chance to run it’s display handling code, and your canvas will not update until after your terrible delays are over.

Using setTimeout is a pain in the ass. It makes coding very messy because you have to use callbacks, something like this:

player.shoot(monster, weapon)
game.drawAnimation(player, weapon, function () {
    game.damage(monster)
    if monster.is_dead() then
        game.kill(monster)

          }

Using this method I was still running into asynchronous event issues, and gods help you if you want to nest your animations (like a shooting rocket causing an explosion).

After a lot of messing about, I came up with a relatively elegant solution. It might be obvious to some, but no amount of googling on my part led me to anything similar.

You have to treat your animations as game actors. They need to have turns just like the player and monsters. They use the same drawing routines, screen updating routines, etc.

Now my game loop looks something like this (in CoffeeScript, but you should get the idea):

endPlayerTurn: () ->
    @nextTurn()

nextTurn: () ->
    if @hasAnimations()
        first_animation = @animations[0]
        @animationTurn(first_animation)
        return

    next_actor = @scheduler.next()

    if next_actor.group == “player”
        @finishEndPlayerTurn()
        return

    if next_actor.objtype == “monster”
        monster = next_actor
        @intel.doMonsterTurn(monster)
        @finishEndPlayerTurn()
        @nextTurn()
        return

animationTurn: (animation) ->
    animation.runTurn(@, @ui, @my_level)
    if not animation.active
        @removeAnimation(animation)

    @finishEndPlayerTurn()
    
    setTimeout(=>
        @nextTurn()
    50)
    return

So, now my code is much more readable. Players and monsters take turns as per usual, using the ROT.js scheduler. Animations are independent actors that always take their turns first, if any are still alive. Within each animation there is a runTurn() method that calls the relevant game code: draw a rocket, draw a flash of light, move an expanding circle outwards, etc. The setTimeout is there but feels much less intrusive to me this way. 
The code exits out to the main ROT.js loop elegantly, and does not hold up any operation or freeze the browser. The last step is to just make sure the player can’t move or start a new turn until the animation is over (this last part is somewhat optional, in my experience roguelikes are not that fast-paced anyways).
The tricky thing is thinking of animations as game actors. The player may launch a rocket or a laser, but it will be the actual laser actor that calls the attack() or damage() functions. It is a little tricky to get used to, but I find it much more simple and easy to code than worrying about callbacks.
Your mileage may vary, but I wanted to put this out there so the next developer trying to solve this problem can save a few days of refactoring hell. 

RoboCaptain: That's levitation, Holmes

1 min read robocaptainroguelikedevroguelikesUncategorized

Jetpacks! Chasms to fly over! Also melee weapons with special attack patterns! Also flying enemies! Also ammo-based guns!

Melee weapons are a bit different from systems. They take up a coveted slot, but you can carry them around when they aren’t in use. When activated, the current weapons all have special attack patterns (ala brogue). The blade will pierce multiple enemies, the flail will damage all surrounding enemies, and the hammer will temporarily stun your target.

Coming soon: radiation, fire, exploding barrels, and upgrades. And recharging. And rockets. And…

PS – I will need beta (alpha?) testers at some point this month. Shoot me a comment or e-mail (twpage AT gmail) if you are curious and want to help.