[Padz]

Yeah the first monster is a b*tch! I do mine one stage at a time ie. basic movement, player interaction, advanced movement like dodging or hiding. Then move on to attacks and what not.
But you're right it is easy sailing from there on you just gotta make sure it's easy to vary the monsters abilities and bang some specials in there.

That drawing is pretty cool, you should make a full comic strip or get a site up or something.

[Captain Failmore]

I might actually need some help getting the monsters to work since they have to do a LOT. Path-finding, a little bit of crude decision making, etc. Plus the whole ticks-versus-turns and timing BS that comes along with it. Getting these things to act right could be a logical nightmare unless I plan things out in very well defined steps.

That said, this will be a challenge. Getting the levels to draw themselves and do crazy shit is the easy part.

Every entity including the player will require most if not all of these to function.

• Sensory checks from current location.
  
• Decision making based on nearby monsters including the player.
  
• Additional decision making based on status. (Flee, use items, follow, etc.)
  
• Code for the actions themselves.

In the case of the player there is no artificial intelligence, just player input, but still sensory checks and action code. For instance, I only want the game to print characters for monsters the player can detect, and only want monsters to be able to make decisions to act on entities that they're aware of. (The inclusion of hearing checks adds the potential for an interesting class of characters and monsters that use echolocation. It also means that if you do rely on light to see instead of just having an all-lit dungeon, running out of light doesn't mean instant death but could mean a serious inconvenience and severely compromised fighting ability.) That all comes later though, after finishing the level construction and moving on to the light-maps and cover.

[commodorejohn]

See, I can't see why these pictures shouldn't be what the game is like. It'd be like SenZar: The Roguelike.

This post has been edited by commodorejohn: 26 January 2009 - 11:30 PM

[Seventh Shade]

The wizard chants "Fuck you!" You feel deathly nuked.

I guess generic monsters are okay if the AI and the feel of the game are good. Still, one of the things I liked best about morrowind were the unusual monsters. A few of the really classic monsters are pretty hard to avoid using in some fasion (undead, demons).

[Captain Failmore]

Another factor determining the ultimate variety and flavor of the entities in-game is what theme I decide to apply to it in the end. I'll say right now that at this point, thematic possibilities include anything from medieval fantasy to space opera, and that the engine will ideally just provide the framework for a broad range of different themes and interactions. (My lack of direction stems from having a ton of influences. DoomRL, Dungeon Crawl, Jojo's Bizarre Adventure, I'm not sure where to begin.)

Also, I may have found an even better solution for the room-overlap dilemma: Specific nuclear coordinates drawn within at least a minimum distance of one another that will definitely turn into walled rooms instead of surrounding 'outside' space. This will make the placement of special features much, much easier.

[CJA]

your influences are wonderful influences! I'd be VERY happy to give you monster ideas! Enemy design is the most fun!

ILU keep it up

[Captain Failmore]

Hit me, then.

Until my next level generator update this is a theme-agnostic monster idea thread.

[Lachesis]

This game needs travelling salesmen enemies

[Captain Failmore]

"BUY MY CRAP OR I WILL CUT YOU."

[Captain Failmore]

Improved random level generator included in this release.

• X-then-Y right angle hallways.
  
• Y-then-X right angle hallways.
  
• Angular to straight hallways.
  
• Square rooms.
  
• Rectangular rooms.

Edit:

Increased the level size, and fixed a minor bug with angular hallways finishing prematurely, resulting in unintended dead-ends.

Attached File(s)

•  Dungeon_Brawl.zip (41.17K)
  Number of downloads: 60

This post has been edited by Captain Failmore: 27 January 2009 - 07:35 AM

[Padz]

I just had a look, seems a lot better than before! I just thought about the hallways that cross over you could make the engine do a check before placing if the planned route will cross any other paths or be adjacent to any as there are loads! Unless that's how you like it! I'm looking forward to a basic playable version to see how it turns out.

[Captain Failmore]

Hallway types I have planned:

• Wide hallways.
  
• Irregular squiggle hallways.
  
• Irregular width 'cavern' hallways.
  
• Convoluted maze-like hallways.

Room types I have planned:

• Circular.
  
• Multiple-circular.
  
• Multiple-rectangular.
  
• Other geometric shapes?
  
• Irregular space-filling rooms.
  
• Featureful rooms, to be added after special placement is implemented.

[Captain Failmore]

All three types of hallways can now appear in widths of one, two, or three. Diamond shaped and triangular rooms are next, and the diamond shaped rooms should allow me to make some nice looking irregular hallways with lots of hiding places and what have you. By the way, is there any easy way to draw a circle on the board? It'd be very useful information to have.

