ToME: the Tales of Maj'Eyal

So I may be completely out of my gourd, and it's entirely possible I've bitten off more than I can even get my mouth around, much less chew, and I definitely needed that one more ball in the air, but after about the fiftieth time getting blinded/stunned/confused over in T4 and going, "Argh! I want my Potions of Cure Critical Wounds back, dammit!", I decided to bite the proverbial bullet and make the attempt to port T2 to the T4 engine.

Now, I'd prefer to have gotten further along with it before mentioning it, but I kinda got called back in, and I could hardly just casually stroll back in after all this time without bearing gifts, so here we are. What I've got so far isn't much more than a mock-up; character creation works (mostly...), and Bree is partly implemented (stores were the next thing I was going to try to figure out how to implement...), and the Barrow Downs is present but may or may not work. [Man, that sounds awfully anemic when I actually say it out loud...]

My questions at this point, then, are:

• Is this a worthwhile project? Is there interest in it?
• Am I stepping on any toes here? I'm trying to think I started this after LordEstraven stepped down from 2.3.9 maintenance and before AnonymousHero stepped up to replace him. It's certainly not my intention to muscle in on anyone's territory or fracture the community or anything like that.

So. How badly have I stepped in it here? [dons flame-retardant hazmat suit]

First, a correction: I never maintained ToME. I maintained a fork of it for a while (on and off) in which I tested out some ideas of mine, many of them rather silly.

But anyway... IMO this is a noble idea, but I don't think it will lead anywhere good. T4 is a good game from what little I've seen, but the engine has huge problems - not just with Linux and wimpy hardware either, a lot of users have had problems getting it to start on Windows 7. I feel that porting it to an engine that has problems on so many systems would be as good as throwing it in the trash; the user base would be limited by hardware capability, driver support, software compatibility... Suffice to say I don't think it's smart.

