Thread: Re: XML was RE: [GD-General] RE: A portable preferences library (Page 3)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Jorrit T. <Jor...@uz...> - 2003-12-16 12:14:47
|
Alen Ladavac wrote: >>We use XML a lot in Crystal Space (http://crystal.sf.net). It does tend >>to give very >>big files but we also found that it doesn't matter. >> >> > >Just how big that is? Can you please compare size of a mesh in XML format to >the same mesh in, say, .3ds or .lwo? > > I didn't make the map files so I don't have any of the model files that were used but I can show you an example of a simple mesh in CS: <meshobj name="cube"> <plugin>thing</plugin> <params> <v x="-1" y="0" z="1" /> <v x="0" y="0" z="1" /> ... (more vertices follow) <material>brick</material> <p> <v>0</v> <v>1</v> <v>2</v> </p> <p> <v>3</v> <v>2</v> <v>4</v> <v>5</v> </p> ... (more polygons follow) </params> </meshobj> So this is indeed pretty verbose. > > >>CS supports reading >>from ZIP files >>so map files are usually placed in compressed archives. XML compresses very >>well (due to the high redundancy) so the size disadvantage nearly completely >>disappears in that case. >> >> > >Can you also please compare size of a zipped XML mesh and a zipped .3ds, or >.lwo or similar format of the same mesh? > > Sorry. Don't have the needed models to do that. >Also, in case that zipping really does remove the redundancy well enough to >allow us to ignore the size difference, did you check your effective loading >throughput? Meaning how much MB/sec can you read from the disk. To make sure >that the parser is not slowing your loading. Ideally, you should be limited by >the transfer rate of the disk, not by the CPU. > > The PlaneShift game (made with CS) has about 25 megabytes (uncompressed) of XML files (aggregated in four big files) of level data. On my Linux system at home (an Athlon XP2000) the levels load in about 16-20 seconds. That includes the following operations: - Extracting the XML data from the ZIP. - Parsing of XML. - Creation of all objects. - Loading of all textures used in the levels and preparing them for use with OpenGL. - Creation of the kdtree for the visibility culler. - Loading of the lightmap data for the 100000 polygons that are in those levels. - Creation of oriented bounding boxes for collision detection (this is the most time consuming operation of all things mentioned here). I don't have seperate numbers for XML parsing but it is a relatively small part of the entire thing. Of course this is done using a hand-made XML parser which is very lean and mean and is optimized specifically towards reading. Greetings, |
|
From: Alen L. <ale...@cr...> - 2003-12-16 14:37:35
|
> The PlaneShift game (made with CS) has about 25 megabytes (uncompressed) > of XML files (aggregated > in four big files) of level data. On my Linux system at home (an Athlon > XP2000) the levels load > in about 16-20 seconds. There is a mistake in your reasoning, isn't it? You say that we shouldn't look at the size of the uncompressed XML data. Then you start profiling how many uncompressed MB/s can you load. You should look at the number of compressed MB/s. If running from harddisk, you should be loading between 5-20MB/s (depending on speed of the drive). Anything less than 5MB, and you are very CPU limited. And you should _never_ be CPU limited while loading. Not even close. If you are CPU limited on a 2GHz CPU, think about all the poor 700MHz Celeron users trying to load your game. There is no excuse for loading data at less speed than the media can stream. Think about whether your users like to wait 20 seconds to load a level. If it could be loaded in 5, or even less... Can you get some more accurate profile? Alen |
|
From: Jorrit T. <Jor...@uz...> - 2003-12-16 14:50:50
|
Alen Ladavac wrote: >>The PlaneShift game (made with CS) has about 25 megabytes (uncompressed) >>of XML files (aggregated >>in four big files) of level data. On my Linux system at home (an Athlon >>XP2000) the levels load >>in about 16-20 seconds. >> >> > >There is a mistake in your reasoning, isn't it? You say that we shouldn't look >at the size of the uncompressed XML data. Then you start profiling how many >uncompressed MB/s can you load. > Well the engine IS loading uncompressed MB's. The decompression happens by another part of the loader so when I'm talking about load time performance I'm talking about the time to parse the UNCOMPRESSED file. >You should look at the number of compressed >MB/s. If running from harddisk, you should be loading between 5-20MB/s >(depending on speed of the drive). Anything less than 5MB, and you are very >CPU limited. And you should _never_ be CPU limited while loading. Not even >close. If you are CPU limited on a 2GHz CPU, think about all the poor 700MHz >Celeron users trying to load your game. There is no excuse for loading data at >less speed than the media can stream. > Yes they are. You have to process the data. You have to send textures to the hardware (which is something that you cannot do in load time). Note that binary dump of a structure is not possible in our situation since Crystal Space is portable and has to run on various operating systems and CPU architectures. So we cannot depend on binary data being compatible. That means there is always SOME processing. Greetings, > Think about whether your users like to >wait 20 seconds to load a level. If it could be loaded in 5, or even less... > >Can you get some more accurate profile? > >Alen > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >Does SourceForge.net help you be more productive? Does it >help you create better code? SHARE THE LOVE, and help us help >YOU! Click Here: http://sourceforge.net/donate/ >_______________________________________________ >Gamedevlists-general mailing list >Gam...@li... >https://lists.sourceforge.net/lists/listinfo/gamedevlists-general >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=557 > > > > |
|
From: Alen L. <ale...@cr...> - 2003-12-16 17:53:57
|
> Well the engine IS loading uncompressed MB's. The decompression happens > by another part > of the loader so when I'm talking about load time performance I'm > talking about the time to parse > the UNCOMPRESSED file. Please try to understand that I am not trying to bash you. I would like to know the numbers. Those 16-20 seconds you gave is not a useable number, because it is mixed with other preprocessing. And because unzipped file size for XML is not very meaningless. Hm. How can I explain this better? It doesn't matter how fast does it load in terms of MB/s of some format that you use. What matters is how much useable data per second can you load. Since we don't have any defined units for "useable data", we can only compare that with some binary format. If you say that XML size increase is neutralized by zipping, I would assume that you mean that a zipped XML file would be of about same size as zipped binary file with that same data in it. Now, the best way to judge the speed of XML parser would then be to see how much _zipped_ MB/s can it load. If it is much below HDD speed, then you cannot say that its costs are negligible. Is that a more understandable explanation? And can you please give us that info? Thanks, Alen ----- Original Message ----- From: "Jorrit Tyberghein" <Jor...@uz...> To: <gam...@li...> Sent: Tuesday, December 16, 2003 14:50 Subject: Re: XML was RE: [GD-General] RE: A portable preferences library > Alen Ladavac wrote: > > >>The PlaneShift game (made with CS) has about 25 megabytes (uncompressed) > >>of XML files (aggregated > >>in four big files) of level data. On my Linux system at home (an Athlon > >>XP2000) the levels load > >>in about 16-20 seconds. > >> > >> > > > >There is a mistake in your reasoning, isn't it? You say that we shouldn't look > >at the size of the uncompressed XML data. Then you start profiling how many > >uncompressed MB/s can you load. > > > Well the engine IS loading uncompressed MB's. The decompression happens > by another part > of the loader so when I'm talking about load time performance I'm > talking about the time to parse > the UNCOMPRESSED file. > > >You should look at the number of compressed > >MB/s. If running from harddisk, you should be loading between 5-20MB/s > >(depending on speed of the drive). Anything less than 5MB, and you are very > >CPU limited. And you should _never_ be CPU limited while loading. Not even > >close. If you are CPU limited on a 2GHz CPU, think about all the poor 700MHz > >Celeron users trying to load your game. There is no excuse for loading data at > >less speed than the media can stream. > > > Yes they are. You have to process the data. You have to send textures to > the hardware (which is > something that you cannot do in load time). Note that binary dump of a > structure is not possible > in our situation since Crystal Space is portable and has to run on > various operating systems and > CPU architectures. So we cannot depend on binary data being compatible. > That means there is > always SOME processing. > > Greetings, > > > Think about whether your users like to > >wait 20 seconds to load a level. If it could be loaded in 5, or even less... > > > >Can you get some more accurate profile? > > > >Alen > > > > > > > >------------------------------------------------------- > >This SF.net email is sponsored by: SF.net Giveback Program. > >Does SourceForge.net help you be more productive? Does it > >help you create better code? SHARE THE LOVE, and help us help > >YOU! Click Here: http://sourceforge.net/donate/ > >_______________________________________________ > >Gamedevlists-general mailing list > >Gam...@li... > >https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_id=557 > > > > > > > > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=557 > |
|
From: Noel L. <ll...@co...> - 2003-12-16 13:22:57
|
On Tue, 16 Dec 2003 12:42:45 -0000 "Alen Ladavac" <ale...@cr...> wrote: > Also, in case that zipping really does remove the redundancy well enough to > allow us to ignore the size difference, did you check your effective loading > throughput? Meaning how much MB/sec can you read from the disk. To make sure > that the parser is not slowing your loading. Ideally, you should be limited by > the transfer rate of the disk, not by the CPU. > > Please bear with me here... I have no problems with converting, but I must > make sure that it is _the_ true religion. ;) I think that looking at XML as the final format to load assets in the game is missing the point. XML is great for many of the things listed here, but sometimes (only sometimes), it makes sense to use a different format to optimize load/parse times. For instance, we export all of our models, hierarchy, meshes, and materials into an XML format. Artists can take those files and drop them straight in the game and everything will work fine. However, our resource build will convert all geometry into optimized, binary formats that can be loaded with no overhead, because we profiled it and determined it *did* make a difference (and working on console games, it's one of those things that really matters). There are some formats we haven't bothered changing from XML (hierarchy, materials, etc) since the amount of time loading them and parsing them is negligible compared to the rest of the load times. --Noel |
|
From: Brian H. <ho...@py...> - 2003-12-16 04:42:53
|
One of the problems typically encountered when trying to design a portable library's API is dealing with platform specific flags/parameters. Examples: - specifying choice of DX or OpenGL under Windows (moot under Linux and OS X) - choice of OpenGL32.DLL - specifying preference for DD 5.1 vs. stereo sound - selecting IRDA vs. TCP/IP for sockets on a PocketPC There are at least two standard ways of handling this that I'm aware of. The first is to simply have a ton of flags that are known to be system specific, e.g. you have a PREFER_OPENGL flag which is ignored on everything but Windows: MyLib_init( ..., SOME_FLAGS | PREFER_OPENGL ); The second way is to have "backdoor" functions that are only available on a specific platform, so possibly requiring an #ifdef: #ifdef _WIN32 MyLib_setOpenGLLibrary( "opengl32.dll" ); #endif I've never liked these, because they pollute all namespaces for the sake of a hack on a small subset of platforms. Then I remembered the cvar system in the Quakes. I always thought of them as borderline hackery, but in hindsight they're actually elegant in their ability to broadcast huge amounts of information, dynamically (editable at console) but in a fashion that only the interested subsystems will care about. You can set "gl_finish 1" and it has no effect, unless you're running the GL renderer. So instead of polluting/hacking an API in order to deal with each platform's little quirks, it seems that it would be better to use a cvar system to broadcast all non-portable or dynamic information. What I've done is made a simple properties system, which I'm sure everyone else has done as well. Then for a particular API, you simply pass it the property system and it uses that for any private crap it needs. property_system *ps; PropLib_createPropertySystem( &ps ); PropLib_setPropertyString( ps, "opengl DLL", "opengl32.dll" ); . . . MyLib_initOpenGL( ... /* misc stuff */, ps ); You can then dump all your This does introduce a dependency on a new library, the property_system stuff, but it seems to have a lot of other benefits going for it if you're developing a lot of portable libs. This ties into the PrefLib as well, since I was having a hard time reconciling PrefLib's persistency vs. performance expectations (i.e. does it cache then write on flush, or does it always write-on-modify, etc.). So now PrefLib is WAY smaller, because it doesn't have its own property system. Instead, you simply create your properties using PropLib, then you can serialize however/whenever you want: PrefLib_createPreferences( &pf, "com.pyrogon.mynewgame" ); PrefLib_writeProperties( pf, ps ); The PrefLib ONLY takes care of reading/writing to the platform specific preferences facilities (although at this point I'm just preferring file system preferences and only going to the registry when requested), and it doesn't handle property management at all. It's a clean break between the two, which is probably what I should have done originally. And more importantly, I've solved a problem for my other to-be-open-sourced stuff with how they deal with platform configuration options. Does this all sound sane? Brian |
|
From: Greg S. [work] <gr...@st...> - 2003-12-16 04:44:46
|
What I like about XML is that it is an easy to read, easy to edit, and object oriented (depending on how you use it, of course). People are familiar with it, it's very extensible and can be used on a number of completely unrelated game systems, and there are 3rd party tools/api's = if you don't want to roll your own parser. As a more practical example, I'm planning on re-writing a piece of code = to use XML. Currently we have files which artists create using a tool = which describes animations, models, special effects, etc for a "character" in = our game. These files are saved as binary files, and are added to version control. I think you can see where I'm going with this - too often = artist X got confused and checked in very old versions of these files. Because = they were binary, doing diffs and such was next to impossible. It'd be nice = to see that artist Y added this particle system to the character and that's = why our frame rate is plummeting. Obviously any text file format would do the trick here, but since we = have a working XML system, and it's "object oriented", it's pretty easy to do. = End result is a new file format that's easy to read and edit, in code or by hand. I'm not saying XML is the end all be all of text file formats, but it = sure makes sense if you've got it working. Oh, and if you view XML files in = IE they are color coded and you can expand/collapse the tags!!! w00t. =3D) > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On Behalf Of > Brian Hook > Sent: Monday, December 15, 2003 11:14 PM > To: gam...@li... > Subject: [gamedevlist] XML was RE: [GD-General] RE: A portable = preferences > library >=20 > This list server is getting more and more flakey...anyway, this is a > repost since my prior one evidently went into the great void.. >=20 > > Behalf Of Jeff Laing > > I'm surprised that no-one has said "use XML format please" - its > > not that painful, given that you'll have a fairly limited schema > > to implement. >=20 > So here's a question -- I know that whenever a discussion about text > file formats comes up there is often a "use XML" grenade tossed into > it. Now, I can think of a lot of reasons NOT to use XML (i.e. it's > overkill, for one), but I'm curious what real, tangible reasons for > using XML exist, as opposed to a simple application specific structure > (like INI files). >=20 > Brian >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_idU7 |
|
From: Pierre T. <pie...@no...> - 2003-12-16 08:30:23
|
It's kinda interesting to read in the same thread: "What I like about XML is that it is an easy to read [snip]" and then "It also has the variously massive disadvantages of not being particularly human readable [snip]" ... |
|
From: Jorrit T. <Jor...@uz...> - 2003-12-16 08:39:51
|
Pierre Terdiman wrote: >It's kinda interesting to read in the same thread: > >"What I like about XML is that it is an easy to read [snip]" > >and then > >"It also has the variously massive disadvantages of not being particularly >human readable [snip]" > >... > > Actually in a sense both comments are true :-) If you read XML in a text editor that doesn't have any specific XML features then it is not THAT easy to read. However, there are lots of tools in existance that can browse XML files in a more structured way. And in that sense it becomes very easy to read. This is also one of the advantages of XML. There are so many tools available. Greetings, |
|
From: J C L. <cl...@ka...> - 2003-12-16 14:51:46
|
On Tue, 16 Dec 2003 09:39:19 +0100 Jorrit Tyberghein <Jor...@uz...> wrote: > Pierre Terdiman wrote: > However, there are lots of tools in existance that can browse XML > files in a more structured way. And in that sense it becomes very easy > to read. This is also one of the advantages of XML. There are so many > tools available. Agreed, but it is also one of the disadvantages in that they are all new tools and fundamentally different tools (eg not stream based) than the text processing tools you are already familiar with. You're not only making an investment in a data format, but in a set of processing tools to go along with it at the same time... -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: J C L. <cl...@ka...> - 2003-12-16 05:16:35
|
On Mon, 15 Dec 2003 23:14:17 -0500 Brian Hook <ho...@py...> wrote: > So here's a question -- I know that whenever a discussion about text > file formats comes up there is often a "use XML" grenade tossed into > it. Now, I can think of a lot of reasons NOT to use XML (i.e. it's > overkill, for one), but I'm curious what real, tangible reasons for > using XML exist, as opposed to a simple application specific structure > (like INI files). -- Generic off-the-shelf known-working/correct parser. -- Generic off-the-shelf correctness/validity known working/correct checking (mostly, modulo DTD details etc). -- Able to represent complex nested/recursive structures. -- Able to standardly represent simple/small and large/complex types (eg basic types and large data blobs). -- Relatively easily processed and viewed/edited by other tools. -- Can safely/accurately refer to data objects stored externally to the dataset (eg MIME objects in-file or fully external). -- Relatively mature toolchain. -- Relatively familiar to potential employees and their preferred toolchains. It is however a very large hammer for what is usually a very small nut. It also has the variously massive disadvantages of not being particularly human readable and of working poorly with standard text processing tools (eg grep/sed/perl/cut/etc). -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
|
From: Andrew G. <ag...@cl...> - 2003-12-05 11:09:57
|
And hey, Doom also stored it's config file in the game directory so that's another mass seller which counters my opinion! But for arguments sake lets get rid of all those games released before the year 2000 when your average PC came with 98/SE/ME... which leaves BF1942. I'm not sure what relevance it being a popular online game has, while it's a fantastic game I don't think it's sales were anything remarkable. Anyhow, as someone pointed out there are games out there which require admin privileges to play but more and more are switching to using the correct location for this sort of thing. Unless you haven't looked lately then XP now comes packaged with pretty much any PC and Microsoft are really pushing the muti-user angle since it's the first OS targetted at the home market which has good support for this. People who think they know better might disagree with this usage scenario, but when Microsoft pushes an aspect or usage pattern it more often than not becomes adopted (I used to hate 'My Documents' when it was first introduced, but I use it now). Anyhow, you are of course free to do whatever you want, but my advice to anyone thinking of releasing a PC game in the future would be to follow the recommended approach and install all per-user options in the correnct location. Even if everyone using a PC has a single login then the worse that happens is their saves are stored with all similar data and can easily be backed up. _____________________________________ andrew grant | programmer | climax brighton ag...@cl... - www.climax.co.uk > -----Original Message----- > From: Garett Bass [mailto:gt...@st...] > Sent: 05 December 2003 03:09 > To: gam...@li... > Subject: RE: [GD-General] A portable preferences library > > > // Andrew grant wrote in response to Colin Fahey: > // > // I'd be surprised if your approach makes it through > // QA of any publisher worth their salt. > > Colin's approach is exactly what is used by Quake, > Quake2, Quake3, Half-Life, and by the transitive property, > Counter-Strike. Another popular game using this technique is > Battlefield 1942. > > Personally, I find Colin's suggestion to be a perfectly > acceptable means of managing preferences for a game. I > particularly like the ability to keep a variety of preference > files onhand. More than one per user can be handy if you are > experimenting with some scripted input behavior in your spare > time but don't want to lose your competition config. > > Now, I'm not sure this is true, but I've heard that > Counter-Strike is currently the most popular online FPS, and > that 1942 is second most popular. And yet you exclude > Activision and EA from your set of all "publishers worth their salt". > > // Something that's pretty common these days where > // Dad has to install the games little Johnny wants > // to play on the family PC. > > Ok, this makes me feel a little dumb. I've been trying > to set up a restricted access user on a Win2k box at work, > and no matter what I disallow, I still can't figure out how > to prevent the user from installing stupid crap from the internet. > > Somehow I doubt there are many fathers who are running > serious system-level multi-user setups at home. More likely > everyone just uses the same login and shares the same > clutter. Sure, it's still multi-user, as in "used by > multiple people", but not at the registry level. > > So, I'm guessing that the multi-user advantages of the > registry-stored preferences are likely used only by an elite > few with some serious IT skills. Another example of 99% in, > 1% out. I'm partial to 1942's handy built-in multiple > profiles dialog. I suppose you could always use a single > registry key to set a default profile for each system-level user. > > Apologies in advance for the rants. > > Curious, > Garett > > |
|
From: Richard S. <Ric...@ei...> - 2003-12-05 12:55:49
|
Ivan-Assen said: > If you are really opposed to using XML - after all, why would=20 > a "simple" > preferences library need a big bad XML parser (answer: you'll=20 > likely need > an XML parser in the game anyway...), you can play the=20 > revolutionary by using YAML: >=20 > http://www.yaml.org Looks like an alternative, except currently there does not seem to be a C++ parser for it, or, perhaps more importantly[0], no support tools. Certainly churning out a language spec for SCite (or editor of choice) would be simple enough, but comparing this to the enormous resources available to the XML user leaves it with a long way to go. Which is fine by me as I'm 80% of the way through implementing a complex data and rule based system in C++ using XML as the interim data format and would hate to find a better alternative at this late stage :*) Rich [0] Only because non-validating parsers for this kind of language are not too hard to produce[1] [1] And indeed, to get game-quality optimisations, I'll have to write my own micro XML parser so we can stop using Xerces |
|
From: Ivan-Assen I. <as...@ha...> - 2003-12-05 13:11:06
|
> And indeed, to get game-quality optimisations, I'll have to > write my own micro XML parser so we can stop using Xerces Xerces? We decided against using a validating parser, and are happily using expat. We have around 1500 XMLs in a game installation. We don't have tests for how long it takes to load them all, because they most of them are loaded on demand, but in normal gaming sessions (load the game and play 30-40 minutes) profiles showed that total time spent inside expat was < 500 ms. |
|
From: Tom S. <to...@pi...> - 2003-12-05 19:13:52
|
> > And indeed, to get game-quality optimisations, I'll have to > write my > > own micro XML parser so we can stop using Xerces > Xerces? We decided against using a validating parser, > and are happily using expat. If your looking for a very small fast XML parser CMarkup ( http://www.firstobject.com/dn_markup.htm ) is it. Download the eval zip which contains all the source... It's just one header and source file which is under 1600 lines all together. It has 3 different flavors... MFC, STL, and one that wraps MSXML.DLL. The thing is so simple that you can easily 'find and replace all' your own string class if necessary. It also uses EDOM ( http://www.firstobject.com/dn_edom.htm ) which makes querying the parser for data dead simple. If you can't tell I had a very good experience with it. Definitely check it out. Tom |
|
From: Simon S. <red...@ho...> - 2003-12-05 17:15:04
|
>Anyhow, you are of course free to do whatever you want, but my advice to >anyone thinking of releasing a PC game in the future would be to follow the >recommended approach and install all per-user options in the correnct >location. Even if everyone using a PC has a single login then the worse >that >happens is their saves are stored with all similar data and can easily be >backed up. The only "Correct" thing to do on the Windows platform is what the logo spec says: http://www.microsoft.com/winlogo/software/default.mspx (spec is downloadable from http://go.microsoft.com/fwlink/?LinkId=9775 , Main sections of interest here are 2.0: Install/Remove, and 3.0: Data and Settings Management.) _________________________________________________________________ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp |
|
From: Parveen K. <pk...@al...> - 2003-12-05 20:21:08
|
On Fri, 5 Dec 2003 14:28:06 +0200 gam...@li... wrote: > > I believe Microsoft are working on something like "zero-install" games, > where the CD is just popped into the drive, and the game uses part of the > HDD for caching - but doesn't rely on it being preserved across runs, > similar to what games use the Xbox HDD. Sounds similiar to the Gentoo LiveCDs. Having America's Army, UT2k3, and RtCW:ET on bootable CDs are a god-send when you're bored out of your skull and away from your own machine. www.gentoo.org www.gentoogames.com |
|
From: Mat N. \(BUNGIE\) <mat...@mi...> - 2003-12-05 22:24:16
|
Wouldn't it be easier to add the ability for the user to import/export preferences? (Along with the requisite documentation.) MSN -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Tom Spilman Sent: Friday, December 05, 2003 11:31 AM To: gam...@li... Subject: RE: [GD-General] A portable preferences library=20 > -----Original Message----- > Behalf Of J C Lawrence > > Maybe I'm hard-core, but I think everything an application needs to=20 > > operate, short of the absolutely guaranteed resources of=20 > the operating=20 > > system, should be packaged with the application -- and totally=20 > > portable. >=20 > In the case of user preferences this violates the model of=20 > segmented access rights and patterns as it requires that=20 > users have write access to the installation point the=20 > application. Maybe one that wants to maintain application controlled config selection ala BF1942 for instance, yet not violate the write access of non-admin accounts should use SHGetFolderLocation( CSIDL_COMMON_APPDATA ), CSIDL_COMMON_DOCUMENTS, or whatever is equivalent to 'C:\Documents and Settings\All Users\' in other OSs. =20 Tom =09 ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D557 |
|
From: Nicolas R. <nic...@fr...> - 2003-12-06 23:14:02
|
Hi ! Just to add my 2 cents about that very touchy subject: 1- Admin installation (and DLLs or Shared Extensions). - I don't want to "re-" implement my DivX codec in my game, and therefore I'm using the system's one. But I can't be sure the system is already having it installed. If not, I do install the "official" one. And the only place for system-wide shared code is... in system. I think that's the main reason for many games to require the "admin" login during installation. - I *could* install the codec right next to app, but this won't be patched, correctly if the user is installing a newer version. - Another example is the DirectX dependency. If your app is using DX9b, you *need* to install it (10% users only knowing what DX is), and you *must* be admin for that. - Any inter-dependency through pieces of codes should be handled by the system, and therefore, uninstalling be handled by the system as well (to check those inter-dependencies). Alas, AFAIK, there is *no* system handling code dependency correctly (and completely). - Reason for DLLs (or shared extension) is essentially code separation. If one day during your development you find that a reference is missing in the DLL (or shared extension), it means that somewhere, code release process was broken (or misused) [or it may be due to @#!#@=E9 compiler 'missing' code changes]. BTW, though being the only user on my machine, I am certainly not an admin on it (though still having debugging rights :) ). And I can't count the number of downloaded viruses (or simply f..... Ad programs) that failed to spoil my system that way. To continue on this thought: never found a single unix geek who was "using" their system under the root login (they were always using the 'su' for temporary admin purpose). 2- Multiple-instances & Auto-update. I really think it is nonsense to install the same application n times on the same machine. - I know hard disk space is cheap (even cheaper than raw CD-R now), but you cannot say someone, hey, buy more disk so another user can launch me. Note that a possiblity is given with "current directory" setting (available through the shortcut). But it is leading to another problem when an unknown new user is launching the thing (creating a new directory, updating the shortcut...). - You don't want to patch the same application multiple times. Even less if each instance is sharing data with other instances (which would yield to complete mess, not saying that you may have 8472 different shortcuts, and you cannot tell a user to change the path in them) ! - You don't want to spend those 10 minutes installs from CDs 'n' times. [if you are not copying data from CD, it means you won't be able to patch those data]. - Automated update. Sincerely, I never ever used a game auto-update feature. Why ? Because I prefer to store the update installer somewhere accessible for my next "re-install" (an re-patch :) ). Plus, if the game is installed multiple-times (on multiple-machines), I don't want to download that update 'n' times [especially knowing how fast is servers access when new updates are available]. Of course, I'm not a low-end user, but still do know some low-end (very low end trust me ! :) ) users who are doing the exact same thing [though storing updates on the desktop]. 3- Multiple-Users / Multiple-Machines. I think it is wrong to think that a machine will be used by a single user. Especially knowing how easy user selection is on XP-Home edition. Even very low-end users are using the feature (not even knowing they are 'loging' into something :) ). The same thing has to be said with small home networks. They tend to be quite common (especially with all those WiFi network bundles now) and so easy to manage (as long as you are not under unix :)) ) 4- Data locations. - There are at least 4 major data locations needed for an app (not sure all games need those, but...). a- Machine specific (non-portable) data (data relating to machine's hardware and setup, like binary-code). b- Application specific (portable) data (usually game content). c- User/Machine specific data (data relating to user's preferences based on machine's hardware: D3D, OpenGL, resolution, EAX, ...) d- User/Application specific data (key bindings, colors, skins, names, network games, saved games). (a !=3D b) (and c !=3D d) because of portability issues. (c !=3D d) because of roaming profiles (same preferences on all = machines) ! (a !=3D c) because a user may prefer lower resolution for higher FPS, while another one may prefer best visual quality, though choices are based on hardware. (b !=3D d) because of ... User Preferences ! :) On windows: (a) =3D (Application directory)/"WhatYouWant", could be HKLM (but it prevents shared-network-drive installations). (b) =3D (CSIDL_COMMON_APPDATA)/"YourCompany"/"WhatYouWant" (c) =3D (CSIDL_LOCAL_APPDATA)/"YourCompany"/"WhatYouWant", could be = HKCU. (d) =3D (CSIDL_APPDATA)/"YourCompany"/"WhatYouWant" I dislike usage of CSIDL_PERSONAL (My Documents) because saved games and preferences are obviously *not* documents, but should still be able to roam with my profile. I'm not sure what would be the correct locations on other systems. 5- Data format. For preferences and anything the user may want to edit 'by hand': XML rulez ! :))) For application specific data / saved games, I guess proprietary encrypted formats are still the way to go (to avoid at much those littles pesky saved game editors). Nicolas |
|
From: Colin F. <cp...@ea...> - 2003-12-07 02:21:11
|
2003 December 6th Saturday I am satisfied with the idea that different applications will require different schemes to store data, such as user preferences. Nothing stops me from running an application from my keychain USB memory device and having it store my user preferences there. I can have as many versions of the application as I want, even identical versions, coexisting on my keychain USB memory device, each with its own set of persisting data and preferences for any number of "users" (which has nothing to do with the total number of users on any given host machine). I can remove the keychain USB memory device from a computer without leaving any residual trace of the application, and I can attach to a new machine without any installation procedure. All of that existing flexibility suits me just fine. I understand that other applications benefit from the window manager or file explorer knowing about them. Some applications will be less transient than the scenario I descibe above. There will be applications that all users of a multi-user system (in the conventional sense) are likely to want to use, and I can recognize the benefit of "scattering" preferences to the persistent stores associated with each user. In some cases this facilitates user "roaming" to other machines. (However, consider the fact that my keychain USB memory device can "roam" to any machine with a USB port, regardless of network connectivity and some domain controller to share data about me.) I'm not sure if I agree with the objection that multiple installations of an application (including games), one per user, is necessarily bad! One user might choose to mod the game or apply patches... I agree that acquiring patches and storing them on a CD-ROM so one doesn't have to risk not being able to download them in the future (when the game company goes out of business ;-)) or the inconvenience of downloading in the future, is a good option. Briefly, about the DivX codec or the DirectX version example... I want to say that the product shouldn't ship when it requires something the target operating system doesn't have by default, but I know that's a little extreme. Also, I'm not sure "XML rulez". It's hard to beat the convenience and simplicity of a text file that resembles an *.INI file. Text editors are commonplace, but I've never really considered using an XML editor (something that handles the tags transparently). I'm not saying XML is bad, but I guess the idea of using an XML editor as spontaneously and easily as, say, Notepad for really plain text files, is an idea that I haven't considered yet. I want to make a comment regarding all of my posts on this subject: I admit to irresponsible, superficial consideration of this issue; soooo, if you haven't already, disregard everything I have said! :-) --- Colin cp...@ea... |
|
From: Ken P. <ke...@dr...> - 2003-12-07 02:31:20
|
>I dislike usage of CSIDL_PERSONAL (My Documents) because saved games and >preferences are obviously *not* documents, but should still be able to >roam with my profile. Define "document". Save games document my progress within the game. Prefs files document my preferences. Would a Word file still be a document if you didn't have a reader for it? >5- Data format. >For preferences and anything the user may want to edit 'by hand': XML >rulez ! :))) >For application specific data / saved games, I guess proprietary >encrypted formats are still the way to go (to avoid at much those >littles pesky saved game editors). What a useless waste of time. Whatever you design, they will crack. And if some user at home edits his save games to make the game a little easier for themselves, who cares? The time spent encrypting your save games in your proprietary format could be better spent polishing the game itself. I understand the need in a multiplayer game to keep people from cheating, but I do not understand at all the opposition many game developers have to single player games having editors. It's not you against the players, it's okay if he wins even if it isn't the way you intended. |
|
From: Colin F. <cp...@ea...> - 2003-12-07 09:54:41
|
2003 December 7th Sunday > I understand the need in a multiplayer game to keep people from cheating, > but I do not understand at all the opposition many game developers have to > single player games having editors. It's not you against the players, it's > okay if he wins even if it isn't the way you intended. I totally agree. I also think that making it impossible to save the game state at arbitrary times and places (which should almost always be technologically possible without some wacky paradox) is just annoying. For some people the game just isn't fun with the stock rules. I gave up playing Oni, and almost gave up before finishing GTA3, because of lengthly missions that I would fail at almost the last moment -- only to be forced to start from the very beginning again! Imagine reading a novel, and on page 200 you encounter an unfamiliar word that forces you to start reading the novel from the very beginning. After a while you would begin to hate seeing the same stupid stuff over and over again, just to catch brief glimpses of the worthy challenges before being sent back to the beginning. Funny anecdote: I remember a guy who played Half-Life in "god mode" from beginning to end. His character was totally invulnerable -- but he'd still very carefully avoid threats and he'd get freaked out when his character was attacked by enemies. This was shocking to me, because it required convincing oneself that taking damageless damage was really bad. But I realize that me and my desire to save games at arbitrary points is just another "safety net" in a continuum of comfortable risk. There are a few "one-shot kill" games, like Rogue Spear and maybe America's Army. If one's character is shot once (or, sometimes, twice), that player must sit out the rest of the multiplayer match. (Rogue Spear did allow the first few dead characters to assume control of any living non-player characters remaining in the team's squad, but just consider the general high stakes of games of this nature.) Anyhow, for some people the high stakes are obviously a thrill. For some, no game is worth playing unless the reward is fantastic (like being the only survivor in a one-shot kill match). A state lottery might have a pot of $100 million, and clearly lots of people like the nature of that kind of "game" (crazy odds but huge reward), but that same scenario can be a big turn-off for others. Anyhow, I like the idea of tuning the rules and "laws of nature" in a game, because it is just like adjusting the bass and treble on a stereo. There is no good or bad way to play a game any more than adjusting the sound of music to increase listening pleasure could be considered "cheating". If people want bragging rights (e.g., "I defeated the Britney Spears Mech with my Paris Hilton Pokemon at the Pepsi-n*Sync MTV beach house."), then the Educational Testing Service will have to offer standardized testing in video games, with standard equipment, because anyone who *wants* to cheat in any single-player game on any system will find a way. That would be awesome: sending colleges official video game scores. Of course ETS would charge $4 for each addional score report, and your bad video game scores would haunt you for five years! There'd be video game prep courses, private tutors, and pressure from parents to not flunk video games. Every now and then there'd be the guy who got a perfect score, going on to play video games at the school of his choice -- probably going on to do something really video game-y for society some day... To summarize, I think that the observation that "It's not [game developers] against the players [...]" is really great, because I suspect a lot of development teams don't actually explicitly consider their relationship with players in this regard. Maybe some developers vaguely think enforcing game conditions will permit a standard that will make the game a meaningful basis of comparing people (just like a standardized test), but I wonder how the team would vote if the matter was raised explicitly at a meeting. I think that simple observation could very well change the unspoken attitude of developers toward their anonymous end-users. I think it could very well be a good core principle to remind everyone of at, say, monthly milestone meetings, or whatever. Well, it seems important to me, anyhow, now that I've seen the idea spelled out. --- Colin cp...@ea... |
|
From: Stefan B. <ste...@di...> - 2003-12-18 09:59:10
|
> But for arguments sake lets get rid of all those games released before the > year 2000 when your average PC came with 98/SE/ME... which leaves BF1942. > I'm not sure what relevance it being a popular online game has, while it's > a fantastic game I don't think it's sales were anything remarkable. *cough cough* I believe BF1942 has sold in the region of 2.3million units which makes it one of the ten best-selling PC games ever ;) That said, I don't know if saving the preferences to the application directory is such a brilliant idea. Cheers, Stef! :) Stefan Boberg Chief Technical Officer Digital Illusions CE AB |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X