Level size has increased further, as has the number of rooms. This is mostly as a stress-test, but I'm rather liking the vastness of it all. (However, the number of hallways is now much lower, and exactly equal to the number of rooms. This reduces the amount of overlap sharply while keeping everything well connected.) Still no featureful rooms yet, but by the time I get to that point I'll be putting things on the V-layer instead of the board anyway and should have the beginnings of the interface ready.

[Wervyn]

Captain Failmore, on Jan 27 2009, 07:52 PM, said:

By the way, is there any easy way to draw a circle on the board? It'd be very useful information to have.

This probably isn't what you mean by "easy", but:

set "commands" to "(1<<18)"
set "$bar" to "ÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛÛ
ÛÛÛÛÛ"
. "80 solid block characters."
end
: "keyc"
set "local1" to random 5 to 20
set "local2" to random "local1" to "(79-'local1')"
set "local3" to random "('local1'/2+1)" to "(24-('local1'/2+1))"
set "local5" to random 1 to 15
set "multiplier" to "local1"
set "divider" to "(1<<16)"
loop start
set "local4" to "cos('asin('loopcount'*2+1<<16/('local1'+1))')"
if "local4" <= 0 then "EL"
write overlay "local5" "&$bar#('local4'*2+1)&" at "('local2'-'local4')" "('local3'-'loopcount')"
write overlay "local5" "&$bar#('local4'*2+1)&" at "('local2'-'local4')" "('local3'+'loopcount')"
: "EL"
loop for "('local1'/2)"
end

Basically, simple trig. And it IS simple trig, MZX's handling just makes it look complicated when you're aiming for precision. The basic idea here is to draw a horizontal line of blocks for each y value of the circle that maps to a character. The circle is given a radius of local1, an x coordinate of local2, and a y coordinate of local3 (plus a random color). local4 is the calculated x for each y value in the loop, using a basic conversion. At each iteration of the loop, Y is a known value, and R is a known value, which makes the angle in the first quadrant arcsin(Y/R). For our Y, we multiply by 2 to halve the vertical distance, since characters are about twice as tall as they are wide; and we add 1 to offset the line reading so that our circles don't end up with little nubs on the sides on the center line. We multiply (i.e. bitshift) by 2^16 for the sake of precision, and then divide by the radius, plus an extra one as a fudge factor (doesn't matter much in practice, but I wanted it). The divider counter is also set to 2^16 in order to take advantage of this precision. Then, having got that angle, we take the cosine of it to get the X value, which is automatically multiplied by our multiplier set to the radius. Finally, to draw the line, we take a chunk of a solid string twice as long as X (plus 1 for the center), and draw it offset negative from the center X, both above and below the center Y. The same principle can be easily applied to a copy block to carve out space from a chunk of solid.

"Pfft, Bresenham's."

[Captain Failmore]

I see. Given that level generation is already a wee bit slow, I might forgo circular rooms for now in lieu of simpler solutions. I'll probably keep that for special rooms though, like big circles with stuff in them.

That said, I have up and down facing triangles in now, and am working on the other two directions. Diamonds will be easy. Not so sure that I actually like how the triangles look, but I could use the code to create silly things like Triforce rooms and anything else that comes to mind. In all, the level generator is thus far able to produce some very dynamic level layouts and impressively large levels, usually in only a few seconds time. (And that's a 9-screen level, or twice that if you consider that the view-port and typical sight range will be something like half that size. Actual levels will likely only be 4-screen.) The shape of the resulting levels kind of reminds me of a city or something, minus the big triangles.

[Wervyn]

For the record, the code I posted there is pretty fast, and can churn out around 10000+ circles with radii from 5 to 20 in a second. Meaning roughly a .1ms cost for an average circle of radius 12 or so. Unless you're worried about generating a lot of big rooms (think radius 200 or something), I doubt you'll notice a lot of slowdown with this, and certainly not compared with the algorithm that maps the level itself.

"We have to do something about this. And by we I mean you."

[Captain Failmore]

If you thought this was going to be a meaningful update, YOU WERE WRONG.

I'm using this to take notes so you can laugh and cringe in horror at how I plan to implement certain things.

FLOOR-ITEM DATA:

Each tile of floor space will be represented by:
$IM<two characters for coordinates up to 256 x 256>

Which is empty by default unless an item is present.

The string accumulates item addresses, each three characters long, and is capped with a stop-character that isn't also a blank. (Meaning that the absolute number of items that can be present is over a million. I strongly doubt I'd need more.)

Each item will be represented by:

$IE<three character item address>

With item data following in the string in a format that I've yet to really... decide on.

