On the PC, I’ve always preferred to have NO ‘resource’ files copied from the resources directory into anywhere else each time I’d run the app/game. Up until Cocos2d-x 4.0, it was fairly straightforward to fix the issue each time just by backing out the changes from this commit: https://github.com/cocos2d/cocos2d-x/pull/10431/files, and then doing a few other tweaks here and there (remove the post build ‘copy’ event in VS, etc) to run the app or game using the resources right there where they already are in the resource directory.
What I am wondering is if somebody could point me to the relevant location for that - using Cocos2dx 4.0. I realize that all of that seems to be done using ‘CMake’ in this version - so I am finally biting the bullet and trying to learn how it works and how to use it. There seems to be a lot of CMake related files, and I’ve looked through them all and see spots that look related, but it is kind of daunting for a CMake noob. If somebody knew the exact file(s) that might deal with this one specific particular issue, it would be a great help as I get my feet wet learning CMake and how to use it with Cocos2d.
In short - I was wondering where in the CMake files I need to go to remove all the ‘file copying’ that goes on after compiling. (On PC only, I understand that the iOs and Android versions need to be ‘packaged’ into an IPA or APK to install it to a device.) After doing some looking around - it seems the ‘sync_folder.py’ and maybe CocosBuildHelpers.cmake and cocosBuildSet.cmake would be the files I would need to alter to stop all the file copying that happens on the PC version. Unfortunately I am not familiar with either Python coding, or Cmake yet, so this isnt as easy as perhaps it should/could be if I knew Python and Cmake better.
To R101,
To be honest - I have always wondered the exact opposite (ever since that commit (Feb 25, 2015) that I mentioned above)… why would anybody want to copy resource files from one spot to another for basically no reason, every single time one compiles the app/game to run it?
My desire to not copy files needlessly began with that commit, when all of a sudden every time I compiled I had 2 Gb of textures and game data that had to get copied from one spot to another every time I wanted to compile. And for no reason - this copying didnt occur before that commit and everything ran great with zero issues. As soon as this commit and all the resource copying started, I just began to have issues everywhere with resources. For example, I would save a file, and it wouldnt always be obvious WHERE the saved file was, in the ‘real’ resources folder with the rest of my game resources, or in this ‘new’ copied area of resources that MSVC just generated. If I wanted to access this newly saved file, it was giving me unnecessary headaches, I needed to do wierd things like copy the newly saved file over to the newly generated ‘working’ resources file.
In short - even on smaller projects that dont have 2gb of resources, it just doesnt make sense to me why this step of copying the resources folders from where they are to some new spot is necessary (and in fact, it wasnt until that commit in 2015)…and for me, not only does it seem very unnecessary - it actually complicates things in several ways.
The app executable and related libraries are built into a separate build folder, and the default Resources folder should be a sub-folder of that build folder. If you’re trying to access resources from outside that relative path (since you implied that you access resources from your development folder), wouldn’t you consider that to be a really bad idea, because it doesn’t reflect the file structure of the final installation on the user’s device?
Also, when you mentioned saving a file, if you mean through your app, then it should not ever go into the Resources folder, since on the user’s device that would be (and should be) read only, for instance if it’s in an APK on Android or if it’s in C:\Program Files\YourApp\ for a Windows release. Save files should only ever go into the writable path, which is provided to you by the OS.
There is an alternative solution which would not require you to have to copy any resources, and not even have to modify the game engine etc. You can have your resources in any path you want, just as long as you add that path to the search list via FileUtils::addSearchPath(), and cocos2d-x will attempt to load resources from that path.
Perhaps its time I could look into the ‘new’ way of doing it again. (New as of Feb 25, 2015 that is). I just know that all caused nothing but headaches for us, and simply undoing that commit each time I start a new project wasnt all that big of a deal. And it still isnt, after toying with it for awhile now, I have v4.0 more or less working in the same way too, it just seams hacky because I have no idea what I’m doing in python and cmake files. I’m sure if I learn more about those, then there would be a better, more ‘correct’ way to get it to work.
and the default Resources folder should be a sub-folder of that build folder.
I guess this is where I disagree. My opinion is that the default resources folder should actually BE the default resources folder. “C:\NewGame\Resources”, or “E:\HalfLife3\Resources”, or whatever it is for your particular game or app. Having multiple versions of the resource folder just overly complicates things in multiple ways while also adding extra delays at compile time. And for no benefit (imho). And it always worked that way (not copying the resource files), for years and years, up until that commit… so I guess I just prefer to keep doing it the way it was done prior to that commit. It just makes no sense to me to do it otherwise.
Again, keep in mind, I am 100% only talking PC here, where 95% of all my development and debugging takes place, even for iOs and Android apps. When its time to compile it and run it on an iOs and/or Android device, then obviously I realize there is the need to ‘package up’ all the resources into a file (ipa or apk) to run it on the device. At this time I simply change the ‘save’ directory from “F:\HalfLife3\Resources\save” (or whatever the game is called and whatever drive its on) to whatever the OS’s save directory is on the particular device and everything works fine.
I am strictly 100% talking about only the PC here, where there is no need whatsoever to copy or move the resources folder (or its contents) around…and which is how it was done for many years until that change/commit occurred around version 3.12 or so.
Pre-Windows 7, it was the norm to save files in the installation folder of the application, but with Windows 7+, that is certainly not the case. If users want to install their application in a relatively secure area (like C:\Program Files), then they should be allowed to do so, without risk of those files being modified in any way. The only way an app is allowed to save data in such a location is if it has elevated privileges, and it would be an extremely bad idea to force the user to run the game in admin mode just so files could be written inside the installation path.
Even if a user chooses to install the application in any other location, like C:\MyGame\, that’s fine, but still, give them the option to set where they want to save the files. If I recall correctly, the recommended place to store files (like save games) is to MyDocuments or to the %LocalAppData% path, like C:\Users\[username]\MyGame\.
Where the game saves data doesnt have all that much to do with the original point of my post, though… it was mainly about unnecessarily copying resource files from the actual resource folder to some new intermediate folder at compile time, on PC.
That being said though - I agree, if your game will also be released on the PC, the best bet is to let the user choose where they want to save. Short of that though, in the past when I’ve just chosen to have my save file right in the resources folder with all the other game data, and it never caused an issue with people having to get permission. I’ve always preferred games I use to keep themselves self-contained, I dont want my games and apps I use touching my C drive at all, much less mucking around in MyDocuments or in my user’s directory. It honestly shouldnt even matter, just as on a mobile device, where the data is getting saved to, as far as the user is concerned…so I’d rather have it all together nicely.
I believe what you are saying about admin mode is or could be true, and would definitely look into it more next time I release something on PC… but back in 2016 during our last release that was also on PC (DRM free as well as Steam and a console, Cocos2dx v2.2.6), we had zero problems at all that I’m aware of with anybody having to run in admin mode. Lately I’ve stuck to mostly iOs and Android releases (though I still do 95% of the dev on the PC, and like to keep the PC version working and up to date for various reasons).
But again - I just think thats a personal preference - I prefer my games all to be self-contained in 1 directory wherever I want to store it, and not strewn all over the place … other people def might prefer to have all their savegames for every game all in the \MyDocuments folder… there are probably many differing opinions, I get that… and the only way around that would be to let them chose then.
But again - the main point/question of this post isn’t about where to save, it was about the unnecessary (imho) copying of the actual resource folder contents on PC at compile/debug time on PC.
I’m sure if I learn more about those, then there would be a better, more ‘correct’ way to get it to work.
… other people def might prefer to have all their savegames for every game all in the \MyDocuments folder… there are probably many differing opinions, I get that… and the only way around that would be to let them chose then.