rpg, you're looking at this the wrong way. you're under the mistaken assumption that i don't think people with disabilities should play-- let's use the example: quake.

this is not the case at all. my post above was trying to say that (in the example) a blind person wouldn't enjoy playing quake because they wouldn't be able to see the level. in my example, i arbitrarily chose the breakdown of a map's components to be 70% visual and 30% audio. they would only be able to hear ambient sounds.

i just can't imagine a way to impart the visual aspect to the person in a way that would allow them to enjoy it.

Should we therefore make no effort to create a bionic suit so that a quadriplegic could run an obstacle course?

ok, if you want to go sci-fi, then sure. just feed to visual input directly into the brain. but my post assumed that you were talking about stuff that was possible at this time or the near future.

re 17439:
that's not a rebuttal at all. him being deaf doesn't mean anything because he wasn't making music for deaf people. 

Rebuttal wasn't my intention. 

I'd really prefer to focus on the level and game design aspects of this rather than the ethics.

It looks like no one wants to discriminate, but to answer my original question it also appears that no one has ever thought about accessibility for their levels/mods/games. What I really wanted to talk about is what people are doing, or what can be done, to improve accessibility. So far, a lot of comments have pointed to extreme cases and concluded that not a lot can be done. Going back to the real world example, let's not focus on the quadriplegic just yet; instead, let's focus on the guy who needs a prosthetic. What can be done?

P.S. friends have told me of at least two people they know who are deaf (or very near deaf) but still enjoy listening to music--they turned the volume up really high and feel the music. And for megaman: http://autodios.blogspot.com/2009/04/paintings-for-blind-project.html

P.P.S. I'm in no way trying to make people feel guilty for making a map/mod/game that gives a handicap to disabled people. However, I am really interested in the exchange of ideas, and I've always felt that the people here have a lot of potential for that. 

rpg, i don't how anything can be done from a level design point of view. if you want to let a guy who has a prosthetic hand (or whatever non-critical disability) play a game, it's in the hands of the guys making input devices and such. if his hand is missing, it doesn't matter how i build my level, he still needs a special controller which is out of my (sorry) hands. 

after a bit more thought, i can only think of one obvious and fairly easy thing to alleviate handicap for disability and that would be to not rely solely on colour differentiation for those who are colour blind.

but anything more complex than that (say, making a map that would be playable and appealing to someone who's autistic) is beyond me because i just don't know enough about these more complicated problems. you'd have to understand how an autistic mind works (as well as the varying levels of autism) to be able to create something appealing to someone with the condition, there's not much common frame of reference. 

Quake is particularly limited in what it can do for somebody who is visually impared, because almost all the media editing tools are geared to change visual elements. In stock ID1 you have no ability to add custom sounds, whereas you can include any number of new textures to a map.

Although you can overcome that limitation with a QC mod, you are still fighting an uphill battle. The quake sound engine is very limited. When you want to play a sound, you can only control the volume and attenuation. Once you have begun playing the sound, the only thing you can do it play another sound on the same channel to override it. The engine does not support moving sound sources at all, and I think that is a critical omission. These things can be fixed, but by now it's something that requires a coder - that can't just be achieved by mapping. 

are there painters that paint for blind people? 

I agree that Quake itself, as it is, isn't really translatable for the blind. However, I think you could come up with something in the Quake universe that would be with a little imagination. Something less visually oriented and more about sound, force feedback, etc. 

What you're talking about does not really apply to what I'm talking about. Let me make an analogy about what you're asking: are there game developers that make games for non-gamers?

Gaming is not an inherently visual medium; many video games utilize at least two senses, and most don't require perfect perception from either of those. And I'll repeat myself again: disability is not binary.

And why is everyone so hung up on blind people? 

I saw a TV program on new sciense skill that handled about helping people who had a physic damage like missing an arm.
Docters had made a electonic arm attached to some neural imputs.
The patient could move this arm by really thinking hard he had to weighten something. This made the arm go. He could also pick up a glass of water and drink from it.

The only bad aspects were that the patient had to think really hard to make the process go. Also when he had to pick up an egg, the thing just broke, becayse he hadn't the attitude to give the process more accumilation.

So maybe there will be a time people with handicaps can play Quake. Although they will really affirmative the nightmare Quake's Gill horror.

And megaman, let me only say that there are people that paint,
not severly for blind people.
Only you miss the fact that there is structure, smell, empathy.
It may be hard to say for someone in good health, but I can even like a picture from some foot or mouthpainter. 

Going back to the web example, accessibility is just as relevant to the content developers (website developers) as it is to the interface developers (browser developers). I feel that the same goes for game development: you can't aim for comprehensive accessibility without the support of both, but you can still make progress with just one.

You also said that Quake is more a medium of art. To me, video games in general should always primarily be a medium of strategy, interaction, and entertainment; to me, this is the message that is being delivered. Art is a secondary, but still very important, goal. Tetris is not fun and addicting because of its artistic contribution--but I know I'm not telling you anything new. Adjusting gl_picmip would certainly detract from the art of Quake, but it will still be fun to play. 

By no means an exhaustive or fine-tuned list, and I'd love to hear to some comments, criticisms, and additions (but please, no more comments about blind people, ok? Let's be more open-minded):

Dextrous interaction: The required set of in-game maneuvers should not require above-average dexterity. While this will make your map/game accessible to novice gamers, it will also prevent exclusion from gamers who lack fine motor control.

Audio signals: Avoid requiring the gamer to hear a sound in order to proceed, or otherwise penalizing the gamer for not hearing a sound.

