Is there a way to store settings per user in Unity3D game?
I'm looking for something similliar to user.config that can be found in .NET. It is created per computer user.
I need it to store some values (filtering parameters) that can be changed by user/player. It must be possible to save new values too.
If there is no such automagic way what is the best approach? I did consider:
Saving to text file.
Saving to binary file.
I think the PlayerPrefs class should fit your needs. It supports all platforms and provides the basic types like float, int and string including default values.
Under Untiy 3.x PlayerPrefs were reprted to be pretty slow on mobile devices - see the blog entry Writing PlayerPrefs, Fast. I used a modified version of it in several projects and it works fine except for Windows Store apps as they don't support all System.IO classes.
Regardless what solution you take, I would always suggest to encapsulate calls in your own facade class. Thus you can change the underlying implementation and add missing features like array support easily.
Related
I am creating an app that reads some info from a scale via RS232 serial port connection. There are a couple of types of scales that are in use, so I would like to store specific settings for the scale in my program. What is the best way to do this? Via app.config? Or should I put the values in a database?
It really depends on where will these configurations be used?
If you are working on a distributed huge system, which means these configurations are probably shared/used by other systems. You'd better store it in the database, with a common protocol which other related systems agree with.
On the other hand, if these configurations are used for a small application, storing them in a config file(or an xml file whatever you like) is suggested because, you don't need a gun in order to kill a mosquito.
app.config would be the easiest option for you. I think a database might be a bit overdoing it for just some settings, but if you wish to use something outside of what is offered by VS (namely app.config) then you could always whip up a quick custom XML settings file. All depends on what you wanna do with it and how comfortable you are with the other technology.
Is the information chaging ? that means when you ran ur app , would it be the case that information is updated ?
if the information is static and do not change frequetly , you can store in the app.config.
or in a xml file and you can read that information lately.
but if the information is dynamic then you need to create a model and expose scale information through model's peroperty.
Do not forget the registry.
Use the registry when:
You need your settings to be accessible for a domain admin
you need to secure some settings (using Windows security)
(You can make some settings read-only)
There are a lot of small settings that change very often
If it's simple and straightforward than app.config is the way to go - you don't need to set up a database and you get to use simple built-in interfaces.
If you choose to go with a database check out mysql for a simple file based database that has a simple deployment scheme.
I am writing a game in XNA. The first main goal is to have it complete and running on Windows but after that I will be purchasing the 360 kit and changing all the bits I need to change in order to make it into a working game on 360.
I am currently writing a level editor which i will be using to create the levels but also leaving in as a user feature. I was wondering what the best/most common/easiest way of saving out the data would be and where should I save it?
Level Format
As far as the format that you save the data in, this is up to you. If you can represent your level data as flat text, perhaps a series of lines and numbers, go for it. Many level editors represent level data using a custom class/struct or XML.
Preparing to save
If the data is flat text or XML then your job is easy, there isn't any prep-work to do. If the data is contained in a class/struct then you will need to first serialize the data before writing it out to storage.
Serialization basically makes it easy to persist the data in your class by converting your class to a format that is easy to write to storage (de-serialization goes the other direction).
Serialization is often done with the XMLSerializer class. For a simple example of this you might want to see the MSN example where they demonstrate how to save/load save game data.
Note: Some folks don't like serializing to XML because it exposes their data to prying eyes, for a level editor this is probably a non-issue and perhaps even desirable.
Saving the Data
The final consideration is the method used to save the data. On the PC, you can write data to any arbitrary location using standard .NET libraries, however this is not the case on the 360. If you've played many 360 games, you'll know that every game pops-up a dialog asking you which storage device to use. You will need to use the same classes & methods as other 360 games, namely the XNA StorageContainer class. Microsoft has some great examples here that should help you along.
As you plan on leaving your level editor in as a user feature, I would recommend that you use the XNA libraries (Guide.BeginShowStorageDeviceSelector, StorageContainer) to implement your saving/loading of level data for the PC and 360. This is just to avoid having to write separate save/load code for the PC and 360.
i would suggest using the Microsoft.Xna.Framework.Storage Namespace. The main benefit being that this direction would work when porting to the xbox360 with little to possibly no changes in the logic of saving the information.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What is the best way to store user settings for a .NET application?
I have found alot of VERY different examples as to how one would save application settings (per user) from a Winforms application.
I imagine that the correct way to do this is very simple in c# and am hoping someone can enlighten me?
At some point, the answer boils down to a matter of taste. I'd say you'll end up with at least these options:
store it in the registry, where you have the HKEY_CURRENT_USER key. Everything under it is user-specific. This is usually preferred when you want to store a bunch of small key-value pairs. The main advantage of this system is that your settings are easy to find and share throughout several different applications. To follow this path, you can start from here.
using .NET Application settings, provides the easiest way to access your settings at runtime. Again, it's better for using with key-value pairs of small-sized data. IMO, the main advantages of this method is its simplicity and the fact that it empowers you to use some .NET classes as values (not forcing you to convert everything into more basic types). To follow this path, you can start from here.
store it in User Data folders, which are usually hidden under the user's profile directory. This is preferred when you want to store a large amount of data or any number of files. The main advantage of this method is that you can manipulate your data as you would with any files (that may also be a disadvantage). To follow this path, you can start from here.
You can use the settings infrastructure provided by .NET. In your project's property pages, go to the Settings page, and define your settings. You can define the scope of each setting as "Application" or "User". A class will be automatically generated to access these settings from code.
To access settings Foo and Bar, use :
// Read settings
textBoxFoo.Text = Properties.Settings.Default.Foo;
// Write settings
Properties.Settings.Default.Bar = checkBoxBar.IsChecked;
// Save settings
Properties.Settings.Default.Save();
I would use Application Settings. It's pretty straightforward and will take care of some issues for you (such as not having write access to the folder where your app may be installed without administrative access, which rules out directly using app.config for your settings).
I am looking for ways to store data in a Windows Forms application in .NET.
I want to make the input data of a system persistent, so when I close my program and open it again, the data is retrieved.
Which ways of doing this exist besides creating a linked database?
Examples are gladly appreciated.
There are dozens of different ways to store data. It completely depends on what data. Is it:
Just a couple of configuration values? Use the built-in Settings library.
Machine-wide configuration? Use the registry.
Transactional? Use a relational database.
Related but not transactional? Use a lightweight database like SQLite or SQLCE.
Structured but not related? Use XML or JSON files.
Somewhat structured and high in volume? Use a NoSQL solution like MongoDB.
And so on... there are different solutions for every storage requirement and many projects make use of more than one at a time.
An easy way would be to make use of XML.
Using XML in C# in the simplest way
Read/Write Xml document with FileStream
If your data is not mission critical (e.g. user preferences), you could just serialise your objects to file, and de-serialise them next time the app is loaded.
Examples? Do your homework yourself :)
Anyhow, possible ways are:
Registry.
Files. Like Microsoft Word does. Or like an ini file, like most games do for example for their settings
Databaase
Which makes sense depends on what the application DOES and other scenarios around it. A fast answer is not really possible without knowing more.
I'm using Visual Studio (2005 and up). I am looking into trying out making an application where the user can change language for all menues, input formats and such. How would I go on doing this, as I suppose that there is some complete feature within .Net that can help me with this?
I need to take the following into account (and fill me in if I miss some obvious stuff)
Strings (menues, texts)
Input data (parsing floats, dates, etc..)
Should be easy to add support for another language
I'm not an expert with .NET by any means but Localization is never just as simple as "swapping out String values" or "changing date formats". There is much more to be taken into consideration such as layout, proper text placement.
Take Chinese for example. The way you read is top to bottom not left to right. If properly localized the app should take that into account.
http://msdn.microsoft.com/en-us/library/y99d1cd3(VS.80).aspx seems to be a good start though if you're dealing with Windows Forms.
The classic recipe is: design the app with no native language but a localization facility, and develop an initialization into one language (e.g., English). So you build the app and localize it into English every night; without the localization step it would not be usable. Do that well, and the resources for the initial sample localization can be replaced with those for any other language. Take into account non-roman scripts from the beginning. It's much cleaner to have a no-language app that always requires localization rather than a language-specific app that needs to have its native language subtracted and a replacement added.
For strings you should just separate your strings from your code (having an XML/DLL that will transform string IDs to real strings is one way to go). However you do need to make sure that you are supporting double byte characters for some languages (this is relevant if you use C/C++).
For input data what you want is to have different locale's. In Java this is relatively easy, and if you use C# it probably is quite easy also. In C/C++ I don't really know. The basic idea is that the input parsers should be different based on the locale selected at that time. So each field (textfield, textbox, etc.) must have an abstract parser that is then implemented by a different class depending on the locale (right to left, double byte, etc.).
Check the Java implementation for details on how they did it. It is quite functional.
You definitely need to be using the .NET ResourceManager and the resx file xml format, however there are a number of approaches to using this.
It really depends on what you are wanting to achieve. For me I wanted a single xml resource file (for each supported language) that could be modified by anyone. I created a helper class that loaded the global resource file into ResourceManager (once only) and I had a helper function that gives me the required resource for a given name. The only disadvantage in this approach was that I could not leverage dynamic binding of resources to properties.
I found this better and easier to manage than multiple or embedded resource files for every form. Additionally exactly the same approach can used in an ASP.NET application. I also found this approach means that outsourcing translation of resources and shipping language packs to customers much more manageable.
Microsoft's recommended approach is to use satellite assemblies, as described in Packaging and Deploying Resources. If you're using a ResourceManager to load resources, .NET will load the correct resources for the CurrentUICulture. This defaults to the user's current UI language setting in Windows.
It is possible to localize Windows Forms either through Visual Studio or an external tool, WinRes.exe. This article describes WinRes and how to use Visual Studio to localize the form.