ToME: the Tales of Maj'Eyal

I've been thinking (that means trouble), and if no one is willing to keep developing Tome in C, why not port it over to some other language? Obviously it would be a tremendous work, but think of the possibilities, complete code clean-up, some more widely known language, and quite probably (once first release) a much easier to maintain code base. But then again, there are problems, a lot of work, possibly less portability, and work. What does everybody out there think?

_________________
-The Bigfoot

I really do exist.

That would mean implementing the whole LUA thing in another language wouldn't it? Ugh.

Anyway I guess I could offer my help, though I'm really quite a novice.

I speak C and am willing to develop in it, even though I haven't been active in the last few weeks. C is a widespread language, and I see no reason to port the engine away from it. (Into what? I actually prefer C++ but not nearly enough to port the engine, not even close.) Moreover, the engine contains quite a bit of code. There are over a hundred thousand lines in total, according to a quick wc command.

What we are lacking is leadership and direction.

_________________
Zothiqband -- still an Angband variant.

Hmmm.... I really don't know any Lua.


C is a widespread language. And admittedly faster and more powerful than the majority of languages. Over a thousand lines of code? I need to download the source and start looking through. That instantly made me think of python, it is quite efficient in terms of code-length, easily portable, quite simple, no need to compile, though it may not be very familiar to many people (me included).

Or we could just get leadership and direction.

_________________
-The Bigfoot

I really do exist.

There are many C source files with more than a thousand lines of code.