Basically, the $IM strings refer to locations on the floor and which items are there. The items themselves are represented by the $IE strings, whose addresses are referred to in the $IM strings.

Yeah.

More as I come up with it.

Yes, this will be a hellacious, memory devouring mess. Unless it's not.

This post has been edited by Captain Failmore: 01 February 2009 - 04:35 AM

[Padz]

Sounds good, have fun coding it! I'll be using a similar system for my worldmap>localarea coding. and there are 125,000 local areas on my world maps! so many many counters!

[Captain Failmore]

Important update is as follows:

I am gradually beginning to learn strings. Happy day.

In accordance with that whole 'plan things before you try and program them you fucking idiot' approach, instead of dwelling on how I plan to store data (which is turning out to be the easy part) I'm starting to plot, among other things, how picking up and dropping objects will work and change your stats and all that, as well as how looking at them via the mouse will function. If I can get some motivation (and caffeine) in me I might have a little toy for you guys to prod at in a couple days with some rudimentary pick-up and drop-off code as well as a look function. Obviously this will be very important in the game since it'll form the foundation of the inventory system for both the player and (eventually) monsters.

Holding off on any further expansion of the level generator since what I have right now may not even be applicable to future versions of the game. I'm asking myself, among other things, how much data do I want to store on the board, versus how much do I want to store as counters and strings? I do like the way levels are constructed now though, and will be absolutely sure to include the methods of tile placement I have already in future versions of the game along with their respective improvements.

Final note: Expanding item location addresses to three characters for X-coordinate, Y-coordinate, and level. That means we could hypothetically have up to 256 levels. Sweet Jesus.

[Captain Failmore]

Well, after fighting with it for a few hours I got generic inventory code done. For now, it only references the player's inventory which is set up manually at first. In the future when entities are actually put in, every entity will have its own inventory, and this code will just be a subroutine for adding and subtracting items from the inventories of entities or the floor. Includes the old random level generator with some new tricks added in.

The equip-remove code will work very similarly, almost identically save for an as yet unwritten routine to check the stats of the items being equipped or removed and alter the stats of the entity changing its equipment accordingly. I'll probably tackle that sooner than later, since I'm already on an item-kick.

Edit:
Threw in some instructions!

Attached File(s)

•  DungeonBrawl002.rar (48.27K)
  Number of downloads: 57

This post has been edited by Captain Failmore: 07 February 2009 - 04:07 AM

[Padz]

I'm liking the new dungeon layout, a lot more refined and nice variation in rooms. I think the diagonal routes may give me arthiritis one day but hey ho. The inventory system looks good and seems to run very well, it also seems a lot more streamlined than the way i plan for my game! good stuff!

[Lachesis]

Some roguelikes have diagonal movement! Consider this for yours, if you ain't already. Especially since there's diagonal corridors :x

[Captain Failmore]

Way ahead of you. I haven't played a roguelike yet that didn't let me use my numeric keypad. I consider that an essential part of the game, and the angular hallways reflect that.

I'd include one tile wide angular halls if they didn't look silly. I might include them yet, but like I said, the RLG is on hold for now.

As for right now, I'm trying to finalize what stat system I plan on using, since there's no point in moving forward with equip-remove until I have stats and a data structure for items. I might bug /tg/ about that.

[iamgreaser]

I personally recommend that you use pythagoras rather than trig:
CAUTION: untested code follows.

loop start
set "xdist" "abs('loopstart'-'radius')"
set "cheight" "sqrt(('radius'*'radius')-('xdist'*'xdist'))"
. "Draw from ('ypos'-'cheight') to ('ypos'+'cheight')."
loop "('radius'<<1)"

Nevertheless, if it's reasonably fast, you should be sweet.

[Captain Failmore]

So yeah I'm totally on break right now and school kind of derailed this project.

But I'm gradually drifting back toward it.

I'm not sure whether or not learning Visual Basic has helped or hindered my ability to program. :|

[Dr Lancer-X]

Captain Failmore, on May 23 2009, 04:17 AM, said:

I'm not sure whether or not learning Visual Basic has helped or hindered my ability to program. :|

I know that Dijkstra thinks it does.

But he's dead.

[Koji]

and we all know how death illegitimizes opinion

This post has been edited by Koji: 26 May 2009 - 12:05 PM

[Captain Failmore]

MATHEMATICIAN ROGUELIKE

USE DIJKSTRA'S ALGORITHM TO DEFEAT THE NILBOGS

[Dr Lancer-X]

you'll need boyer-moore's
nilbogs have negative edge weights

[Koji]

oh god that was nerdy

anyway hey has this got any work done on it?