I have to write some tools for our current project, and I’m looking at the different programs I could write those in.
maxscript
unity
director
What would be great for our situation is if we could have these tools be webbased, so it’s easy for us to make sure all leveldesign dudes are working with an up to date tool.
However, these tools need to read and write files on the local harddrive. I’m wondering if there is a way that the unity webplayer can actually allow that, when given permission by the user. I basically want my web app to have full desktop-app capabilities, as long as the user says that that is fine.
Does anybody know if that’s something I can make Unity do?
In director I could write a custom xtra that lets me do whatever I want. I’m hoping there is a similar construct for the unity webplayer.
Unfortunately, there’s no good and consistent way of accessing the local hard drive via anything that’s web based that I know of (outside of making your own browser plugin that talks to unity, or making some local app that reads unity’s player prefs).
However, the thought of having design tools on the web is very appealing. In Jetpack Brontosaurus we actually had all of our mission information put into the game via the browser. Our browser tools saved information in the JB database, which was in turn pulled down by unity during the game’s run-time. This is handy in a couple ways, one is that we got to have a unified and always up to date system for editing mission information, plus we could edit the information at anytime after the game was deployed without making another unity build.
I’m sure this could be expanded on. It makes sense to be able to save a slew of transforms made by the level designers in the unity player that the unity editor can pull down and populate the scene with.
Having the webbased editor read and write stuff from a db instead of the local drive is defenitely an alternative.
I like the local drive, because then people wouldn’t have to “commit” in order to save their work. they could just try out some changes locally, and throw them away if it doesn’t work. The db solution would then also start to require versioning of items etc.
Making tools for unity with unity is actually one of the few things that director is better at, since it has its import process available at runtime.
I guess when worst comes to worst I can just stuff a “shockwave file access” movie in the same page, and have the unity tool talk to the shockwave tool, which in turn deals with the actual file system access.
The web player’s only option for saving data outside of itself is to send via WWW or relay via browser-side JavaScript (to JS on your page, or to a Flash object, etc). You can relay a surprising amount of data–there was an open mic session at Unite demoing a Flash-based image uploader tool that immediately relays the bits to Unity for 3D preview.
We’ve done some tools in Unity. Our Splume level editor was a separate Unity project that simply serialized all positions to a text file. We used this editor for the levels we shipped, but we also exposed it to users. We used it locally and saved out a .txt file; the user-side stuff just saves to a database. We have a “published” flag so users can fiddle with stuff before deciding to share it with others.
If you want to force people to commit assets inside of a Unity project (.txt files you get at with TextAsset, for instance), you could easily use a database as an intermediate step. When the user is satisfied, you could send them to a URL that simply spits out the txt file. Although, it isn’t that difficult to do versioning if you wanted to make the web database authoritative rather than temporary storage.
As Shawn mentioned, we store all of our Jetpack Brontosaurus mission info on the web. This introduced a few problems on deployment, though. For example, we can’t produce a standalone build that runs without an internet connection, ie for demo requests at expos. We could work around this with some engineering, but I’m not sure we’d take the same route in the future. We would probably do something like I described above–require a step that produces a .txt file which then needs to be moved into the build (at least for deployment).
