Jp's Lab

GIAD 2009 entry

Sun, 13 Sep 2009 17:29:24 GMT

Here's my entry for the Game In A Day contest, 2009: Gears of War.

It's a turn-based tactics game - you have a bunch of robots, your foe (Either an AI or another human player) has a bunch of robots, and you would both rather like it if the other's robots all vanished.

I'm actually reasonably happy with the quality of the result, given the timeframe. The graphics are utterly awful, as you might expect from me, and the UI is a little clunky - but the gameplay is, I think, actually pretty good, and the AI manages to be semi-competent, in that it's actually trying to hurt you and not doing random stuff (Actually, my first cut at AI for it just had the AI moving 'bots randomly and then firing at any enemies in range...)

I might actually continue the game in the future - probably with some rewriting of code and better graphics, but the same game, at least.

(set! age (+ age 1))

Wed, 01 Jul 2009 08:39:57 GMT

Well, I'm 20, officially, as of about 1 hour and 8 minutes ago. I am no longer a teenager. I've nearly finished my degree. I have no more excuses.

Time to actually write a goddamned game.

Not Getting Stuff Done: Yet to be named roguelike

Mon, 01 Jun 2009 05:50:23 GMT

When I entered IainPeregrine's Get Something Done challenge, I did in the full knowledge that I likely wouldn't have enough time to get something done. Turns out that the last year of an engineering degree has a lot of assignments - whoever would have thought it?

Anyway, due to university/work commitments, I was far, far too busy to actually get something done this May. When I hit uni holidays, I'll see about it then.

But for now, what my project was intended to be: A successor to Ruin.

Ruin is really the first thing I've released on BYOND that I could really consider a completed game, and it's got a number of serious flaws. For example:

Maps follow a tree structure, causing a lot of backtracking and metagaming of the map
Very simplistic magic
Does not use the isometric perspective for anything useful
Ugly programmer art
Missing a number of useful features - such as a town level, a dungeon map, etc.
Reasonably ugly code.
Terrible interface.

It also has a smidgeon of good:

I quite like the way magic item generation works, in terms of generating interesting magical items.
The way dungeons are saved and cached is reasonable
Definitely a number of design decisions I'd like to keep on hand. (Particularly spells/scrolls/potions, the way character statistics are calculated, and monster AI).

I'd like to see if I can do better. I haven't come up with a name for the project as of yet (Ruin 2 will suffice for now, I suppose, but I might come up with something a little catchier in the future). Planned features:

Much snazzier dungeon generation using my most recent dungeon generation library. This means maps will be graphs, and rooms will be furnished.
In addition to the better underlying generation algorithm, I intend to place 'features' throughout the dungeon. When you roll up your character, the game will decide, for instance, that there is an orc barracks on dungeon level 4, an underground lake on level 7, a temple dedicated to an evil god on level 13, and a dragon's lair on level 21, say. These would all influence the generation of that level, and would, of course, be randomly generated.
Magic item generation revolving around randomly selected properties, each with a point value. Think the way D&D magic items work - each property is worth some point value, and the item is, in total, worth the sum of the point values of all its properties.
Standard roguelike functionality that was missing from Ruin, including a town level with shops and the like (gasp), and dungeon maps (double gasp).
Icons from someone who can actually draw (Likely an artistically-inclined friend of mine I'm roping in)
Still the isometric perspective, but actually used for something. With the more advanced dungeon generation, and actually functional art, this should be less of an issue. This won't be actual Z-levels in a single dungeon level (So elevation won't be an issue), this will simply be 3D pretties. It will be optional, like Ruin, so you can run the game in 2D top-down mode if you'd like.
Interesting sense functionality to handle things such as blinded characters, magic items that enhance your sense of smell, hallucination, and sound in fun ways. This will also apply to monsters and monster AI.
More documented and ordered development process.

It's a lot planned, but I think I can pull some of it off on the first release and the rest of 'em over time.

A few more words on the last point: I intend to try developing this project more publicly than other stuff I've done. It's not that I try to be secretive when working on stuff, it's just I don't think anyone would be interested.

I still think you're not going to be interested, but regular status updates provide motivation for me to keep working. So the plan will be that once development kicks in in full swing, I'll be making semi-regular posts detailing progress to date and intended next items for completion. I also intend to produce design documentation, and a series of near term, medium term, and long term goals to keep me on track.

Finally, I intend to store the source code in a publically readable SVN repository. Development won't be open source, in the sense that I won't be soliciting patches from the public (Although if you have the urge, suggest away), it will be both readable and usable. Likely released under a BSD license or the like, once I've got a firmer idea of what my legal responsibilities under such an arrangement are. Might end up just being public domain.

tl;dr: Sorry, IainPeregrine, I didn't find the time to do anything for your brilliant challenge (And I really mean that, it was a damned fine idea), but I intend to develop a much-improved version of Ruin some point in the future (Likely beginning mid-July, after exams).

DM is somewhat unique - lexing/parsing issues with block structure

Fri, 13 Feb 2009 02:33:22 GMT

I've been continuing on with my attempts to write a parser for DM code, and there's this one block I keep hitting again and again - determining block structure.

I can handle this case:

That is, if it's entirely indented with tabs/spaces/whatever.

I can handle this case:

a
    b
    c/d
    e/f/g
    h

That is, indentation with mixed tabs and slashes, with nothing under the slash'd lines. But this?

Can't figure out how to do it. Everything I've tried so far can't parse 'g' correctly (Parses it as under 'e', rather than under 'f') or can't parse 'h' properly (Parses it as under 'e', not under 'a').

That construct is legal in DM, I'm certain, but I can't for the life of me figure it out. And because DM is the only language I know of (And I've done some searches about it) that uses indentation to indicate block structure but allows that use of slashes, I don't have any examples to crib off of.

I'm using flex and bison - I'm getting the lexer to figure out the block structure (So technically it's not a parsing issue, but whatever) and then passing definitions up to bison with the block level set in a global variable. Any ideas on how to handle it? This is the most correct I've got at the moment:

%{
        int depth = 0;
%}

%%

[\t ]                           depth++;
\n                              depth = 0;
\/                              depth++;

EDIT: Wait, no, I came up with a solution:

%{
        #include 

struct depth_t {
        int depth;
        int tabdepth;
} typedef depth_t;

        int depth = 0;
        int tabdepth = 0;
        depth_t tempdepth;
        std::vector<depth_t> stack;
%}

%%

[\t ]*                          {
                                        depth+=yyleng; tabdepth+=yyleng;
                                        tempdepth = stack.back();
                                        if(tempdepth.tabdepth < tabdepth) {
                                                depth = tempdepth.depth + tabdepth - tempdepth.tabdepth;
                                        }
                                        else {
                                                stack.pop_back();
                                        }
                                }

\n                              {
                                        tempdepth.tabdepth = tabdepth;
                                        tempdepth.depth = depth;
                                        stack.push_back(tempdepth);
                                        tabdepth = depth = 0;
                                }

\/                              depth++;

That appears to work, although I can't help but feel that I'm overcomplicating issues... And of course, it won't work with braces. That's easy, though.

EDITEDIT: That's a vector of depth_ts, of course. For some reason the <depth_t> got cut out, even though I've got <pre> tags around it. Is that a bug?

EDITEDITEDIT: More issues! You wouldn't believe it, but it took me this long to realise that / is also used for the division operator. That means block depth is going to have to be determined at the parser level. Crap. I think it'll mostly convert, but I'm not sure how I'll have the grammar distinguish between, for example:

a/b //Defines /a and /a/b

world/New()
    var
        a
        b
    a/b //Does nothing

without making the parsing much more complicated than I had originally invisioned. Ah well, such is life. I suppose I can just ignore everything with a tab-depth greater than a function... and I can tell its a function because it has () at the end of it.

Jp's Thoughts on JRPG Design, Part 3 - Defence!

Mon, 09 Feb 2009 18:25:39 GMT

Last time I discussed how I think difficulty in a JRPG-style game should revolve around making the player think - forcing them to strategise. I also think that's where the fun lies - a game where you can just press X to win is boring.

One area where I think JRPG-like games can add strategy - thereby increasing fun - is defensive actions. Most JRPGs have a pretty woeful selection of ways to defend yourself:

- The ever-present 'defend' command. It's completely useless. You give up a chance to attack or heal for a slightly lessened amount of damage next round. Does anyone ever use this? Why does it even exist?

- 'protect' and 'shell'-style spells - basically, you cast the spell in question on a character, they take less damage from physical/magical attacks for the duration of the spell. They're better than 'defend' - because in many cases they're worth spending an action - but they're still not great. In general they're either entirely not worth using, because you don't need to bother defending, or they're mandatory, because you take too much damage otherwise. Also, the only tradeoff you're making is between one action of doing something else and a number of actions of reduced damage, there's not much strategy involved - it's always either a good idea or a bad idea, no thinking involved. Well, okay, in some games 'shell' reduces the amount of HP healed by magic, but the effect is generally negligable because healing is so damn easy in most games (More on that in another post).

- 'cover' or 'sentinel'-like abilities. Continuing on with Final Fantasy abilities, 'cover' is generally a passive ability on some characters that means they occasionally take single-target attacks for another member of the party, occasionally only when the target is heavily damaged, and 'sentinel' is generally the defend action, except that you also cover for teammates. 'cover' has absolutely no merit in terms of improving strategy, because it's a passive ability and you're making absolutely nothing in the way of tradeoff. It also generally activates so rarely that it may as well not exist. 'sentinel', on the other hand, I've actually found several uses for. It goes in the 'good idea, need more of them' basket. For example, consider the following example: The player is fighting a boss. This boss retaliates every time the player targets him with an action, and kills every member of the player's party in one hit. You could go all battle-of-attrition and just keep bringing people back to life, but that's wasteful - you could, alternatively, have your toughest party member use a 'sentinel'-style ability, and then have your other two party members attack - your tough character takes the hit and survives (because they're defending), and then you just have to heal them, not bring them back to life.

- 'reflect' - cast a spell on a character, and magic cast on that character is then reflected back to the user for the duration of the spell. This I find fascinating. It's an incredibly powerful defensive ability - that character is completely immune to magic - but it's also a massive tradeoff, because you lose the ability to cast beneficial magic on that character. In particular, that makes it hard to heal them in many games. Finally, it has useful offensive properties, if you consider that reflected spells generally go through reflect - also, some versions just reflect the magic to the 'other side' of the battle, so if one of your characters casts an offensive spell on one of your other characters with reflect, then it hits one of the enemies, not the caster - that means you can get multiple hits of one spell on a single enemy by casting reflect on your entire party before casting a multiple-target spell on them. Unfortunately, 'reflect' is generally crippled, because it generally only affects a very limited selection of abilities - so most monsters can ignore it completely. Also, it's generally easy for monsters to remove, so anything with a shred of AI can just cast a 'dispel' equivalent before blasting you with magic. But it's definitely an example of how defensive stuff should work.

Those are the sorts of things available in the vast majority of JRPG-type games. There are some interesting corner-cases - Golden Sun, for example, has abilities that cause your entire party to take absolutely minor damage for one turn, and Baiten Kaitos' battle system puts defence on essentially the same level as offence - that's an awesome game, by the way. If you can live with the terrible voice acting and reasonably boring storyline, the brilliant battle system is worth it.

Anyway, in general the defensive abilities I've noted as interesting above have a few things in common - they make a tradeoff more interesting then "I could defend, or I could attack". 'reflect' trades the ability to buff the character for immunity to magic. 'sentinel' trades knowing who the enemy is going to attack for exposing one character to potentially a lot of damage (Until his/her/its next action, that character is going to get hit with every single-target attack thrown at the party). I think that's the absolute key of defensive abilities - first, they need to do something that's worth it, and secondly they need to make an interesting tradeoff.

But there is, I think, a problem with this approach - any ability that takes an action to use is always going to be second-rate compared to attacking the enemy. No player is going to waste their time faffing about with defensive options against mooks when they can just kill them before they attack. At best, they'd just get used against a few bosses and mooks - they'd be a niche. Monster that uses only magic attacks? Reflect it is. But that's the only time it would ever be used. That doesn't really add much to strategy.

So I think defensive options shouldn't cost an action to use. They need to be passive. Normally, that would be a problem - players would just use the most powerful defensive ability and they'd never have to think about it, because it's passive. But if every ability makes a major tradeoff, it suddenly becomes more interesting - particularly if that character can change his/her/its defensive ability during battles. Consider the following system:

Every character has a number of defensive abilities. They are learned over time like any other skill. Characters are always using one defensive ability out of their set of known abilities. Players can change that skill on the menu, or during the characters turn in battle. Changing the ability the character is using does not cost a turn - so you can change their ability and attack in the same round. All the abilities have a powerful effect, but they all have penalties, so the 'best' ability changes situationally. Here are some examples of potential defensive abilities:

- Damage from melee attacks is significantly reduced, but magical and ranged attacks do more damage (Probably for a sword-and-shield sort of character)

- Character is unaffected by all magic, but cannot cast any spells (Probably on a magic user, but they'd have to have something useful to do if they couldn't cast magic. Items, perhaps?)

- Character counterattacks all physical attacks directed towards them before they are attacked, but take more damage from attacks (Maybe for an archer character - they shoot monsters before they get attacked, but are more vulnerable because of it)

- Character intercepts all single-target attacks directed at the party, and takes significantly less damage from all physical attacks, but deals signicantly less damage with physical attacks (A sort of paladin-y ability).

- Character takes significantly less damage from magical attacks, but is more vulnerable to physical damage (say, a mage actively countering enemy magics, but the concentration required leaves them vulnerable).

I'm sure you could come up with others in the same vein. I'm still split on whether or not there should be a 'neutral' option with no benefits or penalties - on the one hand, characters sort of need somewhere to start, and it allows players to opt out of all this mess if they find its too complicated, or if they don't have an appropriate ability for the monster they're fighting. On the other hand, the lack of a neutral position forces players to consider defensive options, so they're required to strategise in this way.

I still don't think those abilities are enough, though - there's one last element I'd like to see. To foster interesting strategy, there should be some defensive abilities with an effect greater than a single character - like the 'sentinel'-style ability in the list above, they should be team-players. What if an upgraded version of the 'shell'-equivalent above caused all enemy magical attacks to do significantly less damage, no matter who they targeted? You'd probably want to bump up the penalty a bit, too - maybe it costs MP every round the character has it active.

Anyway, that's how I think it should be done. Does anyone have any thoughts? Ideas for cool abilities? Know of any games that do something similar (Like the lightsabre forms in KOTOR 2)?

New version of Jp_DungeonGen

Sat, 24 Jan 2009 20:08:59 GMT

I've updated Jp_DungeonGen a bit. The helpfile hasn't really been updated particularly well, so it's sort of out-of-date. Sorry. I'll probably fix that eventually. In the meantime, there are examples in demo.dm that show you how to use the new features.

New features:
- You can now specify that rooms have multiple disjoint sets of borders - think of, for example, a room that's a square with a rift going through the middle. The walls on both sides of the rift are borders, but you can't cross the rift, so you could occasionally get dungeons where stuff wasn't reachable if you just specified that all the walls were borders. You can now say that the walls on one side of the rift are one border, and the walls on the other side are a different border, and it'll get connected correctly.

- You can now turn on a 'doAccurateRoomPlacementCheck' flag, which changes the way that the generator checks to see if it can place a room or not. It uses AABB if you're not using the accurate placement check - so it's fast, but there can be lots of false positives, particularly with some room geometries. With accurate checking on, rooms are checked for collision tile-by-tile - a bit slower, but doesn't have the same false-positive issues. However, rooms need to support accurate room-placement checking by populating their list of stuff at New(), or the generator just defaults to AABB for that room. This is mostly useful in conjunction with the next feature...

- The generator can now incorporate preexisting features into the dungeon generated. If you turn on the 'usePreexistingRegions' flag, the generator will treat any non-dense regions as rooms and will connect them up to the dungeon. The demonstration for this feature in the current version of the generator generates a cavern and then generates a simple dungeon on top of it, for example, to give you a dungeon with some caverny bits with rectangular worked rooms connected to them - maybe the orc lair attached to a natural cave, for example.

- The generator can now have maximum and minimum sizes specified on a per-room basis, and you can also specify whether a given room is required to be placed in the dungeon (Say, a throne room) and how many times it's required to be placed (Say, the two guard barrackses). You can also specify that there's a limit to the number of times a given room can be placed in the dungeon (Say, for a treasure room - you only want one per level at the most). It still supports the old style, but you can use the new stuff if you want.

None of these changes should break backwards compatibility, but you might want to look into adapting anything you've done with the generator to work with it, anyway.

Jp's Thoughts on JRPG Design, Part 2: Difficulty is difficult

Thu, 27 Nov 2008 13:01:27 GMT

Controlling the difficulty of a JRPG is important. You need mooks to be easier than bosses, you'd like the monsters to follow some sort of sorting algorithm of nastiness, getting tougher as the game goes on, and it'd be fairly ego-stroking if the super-secret hidden boss was incredibly challenging.

The annoying thing is that difficulty is not easily quantified for creatures in a JRPG game - and in particular, the statistics of a creature are not the primary determinant of difficulty. This can often lead to 'hard' bosses being surprisingly easy.

An example: In the game Lufia 2: Rise of the Sinistrals (Just 'Lufia' in Europe), there is a hidden boss that you can only fight quite near the end of the game - the Egg Dragon. This monster has 65535 HP and pretty good attack and defence statistics, along with no elemental weaknesses to exploit. It's also quite easy to beat.

Much earlier in the game - in about the fifth or sixth town you reach, if I remember correctly - the storyline boss is a giant spider. I generally consider this to be the hardest boss fight in the game.

Clearly these two are the wrong way around. Let's look closer to find out why.

The Egg Dragon has a number of actions it can take:
- A very strong physical attack against one member of your party. It won't quite kill your characters (Assuming they're at the maximum level and full health) in one hit, but on some of them it gets quite close.

- A spell that hits all members of your party for absolutely piddling damage (Omitted in the analysis for brevity - doesn't change much)

- A weak physical attack against all of your party, with a chance to confuse. (Omitted in the analysis for brevity - doesn't change much)

Each round, it acts before your characters.

Generally, the strategy to beat it goes something like this:
- One party member casts a healing spell on every character in the party. This spell will heal every member of your party to full health or nearby.
- If your designated healer is starting to run out of MP, one character uses an MP-recovering item on them
- The remaining characters attack

There are some further complexities involved - you need to deal with confusion if the Dragon uses that particular move, and there are some skills you can use to quickly chop off a lot of health near the start of the battle, but that's the simple form.

The tarantula boss, on the other hand, does a number of things:
- It starts with two allies, reasonably weak spider enemies.
- It can attack a single character for a pretty good amount of damage - probably three hits will kill any member of your party at this stage in the game
- It can attack all the members of your party (With a reasonably weak attack) with a chance of poisoning them
- It can attack all the members of your party (with a reasonably weak attack) with a chance of confusing them
- It can attack all the members of your party (with a reasonably weak attack) with a chance of putting them to sleep.
- It can summon new allies if you kill its old ones.
- It can heal itself by a little bit - it only starts doing this when seriously wounded

You only have three party members at this stage of the game, and the boss is weak to fire attacks.

Honestly, there probably isn't a general strategy for dealing with the Tarantula. By now I've come to deal with it by ensuring I pick up a powerful fire-elemental weapon before fighting it, and grinding a fair bit before taking it on. Any strategy would look something like this:
- Deal with whatever status effects the Tarantula has inflicted on you last round
- Heal wounded party members
- If one of your spellcasters is free, use a fire-element spell to damage all the enemies
- Attack the Tarantula

That's pretty general, considering how specific the Egg Dragon strategy was. A computer, even quite a dumb one, could beat the Egg Dragon. I'd be reasonably impressed with anyone who wrote an AI that could take on the Tarantula with a party of appropriate level - it's not a superhuman feat, but it wouldn't be easy, either.

So we've identified the key cause of the Tarantula being perceived as so much harder than the Egg Dragon - when battling the Egg Dragon, there's a simple set of steps you can follow every round that will guarantee you will win (The pattern is so regular that I could work out how many rounds it had taken me to beat the Dragon by counting how many MP-restoring items I had used). When battling the Tarantula, there is no formula - the strategy involved is very general, and heavily emphasises keeping yourself alive over doing damage. Pattern is the key - if you can slip into a pattern against a boss and still beat it, that boss is not very tough. You don't need to think at all - the symbols from the screen just get translated into button presses and fed back in. Against a tricky boss, each round is a life-or-death moment - you must carefully consider what the optimal strategy is.

But why could we slip into a pattern for the Dragon and not for the Tarantula? The Dragon has significantly better statistics. Indeed, with 65535 health, it takes more than half an hour to beat the thing. The Tarantula isn't nearly as threatening, from a pure statistics viewpoint - its attacks aren't as damaging and it isn't as durable.

If you look at the lists above, you'll notice that the primary difference is in the abilities of the creature concerned - the Dragon can basically only threaten the party with a very strong attack on one character (And the confusion, but in practice that's not a significant problem). The Tarantula, on the other hand, has allies, so it isn't outnumbered, it can inflict several status effects on multiple characters at once, and it can take advantage of 'free' turns by re-summoning its minions or even healing itself. It has more leeway to choose the optimal action. (Also, by the time you get to the Egg Dragon, you have much better healing magic, but that's an issue for a later article).

This is a very important insight - the actions that a creature can take are the primary determinants of its difficulty - not its statistics. It doesn't matter how much attack the creature has - if all it can do is attack, it will not be very hard to beat - excepting ridiculous cases, like monsters that can one-hit-kill every member of your party in one action. Depending on the way the game works, even that might not be a problem (Grandia 2 has some monsters that can cast a spell that does exactly that - it works because you can delay their actions by attacking them).

Hard creatures need to be able to disrupt the player's strategy, and they need to be able to take advantage of 'free' turns when the player isn't attacking them because they're busy dealing with whatever the creature did to them. They need to keep the player on their toes - every round, the player should be only two or three rounds away from a loss. The player should be on the defensive - their primary concern should be to stop their party falling apart around their ears, and any damage done is incidental. Such a setup also lets skilled players really shine, as it gives them opportunities to do some thinking and get a few more actions in, or make the ones they've got count more.

In general, 'hard' creatures should have the following abilities and properties:
- They should have allies. It's much easier to beat something when you can gang up on it - with allies, there are more creatures for the player to worry about, and some extra actions on the creature's side of the field.
- They should be 'fast'. This may mean something different in different battle systems. In Lufia, where battles proceed in a number of 'rounds', where each creature takes one action in speed order, it means going before the party. In a Final Fantasy, ATB style system, it means taking a number of actions - ideally, one action for every action the player takes.
- They should be able to cause status effects, preferably to several characters at once. Status effects disrupt the player's strategy, and are extremely annoying. However, if you only inflict one PC with whatever nasty you can cause, this is not necessarily a big deal - most games will allow players to cure a status effect in one round, so single-target status effects will only cause one lost action on the PCs part and probably won't stick around. Two or more, however...
- They should be able to heal themselves. Nothing says 'scary' more than the realisation that the boss can actually fix whatever you've been doing to it. It forces players to think - they need to be able to do damage to the creature faster than it can heal it off. It also punishes players for giving the creature free rounds - if round ends with the party worse of than at the start, then the monster is being difficult.
- It must be able to threaten the party. It's no good having allies, being fast, causing status effects, and being able to heal yourself if you can't actually hurt any PCs and get killed in one hit. The creature needs to be able to do significant damage to PCs, and it needs to be able to take a few hits in return.

Obviously, not all creatures should be like this - it's more a matter of slowly adding features from this sort of direction as monsters get 'harder', in addition to improving their stats so they can keep up with the party.

This is another aspect of the players-are-smart principle - they will find the quick and easy pattern to beating a given boss, and will then abuse it. The best way to make sure such a pattern doesn't exist is to have the boss disrupt the party in unpredictable ways. Remember - the difficulty of a battle is determined by how much it makes the player think, not by how hard it 'would be' for the PCs. It doesn't matter that they take more than 9000 points of damage from the gnashing fangs of the terrible beast, or that it takes some incredible amount of hits to dispatch it - to the player, these are just abstractions. They're not feeling those fangs. All they're noticing is that if they keep healing with one character every round, they're home and dry.

jp_DungeonGenerator released

Fri, 21 Nov 2008 02:05:17 GMT

http://www.byond.com/developer/Jp/jp_DungeonGenerator

It's got, like, a helpfile and everything! Amazing!

Anyway, this is the first stab at it. I intend to take it somewhat further. The following features are on my wishlist, and I will be implementing the vast majority of them:

- Make get/setDoAccurateRoomPlacementCheck() do something. Currently, it's not even listed in the helpfile, because it just gets and sets a boolean parameter that makes no difference. The check it's referring to is collision detection - making sure I don't drop one room on top of another. At the moment, that's done using axis-aligned bounding boxes. I can certainly imagine situations where this would be undesirable (Indeed, one of them is coming up in a moment), but doing more thorough detection is much slower. So, this flag indicates whether it should just do AABB, or AABB followed up with a tile-by-tile test. I've already got what is probably pretty close to an optimal algorithm worked out, I just need to implement it - first I need to figure out how to get the rectangle of overlap between two squares. Anyone got any ideas/links to website that describes how to do it? I'm sure I can figure it out given enough time, anyway.

- Make get/setUsePreexistingRegions() do something. Another currently undocumented flag, this is intended to allow you to generate 'on top of' features you've already placed. The idea is that when the flag is enabled, the generator will, before placing any rooms, scan the area you're generating in for open regions. If it finds any, it uses them as regions in the generation - doing such things as collision-detecting with them so rooms aren't dropped on top of them, and linking them up with the other regions, so that reachability is ensured. This would allow you to draw a river through the centre of a z-level, for example, specify the entire z-level for the generator, set the flag, and then go for it, and links to the river will be made as appropriate. This shouldn't be too tricky - the hardest part is working out which bits are regions and what the borders should be - but I thought I should probably get better collision detection first. The biggest degenerate case is a large ring - no rooms will be placed 'inside' the ring, because AABB thinks they collide - obviously this isn't the desired behaviour. This'll be the second thing I implement.

- Finally, I'd like to set up rooms so that they can have multiple sets of borders. This would be useful for a room that was, say, a chasm, with a ledge on either side. You can't cross the chasm, so the two ledges are different entities. If you tried that in the current generator, it wouldn't guarantee reachability - sometimes, you'd have to cross the chasm to get to some rooms. But if you could specify multiple sets of borders for the room, you could specify that one ledge was one set of borders and the other ledge was another set - the room would get turned into two regions, and reachability would be done from that. Reachability guaranteed, ledge-room preserved. This shouldn't be too hard - the trickiest part is ensuring backwards compatibility in the representation of borders. I'll likely do that using an extra flag added to /jp_DungeonRoom, and rooms that use the multi-region stuff just set it to 1.

Can't think of any other features I'd really like to add to it right now. If any of you come up with one, pass it by me.

I can't announce what else I intend to do with the generator because of the Thought for the Day (Which appears to have vanished with the new site. Pity).

jp_DungeonGenerator code done

Wed, 19 Nov 2008 01:56:50 GMT

The code for the first release of the jp_DungeonGenerator library is pretty much done, barring an unforseen bug. The only thing I've got left to do before it's really ready for release is write a helpfile, which I most certainly will be doing - I intend to do this library right. But if you're brave enough to fiddle around with some reasonably complicated and probably quite brittle code written by someone with an aversion to commenting, without a roadmap, here it is:
http://www.byond.com/members/Jp/files/hub/ jp_DungeonGen_src.zip

There are several examples provided in the demo for the generator, but they're currently uncommented (This will be fixed for release), and the general contract for the generator and the rooms is not explained anywhere so far (Which will be fixed for release). Violation of that contract can quite easily cause runtime errors, so it's probably best to hold off for now.

But I thought I should run through what the generator can do. So here are the examples:

We start off with a really simple example, called, unsurprisingly enough, 'simple':

All the 'simple' example does is generate a map consisting of a few rectangular rooms with the same size, and then ensure that they're all reachable. The map won't have any loops, nothing particularly exciting or interesting. But we've got to start somewhere, right?

A slightly more interesting example is 'loops'. It sets the generator up to add some extra link above and beyond those required for reachability, and ends up looking something like this:

Same rectangular rooms with the same sizes, but now there are a number of loops, if you look closely. Simple, reasonably fast, gets the job done, but not very exciting.

Let's spice up those rooms a bit - perhaps we want rooms with different shapes?

The 'rooms' example makes the dungeon with four different types of room - the square you've been seeing so much of, a circle, a cross, and finally a room I've created for the examples called 'deadend', which is one tile of floor, and ensures that a path will only ever enter it from one square - unsurprisingly, this causes dead-ends - you can see several of them in the screenshot.

Maybe if you had a big vault room and wanted some paths around the edge, you could do something like this:

The 'centered' example just places one large room and then draws a number of paths around the outside of it - could be quite useful in some circumstances. When two certain features are added to the generator later, this style will be much more useful - more on that on release.

All of the dungeons to date have looked somewhat clean, artificial - they look like rooms cut into rock by an intelligent being, not, say, a cave. Well, with a little bit of work, you can get something like this:

The 'cavern' example uses another room I wrote specifically for the demonstration (All these room datums are in the example source, by the way, so you can see how they work). It generates a few blobby masses using the 'cavern' room, then links them together, and then finally does a postprocessing step where it runs through every wall bordering a floor in the dungeon, and does an if(prob(EROSION_PROB)) new /turf/floor thing on it (EROSION_PROB is set to 30 in the example). That's a very simplistic implementation, of course, but it's more to demonstrate some of the postprocessing you could do to generator output.

All these dungeons are a little bare - there's nothing in them but floor and wall. So, I whipped up a few rooms that place some furniture and generated a dungeon with them:

The 'furnished' example places some rooms with a fountain in the middle, rooms with a few pillars near the middle, dead ends, and finally, some rooms that place doors on the entrances to the room. Excuse my pixel art, but you can get a fair idea of what's going on.

There should be a helpfile and a proper release in 48 hours at max. Until then, you'll just have to play with the code if you want to figure out how things work.

Have fun!

Exams done

Mon, 17 Nov 2008 02:10:22 GMT

Just finished my last exam for the year today. I now have this marvellous, magical thing called 'free time' until the end of the year.

This means I will have time to actually finish that dungeon generator. I'm just posting to say "I'm not dead, just a student"