Game Development Community

GG - Please restore writing files directly to the game folder

by Conor O Kane · in Torque Game Builder · 06/07/2008 (12:24 am) · 21 replies

After TGB 1.5 the ability to write files directly to the game folder was removed, and all file writing now has to be done into the users application data folder.

Please restore the ability to write to the game folder. I can see no benefit in the restriction, but plenty of problems.

The main problem is that players cannot find the written files. The folder that files are now written to is...

C:\Users\Username\AppData\Roaming\Publishername\gamename\game\ on Windows Vista and

C:\Documents and Settings\Username\Application Data\Publishername\gamename\game\ On Windows XP.

The average user cannot find this folder. To add to the problem, this folder is hidden by default, and the average user does not know how to unhide hidden files and folders. The end result is that users cannot modify the game settings if they are stored in a text file.

With my TGB 1.5 games I could put in the readme file "If you want to change any of the game settings, just edit the settings.txt file in this folder".

I cannot do that any more and this greatly reduces the quality of the user experience.

I understand that the restriction is in place because if a player is playing on a non-administrator account they will not have write access to the game folder. This is not an issue however as almost all windows users are running in administrator mode. Those few who are not are probably using business computers not suitable for gaming.

My game Harpooned, which was written with TGB 1.5.2, and wrote files directly to the game folder, was downloaded by over fifteen thousand players and not one complained that the game didn't work. I think this shows it is perfectly acceptable to write to the game folder directly.
Page «Previous 1 2
#1
06/07/2008 (1:45 am)
I think this change was a must, to have the compatibility with VISTA. VISTA doesn't allow writing into the games folder by default (or at all) so I can understand that they needed a different method of doing things automatically.
#2
06/07/2008 (2:01 am)
Vista does allow writing to the game folder unless you are logged in as a user that does not have administrator rights. The default user created when you install Vista has administrator rights.
#3
06/07/2008 (2:40 am)
But moving forward with the big picture practice of not requiring administrative rights to run an application is the Right Thing to Do(tm).
#4
06/07/2008 (7:43 am)
I understand it's the right thing to do, and the default folder for the openForWrite function can stay the user folder. But I'd like the option to write into the game folder, so that players can find files.

The application would still run perfectly well without administrator rights. It just wouldn't save any settings files.

Besides, since you can't install a game without administrator rights, why would anyone try playing it that way?
#5
06/07/2008 (10:39 pm)
Because the security model for all OS's is to install as adminsitrator and run at a reduced priviledge level. This reduces the window of vulnerability for malicious code to be run. Most OS's now have a "run as" equivolent for installs, so that entire system isn't at administrative level for the duration that the install is taking place, further protecting the system.

Instead of wanting the system to run at an administrative level, why don't you provide a link to hard-to-find folder in order to allow them to find it easier?
#6
06/07/2008 (10:58 pm)
If the user can edit game settings in-game, there is no need for them to find/modify this ini file. If modifying the file is the only way to change settings, then just put the file in the project folder and load it from there. Assuming they can't change the settings in-game, there is no need to resave it.
#7
06/07/2008 (10:59 pm)
Brian: I do provide a link to the folder, in the readme.txt.
Firstly, most people don't read the readme.txt, and secondly, even those that do cannot find the folder unless they have specifically turned on hidden folders.

Basically, experienced computer users (like everyone on this forum) have no problem finding the user folder. But 99% of people are not experienced computer users and they either can't find the user folder, or quickly lose interest when presented with instructions and give up.

It's unfortunate that windows has made the user folders so hard to find. I want to make things easier for my players by putting the settings files in the game folder.


James: Mostly I do allow the game to change the settings and save directly to the settings file, however there may be some features that I do not want to be editable in-game, perhaps some cheats or easter eggs, but I'd like the player to be able to edit them. I need the game to both read from and write to the settings file, and I want the player to be able to find and edit it.