(Though I must also admit some bias. T2 is a relatively tiny text based game, even if it's gigantic by *band standards; code quality and faux modularity not withstanding, I would hate to see it turn into a RAM-gobbling effects-laden behemoth like T4.)

BTW though - I should mention as a possible alternative that AH is working on a port of T2 and Theme to pure C. It's currently a branch of tome2 on Gitorious; if you've got decent C skills you might be able to contribute. (I don't, unfortunately.)

Also, on the subject of cross-platform-ness, I made some changes to the SDL interface (subsequently accepted by AH) which made the window size itself depending on font and font size, instead of requiring startup parameters for size (or defaulting to 800x600 with lots of empty space). It still has huge performance problems, but it's less annoying now. (And still performs better than the Win32 interface.)

And a *huge lot* more have no problem at all.
And those that do will mostly be fixed in b41 with the sdl upgrade (which if you want to go this way is no TE4 fault at all if it doesnt work ..).
You judge harsly and fast for somebody who admits not using it.

As to using (not much) RAM (compared to any other modern games); get on with your time. Yes there is beauty in games that fit on a floppy disk and run on a dos emulator. But floppies are no more and dos only lives in emulators.

As to Zizzo: go on I find the idea quite fun. It's a huge task because T2 was not a small game (although probably smaller than T4 in term of content) but even if you do not do it all it's a worthwhile experiment and it's fun

A pure text game without fancy graphics things won't be as demanding as ToME4 is. My T-Engine games run much faster for instance. And old curses games have just as much compatibility problems.

I think you shouldn't underestimate the amount of work involved though. Only DarkGod has made a game of that scale in the T-Engine. It's not as simple as just porting.

I've tested the module you posted, got a few comments:
- please oh please: get rid of the 18/xxx notation, it is silly, stupid, old, undescriptive, annoying, and many other things ..
- you dont have to do "Vampire Dunadan" you could have the race mod be separate, birth descriptors are not fixed at all
- I see you have got all terrains & objects already imported, you made a convert script I imagine ? that's very nice

My best advice would be that you aim to get something playable ASAP. Implement combat, implement the few skills needed to make a basic class work (a warrior probably), fill up the barrow downs. Once you can play & clear the barrows you're on the right track, from then on it's "just" adding more (a lot)

I think this is a really cool idea but would be a huge amount of work getting everything ported (at least I think it is)
I downloaded your progress and was impressed on how similar it looks like the original.
Some comments and concerns of mine are
you can add extra columns to the birth descriptor. you can make subraces and subclasses there own column
I don't think Te4 has macro support so spell casters may need to be rethought in some minor way
yeah the 18/XX is just annoying and should be gotten rid of
you may want to create a birth screen where the user can change the name

A lot of those are concerns and this looks like an interesting project

I wouldn't use macros for spellcasting. There's really no need for them with T-Engine.

I understand wanting to be faithful to the original but the original was a product of it's time and hanging on to things just for the sake of legacy isn't good in my opinion.

It's not so much a case of legacy support IMO, as of being friendly to hardware from a few years back. Not everyone buys top-of-the-line machines, or upgrades to a new machine every two years, or even upgrades their RAM and/or video card.

We're talking about a 2D game, with very limited graphical effects. IMO, one has to ask if such a game really needs an almighty OpenGL based engine behind it. Getting with the times is one thing, wasting system resources is another. Just because the RAM and CPU and GPU cycles are there, doesn't mean they must be used by the game.

(And I think there's an incredible amount of waste going on in the computer industry at large. Progress too; but workstations turning into paperweights overnight creates some serious problems... That's rather outside the scope of this discussion, but I think it should be mentioned.)

Not to say I don't see the value of using TE4, BTW. It is an already existing game engine with an already existing module framework... That counts for something.

T-Engine is fine. It has some issues with some chipsets and the SDL guys have been working hard on the 64-bit Windows compatibility issues (which is an issue much of the software industry is dealing with, not just ToME).

I was running ToME on a machine that was 10 years old up until very recently and most modules aren't going to take near as much resources to run.

Also releasing on T-Engine means your module is already cross platform.

Anyway, I think this thread is getting off topic. I would love to play a modern port of ToME 2. I loved that game but after playing using T-Engine I can't go back to crap like macrod spell casting or a lack of mouse support.

*edit* VVV

Lord Estraven wrote:If you say so....

You're really going to be like this... I know you had a huge amount of trouble getting the game to run and I know you're not the only one that's had issues with it. I also tried to suggest ideas and gave feedback in your thread when you asked what hardware people ran the game on. You can look back there and see lots of ten year old hardware, sub 2 gigs of RAM, XP set ups, etc. etc. As to OpenGL it's not even the issue. The issue is SDL (because DG updated to the latest SDL before it was released with the hopes that by the time SDL 2.0 was ready ToME would either still be in beta or close to release itself, something that so far seems to be working out). And as to rather or not a Roguelike engine really needs OpenGL you're right, it probably doesn't. But you can make other games on T-Engine (it's not just for roguelikes) and if you want to use OpenGL for your roguelike you can.

Anyway, it's time for me to shut up. Because I'm all out of being polite.

If you say so... I personally don't use Macros, but FWIW Vanilla's SDL interface has mouse support.

BTW Zizzo, what are your plans re the Automizer? It would be nice IMO to replace it with something like the auto-squelch system in Vanilla - less powerful but absurdly more convenient.

I think the TE4 interface will work well in a t2 module. I don't think anyone should go so far as to duplicate every single quirk of the old engine, though. Just the content would be fine. Thaumaturgy and other things had a fubar'd interface to begin with, so I won't feel bad to see macros die in favor of the TE4 system.

It's a monumental project, to be sure. I'm excited to see how it turns out.

^^^ Sorry if I stepped on people's toes above. It is only a game, after all; nothing terrible would have come of it had I kept my mouth shut.

I guess I'll sit back, relax, and let things take what course they may.

Oh man, what have I gotten myself into here?

Lord Estraven wrote:First, a correction: I never maintained ToME. I maintained a fork of it for a while (on and off) in which I tested out some ideas of mine, many of them rather silly.

Ah. [bows] We Apologize for the Error.(TM)

Lord Estraven wrote:(Though I must also admit some bias. T2 is a relatively tiny text based game, even if it's gigantic by *band standards; code quality and faux modularity not withstanding, I would hate to see it turn into a RAM-gobbling effects-laden behemoth like T4.)

Hey, I can sympathize; I was playing Angband on systems with no graphics at all, and I advocated for keeping ASCII mode back in ToME 3. That proverbial ship has apparently sailed, though. For myself, I got T4 built on my Debian box without much hassle; my only problem is that the X driver for my Intel graphics chip apparently doesn't support whatever SDL or OpenGL stuff the game is using, so the CPU is apparently doing all the work. My poor laptop's fan kicks into high gear just sitting in the level-up dialog...

Grey wrote:I think you shouldn't underestimate the amount of work involved though. Only DarkGod has made a game of that scale in the T-Engine. It's not as simple as just porting.

Now he tells me...

darkgod wrote:- please oh please: get rid of the 18/xxx notation, it is silly, stupid, old, undescriptive, annoying, and many other things ..

That's configurable as a birth option. [checks code] Okay, it's not a birth option, it's a gameplay option, which will be configurable as soon as I implement the options dialog. Or maybe I'll just promote it to birth option for now. At any rate, it's how I learned Angband and ToME, so it's gonna be there in some form one way or another.

darkgod wrote:- you dont have to do "Vampire Dunadan" you could have the race mod be separate, birth descriptors are not fixed at all

Oh, race and subrace are separate birth descriptors internally; I only display them in a single tree because I didn't think I had room in the Birther dialog for separate race and subrace lists.

darkgod wrote:- I see you have got all terrains & objects already imported, you made a convert script I imagine ? that's very nice

Perl FTW. I can't imagine doing all that by hand...

darkgod wrote:My best advice would be that you aim to get something playable ASAP. Implement combat, implement the few skills needed to make a basic class work (a warrior probably), fill up the barrow downs. Once you can play & clear the barrows you're on the right track, from then on it's "just" adding more (a lot)

Oh, is that all? And here I was despairing of how much I was going to have to do to get even that far. After all, if I want my !oCCW's back, I have to (a) implement !oCCW's, (b) implement all the temporary status effects that !oCCW's fix, (c) implement stores from which my character can buy !oCCW's, and (d) implement the gold my character will need to buy !oCCW's from said stores. I don't think I'd want to walk the Downs without some ?oWoR's in my pocket either.

Goblinz wrote:I don't think Te4 has macro support so spell casters may need to be rethought in some minor way

Oh gods, I am dreading trying to figure out how to handle that. I mean, you've seen my macros file, right? I eventually had to go to two-character macros to cover all the spells. I don't think T4 has that many hotkeys...

Goblinz wrote:you may want to create a birth screen where the user can change the name

Hm? Oh, that's right, you can change the character's name from the 'c' screen. I may try to wedge that into the Character Sheet dialog somewhere.

MasterShizzle wrote:Thaumaturgy and other things had a fubar'd interface to begin with, so I won't feel bad to see macros die in favor of the TE4 system.

Urk, it's been far too long since I played my Thaumaturge character. That will probably be done much later.

Lord Estraven wrote:BTW Zizzo, what are your plans re the Automizer? It would be nice IMO to replace it with something like the auto-squelch system in Vanilla - less powerful but absurdly more convenient.

Dude, you've seen my automatizer file, right? I use all that power. I'm actually sorely tempted to make the automatizer a fully scriptable Lua file, to overcome some of the shortcomings of the current automatizer (when my weapon gets cursed, for instance, the automatizer stops recognizing it as {excellent} or {special} and doesn't know it supposed to keep destroying {good} weapons).

I can understand the appeal of something simpler, though. I'll probably do it via addons, so you can go with whichever solution you prefer. I don't remember how Vanilla autosquelch works, though.

----

On a side question, should discussion of this whole thing be happening here, or in T-Engine 4 | Modules?

zizzo wrote:

Lord Estraven wrote:BTW Zizzo, what are your plans re the Automizer? It would be nice IMO to replace it with something like the auto-squelch system in Vanilla - less powerful but absurdly more convenient.

Dude, you've seen my automatizer file, right? I use all that power.

Have you tried the squelch system in recent vanilla Angband? I found it just as usable as T2's -- you just have to let go of the idea of using a single file for all your characters. It's so much more convenient to use in-game that this is not a problem. (I believe Angband has also reduced the number of drops somewhat, so that may be a factor. Reducing the number of items also seems a desirable thing in T2, but I digress...)

zizzo wrote: I'm actually sorely tempted to make the automatizer a fully scriptable Lua file, to overcome some of the shortcomings of the current automatizer (when my weapon gets cursed, for instance, the automatizer stops recognizing it as {excellent} or {special} and doesn't know it supposed to keep destroying {good} weapons).

Unless you're willing to force people to use an external editor (or implement an in-game Lua editor) that's probably not a good idea in terms of UI.

zizzo wrote: I can understand the appeal of something simpler, though. I'll probably do it via addons, so you can go with whichever solution you prefer. I don't remember how Vanilla autosquelch works, though.

Please try it out for a few mid-to-high level characters. It works a lot better than you might think. The fact that it a) doesn't actually destroy items permanently, and b) runs faster rather than using linear time in the number of items squelched(*) are also bonuses, IMO.

(*) A white lie, you can avoid most of the overhead but only if you go in manually and edit your .atm file and manually group rules by tval. It's a stupid default.

Anyway, you've certainly got your work cut out for you. People have tried before to port vanilla (a much smaller game) to high-level languages, and all have failed so far.

Re: "Competition" for maintenance. I certainly don't lay any claim to having exclusive rights to porting/maintaining T2. I will say though, that almost all of the Lua is gone now (in the "unlua" branch) and the only hard part left is the ... Automatizer. Once that's ported, all traces of Lua in T2 will be gone and some modernization and cleanup effort can begin. (I'm not quite sure what direction that'll take, but I'm thinking of a statically typed higher-level language which can interface with C easily -- unfortunately there aren't too many candidates, but C++11, Go and D perhaps look like somewhat realistic options.

Anyway, if you do go ahead, then good luck to you!

Yeah I've moved it to the modules forum where this belongs

As for UI & stuff, I'd say, take all the gameplay, but make a new UI yes. People today are not expecting/wanting to make macros to use a simple spell. Hotkeys work, they work with the mouse, the keyboard, you can even easily drag&drop them (the engine gives up to 5x12 hotkeys, that's quite a lot and more can be added if needed).
As for automatizer, yeah probably reducing the drops is much better than requiring such a thing.

PS: OpenGL is 20 years old, you'll be hard pressed convincing me it's "cutting edge tech". It only requires a non-stupid video card driver