Yes PlayerPrefs saves it to local machine almost just like your .txt would have been. Your original post makes not much sense what are you trying as ratings sound more like server data and not local.
If you want users to give ratings and store them in one place you need a webhost with a database access and create a webservice to handle the data between webplayer and database. You use the webservice with the WWW class.
Sorry, I clearly didn’t ask my question very well.
What I am trying to achieve is:
The player (anywhere in the world) runs my webapp (from a simple wordpress.com page)
The webapp will pull in the parameters for their game from a .txt file stored on the server.
They are asked to rate what they see on a scale of 0 - 5
This rating is then saved into a directory on the same server as before.
Hopefully this now makes more sense?
So like you said Ostwind, would I still need a web host with database access?
// now you have your file’s text, you can do whatever you want with it.
string textFileContents = fileWWW.text;
}
Saving the rating can definitely be done without a database, but it would be far less handy to work with.
If you have a php-server, you can check this tutorial on writing files:
Then you can use WWWForm, or maybe even simpler with a GET-approach (if it’s just a rating). If you’re using the GET-approach you can do a WWW with a URL-argument.
Related question - can you build some kind of application on your desktop that could hook into the web app to save data locally? If you’re making a voxel game and saving the chunks, playerprefs seems like a bad way to do that. A database might work, but that would either be huge values or too many rows per player.
Of course for something like that I’d probably just deploy to desktop, but webgl could be more attractive and get more views online.
Darn, that’s what I was curious about. Any chance the desktop app could read playerprefs? Like…
playerprefs var 1 - outgoing data stored here, begins writing and sets var 2 to value ‘1’ when it is read as ‘2’
playerprefs var 2 - set to 1 when writing, is set to 2 by a desktop program to tell the program to continue writing to var 1
I think that with a good serializing algorithm you could store the voxels online. The voxel-information-map will be almost like an image, and images are fine to store in loads right? Ok you will have a 3rd dimension, but on the other hand you wont need as many bits for each voxel as an image needs. Remember, you can still run all kinds of packign algorithms if you need to lower the size.
That would be possible technically, but it would require your users to start a desktop app while running your webapp. Might as well make the whole game a desktop app then?
I probably would if I needed local file access, but I find it interesting that it’s possible. Thank you.
It would be odd to run a desktop app alongside the webapp, but you might get away with it if the desktop app was some kind of offline companion app with minigames to affect the saved files
Haha yea, I’ve seen that a few times now. If you’re going for a minecraft sort of thing, you’d need to store 4 little numbers per block
x y z id
I’m sure there’s ways to store large sections of land as algorithms, as horp1 may have been suggesting (dunno, I’m kinda dumb), but you still need individual block data if the player is modifying things voxel by voxel.
A local application? I doubt it. What I’ve done in the past is write a web service that allows the Unity app to send the client PC downloads via the web page it’s embedded in. So, the Unity app sends data to the server, the server checks that it’s not junk, formats it appropriately and offers it to the client browser as a file download.
Edit: Actually, since you can make stuff like text editors in JavaScript (the web kind, not the Unity kind) and they can save local files, and Unity WebPlayers can call JS scripts in their containing page, is there anything to stop you from writing a JavaScript that lets a Unity WebPlayer application write stuff out via that?
@angrypenguin@Tomnnn
The both of you really piqued my interest in just what was possible with passing data back and forth between the client machine and the WebPlayer/WebGL. I ended up taking the idea and running a little ways with it, you can observe the fruits of my efforts below.
There is no verification in place, as this was a simple experiment, but the upload form requires a text file to be parsed - with the basis already in place support for JSON or SQLite data is fairly trivial to add. Secondly, most browsers will load the data back from the application as a new webpage instead of downloading it automatically. This is a fairly simple fix, but ultimately this was only a proof of concept.
If either of you have any questions, please feel free to ask!
@lorenalexm haha, it worked! Wasn’t hard to figure out how to use either, nice job for a proof of concept version 1.0!
Bravo I’m glad this is doable instead of my silly idea lol.
–edit
Hmm… is it possible to make the javascript part of the page function within the unity code? I’m just wondering if a web portal would be willing to let you place & run your own JS code outside of the unity app. Could my dumb idea still have merit?
@Tomnnn I haven’t had a chance to look into anything regarding the second part of your message as of yet. But as far as I understand the player is essentially sandboxes, and I believe it would be very difficult if not impossible to get it to function without some sort of control over the actual page the player is sitting in. To echo what you said, I doubt many portals would be willing to provide you access to modify the actual page your player was sitting on unless you were providing significant revenue to them.
That being said, it wouldn’t be difficult to write a web application that you run on your server which communicates with the player and facilitates the writing and reading from either a database or actual JSON files. You’d loose the ability to have the user upload and download the files such as in my proof of concept, but everything would be kept on your server and could then work seamlessly between mobile, desktop and even a Webplayer/WebGL using a few simple API calls.