For example, generate.c is 8359, cave.c is 4939, monster2.c is 3773 , object2.c is 2144, and spells1.c is 3980 lines long. ToME is far bigger and more complex a game than you might think. Also, wilderness travel in particular takes surprisingly much in the way of CPU the way things are currently coded. I had to turn rotting corpses off by default in the T-Engine due to the performance hit it takes to go through every single item on the map every single time is stepped forwards (IIRC 10 times per normal-speed player-turn, except in the wilderness mode, where it's much more per step) and decrement the freshness counter for those items that have it, even if no item has one.

A lot of modern games are graphics card bound. ToME can function with truly ancient graphics, but its CPU requirements are quite a bit beyond the likes of Rogue.

_________________
Zothiqband -- still an Angband variant.

Hmmm.... You're probably right, porting over isn't such a good idea, I just started looking through the code (though not really understanding C). It is very complex, I still play with a print-out of all the keyboard commands next to me.

It's graphics are the same on both my old 32-bit graphics card, and my new 256-bit graphics card. Though I must say that I noticed something of a speed improvement when switching from a Pentium4 to two dual-core cpus.

So... Where would leadership and direction be found around here?

_________________
-The Bigfoot

I really do exist.

hmmmmm.... try over there --------->

But seriously, DarkGod had most of it (it is his game after all), but because he is MIA (due to real life) we have been somewhat floundering... that said the engine has gotten worked on (thanks Nerdanel) but the ToME module itself has been mostly dormant.

so I guess the best way to help would be to learn lua (though we use an outdated version that is edited) and help with the module. Though at the same time I know it has been tossed around about moving to the new lua. but if you learn the old lua, it shouldnt be that hard to switch to the new one.

_________________
Oliphant am I, and I never lie.

I know DG got married and I wish him all the best, but honestly, you'd think there might have been a spare 5 minutes over the course of the last year+ when he could have posted something to let the community know what's going on and if he ever intends to return to the project. If he doesn't, then he can simply hand the reins over to Nerdanel or some other active member who is willing and able to take the project forward.



Only 46 to go now, albeit it's been two months - get voting and I'm sure LB & Co will spring into action

So I could learn lua and c. Or I can just vote another 50 times..... I think I'll vote another 50 times.

_________________
-The Bigfoot

I really do exist.

I think we need more module developers. I'm the only person to have updated a module in 2009. The engine should be serving the needs of the module developers, but without module developers all that it's left is fixing (mostly irrelevant) problems reported by automatic tools and trying to implement random stuff that strikes my fancy.

The C code is actually not that bad, the Lua part of the engine is far more incomplete, and the ToME module is seriously unfinished. I'm far better with C than Lua too.

_________________
Zothiqband -- still an Angband variant.

I really believe leadership and direction are paramount here.

Clearly, we can't simply appropriate DG's game, but he has proven willing to release the work Nerdanel has done in the past, so I think we can make a distinction between actual ownership and practical ownership. If DG ever does come back and wants the helm returned to him, then of course it's his to demand. Xandor made a brave effort to whip people into line earlier this year, but the problem was that (with the best will in the world) he is an expert neither on the module, nor the engine. So...

My suggestion would be that Nerdanel takes ownership of the engine and LordBucket takes ownership of the module. Nerdanel has said that she has no interest in the direction the module has taken - fine, no need to get involved. LordBucket has said that he cannot code the engine and is not willing to create the entire module himself - fine, but we need someone to lead the way and dish out the work. From what I've seen, there is no shortage of adept programmers willing to help on both elements, but there is no driving force.

I'm just throwing those two names out there, as they are the two members who have been the most active and vociferous on the two aspects of the project. If they don't want to get involved this way, that's fine of course. If someone else with the requisite skills wants to lead, fantastic.

At the moment, we're going at this backwards and trying to work out how many people we've got. It's not going to be possible to engage people's interest or enthusiasm with vague questions about whether they would be interested in helping with some form of coding in principle. What needs to be done is for the module owner to roughly lay out how much work he thinks is involved, then start asking the people who've expressed an interest whether they would be willing to cover specific tasks. If there are enough people, great; if not, that's an end of the matter.

It's easy for me to sit here and pontificate when I have no idea what things like Lua and memory leaks are, so apologies if I sound pompous or hypocritical, but this game is going nowhere until someone takes responsibility for it.

More module developers? That's it? Making a basic module is pretty easy.

Since I play around with making mods for it occasionally, I might as well try and finish one of them. I can't promise when it will be done or it's quality, but I'll try to make one. It won't have a lot of new exciting features because I don't know tome Lua though. At the risk of sounding over-confident, rash, and perhaps even spoiling the plot, I've always wanted tome to be a bit truer to the books, that is all I wish to say for now. I will not be discussing the mod in the forums until completed.

_________________
-The Bigfoot

I really do exist.

Sure, we could use more engine developers too, especially on the Lua side. I've been trying to make random artifacts work, but there's a bug I can't figure out in reading in the array of randart parts. I don't even know if it's even something particularly hard, since it might just be something stupid that I just happen to consistently overlook.

Anyway, making modules is more work than it might look, especially if you are trying to make a complex module with a lot of features. It is also good at revealing bugs and missing features in the engine.

Well, at least this discussion has made me touch the code again, even if all I did was to correct a bunch of minor things splint warned about. The idea is that if I fix enough stylistic issues that don't really matter the "stylistic issues" that are real bugs become obvious as they no longer disappear among a crowd of spurious warnings.

_________________
Zothiqband -- still an Angband variant.

It is not a complex module. I've already started and then I thought of something. I'm modding 2.3.5 since it is the only version that works fully on my Vista machine. None of the 3alpha series works, they always crash, giving me a bunch of error messages.

_________________
-The Bigfoot

I really do exist.

Naturally, I was talking about modding 3.0. Modding an old version does nothing to improve the new version since the two are incompatible. You also have a MUCH wider range of modding options in 3.0, with the associated increase in complexity.

I've heard that ToME 3 is broken on Vista but I thought that extended to all ToME versions. I've also heard the problem is in the Windows frontend and that the multiplatform SDL frontend should work fine. The problem is that the Windows compile is compiled with the frontend that doesn't go along with Vista.

I'm a Linux user with no access to Vista so I can't test this myself. It looks like someone with the capability to compile on Windows should try to produce a ToME 3 binary with the SDL graphics. If it works, we can then declare the old Windows graphics deprecated since Microsoft broke them and apparently there isn't anyone willing to fix them or even knowing what's the problem.

_________________
Zothiqband -- still an Angband variant.