well, everything in one directory does have some advantages during development. i can run the game straight from the release folder - don't have to install or update first. i can test install the demo to \program files(x86)\caveman3 without interfering with the version in the release folder - IE two completely separate installs with their own settings. also, everything in one folder makes it easy to find stuff - no chasing through folders to the right subfolder for some particular file type, etc. i can get away with it due to the relatively low number of assets in the game due to heavy reuse. example: all humans are implemented with just 10 skinned meshes and about 10 hair meshes.

but for end users, none of this "all in one folder" stuff is really necessary.

As irksome as jumping through those hoops are, you would probably be best jumping through them. The primary reason for this is that you ideally want to mimic how your users will be using the game as much as possible -- that means without elevated privileges (preferably, not sure if debugging makes this impossible) and with a filesystem layout that's identical to the final form. You'll find bugs that way that you're otherwise leaving your users to find, and when you do find one, you'll actually be able to trace through it on your own 'install' rather than trying to guess at it based on a bug report.

If you have regular, formal testing of your app through other mechanisms that do mimic an installed environment then you can lean on those, but I still think its a good idea for a serious project. You don't have to go through a whole uninstall/install every time (though, its worth mentioning that more games should more rigorously test their installer and especially their *uninstaller*) -- you can write a shell script to copy your game from its project build folder structure into its final structure and just call that script as a post-built step. (Using a script is a good idea anyways, since it makes the process repeatable and also serves as a kind of documentation that will be helpful when you do create the installer proper.)

As irksome as jumping through those hoops are, you would probably be best jumping through them. The primary reason for this is that you ideally want to mimic how your users will be using the game as much as possible -- that means without elevated privileges (preferably, not sure if debugging makes this impossible) and with a filesystem layout that's identical to the final form. You'll find bugs that way that you're otherwise leaving your users to find, and when you do find one, you'll actually be able to trace through it on your own 'install' rather than trying to guess at it based on a bug report.

yes - that's the right way to do it.

hmm... now i'll have to figure out the accounts and privileges on this computer. its windows 7 with a single account, which i would assume is admin running at user level with promote (i get the admin prompt to continue when doing admin level stuff). if that's the case, the way i'm using it right now should be fine for testing - right?

and i'll still have to figure out exactly which data files to put where. and then i have to figure out if Inno setup can do it. more work to do!