I’m working on an archaeological environment project and I’d like to combine an FPS (without the S, of course) realtime walkthrough with the ability to click on objects in the environment which act as queries for a database storing information about each of those objects.
Is there a way to get Unity to query or, at least, connect, to an external database?
Your best bet out of the box, especially for a web player, is to talk to a web page (PHP or other server-side technology), which in turn talks to a database.
Unity is built on top of Mono (the open source .Net equivalent). Mono has a huge class library, including Mono.Data.dll.
Here is some information from the Mono Project website…
http://www.mono-project.com/SQL_Lite
Another option, would be to put your data in an XML file. Redirecting…
If I go the PHP route, is there a way to make the interaction with the database through a webpage invisible to the Unity user - so all they do is either click on an object in-game and it’s database record appears (without the intermediate webpage showing up) or they can write a query straight in the game, which is then passed to the webpage which is then passed to the database?
If I go the XML route, again, is this invisible to the user? How does Unity use XML?
Thanks again.
– Anthony
I may be misunderstanding but I assume so, yes. Isn’t my high score which appear in a Unity game (standalone or web-based) that are being pulled straight out of a database using php and displayed in the Unity game without delay exactly the same thing?
The Unity web player communicates with the web DB server directly. Basically, the player sends a page request (as if it were a mini browser-within-a-browser) and the page data gets returned to your code. The browser doesn’t need to reload the page or anything like that.
There isn’t an “XML route” as such. XML is just one of the many possible data formats that the PHP script could send back to your code. Unity has classes available that can read XML (and they are actually pretty good) but there is no particular reason to use XML unless you like it or need its features. You could just as easily send comma-separated text back from the server and parse it with your own code.
Also, you might want to consider using Ruby/Rails instead of PHP, especially if your database is fairly sophisticated.
unfortunately, the xml libraries are quite large(around 1mb in the web player).
Doing your own parsing shouldn’t be too bad, commas or other symbols in case you need commas.
Typically we have some server side functions, and Unity calls a function on the server, which then returns values from the database. (this can also shield your database from too many calls)
Calling functions on the page sometimes has yielded strange results, and generally you can just call the server directly.
It will be completely invisible to the user, they will click, and text will appear on screen (or whatever).
Hm… This actually sounds like a typical use case for a Webservice. Unfortunately, when parsing XML is an issue in the Webplayer, that would obviously also apply to the use of a Webservice, maybe even more severely…
Isn’t the complete Mono-API (2.0) included in the Webplayer? If not - which parts would be missing? In the feature list of Unity 2.0, it says “Support for .NET 2.0 including generics!”
If the complete Mono-API is included in the Web-player (which I think it probably is), you can simply use the classes available in the System.Xml namespace (and subnamespaces). They wouldn’t need to be included in your game but available through the Web player plugin installation. Coming from a C#/.NET background, I’m not sure about using Mono-namespaces in JavaScript, though…
Sunny regards,
Jashan
I think you have to–
import system.xml //or whatever the library is called, i forget.
or something like that–I believe you determine what libraries you import, they aren’t standard–that would make the webplayer rather large I think.
The XML library alone is rather large, that was the only issue we had doing it that way. If size isn’t a concern, it’s not an issue, but you can swell your web game pretty quickly importing too many libraries.
We did everything via the www class. This is all the unity code we needed. serverFunction.do would handle all the database access on the server side. It works wonders, and keeps Unity clean.
This assumes you want to get a description for an item you picked up. serverFunction.do performs the query of itemID, and returns the string.
var basePath = "http://www.myhost.com";
var temp = "item5";
var url = basePath + "serverFunction.do"+"?itemId=" + temp;
var www : WWW = new WWW(url);
yield www;
var file : string = [url]www.data;[/url]
It isn’t. If you use something like XML, which isn’t included in the web player download, the DLLs are packed into your web content. This can significantly increase your game’s size, depending on what you’re using.
Whoa, thanks… even if I don’t like that, it’s really good to know… and obviously understandable (I remember a discussion I had I think with Nicholas about exactly this issue a long time ago).
Is there documentation on that anywhere, or would one have to go by trial and error (i.e. import a library, see how it changes the size of the Web player)? If there’s no documentation on that, yet - is this planned to be documented (as I understand it, the UT-Gods are currently really busy with documenting things)?
Or is it simply: If you use ANY of the .NET namespaces, you’ll increase the size of the Web version? In MS .NET, I know that the various namespaces are packaged rather “irregular”, i.e. not totally obvious. For instance, some parts of the System.Configuration namespaces are included in the default DLL, others are only available if you reference System.Configuration.DLL
Web player installer ships with mscorlib assembly (which includes most of the common stuff, e.g. System.Collections and so on). Some things live in System, or System.Xml assemblies and so on; if you use them they are included in your web player data file. .NET class documentation on MSDN says which assembly each class is in.
Hi Aras,
cool, thanks! That clears it up! A VERY cool feature for the Web player would be if it could manage Mono / .NET DLLs. Um… I’ll post that to the Wishlist-forum…
Jashan