The Mana World Forums

This may be in the wrong forum, so apologies if it is.

For a self build, is it better to use tmw server or manaserv?

TMW-eAthena server will be much quicker to set up because it has plenty of content (graphics, monsters, quests, items, maps...) ready. All the content on the main server is licensed under GPL.
The source code for that server is hilariously hard to understand, and therefore hard to extend.

Manaserv will require much more work to set up, but the results will endure longer. In my opinion, it was only recently released as a playable game. There exists much less content ready for use.
The Manaserv source code is much better, the game engine supports many features that are missing in TMW-eAthena, and there is a great team of programmers who continue to improve it.

It's more complicated than Frost said.

Although tmwAthena is an unmaintainable mess, the people who *originally* wrote it actually knew what they were doing. The biggest problems are: people who extended the code base who didn't know what they were doing (the worst of which is the magic system written for TMW - oh, how I wish they'd just added support for the *existing* magic system to the client!); people whose native language was Japanese/French/I-don't-remember-what-else; and scalability.

I'm working on transforming tmwAthena into a maintainable mess that will be easier to add features to.


In contrast, ManaServ is written by people who, frankly, do not know exactly what they're doing. I haven't looked as much at ManaServ as at the Mana client, but I know of at least 2.5 major design flaws. And, unlike my incremental changes to tmwAthena, ManaServ is conceptually incompatible with tmwa content - it's really not the same game.

Thanks for the responses about manaserv and tmwAthena.

I know which one was easier to compile.

Out of interest - how is tmwAthena licensed? Is it GPL (or similar)?

Thanks,

N.

newt_e wrote:Out of interest - how is tmwAthena licensed? Is it GPL (or similar)?

Currently everything GPL2+, but I am adding some of my GPL3+ work to it. I've thought about going AGPL, but there hasn't been enough discussion on that side, and it *does* make things more complicated.

(Contrast the Mana project, which last I checked is GPL2 only, due to approximately one file)

o11c wrote:

newt_e wrote:Out of interest - how is tmwAthena licensed?

Currently everything GPL2+, but I am adding some of my GPL3+ work to it.

Please explain what you mean. It would be easy to interpret your statement to mean that you are changing the license of the project code.

Frost wrote:

o11c wrote:

newt_e wrote:Out of interest - how is tmwAthena licensed?

Currently everything GPL2+, but I am adding some of my GPL3+ work to it.

Please explain what you mean. It would be easy to interpret your statement to mean that you are changing the license of the project code.

Do we really have to have this discussion again?
A lot of discussion happened on IRC, but here is a brief discussion of GPL3+ and a longer discussion about AGPL

A lot of prior discussion happened on IRC (logs of which I don't have right now).

The only people with a reason not to use GPL3 rather than GPL2 are:

• People who need to import source from another project that is GPL2 only, or that are GPL2 historically and do not have access to all the copyright holders.
• Evil corporations who make free software nonfree by exploiting loopholes in the GPL2.

As a developer, I am unwilling to let my works (which represent a significant amount of creativity) be released under a license that has known flaws.

Eek - didn't mean for this to turn into a licence discussion thread.

OK, next sill question, which is more architectural than anything else.

With manaserv, there is the option of using MySQL or SQLite. Does tmw-eathena use a backend SQL server of any description?

(Reply about licenses moved to http://forums.themanaworld.org/viewtopi ... 30#p127330)

newt_e wrote:Does tmw-eathena use a backend SQL server of any description?

Not yet. I'm considering three different courses of action in the long term:

• Postgres:
  Pro: good API
  Con: nontrivial to set up
• SQLite
  Pro: easy to set up
  Con: weaker API
  Con: possible scalability issues
• Write my own, limited, database
  Pro: easy to set up
  Pro: can be optimized for expected use case.
  Con: can't use existing database tools, so I have to write new ones.

MySQL is not being considered for various reasons.

Edit: moved to "off-topic" since you say you're working on a game that's not TMW. We really need a separate forum for such things ...

o11c wrote:MySQL is not being considered for various reasons.

Would it be possible to know them please? I do like this environment and workbench as well:)

Nard

Nard wrote:

o11c wrote:MySQL is not being considered for various reasons.

Would it be possible to know them please? I do like this environment and workbench as well:)

Nard

(Compared to Postgres)
The biggest concerns:

• are a poor API that is only in C. (There is apparently a Connector/C++ but it's not very accessible)
• no support for (threadless) asynchronous IO (essential for an efficient server).
• the documentation was obviously not written by someone with a technical background, whereas the Postgres docs obviously are.
• numerous violations of the SQL standard.
• in its default configuration, MySQL is more prone to disasters that are difficult to recover from. And we *know* we have to worry about those.

(SQLite also does not support async IO, but since it's reading and writing to a file directly, that *might* be less of a concern. I'm not entirely sure, though.)

Did you also consider any no-SQL solutions to persistent storage?

Crush wrote:Did you also consider any no-SQL solutions to persistent storage?

No. Is there something specific you have in mind?

Conceptually, tmwa fits in the classic relational database mindset - rows have fixed columns. Once you get your mind around the fact that you can't represent a list directly, that is ...

I am currently building a similar project with MongoDB. Its advantage is that it is schemaless. You don't have fixed columns, you just put documents into heterogeneous collections. The documents can have any fields you want. They are objects in a format similar to JSON (they call it "BSON" or "binary JSON"), so they can contain nested sub-objects and they can include arrays. That means that a 1:n relation is often not expressed with two tables like you would do in an SQL database. When you have a case of aggregation (like one character owning many items) you wouldn't have a separate collection "Items" with an entry for each item and every entry having a character_id which denotes the owner, you would have an array "items" right in each character document. To someone who is used to relational databases this seems like a violation of normalization, but in MongoDB this works pretty well, because arrays can be accessed transparently by the query language.

The biggest advantage of MongoDB is that you don't have to modify your database when you try out some new feature. That really gives a lot of flexibility and room for experimentation during development. This might not be such a great advantage for tmwAthena though, because its development is already pretty advanced so I don't think that the database schema will change much.

Its not that I want to recommend anything. I don't know your requirements well enough to do so. I was just wondering if you consider any noSQL solutions, because nowadays databases don't always have to be relational. It's not like SQL is deprecated like some noSQL fanatics are preaching. It still has reasons for existing. It's just that it isn't anymore the only way to handle data.