I think the point is that the Memory card technology is supposed to let you lock the data on the card so that other processes (that do not have the key) can not affect it. This is I believe to prevent copying and alteration of the stored information.
The fact that Ridge Racer V can affect this data suggests that the implementation of the protection on the card to prevent this is open to bypassing.
It may be in the future that these early memory cards become prized posessions as they allow people to bypass the Magic protection. Which may be useful for people GameSharking hacking the DVD playback software, etc.
Your posting might actually have been useful if you had bothered to pointed out that I had typed gene when I meant to type chromosome. I am assuming you realised this.
But then it wouldn't have been as much fun as anonymously calling someone names without contributing to the discussion (a common problem with AC).
Of course as an ex-inorganic chemist and computer programmer I guess we ought to be glad I even knew what the topic was about.
What we need are some schedulers for the new century.
eBay: The Scheduler process posts information about available slots and processes bid for the time. After the auction period expires the slot is allocated to the winning process (once the 'cheque' has cleared). The duraction of an auction would be short. Reserve prices might be set but this could lead to idle cycles.
MiddleManagment: The Scheduler makes provisional assignments based upon its favourite strategy, but all of these have to be run past an administrative Daemon which has to authorise all slot allocations. The criteria would be very complex but factors include how sexy the process was and when the admin daemon last ran a golf game. Such daemons only operate during core working hours and are easily distracted so the scheduler can sneak important but boring work through. The government uses a variant of this called the RedTape scheme.
Boeing: The Scheduler runs a standard strategy but every so often it accidently allocates all the slots to the local refuse tip where processes dig through the mounds of trash looking for them.
OpenSource: The Scheduler insists on receiving a copy of the source code of any binary that applies for slots. It then allocates based upon the the degree of innovation (determined by metrics). Library calls or other attempts to restrict access to parts of the program reduce the priority.
SlashDot: The scheduler sets up pools of resource and processes submit requests for slots into this. Other processes enter their own bids or attach sub requests to other processes requests. Processes not engaged in bidding for resources on that pool rate the requests rewarding particularly appropriate requests and penalising irrelevant requests. Particularly successful processes receive a bonus to future requests.
My reading of the article is that it is a less responsive level of switching. It is the equivalent of a phone exchange or patch panel that allows you to change the connectivity between a set of fibres. Obviously there is some other method of sending information on which pairs to connect together. Also I would guess the mechanism that generates the bubble is electricity based (though I may be wrong).
I don't see that this particular technology could be used to switch at the packet level simply because bubbles cannot be created or removed fast enough (we're talking moving physical matter so information would be lost in transition). Or maybe the system can only switch a thousand packets a second. Big gaps but boy do they move fast.
Optical computers require the switching to be instantaneous and driven by light itself (photoreactive or some such). Using this technology in optical computers would be like using relay switches in electrical computers. However relays at least used to be used in MAUs to connect computers together in a network.
This technology is useful for the infrastructure of optical computing systems but we need the optical equivalent of the valve or transistor (light amplified or switched using only light) to build the actual optical processor.
The Ultima online client checks everytime it is connected for any updates and applies them before you play. Because of this I believe the server assumes (reasonably) that all clients are at the latest patch level.
In the case of a Linux version this would require the patches for the Linux version to be available immediately they are for the Windows client. So the Linux client would need to be supported by a team very closely allied with the main development team (and require ongoing commitment).
I must admit that my experience of UA is somewhat out of date (I played the game for a couple of months and gave up). But the hot patching was endemic (at least once a week) while I was playing.
This comment was posted by Anonymous Coward and so starts with a score of 0. It would have to be moderated up to get a higher score. Only logged-in user's posts start with a score other than 0.
I don't know if you read the same article as me but I couldn't even find the words 'media' and 'culture' in the same paragraph.
I think that maybe it's put up or shut up time. For a start if you are so anti-Katz then maybe you should actually have the courage of your convictions and stop posting these attacks anonymously (there is a reason that coward is the second name).
Secondly if you're such as wonderful writer then maybe you ought to treat us to some of your deathless prose. Though how would we know it was you AC?
Go on. Tell us what the magnets say.
Re:Doesn't everyone say this?
on
Genome
·
· Score: 1
In terms of knowledge and understanding the earlier ages are seen as less interesting because less was known. Hey we already know all that so we must be in a more important time when newer knowledge is being discovered. Of course by that argument the future will be even more interesting.
That seems to be ignored by people as they assume that the knowledge they are pursuing is going to give complete knowledge in an area (I remember a comment somewhere about there being nothing more to give a Nobel physics prize for after some theory or other). So things will never be as exciting as this again.
However I think we can safely say that this new knowlege will bring at least as many questions as answers and the people addressing them will think they are in the most pivotal point in human history.
To pull this back towards topic as far as I understand the Human Genome project is invoved in collecting fairly raw information and there is still a lot of work to understand the mechanisms of how this abstract information stored in a 3-digit, base-4 notation actually provides enough information to define you and me.
That will provide for an even more interesting time and who knows what questions those answers will raise.
How high does the conspiracy go?
on
Genome
·
· Score: 1
Does the fact that we all have 23 genes mean that the creator is part of AA? (It's far too long since I read those books).
That may be a good official reason but we all know the real reason.
NASA is afraid of the class action suit that some spaceprobe-chasing lawyers would start on behalf of all the non-terrestrial life-forms that the crash had affected.
Is it true NASA stands for Not Another Space Accident?
There is potentially another reason that you might not want to get a Japanese Play Station 2 and that is the region coding. I haven't actually managed to find anything about this but if it can play DVD Video then my understanding is that a player is "hardwired" to a single region (part of the licensing). That was definitely the case with mine (originally).
USA is region 1 and Japan is region 2 so most US DVD Videos would not play on the PS2. I'm sure someone will come up with a way of bypassing this but it will proabably require internal alterations to the console. You cannot just set the region to 0 either as most modern DVD videos use a method called branching to only run on a player set to the correct region.
I must admit though that this is not really a problem for me as I'm in the UK (also in region 2 - go figure).
As an aside DVD Video is not nearly as big in Japan as the US and PS2 may actually be the first DVD player a lot of Japanese have. This is partly due to the greater penetration of Laser Disk in Japan where it is actually the distribution medium of choise (even over VHS I believe). The manufacturers seem to be protecting their investment by keeping the DVD costs high.
You knew there was a reason they were getting "Phantom Menace" on Laser Disk in Japan.
I do own and would recommend this book to people but I just feel the need to note that it is a bit light on references for a tome like this. It has a two page bibliography with 15-20 books (I don't have my copy here) but only has a few for each topic.
It fails to mention "The Mythical Man Month" - Fredrick P. Brooks Jr (1975) at all despite references to mainframe project management, and the fact that it is the seminal project control book.
It bases an entire chapter on "Design Patterns" - Gamma et. al. (1995) but mentions it only at the start of the chapter and not in the bibliography at all.
Also they Credit "Code Complete" (1993) to Steve Maguire. They may have meant Steve McConnell or they may have meant Steve Maguire's book "Writing Solid Code" published the same year. Both should probably have been in the list.
These are just the items that I can think of without the book for reference.
What they were saying was that if your game depends upon something that you are not sure you can write. Then you'd better prove you can write it before you commit to producing the program or provide an alternative fallback (that you know is possible) for if it turns out you cannot write it.
If you are writing something that is based on known techniques and you are simply writing your own enhanced version then that is not what they mean. Otherwise prove the technology before green lighting the entire project. They are not saying don't do it, just check the details first.
Yes this might have stopped some big games before they started but I suspect in cases like Quake that iD did prove the technology internally before creating the game (John Carmack seems to be very sensible like that).
The other question is how many companies have died trying to produce an impossible game when if they'd checked first they might have succeeded in creating a different great game?
If you read far enough through the book you will also discover that they are arguing that it will be more and more difficult for the smaller game companies to survive on their own. The research department issue is just one of their reasons for this. They relate it to the early days of the movie industry (pre Hollywood) and argue that the big studios are coming (sort of).
There was a game a bit like this in the works a couple of years ago. A core engine shipping with a number of stories to last 5-10 hours each, and new packs of 2-3 stories every few months. But then Cavedog pulled the plug on Elysium.
A pity because it was the most interesting game they had on their lists, and now they've had the plug pulled themselves.
IIRC this book when it discusses architecture emphasises the need to isolate things such as the the platform specific code into modules with more generic interfaces so that they can be more easily rewritten if necessary.
I think this is even the example they use to illustrate the Facade design pattern.
I suggest you read this book. I think you might be pleasantly suprised.
Of course the new guys game probably shipped several months (or even possibly years) after yours (if at all). So the people who wanted a game this month will have bought yours.
If you didn't know how you were going to make a fun game then there has to be the question of why you built the technology in the first place. Everything has to come together and technology before design is putting the cart before the horse.
iD knew they were making a fully 3D version of Doom (with better multiplay etc.) before they created Quake and succeeded.
Half-Life creators Valve knew they were making a story driven FPS style game with good NPC AI when they licensed the Quake engine and succeeded.
On the other hand I'm not sure what Dreamworks Interactive thought they were making when working on Trespasser but what they released was a frustrating game (but a beautiful technology demonstration).
The book doesn't suggest simply assembling your game from other peoples code. It does suggest not reinventing the wheel but rather working on your new wizzy suspension or aerodynamics, and making sure that the final vehicle is fun to drive.
This book is not a coding/programming book but rather an architecture/design book. It does not come with a CD of code examples but rather third party tools and some demos of games they use as design examples.
The emphasis of the first section particularly is very much on gameplay, balance, and playability (the interface works with not against you).
The second section attempts to make an argument that at least some of the methods that are used in large projects would be useful in games development. They present a lot of these and I'll be the first to admit not being convinced by all of them. Some of them may be "crap" but a number of them are common sense and I am sure used in development houses like iD, Ensemble, and Black Isle.
They do emphasis that there will be problems trying to introduce these practices and recommend you cherry pick the ones that make sense to you. They emphasise that excessivly strict environments are just as bad (if not worse) than uncontrolled ones, and I don't remember them mentioning ISO9000 once.
I would recommend that anyone reading this book does not throw it down in disgust at the first suggestion that offends them but rather continue reading. There will be other ideas that are more palitable. Also I'm sure that any successful games house will recognise things they already do (and problems they have already had).
This book is littered with case studies and examples of both good and bad practices. In fact it can be amusing sometimes to play spot the game.
The techniques presented are meant to improve the chances of repeatably producing good games, and allow the shipping of stable playable programs. Can this really be something the computer games industry wants to avoid?
Just thought I ought to mention that "Game Architecture and Design" itself does not simply talk about storylines, ideas, etc. One of the main points in the first section is that the most important part of game design is good gameplay.
They talk about storylines and hooks for games in which they are relevant. They emphasise most that the game should be fun and rewarding to play.
However there are certain types of game where the storyline is very important - indeed discovering, influencing, experiencing it is the enjoyment of these games. These are thing like Adventures and story based RPGs.
The problem is the fact that game is a bit restrictive a term. In the book they make the case for the term (I think) Electronic Entertainment. Just calling it all games is a bit like lumping playing a sport in with reading a book, going to the opera, and hillwalking. They are all recreations but the essential elements that make them fun are very different.
I would argue that Doom and Quake (particularly multi-player) are like sports whereas RPGs and Adventures are more like an interactive book. Story is important only in some but gameplay is essential in all.
If by Joe Public you mean the non-hardcore gamers that pick up a game from their local WalMart then I don't believe they are what leads to the eye candy. It is the hardcore (And on occasion very hardcore) gamers that are responsible for the demands that push the technology forwards for each release. It is them who complain that the graphics are not 32-bit, that the engine cannot run at 1600 by 1200, each object does not have individual images, and that it doesn't support their latest DirectInput toy. The success of "Deer Hunter" shows that Joe Public is enamoured more of gameplay (and very simple gameplay at that). It is hard-core gamers who are currently complaining that 3DO is about to release Might & Magic VIII with the same basic technology as the last two (but enhanced gameplay). It was them who complained the Might & Magic VI didn't support 3D cards. The mainstream is much more interested in games that are fun to play. Obviously they prefer if they don't look totally out-of-date (not many text adventures selling anymore) but cutting edge (bleeding edge?) is not essential. Also gaming can only attract the talents and budgets to produce the games with mainstream involvement. Game prices have fallen in real terms quite dramatically and this has to be offset by greater volumes. If digital gaming were not in the mainstream then either the games would be much more expensive or they just wouldn't be being produced.
Slashdot Mirror
I think the point is that the Memory card technology is supposed to let you lock the data on the card so that other processes (that do not have the key) can not affect it. This is I believe to prevent copying and alteration of the stored information.
The fact that Ridge Racer V can affect this data suggests that the implementation of the protection on the card to prevent this is open to bypassing.
It may be in the future that these early memory cards become prized posessions as they allow people to bypass the Magic protection. Which may be useful for people GameSharking hacking the DVD playback software, etc.
Your posting might actually have been useful if you had bothered to pointed out that I had typed gene when I meant to type chromosome. I am assuming you realised this.
But then it wouldn't have been as much fun as anonymously calling someone names without contributing to the discussion (a common problem with AC).
Of course as an ex-inorganic chemist and computer programmer I guess we ought to be glad I even knew what the topic was about.
What we need are some schedulers for the new century.
eBay: The Scheduler process posts information about available slots and processes bid for the time. After the auction period expires the slot is allocated to the winning process (once the 'cheque' has cleared). The duraction of an auction would be short. Reserve prices might be set but this could lead to idle cycles.
MiddleManagment: The Scheduler makes provisional assignments based upon its favourite strategy, but all of these have to be run past an administrative Daemon which has to authorise all slot allocations. The criteria would be very complex but factors include how sexy the process was and when the admin daemon last ran a golf game.
Such daemons only operate during core working hours and are easily distracted so the scheduler can sneak important but boring work through.
The government uses a variant of this called the RedTape scheme.
Boeing: The Scheduler runs a standard strategy but every so often it accidently allocates all the slots to the local refuse tip where processes dig through the mounds of trash looking for them.
OpenSource: The Scheduler insists on receiving a copy of the source code of any binary that applies for slots. It then allocates based upon the the degree of innovation (determined by metrics). Library calls or other attempts to restrict access to parts of the program reduce the priority.
SlashDot: The scheduler sets up pools of resource and processes submit requests for slots into this. Other processes enter their own bids or attach sub requests to other processes requests. Processes not engaged in bidding for resources on that pool rate the requests rewarding particularly appropriate requests and penalising irrelevant requests.
Particularly successful processes receive a bonus to future requests.
My reading of the article is that it is a less responsive level of switching. It is the equivalent of a phone exchange or patch panel that allows you to change the connectivity between a set of fibres. Obviously there is some other method of sending information on which pairs to connect together. Also I would guess the mechanism that generates the bubble is electricity based (though I may be wrong).
I don't see that this particular technology could be used to switch at the packet level simply because bubbles cannot be created or removed fast enough (we're talking moving physical matter so information would be lost in transition). Or maybe the system can only switch a thousand packets a second. Big gaps but boy do they move fast.
Optical computers require the switching to be instantaneous and driven by light itself (photoreactive or some such). Using this technology in optical computers would be like using relay switches in electrical computers. However relays at least used to be used in MAUs to connect computers together in a network.
This technology is useful for the infrastructure of optical computing systems but we need the optical equivalent of the valve or transistor (light amplified or switched using only light) to build the actual optical processor.
The Ultima online client checks everytime it is connected for any updates and applies them before you play. Because of this I believe the server assumes (reasonably) that all clients are at the latest patch level.
In the case of a Linux version this would require the patches for the Linux version to be available immediately they are for the Windows client. So the Linux client would need to be supported by a team very closely allied with the main development team (and require ongoing commitment).
I must admit that my experience of UA is somewhat out of date (I played the game for a couple of months and gave up). But the hot patching was endemic (at least once a week) while I was playing.
This comment was posted by Anonymous Coward and so starts with a score of 0. It would have to be moderated up to get a higher score. Only logged-in user's posts start with a score other than 0.
I don't know if you read the same article as me but I couldn't even find the words 'media' and 'culture' in the same paragraph.
I think that maybe it's put up or shut up time. For a start if you are so anti-Katz then maybe you should actually have the courage of your convictions and stop posting these attacks anonymously (there is a reason that coward is the second name).
Secondly if you're such as wonderful writer then maybe you ought to treat us to some of your deathless prose. Though how would we know it was you AC?
Go on. Tell us what the magnets say.
In terms of knowledge and understanding the earlier ages are seen as less interesting because less was known. Hey we already know all that so we must be in a more important time when newer knowledge is being discovered. Of course by that argument the future will be even more interesting.
That seems to be ignored by people as they assume that the knowledge they are pursuing is going to give complete knowledge in an area (I remember a comment somewhere about there being nothing more to give a Nobel physics prize for after some theory or other). So things will never be as exciting as this again.
However I think we can safely say that this new knowlege will bring at least as many questions as answers and the people addressing them will think they are in the most pivotal point in human history.
To pull this back towards topic as far as I understand the Human Genome project is invoved in collecting fairly raw information and there is still a lot of work to understand the mechanisms of how this abstract information stored in a 3-digit, base-4 notation actually provides enough information to define you and me.
That will provide for an even more interesting time and who knows what questions those answers will raise.
Does the fact that we all have 23 genes mean that the creator is part of AA? (It's far too long since I read those books).
That may be a good official reason but we all know the real reason.
NASA is afraid of the class action suit that some spaceprobe-chasing lawyers would start on behalf of all the non-terrestrial life-forms that the crash had affected.
Is it true NASA stands for Not Another Space Accident?
The DVD Encryption is unlikely to be the problem - otherwise how did my Pioneer DVD player make it out of Japan to the UK?
There is potentially another reason that you might not want to get a Japanese Play Station 2 and that is the region coding. I haven't actually managed to find anything about this but if it can play DVD Video then my understanding is that a player is "hardwired" to a single region (part of the licensing). That was definitely the case with mine (originally).
USA is region 1 and Japan is region 2 so most US DVD Videos would not play on the PS2. I'm sure someone will come up with a way of bypassing this but it will proabably require internal alterations to the console. You cannot just set the region to 0 either as most modern DVD videos use a method called branching to only run on a player set to the correct region.
I must admit though that this is not really a problem for me as I'm in the UK (also in region 2 - go figure).
As an aside DVD Video is not nearly as big in Japan as the US and PS2 may actually be the first DVD player a lot of Japanese have. This is partly due to the greater penetration of Laser Disk in Japan where it is actually the distribution medium of choise (even over VHS I believe). The manufacturers seem to be protecting their investment by keeping the DVD costs high.
You knew there was a reason they were getting "Phantom Menace" on Laser Disk in Japan.
I do own and would recommend this book to people but I just feel the need to note that it is a bit light on references for a tome like this. It has a two page bibliography with 15-20 books (I don't have my copy here) but only has a few for each topic.
It fails to mention "The Mythical Man Month" - Fredrick P. Brooks Jr (1975) at all despite references to mainframe project management, and the fact that it is the seminal project control book.
It bases an entire chapter on "Design Patterns" - Gamma et. al. (1995) but mentions it only at the start of the chapter and not in the bibliography at all.
Also they Credit "Code Complete" (1993) to Steve Maguire. They may have meant Steve McConnell or they may have meant Steve Maguire's book "Writing Solid Code" published the same year. Both should probably have been in the list.
These are just the items that I can think of without the book for reference.
What they were saying was that if your game depends upon something that you are not sure you can write. Then you'd better prove you can write it before you commit to producing the program or provide an alternative fallback (that you know is possible) for if it turns out you cannot write it.
If you are writing something that is based on known techniques and you are simply writing your own enhanced version then that is not what they mean. Otherwise prove the technology before green lighting the entire project. They are not saying don't do it, just check the details first.
Yes this might have stopped some big games before they started but I suspect in cases like Quake that iD did prove the technology internally before creating the game (John Carmack seems to be very sensible like that).
The other question is how many companies have died trying to produce an impossible game when if they'd checked first they might have succeeded in creating a different great game?
If you read far enough through the book you will also discover that they are arguing that it will be more and more difficult for the smaller game companies to survive on their own. The research department issue is just one of their reasons for this. They relate it to the early days of the movie industry (pre Hollywood) and argue that the big studios are coming (sort of).
There was a game a bit like this in the works a couple of years ago. A core engine shipping with a number of stories to last 5-10 hours each, and new packs of 2-3 stories every few months. But then Cavedog pulled the plug on Elysium.
A pity because it was the most interesting game they had on their lists, and now they've had the plug pulled themselves.
IIRC this book when it discusses architecture emphasises the need to isolate things such as the the platform specific code into modules with more generic interfaces so that they can be more easily rewritten if necessary.
I think this is even the example they use to illustrate the Facade design pattern.
I suggest you read this book. I think you might be pleasantly suprised.
Of course the new guys game probably shipped several months (or even possibly years) after yours (if at all). So the people who wanted a game this month will have bought yours.
If you didn't know how you were going to make a fun game then there has to be the question of why you built the technology in the first place. Everything has to come together and technology before design is putting the cart before the horse.
iD knew they were making a fully 3D version of Doom (with better multiplay etc.) before they created Quake and succeeded.
Half-Life creators Valve knew they were making a story driven FPS style game with good NPC AI when they licensed the Quake engine and succeeded.
On the other hand I'm not sure what Dreamworks Interactive thought they were making when working on Trespasser but what they released was a frustrating game (but a beautiful technology demonstration).
The book doesn't suggest simply assembling your game from other peoples code. It does suggest not reinventing the wheel but rather working on your new wizzy suspension or aerodynamics, and making sure that the final vehicle is fun to drive.
This book is not a coding/programming book but rather an architecture/design book. It does not come with a CD of code examples but rather third party tools and some demos of games they use as design examples.
The emphasis of the first section particularly is very much on gameplay, balance, and playability (the interface works with not against you).
The second section attempts to make an argument that at least some of the methods that are used in large projects would be useful in games development. They present a lot of these and I'll be the first to admit not being convinced by all of them. Some of them may be "crap" but a number of them are common sense and I am sure used in development houses like iD, Ensemble, and Black Isle.
They do emphasis that there will be problems trying to introduce these practices and recommend you cherry pick the ones that make sense to you. They emphasise that excessivly strict environments are just as bad (if not worse) than uncontrolled ones, and I don't remember them mentioning ISO9000 once.
I would recommend that anyone reading this book does not throw it down in disgust at the first suggestion that offends them but rather continue reading. There will be other ideas that are more palitable. Also I'm sure that any successful games house will recognise things they already do (and problems they have already had).
This book is littered with case studies and examples of both good and bad practices. In fact it can be amusing sometimes to play spot the game.
The techniques presented are meant to improve the chances of repeatably producing good games, and allow the shipping of stable playable programs. Can this really be something the computer games industry wants to avoid?
Just thought I ought to mention that "Game Architecture and Design" itself does not simply talk about storylines, ideas, etc. One of the main points in the first section is that the most important part of game design is good gameplay.
They talk about storylines and hooks for games in which they are relevant. They emphasise most that the game should be fun and rewarding to play.
However there are certain types of game where the storyline is very important - indeed discovering, influencing, experiencing it is the enjoyment of these games. These are thing like Adventures and story based RPGs.
The problem is the fact that game is a bit restrictive a term. In the book they make the case for the term (I think) Electronic Entertainment. Just calling it all games is a bit like lumping playing a sport in with reading a book, going to the opera, and hillwalking. They are all recreations but the essential elements that make them fun are very different.
I would argue that Doom and Quake (particularly multi-player) are like sports whereas RPGs and Adventures are more like an interactive book. Story is important only in some but gameplay is essential in all.
If by Joe Public you mean the non-hardcore gamers that pick up a game from their local WalMart then I don't believe they are what leads to the eye candy. It is the hardcore (And on occasion very hardcore) gamers that are responsible for the demands that push the technology forwards for each release. It is them who complain that the graphics are not 32-bit, that the engine cannot run at 1600 by 1200, each object does not have individual images, and that it doesn't support their latest DirectInput toy. The success of "Deer Hunter" shows that Joe Public is enamoured more of gameplay (and very simple gameplay at that). It is hard-core gamers who are currently complaining that 3DO is about to release Might & Magic VIII with the same basic technology as the last two (but enhanced gameplay). It was them who complained the Might & Magic VI didn't support 3D cards. The mainstream is much more interested in games that are fun to play. Obviously they prefer if they don't look totally out-of-date (not many text adventures selling anymore) but cutting edge (bleeding edge?) is not essential. Also gaming can only attract the talents and budgets to produce the games with mainstream involvement. Game prices have fallen in real terms quite dramatically and this has to be offset by greater volumes. If digital gaming were not in the mainstream then either the games would be much more expensive or they just wouldn't be being produced.