ToME: the Tales of Maj'Eyal

Everything about ToME
It is currently Thu Apr 27, 2017 10:58 am

All times are UTC




Post new topic Reply to topic  [ 30 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Dec 18, 2015 4:46 pm 
Offline
Uruivellas

Joined: Tue Dec 13, 2005 12:35 am
Posts: 702
I just pushed branch (based on v.2.4.0) to my tome2 git repo.

At the moment it has one fairly simple change, which is the removal of ALLOC_TYP_TRAP. In other words, floor traps are no longer allocated in normal dungeon generation.

However, floor traps will still be created appropriately
- In vaults and Princess rooms
- On special levels, e.g. Dim Gates
- On quest levels, e.g. Eol's lair
- By monsters casting the Create Traps spell

The idea is to make traps a special danger, rather than an omnipresent one.

Those who wish to try it can clone from my repo, and compile

Code:
git clone https://gitlab.com/miramor/tome2.git -b v2.4-trap-changes
cd tome2
cmake .
nice make


You will need the Boost and Jansson headers first though. On Debian and Ubuntu, that would be

Code:
apt-get install libboost-system-dev libboost-filesystem-dev libjansson-dev


Note: unfortunately I'm not sure this version can compile on Windows at the moment. jansson could probably be cloned and built as part of the build process, Boost seems kind of doubtful though. Hopefully I'll have the time to work on automating the Windows build... at some point.

_________________
"These aren't the hobbits you're looking for."


Top
 Profile  
 
PostPosted: Fri Dec 18, 2015 6:55 pm 
Offline
Spiderkin

Joined: Sat Mar 18, 2006 12:48 pm
Posts: 478
(Moved from the original thread because it fits better here:)

Yeah, I'm leaning towards removing traps entirely too. I've removed them entirely (or, rather, prevented them from spawning) in one of my private branches and have played a few (short-ish) games and I can't say I miss'em at all in terms of game play.

My biggest issue with removing them completely is that this leaves a kind of a strange vacuum in terms of there being useless skills[1]/spells. One approach that I've thought about a bit is to allow monsters to create traps (via spell), but to not have any floor traps (perhaps allow inside vaults?). Another approach might be to remove all the instantly-game-ending traps which necessitate 100% detection and simply not have 100% detection in the game -- however, this risks ending up in "a couple of unlucky trap spawns kills character randomly with no possible way to prevent it" territory. But maybe we should just remove *everything* trap-related to give room for a re-think.

I'll be brutally honest that I'm also slightly motivated by the desire to get rid of the thousands(?) of lines of code required to support traps. (This has to do with a probably-overly-ambitious code conversion project that I've sort of embarked upon... but I don't want to get anyone's hopes up too much in case it never goes anywhere.)

[1] ... but let's face it: Any method of finding traps which isn't 100% isn't going to fly in T2, given the extreme nastiness of some of the traps.

EDIT: Fun little addendum: Removing traps leaves Antimagic users with exactly one useful activatable "spell" based on the Anti-magic skill :), namely Continuum distruption. Maybe that should be streamlined such that any player-initiated teleportation automatically succeeds and enemy teleportation automatically fails (or prompts?) -- though I'd hate to be the one to find all the places where code needs to be changed to achieve this effect :).


Top
 Profile  
 
PostPosted: Fri Dec 18, 2015 7:05 pm 
Offline
Spiderkin

Joined: Sat Mar 18, 2006 12:48 pm
Posts: 478
... and having given it a little more thought: Someone over on the oook forums suggested a few trap ideas, but one that stuck out to me as having great potential was the idea of traps being "static terrain" that was part of the dungeon with timed effects based on player proximity. Those effects could be a timed poison cloud, arrows being fired every turn while you're in line of the trap (or even "one-square-per-turn-speed" radius 1 clouds), maybe a circular "blast" effect whenever you're in a certain radius, whatever.

I think this would could lead to interesting random 'puzzles' if traps were generated randomly in close proximity to one another -- esp. in tight spaces such as vaults.


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 12:08 am 
Offline
Uruivellas

Joined: Tue Dec 13, 2005 12:35 am
Posts: 702
AnonymousHero wrote:
Yeah, I'm leaning towards removing traps entirely too. I've removed them entirely (or, rather, prevented them from spawning) in one of my private branches and have played a few (short-ish) games and I can't say I miss'em at all in terms of game play.


Same here, of course. I stuck with the partial removal because it's less radical, and leaves a role for trap detection spells etc.

Quote:
My biggest issue with removing them completely is that this leaves a kind of a strange vacuum in terms of there being useless skills[1]/spells. One approach that I've thought about a bit is to allow monsters to create traps (via spell), but to not have any floor traps (perhaps allow inside vaults?). Another approach might be to remove all the instantly-game-ending traps which necessitate 100% detection and simply not have 100% detection in the game -- however, this risks ending up in "a couple of unlucky trap spawns kills character randomly with no possible way to prevent it" territory. But maybe we should just remove *everything* trap-related to give room for a re-think.


The former case, hmm... Yeah, that could be problematic.

The latter is (obviously?) the one I favor. The main reason for avoidance being the amount of code grepping involved, and the existence of monster traps.

Though, on further thought, monster traps are pretty darned useless. Maybe the entire trap morass should be torn out.

... And yes, for the record, I am volunteering to do that. :) I'll have plenty of time before New Year's.

