Skip Menu |
 

This queue is for tickets about the Games-RolePlay-MapGen CPAN distribution.

Report information
The Basics
Id: 71331
Status: open
Priority: 0/
Queue: Games-RolePlay-MapGen

People
Owner: Nobody in particular
Requestors: BitCard [...] ResonatorSoft.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Support for u/d/l/r
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 2736
Download (untitled) / with headers
text/plain 2.6k
As it is now, the current form supports NEWS directions. However, not all games work in a typical top-down view. For example, with Terraria, the view is a 2D side-scroller with up, down, left, and right. Currently, I am just using the n/s directions for up/down, but that implies that the cardinal directions have no differences between each other. Left/right could safely be mapped to w/e, but u/d is a lot different. U/d means fall damage, gravity effects, etc. A maze with a long corridor going l/r is one thing, while one going u/d is actually a pit. The user should be able to override the default directions with whatever combination of "n/e/w/s/l/r/u/d" is appropriate for the map needing developing. I could see the following combinations: NEWS - Default and currently implemented LRUD - LR mapped to WE, and UD as a new set of directions NEWSUD - A new 3D-compatible mode. The maps could create both NEWS corridor and pits, as well as rooms with depth. This may be as simple as just adding a third dimension to the map and letting it loose, but I would recommend adding this last. (Minecraft could benefit from this, as well as any FPS.) With LR being mapped to WE, it should be treated as such except for the different letters. (In fact, after it's mapped, the Generator tools and such can completely ignore LR.) UD should NOT be mapped to NS, but instead have the following characteristics: * The sparseness, same_way_percent, same_node_percent, and remove_deadend_percent options should have their own ud_* versions with the defaults turned down low (IOW, to create less long pits). That way, the user can control whether s/he wants mazes that generally kill people or mazes without any pits. * There would need to be an option with the doors to control whether trapdoors or platforms are possible, and whether they have an open/close state. If not, it needs to not add UD doors. * Objects may or may not be affected by gravity. If they are, it should be considered an illegal point (or maybe just a "corrected" one) to place an object in the middle of a pit. I think most of the other MQ functions are compatible, as long as they can recognize the UD $dir. Again, once the LRUD mode is complete, adding the NEWSUD one would likely be as simple as adding an optional third dimension everywhere. The Generators should be able to automatically create 3D Perfect mazes. The PNG exporter would require a "perspective" option, but if it was able to draw LRUD maps, that would be a simple matter of either drawing something in NEWS mode or LRUD mode. Stairs could also be another options for NEWSUD maps, in which no pits are created (or maybe they still can be), and would work for "roguelike" games.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-3047-1317298919-1459.71331-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 1056
I don't really see any reason this couldn't be done. I don't have very much interest in it, personally. To me, it's all about the top down. There are caveats with this stuff. The doors and visicalc portions of the module suite make little sense once the directions change around like that. It's also almost completely æsthetic. We could just as well call the directions 1,2,3,4 and then you can choose to see 1 as up and I'll see 4 as west. In short, if you want to add support for this, it sounds just fine to me and I'd certainly merge the changes, but I don't personally see any point to it. I'm wondering if it would make more sense for you to carve out the parts you really like and build a Terraria specific module. You may not even need to fork to do it, I mean, that's what OO is all about, right? I would certainly be willing to merge changes need to make inheriting and making such a module work too. -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-3047-1317298919-1459.71331-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-3047-1317298919-1459.71331-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-3053-1317315892-552.71331-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
From: BitCard [...] ResonatorSoft.org
X-RT-Original-Encoding: utf-8
Content-Length: 934
Download (untitled) / with headers
text/plain 934b
While it's true that NEWS doesn't really "mean" anything, I'm trying to add some meaning to UD and separate it from the rest, as gravity is a factor in many games. The LR thing is more of a nicety for the user, and it can be mapped in such a way that the changes are transparent to the other modules. With the new letters NEWSUD (again, LR is transparent), the modules treat UD as a different type, whether the user is splitting it up as WEUD/LRUD, or as NEWSUD. Stuff like %opp/%full can be updated to include all of the supported letters. The _interconnected_map would figure out the direction_mode and add the directions specified. Any reference to qw(n s e w) should be replaced with a variable with the same data. I'm okay with doing the changes, but I wanted to get your idea on the perspective. It's something that would work with other games, so that's why I want to include it into GRM proper, instead of a new module.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-3053-1317315892-552.71331-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-3047-1317298919-1459.71331-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-3053-1317315892-552.71331-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-3049-1317316565-441.71331-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 309
Download (untitled) / with headers
text/plain 309b
Yeah, I'm not saying don't do it or anything. I'm just playing devil's advocate. It makes sense as a stand alone module to me, but I like what you're doing on github too. -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-3047-1317298919-1459.71331-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-3047-1317298919-1459.71331-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-3051-1317316871-1571.71331-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
From: BitCard [...] ResonatorSoft.org
X-RT-Original-Encoding: utf-8
Content-Length: 839
Download (untitled) / with headers
text/plain 839b
Show quoted text
> The doors and visicalc portions of > the module suite make little sense once the directions change around > like that.
That's not true. People can still look up or down and get relatively the same visibility. Does d20 define anything for up/down visibility? As far as doors, that's what I was saying about platforms and trapdoors. A platform is something that can simply be climbed on/down to enter a room. A trapdoor might be something that trips the player if they step on it, making them fall into a pit or another room. Stairs (a la roguelike games) could be considered platforms, since player could climb them up or down like a platform. Overall, my goal is to make the changes in such a way as to not impact NEWS mode at all (which would be the default) and only apply the behaviors if one of the other modes are selected.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-3051-1317316871-1571.71331-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-3047-1317298919-1459.71331-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-3051-1317316871-1571.71331-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-3048-1317382582-390.71331-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 964
Download (untitled) / with headers
text/plain 964b
I suppose you're right except that the visicalc takes doors into account. So the orientation of the LR doors will be ... weird. And trapdoros will only have two orientations available, which any four should work, and possibly a 5th (where it just falls away). I think the solution to that is probably for the visicalc to not count the doors for 2d maps, or to assume they simply disappear in those orientations, which may be roughly the same thing. Trust me, the visicalc was hard. Probably the hardest thing I wrote so far. It wasn't just writing it, it was testing it, and then fighting the floating point errors. Feeling comfortable that I had correctness took … weeks. Revisiting it would be a horror I don't personally look forward to. ∴ I think just removing doors in the LRUD orientation makes the most sense. -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-3048-1317382582-390.71331-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-3047-1317298919-1459.71331-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-3051-1317316871-1571.71331-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-3048-1317382582-390.71331-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-3053-1317382625-1331.71331-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 240
Download (untitled) / with headers
text/plain 240b
(Also, I'm exceedingly fond of LRUD vs NEWS as the names of the implementations. Why? No real idea. ) -- If riding in an airplane is flying, then riding in a boat is swimming. 116 jumps, 48.6 minutes of freefall, 92.9 freefall miles.
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-3048-1317382582-390.71331-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
References: <rt-3.8.HEAD-3047-1317298919-1459.71331-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-3051-1317316871-1571.71331-0-0 [...] rt.cpan.org> <rt-3.8.HEAD-3048-1317382582-390.71331-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-3053-1317487215-671.71331-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
From: BitCard [...] ResonatorSoft.org
X-RT-Original-Encoding: utf-8
Content-Length: 1977
Download (untitled) / with headers
text/plain 1.9k
On Fri Sep 30 07:36:22 2011, JETTERO wrote: Show quoted text
> I suppose you're right except that the visicalc takes doors into > account. So the orientation of the LR doors will be ... weird. And > trapdoors will only have two orientations available, which any four > should work, and possibly a 5th (where it just falls away). > > I think the solution to that is probably for the visicalc to not count > the doors for 2d maps, or to assume they simply disappear in those > orientations, which may be roughly the same thing.
Yeah, I think I follow you, and we're mostly on the same page. Really, it's all the same thing, except that the camera angle has changed. Doors are pretty much either open or closed. If a door is open, it's going to "blend into the background" at that point, and more or less act like a true opening. Trapdoors have the potential to block visibility on the left or right side, but it depends on the trap door. (It could be sliding version for all we know.) The user could define that, while s/he is defining whether it's a trap door or just some platform or stairs or something. Show quoted text
> Trust me, the visicalc was hard. Probably the hardest thing I wrote so > far. It wasn't just writing it, it was testing it, and then fighting > the floating point errors. Feeling comfortable that I had correctness > took … weeks.
Yeah, I bet. Geometric line-of-sight code has to be hard. Show quoted text
> Revisiting it would be a horror I don't personally look > forward to. ∴ I think just removing doors in the LRUD orientation makes > the most sense. >
Well, not so much removing doors as just simplifying the code. If the door is closed, it's like a wall. If it's open, it's like it never existed. Now, in 3D mode, that's a different story, but we'll cross that angle when we get to it. Show quoted text
> (Also, I'm exceedingly fond of LRUD vs NEWS as the names of the > implementations. Why? No real idea. )
Heh, probably because it sounds like "Le Rude" or "Le Rud". It's French!


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.