Where to store levels so i can release new packs.

Member
Posts: 153
Joined: 2004.12
Post: #1
Each level i have is a separate FBX file. I want the user to be able to download and "install" (By dragging to a folder) new levels off of my site. Right now i just store them in the application bundle, but obviously most users cant access that.

Where should i store my levels so that its easy for a user to access, but still an appropriate location?

Would it be smarter to create a real installer, so that i can store the levels in something like ~user/library/... and not have to worry about instructing the user to drag the levels into the correct location?

There was a long silence...
'I claim them all,' said the Savage at last.
Quote this message in a reply
Apprentice
Posts: 19
Joined: 2005.06
Post: #2
keep 'em in ~/library/application support/<your application>/levels
(the path after <your application> is up to you, natch)

Just have it so when a user double clicks a .fbx file it launches your game and automatically moves it to that path. That's how adium handles its extentions and it seems to work very well for them.
Quote this message in a reply
Member
Posts: 153
Joined: 2004.12
Post: #3
Thanks, sounds like a good idea.

There was a long silence...
'I claim them all,' said the Savage at last.
Quote this message in a reply
MarkJ
Unregistered
 
Post: #4
yeah, but don't keep all levels there, just the expansion ones, otherwise you may run into problems when switching users.
Quote this message in a reply
Member
Posts: 39
Joined: 2002.04
Post: #5
frozendevil Wrote:keep 'em in ~/library/application support/<your application>/levels
(the path after <your application> is up to you, natch)

Our could stick with the true and tried approach of keeping everything in a single application folder i.e. you could have:

.../appdir/appliaction.app ("application" - application bundel)
.../appdir/levels (extra levels - standard levels could still be stored in the appliaction bundle)
.../appdir/README
.../appdir/manual.pdf
...

This has the advantage of making the "levels" folder slightly easier to find for users - so that you may not need an level installer. It also ensures that all levels (possibly large files) are removed when deleting the application directory - this may be either bad ("where did my levels go ?" - after reinstall) or good ("this stupid application stores files everywhere !" - when unistalling).
Quote this message in a reply
Member
Posts: 370
Joined: 2002.04
Post: #6
But if you do that you also possibly restrict installing new levels to administrative users. You could store it in /Users/Shared/Library/Application Support/YourName - that should be writable by anyone.

Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath the clear blue sky?
Quote this message in a reply
Member
Posts: 89
Joined: 2005.06
Post: #7
Isn't there a way to have them exist simply within the package contents of the application themselves? That's the thing I love about OS X and their applications, their pretty much all self contained.
Quote this message in a reply
Member
Posts: 370
Joined: 2002.04
Post: #8
Yes, they can sit there quite well. The only problem is that it is possible that only administrators can install new levels, depending on where the application is stored. This may be desirable, however, depending on how you want it to work.

Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath the clear blue sky?
Quote this message in a reply
Member
Posts: 39
Joined: 2002.04
Post: #9
Steven Wrote:Yes, they can sit there quite well. The only problem is that it is possible that only administrators can install new levels, depending on where the application is stored. This may be desirable, however, depending on how you want it to work.

That's right, I completely forgot about admin access limitations.

But if admin rights are the problem (access to the "Applications" folder and such I assume), a reasonably clever user (one that knows how to install apps), would probably figure out that apps can be installed locally in some personal folder, where he/she has read/write/execute access - thereby solving the admin access problem, although in a slightly inelegant but fairly user convenient way.

This solution or using "~user/library/..." (storage in user local dirs) both have the drawback of creating different user specific, sets of levels.

Using "/Users/Shared/Library/Application Support/AppName/..." may be a better way if all levels should be accessible by all users.

It's quit simple to support both approaches (if desired), so that user can have both private and shared levels, the only difference in the application would be that it would need to search several folders for level files ("~/...", "/Users/Shared/..." and the application bundle).
Quote this message in a reply
Member
Posts: 153
Joined: 2004.12
Post: #10
Sorry this is so late, but thanks everyone for the helpful input.

I think im going to go with : /Users/Shared/Library/Application Support/Phi/Levels

Is there any reason why i shouldn't store my normal levels in this folder as well?

There was a long silence...
'I claim them all,' said the Savage at last.
Quote this message in a reply
Member
Posts: 370
Joined: 2002.04
Post: #11
This may sound somewhat random - but just make sure that your levels don't have any executable content and you're at least fairly sure that there are no buffer overflows Wink

Nothing turns someone off from an application like a successful user-privilege escalation attack...

Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath the clear blue sky?
Quote this message in a reply
Member
Posts: 153
Joined: 2004.12
Post: #12
I really don't know what that means. My levels are just plain text .FBX files. Is there anything 'special' i need to worry about for "buffer overflows?" I have never even heard of them.

There was a long silence...
'I claim them all,' said the Savage at last.
Quote this message in a reply
Member
Posts: 277
Joined: 2004.10
Post: #13
If I remember correctly libcurl used to have this trouble.

(hackers and buffer stuff...)

I would be extremly careful!

Global warming is caused by hobos and mooses
Quote this message in a reply
Moderator
Posts: 385
Joined: 2002.08
Post: #14
Is there a source for more information on how a buffer overflow error works, what causes it and how it could be used by a hacker? Or, more specifically, what we can do to prevent that from happening? Rasp

KB Productions, Car Care for iPhone/iPod Touch
@karlbecker_com
All too often, art is simply the loss of practicality.
Quote this message in a reply
Member
Posts: 370
Joined: 2002.04
Post: #15
A buffer overflow happens when your program reads an unexpectedly large data structure in. Think it of trying to fit a 512 character string into a char[128]. There are only 128 bytes of memory allocated, so if you try to write any more you will write into an undefined area (at best crashing your application, medium-bad causing unexpected behavior, and at worst allowing random code execution)

Basically, make sure anything that reads user input into a fixed-size buffer has some sort of check to make sure you don't hit the end of it. (And if you're using C strings, leave space for the null!)

This probably isn't an issue if you use exclusively AppKit/Foundation, as I'm sure Apple has audited it fairly well...

Did you ever wonder why we had to run for shelter when the promise of a brave new world unfurled beneath the clear blue sky?
Quote this message in a reply
Post Reply