Asynchronous MySQL++ for T3D ?

#1 It appears to be ported.

#2 If you don't need a central mysql server you might check out the mysqlite resource.

#3 I used this: http://www.torquepowered.com/community/resource/view/9656

#4 I've created a piece to integrate MSSQL, MySQL, Oracle, Postgresql, etc with TorqueScript and C++ that works great.

We even considered selling it as a addon to Torque3D. It works great in our mmo project.

#5 Your MMO client talks directly to the database server?

#6 Isn't it a bit dangerous to have an application make direct queries to a remote database like that? Anyone willing to create a cheat program would be able to gain total access to the database once they figure out how the game connects to it or inject their own code in it. They could then modify, create and delete any information on the database.

AFAIK the recommended practices are to have a server-side application talk to the database, and the clients talk to that application. That application can then validate the transaction requests made form the clients, ideally via very high level abstractions as to prevent cheating.

REALLY BAD MMO EXAMPLE:

Quote:Alice wants to buy an item from a shop. The game client checks which store Alice is in and queries the database for the available items and their prices and presents them on a GUI. When Alice selects an item, the game client checks if Alice has enough money to buy the item, and if so tells the database to add that item to Alice's inventory and withdraw the money from her funds.

In the above example, there are several ways one could hack the game it isn't funny. A modified client could send a database query for any store in the game, regardless of Alice being physically inside it, skip the funds check and add the item to Alice's inventory without withdrawing funds. Also, if the store items are listed by their item type IDs, Alice could add whatever item to her inventory at any time just by knowing their IDs.

REASONABLY SAFE MMO EXAMPLE:

Quote:Alice wants to buy an item from a shop. The game client requests the list of items from the server. The server checks Alice's current location (which is stored in a fast volatile database) to see which shop she's in (if at all). The server then queries the database for the items in that store, and sends them to the client which then displays them in a GUI. When Alice selects an item form the GUI, the client sends the server a command telling the index of the item in the shop she wants to buy (not a global item ID). The server will then check which item that is and its price, verify if Alice has enough funds to buy it and if so, it will add the Item to Alice's inventory and send a message back to the client telling it that the purchase was successful.

In the example above there's little room for hacking. Alice cannot shop outside from a store: the server knows where each player is. Alice can also not shop items that are not in the shops's list, neither skip the funds check. And finally she cannot add items directly to her inventory, since she has to go through the shopping sequence first.

#7 I remember going over this in school right before summer(MMO Design was my last class *Saddness*), but I suppose if he was just testing it's not a bad way to take a layer out of the process, or would this create more problem along the way trying to add it back in later on?