Messages

1

Programming / Re: MultiplayerRL Question...

« on: November 20, 2010, 12:28:49 PM »

In the adventure mode of Dwarf Fortress you can recruit a fairly significant number of companions once your reputation is good enough. Your control over them is pretty loose, however.

2

Programming / Re: A peaceful dungeon exploration game

« on: January 11, 2010, 05:43:43 PM »

Traps and puzzles are where you'll want to focus your effort, I think.

3

Programming / Re: Mixing roguelike and tactical squad combat

« on: January 11, 2010, 02:34:52 PM »

I would be an instant fan of a Roguelike X-Com. I say go for it.

I'd suggest not making tactical combat optional though - do you really want to implement two combat systems?

4

Early Dev / Re: IllFate - Very early development feedback

« on: January 11, 2010, 01:12:33 PM »

I'm not using the Flex framework for this project, just compiling standard Actionscript. Despite its name, Flex Builder is not necessarily for builing applications on the Flex framework. Adobe is renaming the next version Flash Builder to make this a bit more obvious. I have used the Flex framework profesionally before, and found it to be extremely useful but occasionally a time sink.

I've been using FB since shortly after it was launched. I'm a huge fan. It has a lot of features that really speed you up once you get used to using them. As a long time Flash developer I'd always relied  on trace statements and observation to debug problem. Having a real debugger (that actually works) was like night and day on its own. To be honest, every time I'm forced to work in Flash CS3 or CS4 instead of Flex Builder I find it very painful now.

There are some other options out there; FDT and FlashDevelop, but I prefer Flex Builder's official support.

5

Early Dev / IllFate - Very early development feedback

« on: January 10, 2010, 04:40:46 PM »

My roguelike, called "IllFate" is still in its infancy. There's very little to it at the moment, but I want to have a place here for people to post whatever feedback they have on what is done. The earlier I can catch little details that feel wrong or clash with roguelike standards, the better. My overall goal is to build a world with enough complexity to get some emergent history out of it, Dwarf Fortress style.

IllFate is developed on the Flash platform using Flex Builder. I am adopting Test-Driven Development practices, both because I think it suits an expansive roguelike very well and because I want to gain some experience with it.

Development blog is here: http://blog.andrewtraviss.com/

I'm using (bad) haiku poetry to describe each immediate development goal. Every "Verse completed" post has the latest version of the game embedded in the post. That's not a screenshot.

6

Programming / Re: Unit tests and Test-Driven Development

« on: December 27, 2009, 04:18:25 AM »

I've started to work on my game. I'm keeping a development blog here: http://blog.andrewtraviss.com/?cat=30

So far I am enjoying the TDD process. It has roughly doubled the time required to implement little things, but I think I made back most of that time working on the physics.

Should I keep the discussion in this part of the forum until it's  more of a game, or should I move it over to Early Development Feedback now? I actually could use some feedback already about how I've implemented running.

7

Programming / Re: Unit tests and Test-Driven Development

« on: December 15, 2009, 01:26:54 PM »

The code that doesn't fail today will fail tomorrow.

8

Programming / Re: Unit tests and Test-Driven Development

« on: December 15, 2009, 02:57:18 AM »

Thanks for the input. In this case, I'm not aiming for an average RL project, but rather a long-haul type of project (see: Dwarf Fortress). So I expect to need to refactor most of the game systems over time. Unit tests make that a lot less of a scary prospect.

I'm actually planning to take the unit tests to the most serious extent; Test-Driven Development stipulates that you write a unit test first, watch it fail, and then only add enough code to satisfy the test. Lather, rinse, repeat. Some people I really trust swear by it, so I thought I'd give it a shot.

I'm almost to the point of actually rendering a room and an actor to the screen and so far it's pretty comfortable. I'll be using my blog to share the latest version of the game every week. I'll post a link here when I post the first update.

9

Programming / Unit tests and Test-Driven Development

« on: December 11, 2009, 09:19:11 PM »

Has anyone here employed these techniques in Roguelike development, and have they paid off as much as I suspect they would?

10

