GP2X Should Developers Follow Common Design Guidelines

[Titousensei]

It is obviously not going to ensure a higher quality of software, but the end user will not be frustrated by unfamiliar controls and will be able to judge the app on its functionality rather than its user friendliness.

​

Making the user happy is part of the quality of software. Similarly, having better graphics improves the software. I agree that the games themselves are not going to be more exciting or have more FPS or better colors, the code is not going to run faster, but your overall gaming experience is going to be improved if you can install and play games easily. Hence higher quality of software.

 

[DaveC]

Done. http://wiki.gp2x.org/wiki/Suggested_Joystick_Configurations

​

Cool. Thanks. Maybe it should be put in the spot for developement info as well? It is a bit hidden there, it is a good reference for developers figuring out how the joystick works.

 

[DaveC]

I was under the impression that the joystick only registered 8 directions at the hardware level.

Are there really 16 physical directions to choose from?

​

There are 8 physical hardware directions (switches) but when you hit 2 of those at the same time you get another in-between direction giving 16 directions (as shown in chart in blue). In common d-pads there are 4 physical switches giving 8 directions when 2 are hit at once.

I don't know how linux is interpreting these. If they are only giving you 8 directions they are using one of those options in the chart at the low level. Which one I don't know.

As the chart shows there are many ways to interpret those switches at the low level and effect the bias (which direction is more likely to be hit). The case 2 type is how almost all 8 way sticks and pads behaved in the past with their 4 switches.

 

[Godmil]

I was just about to start a post on this subject, and was very happy to see that this thread exists. As a recent user of the GP2X I've been extremely frustrated by the huge variations found in the menu controls of different applications ('start' could be confirm or quit, 'select' could be menu or confirm, etc, etc...). I really like the system set out in the CUI, but I'd greatly appreciate if you could consider one addition.

As had been mentioned before, in the west we tend to use A and X as the main buttons... typically A=confirm, X=cancel. It seems to now be a standard (particularly from the menu system) that the GP2X use B=confirm and X=Cancel. This is fine, it's good that that is mostly a standard, but I was wondering if these two styles could be combined. as in developers could be encouraged to use A,B=confirm, X=cancel.

I'd be extremely greatful if this this could be considered, as I believe this sort of thing will greatly add to the user-friendliness and hence popularity of the GP2X.

 

[Dimacus]

Well, I really belive it's up to the developer, but I agree that some basic layouts might be for the better.
To solve the ingame thing, add reconfigureble keys (I haven't thought it very troughly but it should not be all to hard), that might have some standard layout.

By the " Self-contained application" section, do you mean that all files, executeble and resources should be in the same folder, and not in any kind of subfolders?
If so i have to say that it would be a major disadvantage if your games supports diffrent skins, addons and sutch.

And lastly, I dont think the user should be able to quit the game from inside the "playble" part of the game by some key combination,
but rather pressing the button for the menu and selecting quit from there.

 

[Dzz]

As a developer, I have looked those recommendations over. Some of them seem reasonable and some of them don't. If everybody else was using them I would too I suppose since people would expect certain behaviors. But seeing as they have been ignored I don't have much motivation to follow somebody's web page brainstorm that I don't even particularly like. There seem to be far more recommendations than are needed, and the button use is not very consistent (for example, why should B be used to select a highlighted menu item but A be the "primary action" button during gameplay? They are both "primary actions" in their context and should have the same button assignment).

My personal recommendations are:

1) Try to make the button assignments match those used by other similar games or applications.
2) Never rely on an obscure set of buttons for a function unless that information is clearly visible in the application, even if somebody's web page says that stick click + start is how you should exit an app.
3) When possible, tell the user what key to use. It is not that difficult to put a brief command summary into the program.
4) When possible, let multiple actions map to the obvious choice. In a menu, Stick click, A, and B can all be "select current", for example.