On, Wed Sep 26, 2007, RR4CLB wrote: > Hi! > > The reading I did today is getting a little more clear on these > issues, but having something to experiment with would be great. [Layout description] Regarding that the screen consists of three areas aranged in a horizontal manner. On the top the input facilities, followed the warning message. The rest is occupied by the game screen. Regarding this design the best would be a pygame user interface as I mentioned before. Otherwise you would have two or even three separate windows, one pygame window and two using another user interface toolkit. Using a different user interface toolkit together with pygame will also make it nearly impossible to have fullscreen support. [Screen reader and sound output] The issues Ulf mentioned in another mail are not tha critical. You can create classes, which wrap your drawing code (for text, images) and allow them to provide additional information in another form (sound, text, etc.). The biggest problem however will be to expose those information to the AT system in order to let screen readers and other AT devices read them. I created an accessibility wrapper for python using the Unix ATK/AT-SPI toolkit (no support for Windows and MacOS X so far), which can be used to let arbitrary python classes and objects expose their information to the underlying accessibility provider. http://ocemp.sourceforge.net/papi.html [Game with both visual and text support] Basically that sounds not that hard - the only issue will be to provide the text in a way it can be recognized by screen readers. I am not sure about the state of the console output recognition (Windows command shell, etc.), but if it works you could print the information once a certain event is received. To support both, mouse and keyboard input and to save the time to create an own solution my recommendation would be using PGU or OcempGUI for the user interfaces. Both also allow you to create new classes easily (such as an enhanced image label or button class, which can expose its information using text output or using an image). One critical question would be: arcade or round-based game type? Arcade would need some sort of real time approach when it comes to sound output, otherwise the player will be killed before he recognizes what happened. [Layout in pygame] This really depends on with what you end up with. Which user interface toolkit you choose (if you choose any) and especially what would be needed for the graphical parts. Regards Marcus
Attachment:
pgpy4p9VTQhSJ.pgp
Description: PGP signature