Visual signals: Similar to audio signals, avoid using subtle visual cues as the only signal to the player; especially if these cues will be lost by changing the visual display settings (e.g. turning off lighting, disabling colors, or removing textures).

Input devices: Avoid requiring interaction from a specific input device or input style.

Examples of the input devices guideline: A simple example would be to avoid requiring fine, precise input such as from a mouse. A more extreme, but to me, still highly relevant example would be to avoid interaction styles that are difficult without the use of both hands. Doom and Quake were the only games I played a few years ago when I broke my arm because the controls are simple enough that I could map them onto a 5-button mouse and play only with my right hand. How about trying to play Stalker one-handed? 

Left 4 dead has two accessibility functions that I know of. One is the aforementioned closed-captions. It's worth noting that these have different levels of detail. You can just turn them on for dialogue if you want to be sure you get what the characters are saying. You can also turn on full captioning of sound effects. Then you get captions for other vital sound cues, like the sound of a tank ripping a rock from the ground to throw.

The other option it offers is assistance for colour-blind players, by offering a different HUD colour scheme. This includes making player who are on very low health showing up as cyan rather than red, and drawing the outlines thicker to give a visual cue even when the player cannot read the hue. 

we need abstraction! What's the equivalent to display markup for Quake? How can we say signal the player that a trap is about to be sprung, and have different modes of communicating that, based on the settings of the client?

I guess I'd call this a "gameplay API". 

I seem to remember some discussion about taking weapons from a player between maps in an episode (or something like that).

Can someone point me in the right direction please? 

Moved to its own thread here:

http://www.celephais.net/board/view_thread.php?id=60376 

The essential part of the hack is to create a trigger with classname InitTrigger and touch door_touch. You can then set the trigger's items to the bitflags of the weapons you want to remove.


There are a number of extra things that you may need to workaround:

� The door_touch function will cause crashes without a workaround.

� The function will fail if the player does not have all the items you want to remove.

� If the player is holding one of the weapons you remove, they can still use that weapon until they switch away from it.

� Removing the axe does not behave as you might hope.


The first one is fairly methodical to resolve - you just need some kind of dummy object for the trigger to refer to in the enemy and owner fields. The safest thing to do is create a func_door outside the map, and note its entity number. Then set both enemy and owner to that number.

The second one is also fairly easy to work around. What you need to do is have another InitTrigger entity which the player touches first. This time, use touch BackpackTouch and set items to be all the items you want to remove. The idea is that you give all of the items to the player right before removing them, so that you avoid any problems that might arise. The easiest way to make sure this sequence occurs is to stack the two triggers, and put the BackpackTouch earlier in the entity list.

The third problem is quite thorny. Most of the code that forces a player to change weapons is called when they grab a new weapon. But you will only switch to that weapon if the weapon you are currently holding is your best. If you don't own the weapon you are holding, it will never be your best weapon.

You are okay though, if you are willing to get rid of all the player's ammo at the same time. The trick for getting rid of the player's ammo is to create a BackpackTouch trigger with negative ammo counts. Sadly, the function which bounds the amount of ammo the player can hold only bounds it above, it does not check for ammo counts less than zero. So we have to resort to the same trick as with removing the weapons - give the player full ammo with the first BackpackTouch(which will be correctly bounded regardless of how much he had), then subtract it all off with the second one.

Once the player has no ammo, they will switch to the axe. Since you should always leave the axe item on the player(see below), their current weapon matches their best weapon. You can now give them an item with a further BackpackTouch, and they will switch to that (as long as you give them some ammo for it to boot).

The first sentence of the preceding paragraph actually explains why removing the axe leads to odd behaviour. Once you have no ammo, you always switch to the axe - even if you don't have an axe! However, if the player switchs away from this "magic" axe once they find more ammo or new weapons, they cannot go back to it unless they run out of ammo again. Rather than let the player get into this inconsistent state, just don't remove the axe. 

So I want to setup, or somehow acquire access to, cvs/svn/git repositories so I can conveniently manage some repositories between my home desktop, my laptop, and my linux box at uni. I've seen Beanstalk which is a free, but for multiple repositories I would need to create multiple accounts.

I'm just wondering what everyone else does? 

The only problem it has, for a Windows / Linux setup at least, is that it recognises the difference between a and A, which windows doesn't.

Can cause the odd screw up, but haven't had any other problems.

CVS is a POS.

Git I've never used.

SVN is free and should allow multiple repositories under the same access as far as I'm aware.

And yeah, using a file repository is light years ahead of messing around with external drives, discs, uploads or email. 

git would have the benefit that you would have your "local repository" always with you, where you can check in, branch etc. Then later you would merge to the master. I am not sure if SVN does that too. 

But yeah, it does.

Although merging is only for code - binaries from Max, Photoshop or anything else can't be merged AFAIK. Although nothing stops you from copying out and merging by hand. 

SVN does not work in offline mode, but obviously, if you have a local repository, you are never offline. While local repositories are still much better than flat files, having offsite repositories is much better since it's like an additional backup and you can easily share your work with others. 

 

http://en.wikipedia.org/wiki/Distributed_revision_control#Distributed_vs._centralized

If I understand correctly you could not do a commit to (your local) SVN while being offline. Eg if you are working on a huge text and want to keep it in versioning a DVCS would be useful. It seems much more complicated too though. 

quite fast, but the commands are a bitch to get right. very unintuitive. I can't remember them.

Distributed is nice, local commits are quite an advantage, although i don't get what all the fuzz is about.