ForumsHQ

So here's a question: what is keeping a terminal from having a backend that's uniform (i.e. databases), with frontends that are different? That way, people can program their own interfaces to a backend that's platform independant (i.e. use a database that's available from Java, VB.NET, etc)...



Also, a question about paths - are they really neccessary? Given each room has the needed information to map from one point to another (as shown by Syntax's dynamic mapping functions), could that information be used to go from any one point to another in majormud? Of course presets for rooms like the Bank would be set, but it would allow for any and everyroom to be accessible, as long as you know the map/room number. This way, all you would need is a backend up of the database to "update" all paths... and it would be a lot more dynamic.



Sorry if these ideas don't make much sense - I'm half drunk writing them. But any thoughts?

So here's a question: what is keeping a terminal from having a backend that's uniform (i.e. databases), with frontends that are different? That way, people can program their own interfaces to a backend that's platform independant (i.e. use a database that's available from Java, VB.NET, etc)...

i'm not really sure what you're getting at here. isn't the terminal the frontend? we were (moreso stylez) looking into XML but we don't think the speed is going to be good enough when doing fast read/writes. we're going to use an access database (ADO.NET) and one way or another you can import/export an access database from/to anything.



Also, a question about paths - are they really neccessary? Given each room has the needed information to map from one point to another (as shown by Syntax's dynamic mapping functions), could that information be used to go from any one point to another in majormud? Of course presets for rooms like the Bank would be set, but it would allow for any and everyroom to be accessible, as long as you know the map/room number. This way, all you would need is a backend up of the database to "update" all paths... and it would be a lot more dynamic.

yeah they are for one simple reason, efficiency. it's hard to make human decisions programmaticly that suit everyone. who are we to say it is better to go an extra 100 rooms to avoid a 20 point damage trap. when trying to make dynamic loops, it's also hard to decide how to travel the most efficient way --hitting all the lair rooms while overlapping the least amount of available rooms. it's probably possible, but i think it would produce too many annoyances.



i think what what we could do is make paths the primary way of travel, but also have the db as a backup for when it gets lost or when you're trying to find a room that a path doesn't exist for.

Sytanx53, and I were just talkin... Here's our idea that we might implement...



Interactive Path Creation.



You'd be able to choose Start / End Room (If equal then Loop is assumed)

Specify Criteria ie. No doors, Doors I have keys for only, No River, No Traps etc..



And have it dynamically create a Path or Loop for you and display it on a map, so that you can modify it easilly, and then allow you to save it and use it whenever you want.



How's that?

i'm not really sure what you're getting at here. isn't the terminal the frontend? we were (moreso stylez) looking into XML but we don't think the speed is going to be good enough when doing fast read/writes. we're going to use an access database (ADO.NET) and one way or another you can import/export an access database from/to anything.



I'm not too sure either. The more I thought about it (and talked with Splat), the more I realized that the push for a nice open standard that's platform independant for MajorMud probably isn't that important. What I was thinking, which I now realize isn't going to work that well, is more of an API layer between the databases and the frontend - so you can have your GUI up front dealing with the player interaction, while having the API layer handling the calls from the GUI to the backend database. It would offer more customization than is needed for a measly MMud client, and wouldn't be worth it. I withdraw THIS comment :)



yeah they are for one simple reason, efficiency. it's hard to make human decisions programmaticly that suit everyone. who are we to say it is better to go an extra 100 rooms to avoid a 20 point damage trap. when trying to make dynamic loops, it's also hard to decide how to travel the most efficient way --hitting all the lair rooms while overlapping the least amount of available rooms. it's probably possible, but i think it would produce too many annoyances.



i think what what we could do is make paths the primary way of travel, but also have the db as a backup for when it gets lost or when you're trying to find a room that a path doesn't exist for.



First off, I agree that this wouldn't work for loops. But I didn't suggest it would, either.



For paths, the program could figure out different ways and offer them to you as a suggestion: Pop up box, "Take a longer route, or take 20 points of damage."

Or, you could have a list of different options such as "Avoid traps", "Take shortest path", "Avoid (insert area here)", etc. I *know* this isn't easy. And I *know* this isn't exactly processor friendly. But I think we can all agree that if it was done correctly, it would be very useful, right?





Or, a middle ground: what ways could paths be made more easily, without the need of walking from room to room, and how could they be updated easily? Anyway to possibly import a textfile with 1 command per lineas a feeder file? Walking through 300 rooms just to make one path/loop sucks my ass.



Oh, and just an idea I'm sure you guys have thought of for your terminal: the ability to export a BBS's edits to your terminal's database format (the same way you can with MMud Explorer).

Sytanx53, and I were just talkin... Here's our idea that we might implement...



Interactive Path Creation.



You'd be able to choose Start / End Room (If equal then Loop is assumed)

Specify Criteria ie. No doors, Doors I have keys for only, No River, No Traps etc..



And have it dynamically create a Path or Loop for you and display it on a map, so that you can modify it easilly, and then allow you to save it and use it whenever you want.



How's that?



I like. But like everything else, it all depends on how it's implemented :) I'm not trying to be a prick about this, but I figured talking about best practices/wanted features for a terminal *before* you guys started laying down the base code would be better than waiting for a release.



Knowing first hand how much effort and time Syntax puts into his coding, I have no doubt that this program will be much better than what we already have. So far, he's taken 2 of the 3 tools we used growing up playing mud and turned them from kind of useable into respectable programs that mudders don't live without - this terminal will make it 3 of 3.



I guess what I want to see happen isn't simply a cleaner, more reliable MegaMud, but a complete revolution of how we mud. Think of the difference between QModem/Terminate/whatever and MegaMud, then make that same jump when you develop this terminal, and we'll all be floored. Well, if we aren't already.