Quote:
I'll be brutally honest that I'm also slightly motivated by the desire to get rid of the thousands(?) of lines of code required to support traps. (This has to do with a probably-overly-ambitious code conversion project that I've sort of embarked upon... but I don't want to get anyone's hopes up too much in case it never goes anywhere.)


That would be nice in view of lengthy C++ compile times too. :P

Re the code conversion... What do you have in mind exactly? GoLang, Rust, or such? (I should really start learning one of those.)

Quote:
[1] ... but let's face it: Any method of finding traps which isn't 100% isn't going to fly in T2, given the extreme nastiness of some of the traps.


Another reason behind my "partial" solution above. If we're going to have traps, it should at least be possible to know where they'll pop up. But I still prefer your solution of removing the current trap code.

Quote:
EDIT: Fun little addendum: Removing traps leaves Antimagic users with exactly one useful activatable "spell" based on the Anti-magic skill :), namely Continuum distruption. Maybe that should be streamlined such that any player-initiated teleportation automatically succeeds and enemy teleportation automatically fails (or prompts?) -- though I'd hate to be the one to find all the places where code needs to be changed to achieve this effect :).


Hmm. The streamlining makes sense mechanically, not sure about thematically though. If that, then why not allow AM characters to use devices too? Or, uh... something. AM doesn't make much sense anyway, really.

Thought: maybe get rid of Unbelievers entirely, and merge the Antimagic multiplier into Spirituality, for better saving throw if the player wants?

... Actually I like that latter, because removing AM would allow simplification and de-kludging of the magic code, IIRC.

Also I like the thematic implications. If you want to be a warrior in a world full of wizards, you'd better have good connections. :)

Quote:
... and having given it a little more thought: Someone over on the oook forums suggested a few trap ideas, but one that stuck out to me as having great potential was the idea of traps being "static terrain" that was part of the dungeon with timed effects based on player proximity. Those effects could be a timed poison cloud, arrows being fired every turn while you're in line of the trap (or even "one-square-per-turn-speed" radius 1 clouds), maybe a circular "blast" effect whenever you're in a certain radius, whatever.


This is how traps work in Unangband. The problem in Un is that they are incredibly deadly, and nobody has good trap detection. So my advice in the above case, would be to also make them permanently visible, at least as a generic "unknown trap" feature.

I also think such things would best be done after I rip out the existing trap code. :P

Quote:
I think this would could lead to interesting random 'puzzles' if traps were generated randomly in close proximity to one another -- esp. in tight spaces such as vaults.


Indeed. That'd be something to consider for future versions... Maybe some of the monster code could be recycled for that? Traps as stationary monsters with very few vulnerabilities?

Edit: in the meantime though, I'm going to file a pull request for my branch above, so that we have improved gameplay in the mean time.

_________________
"These aren't the hobbits you're looking for."


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 1:06 am 
Offline
Uruivellas

