Multiarch pnds?

[dimag0g]

Well, x86 PND could download Pandora PND, or even populate the appdata folder with the right files... yes.

 

[mcobit]

The idea is to share gamefiles with different executables in one pnd so you can put the card in whatever system and run it with the same datafiles and saves.

 

[dimag0g]

I get the idea (about sharing gamedata and savegames) and I find it quite useful, I just don't understand why it has to be the One File. What's wrong with creating a portable windows/linux/whatnot app which is aware of /pandora/appdata folder and which is easy to install (basically, "unzip and run", or even "install zip_run.sh and then just click on the zip file" if that seems simpler)?

 

[slaeshjag]

Why does the data files have to be separate? It's not like a game is usable without them...

 

[_wb_]

The appdata folder is not meant for game data files (except maybe if the data is proprietary and cannot be freely distributed, or something like that). It is meant for savefiles, config files and user data (e.g. user-created levels). It's for the stuff that would normally go in /home, not for the stuff that would be in /usr/share.

The effect of removing the appdata folder should be to reset the game to "factory settings", not to delete it.

 

[dimag0g]

Why does the data files have to be separate? It's not like a game is usable without them...

Because of "Hi, I just corrected a typo in runscript, please reload 100 MB package". Data files almost never change. Executables do.

 

[_wb_]

Why does the data files have to be separate? It's not like a game is usable without them...

Because of "Hi, I just corrected a typo in runscript, please reload 100 MB package". Data files almost never change. Executables do.

What about "Hi, I just tweaked one background image, please reload 100 MB data package"?

Delta updates are the solution. Splitting packages up in arbitrary ways is a poor approximation of delta updates, with undesirable side-effects: packages no longer being self-contained, having to ensure that the data package is compatible with the executable package (data formats can change over time), etc.

 

[dimag0g]

The effect of removing the appdata folder should be to reset the game to "factory settings", not to delete it.

Ok, then yes, you need multiarch PNDs here, unless a little dialog "Please wait while data files are downloaded. This will only happen once" could be considered factory settings =)

I don't mean to discourage anymore, but I fear there will be much work for little gain. PNDs are cool in a system over which you have total control, but that will not be the case with other targets. What would you do if a certain libfuckmybrain.so is present on the Pandora but not in x86 linux? create a dependency to a .deb file? That will limit you to Debian then. Will multiarch PNDs support Windows? I don't even mention the possibility to run such games without Administrator password. What will you do if game ports to different platforms share data files, but savegames are not compatible?

I really like the idea of exposing raw data files. It's not as user-friendly, there are issues with not-self-contained packages and side effects, but it's flexible.

 

[sswam]

We can do delta updates. Rsync update works well on compressed pnd files, believe it or not.

We could also do it by mount/rsync/mksquashfs.

Multi-arch is a nice idea, but I think it's unlikely that many developers would bother with it.

It's hard enough to create a working PND as it is!

 

[slaeshjag]

IF Cloudef's project with recipe based building turns out well, mutli-arch could be as easy as fat binaries was on the Mac when apple transistioned PPC->Intel. Just tick a box.

 

[bzar]

^ Well, as you can pretty much take a PKGBUILD from arch's repository, fix the dependency package names (to ångström or wherever) and give it to makepnd, I don't see why it wouldn't work . I did this with SCons a while back, see PNDBUILD vs PKGBUILD. Of course since makepnd is pretty much makepkg with pacman stuff swapped out, it's not very surprising