Temple of the Roguelike / Re: Welcome to Temple of the Roguelike Forums! (a.k.a. Introduce Yourself Thread

« on: September 27, 2009, 02:28:34 PM »

I guess I should make a post here, didn't notice the thread before.

I'm a software developer, recently turned architect. My main introduction to Roguelikes was through Diablo, but I have been pulled into the non-commercial Roguelike scene through Dwarf Fortress.  I've tried to do something a little different there by doing a graphics set, rather than anything functional. I do have some limited art talent and I thought that was a good way to expand on them.

Pretty soon after, I got the urge to start working on my own Roguelike. I almost see it like a developer rite of passage. It amplifies some very important design problems and provides a space very different from commercial development to hone your skills. I am building my currently unnamed game using Actionscript 3.0.

Looking forward to hanging around here for a while.

11

Programming / Re: Handling item properties

« on: August 07, 2009, 04:50:12 AM »

Here's my Item definition class.

Code: [Select]

public class DefinitionItem extends Definition
{
public function DefinitionItem()
{
super();
verbHandlers =
{
"pick up":new HandlePickUp(),
"drop":new HandleDrop()
}
}
override public function apply(in_actor:Actor):void
{
if(!isActor(in_actor))
{
super.apply(in_actor);
in_actor.pathable = true;
in_actor.obstruction = false;
in_actor.state = "inert";
in_actor.addStateVerb(lexicon.verbPickUp, "inert");
in_actor.verbRequirements[lexicon.verbPickUp] =  lexicon.verbGrasp;
in_actor.verbRequirements[lexicon.verbDrop] =  lexicon.verbGrasp;
in_actor.addStateVerb(lexicon.verbDrop, "held");
}
}
}

... and the Weapon definition

Code: [Select]

public class DefinitionWeapon extends Definition
{
public function DefinitionWeapon()
{
noun = "Weapon";
plural = "Weapons";
}
override protected function init(in_event:Event):void
{
super.init(in_event);
verbHandlers =
{
"wield":new HandleWield(),
"DEFAULT_HANDLER":lexicon.definitionItem
}
}
override public function apply(in_actor:Actor):void
{
if(!isActor(in_actor))
{
super.apply(in_actor);
lexicon.definitionItem.apply(in_actor);
in_actor.addStateVerb(lexicon.verbWield, "held");
in_actor.addStateVerb(lexicon.verbAttack, "wielded");
in_actor.verbRequirements[lexicon.verbAttack] = lexicon.verbGrasp;
}
}
}

... and the Sword definition class

Code: [Select]

public class ItemSword extends Definition
{
public function ItemSword()
{
noun = "Sword";
plural = "Swords";
}
override protected function init(in_event:Event):void
{
super.init(in_event);
verbHandlers =
{
"DEFAULT_HANDLER":lexicon.definitionWeapon
}
}
override public function apply(in_actor:Actor):void
{
if(!isActor(in_actor))
{
lexicon.definitionWeapon.apply(in_actor);
super.apply(in_actor);
in_actor.verbRequirements[lexicon.verbWield] =  lexicon.verbGrasp;
}
}
}

I left out the handler classes so this didn't take up a whole page on its own. Suffice to say they each have a single method.

Code: [Select]

handleVerb(verb:String, subject:Actor, object:Actor, converter:Actor=null)
Only the definitions which must implement new Handlers are hardcoded  implementations. The rest should just be instances. Even in my example here, the Sword definition should ultimately just be an instance of DefinitionWeapon with some parameters.

I have not implemented combat modifiiers yet, as I'm still doing groundwork in more important areas. The plan is to use a CombatResolution class to hold the stats for the current exchange, and pass this around to all of the involved Definitions on each side. Order of operations looks to be complicated, though, so I don't want to get into a lengthy explanation until it's actually implemented. What's in my head right now is likely to change.

I hope that's all pretty clear.

12

Programming / Re: Handling item properties

« on: August 06, 2009, 02:45:45 AM »

The way that I am dealing with this type of problem is through "Definition" classes. Rather than relying on class inheritance for Actors, I am building them through composition. A "Burning Sword of Boomerang" would be built up of several definitions:

The Item definition provides basic item interactivity (can be stored in a container, picked up, etc).
The Weapon definition provides functionality for equipping the item and understands how to modify stats during combat.
The Sword definition dictates what types of attacks are available and incorporates your Sword proficiency during combat.
The Burning definition sets the sword aflame and will handle spreading fire during combat (unless the physics system will do so inherently).
The Boomerang definition would override the behaviour for the item when it is airborne to make it return to you after travelling a certain distance.

This approach dictates a lot about how things are structured, so I think it would be difficult to refactor into an existing game. For this to work well during combat, all Definitions for the weapons, armour, and creatures involved in that combat must be given a chance to modify the combat statistics before calculations are done, and then given an opportunity to trigger effects based on the combat result.

I create a singleton instance of each Definition class, and whenever a new Actor is created I call definition.apply(newActor). To simplify matters, some Definitions can imply other definitions (the Sword definition automatically calls apply() on the Item definition, for example). This mimics class inheritance without having to deal with the strictness that comes with it. It also allows me to implement multiple inheritance wherever it is beneficial.

13

Programming / Re: Good ways to do LoS

« on: July 18, 2009, 05:00:31 AM »

I'm using a variant on a flood fill to handle LOS at the moment. For each tile traversed I store a list of directions to fill from that point. Each fill direction restricts 5 of the 8 cardinal directions from being filled from the destination tile. Tiles are processed in order of their distance from the source. If two tiles fill into the same tile, the restricted directions from that tile are only the directions restricted by both operations.

Any thoughts on this approach?