Also, as an indie developer I do not have a QA department, so I am reliant on feedback from other players on forums for my bug fixes. When a bug arises I often have to ask them to check the settings file to see if the error was saved there. They can't find it, so I have to direct them to the readme file where the instructions are. If they still can't find it I have to explain to them how to view hidden files. Then they complain "why did you put it there, it's so hard to find, you should put it in the game folder". So here I am, asking Garage Games to allow me to give my players what they want.
#8
06/07/2008 (11:11 pm)
You are arguing against yourself here... if, in your example, 99% of people can't find the folder, what makes you think they are skilled enough to be editing text files? Usability is the developers problem, not the users' and OS' problem.

1) provide the editability into the game instead of sending them to the test file, or;
2) at least provide a link/shortcut to the folder and/or file in the start menu with your installer.

Reducing Windows' simple security model isn't the answer to usability issues. There are already plenty of ways to provide the usability that you want without opening the system up back to Windows 95.
#9
06/07/2008 (11:37 pm)
1) - I already provide editability in the game. That's not the main problem. The problem is users can't find the settings file.
2) - That might work. I'm not sure how to do that (I use nullsoft's scriptable install system for packaging my games) but I will look into it.

Players (myself included) like having the settings file in the game folder.
#10
06/08/2008 (12:00 am)
This should be super easy to get working btw.

This code right here is where TGB allows the editor to write anywhere...

bool ResManager::isValidWriteFileName (const char *fn)
{
   if(isUsingVFS())
      return false;

#ifdef TORQUE_TOOLS
   return true;
#endif

So just change that function to instead return true always right at the top, and you can write anywhere.
#11
06/08/2008 (12:05 am)
Thanks James. I guess it's finally time to upgrade to the pro version.
#12
06/19/2008 (7:57 am)
Well, a correct way, is not to use appdata, but would be to use MyDocuments for game saves and config.
#13
06/19/2008 (5:45 pm)
That would certainly be easier for users to find.
#14
06/19/2008 (8:10 pm)
Conor,

diBALLic loads settings out of a settings.txt in the /game folder. The diBALLic source doesn't include any ability to write there though. However . . .

I've written to the levels folder in the actual game directory before with TGB 172. Unless IO has changed between 172 and 173, you should still be able do that using a somewhat sketchy method. The thread is around the forums somewhere, but its getting late -- drop me an email and I'll send you the source of the game that saved level files to the game directory.

No need to buy pro yet! [hopefully]
#15
06/20/2008 (8:42 am)
Probably the correct way for your game to share a highscores table between all users of a pc is to save it in allusers/appdata. It would make sense for TGB to support this.
#16
06/21/2008 (1:49 pm)
Did you ever get it working, Conor?
#17
06/25/2008 (1:22 pm)
Can someone explain James Ford's modification to the 'isValidWriteFileName'. I've tried several times to get it working with no success.
#18
06/25/2008 (2:34 pm)
Does it cause any other problems or just continue saving in appdata? What about if you type in the full explicit path?
#19
06/25/2008 (2:58 pm)
Should I change it too:

bool ResManager::isValidWriteFileName (const char *fn)
{   
     //always return true;
     return true;

     if(isUsingVFS())      
          return false;

#ifdef TORQUE_TOOLS   
     return true;
#endif

this is what I had, but the file would not save correctly.
#20
06/25/2008 (3:17 pm)
Thats the change I proposed, but its very likely not exactly what needs to be done. For example, even if that change allows you TGB to write to anywhere, that probably doesn't change the fact that "~/" and "./" map to the appdata folder.

Can you elaborate on "would not save correctly"? Are you getting errors when you try to save, is it still saving in appdata or just not at all? What happens when you try to save using an absolute path ( eg. C:/testfile.txt ).

Maybe I'll have a chance to look at this code again tonight. I haven't actually tried this change, I just tried my luck at tracking down how to do it. My throught process was I know the TorqueGameBuilder (tools) exe is able to save in the game path while the TGBGame exe is not, so find the difference, possibly marked by #ifdef TORQUE_TOOLS.
Page «Previous 1 2