Joined: Tue Dec 13, 2005 12:35 am
Posts: 702
Rats... It looks like "special" also includes moated rooms of any sort. :( Guess I'll just have to proceed with ripping out the trap code.

_________________
"These aren't the hobbits you're looking for."


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 6:43 pm 
Offline
Spiderkin

Joined: Sat Mar 18, 2006 12:48 pm
Posts: 478
I'm quite fond of Anti-magic myself, even if you're right that it's a bit of an odd skill/class...

Yeah, considered Rust, and actually it does look kind of like a reasonable option especially since it would permit a gradual migration/phasing-in. There are a few downsides, though it looks like a pretty nice language overall. (Lack of higher-kinded types, general newness, etc.)

Currently I'm exploring the feasibility of a rewrite in Scala.


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 6:44 pm 
Offline
Spiderkin

Joined: Sat Mar 18, 2006 12:48 pm
Posts: 478
Btw, I find QtCreator quite nice as an IDE -- the Find Usages thing is extremely useful when exploring what can be removed without affecting anything.


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 7:05 pm 
Offline
Uruivellas

Joined: Tue Dec 13, 2005 12:35 am
Posts: 702
Quote:
Yeah, considered Rust, and actually it does look kind of like a reasonable option especially since it would permit a gradual migration/phasing-in. There are a few downsides, though it looks like a pretty nice language overall. (Lack of higher-kinded types, general newness, etc.)


Hmm. I have an acquaintance who does infosec stuff, and he loves Rust. Says it's much more efficient for programmer time than C++, and a lot of other benefits. I wouldn't know myself though, I'm still struggling with proper object-orientation.

Quote:
Currently I'm exploring the feasibility of a rewrite in Scala.


Doesn't Scala need the entire JVM, plus its own libraries? :shock:

(Mind, I should warn you, I'm terrible with functional programming. If I contribute stuff for a Scala version, it will probably look like Java.)

Quote:
Btw, I find QtCreator quite nice as an IDE -- the Find Usages thing is extremely useful when exploring what can be removed without affecting anything.


I'll give it a try... FYI I typically use Geany, and/or one of various console editors. Which is probably part of the problem. :P.

Edit: "Find Usages" sounds fantastic though. grep and friends will only get you so far, and all. :(

_________________
"These aren't the hobbits you're looking for."


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 7:12 pm 
Offline
Uruivellas

Joined: Tue Dec 13, 2005 12:35 am
Posts: 702
BTW, I should probably mention, I see two things in the current code base that I think might be problems, as far as porting to another language:

1. HUGE functions. Many functions go on for pages and pages, and should really be split up in some way. (Again, I volunteer!)

2. Code duplication. This seems particularly prevalent in the trap-related code sections; experimenting with deleting stuff today, I often found myself removing the exact same stanzas of code two or three times, including the comments.

... I'll see if I can get any of this squared away today.

_________________
"These aren't the hobbits you're looking for."


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 7:14 pm 
Offline
Spiderkin

Joined: Sat Mar 18, 2006 12:48 pm
Posts: 478
Lord Estraven wrote:

Quote:
Currently I'm exploring the feasibility of a rewrite in Scala.


Doesn't Scala need the entire JVM, plus its own libraries? :shock:



Only if you don't run in in the browser!. Obviously there would be quite a few changes necessary to avoid file access and such, but it should be feasible to get a browser-based version of T2 using scala.js.

Such a thing could be possible using Rust + WebAssembly, but I'm guessing it's going to take a while to reach maturity.


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 7:22 pm 
Offline
Spiderkin

Joined: Sat Mar 18, 2006 12:48 pm
Posts: 478
Lord Estraven wrote:
BTW, I should probably mention, I see two things in the current code base that I think might be problems, as far as porting to another language:

1. HUGE functions. Many functions go on for pages and pages, and should really be split up in some way. (Again, I volunteer!)

2. Code duplication. This seems particularly prevalent in the trap-related code sections; experimenting with deleting stuff today, I often found myself removing the exact same stanzas of code two or three times, including the comments.

... I'll see if I can get any of this squared away today.


Yes, but the way I intend to do it would be to actually convert stuff with minimal modification, so it'll look basically look very much like Java-in-Scala at first (with mutable data all over the place, etc.). When the code has been converted and can run (at least minimally) it'll probably be feasible to start to disentangle things using the better support for large-scale modularity of Scala. (Traits, ctor dependency injection, etc.).

In short: I don't think it's worth your time to try to do any refactoring of the C++ code base. (At least assuming that the rewrite actually happens... which is a big assumption.)


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 7:46 pm 
Offline
Uruivellas

Joined: Tue Dec 13, 2005 12:35 am
Posts: 702
Ah, gotcha. In that case maybe I'll also hold off on the complete trap removal?

_________________
"These aren't the hobbits you're looking for."


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 8:03 pm 
Offline
Spiderkin

Joined: Sat Mar 18, 2006 12:48 pm
Posts: 478
Lord Estraven wrote:
Ah, gotcha. In that case maybe I'll also hold off on the complete trap removal?


Trap removal would be great! I still haven't tried to "do it right", so you'd actually be saving me a lot of work if you could do that.


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 8:12 pm 
Offline
Uruivellas

Joined: Tue Dec 13, 2005 12:35 am
Posts: 702
Hmm. "Doing it" I can manage, doing it right possibly not. I'll see though.

Edit: this may be harder in QtCreator than I thought. "Find Usages" generates a lot of false positives somehow. :?

Edit 2: yeah, I'm going at this with Vim for now.

Also: argh! There is confusion in the code between 't_info' and 'tr_info'. Sometimes t_info is terrain, other times it's trap info. ARGH.

_________________
"These aren't the hobbits you're looking for."


Top
 Profile  
 
PostPosted: Sat Dec 19, 2015 8:32 pm 
Offline
Uruivellas

Joined: Tue Dec 13, 2005 12:35 am
Posts: 702
Okay, so, the traps code is not only entangled with Rogues' monster traps, but also with searching, hidden doors, and chest traps.

I am considering removing all of them.
- Searching and hidden doors are pretty useless, especially without traps, and don't add much flavor
- Chest traps are very, very heavily dependent on floor trap code AFAICT

I will try to preserve them for now though.

(But yes, it would be very nice indeed to yank out all that code!)

Edit: I'll keep trapped chests, hidden doors, and searching for now. Monster traps will be gone though.

Edit: or not, because t_info includes chest traps too. BLARGH.

_________________
"These aren't the hobbits you're looking for."


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 30 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group