Changes

Jump to: navigation, search

Guidelines for Programming games

748 bytes added, 11:51, 16 March 2013
The following are guidelines that you should consider when programming games:
* Games should be playable with joystick alone. All menus and such should be possible to select using joystick alone. This allows the game to be played on GX4000 for example and to play it without needing to press a key. It could be also selectable with number keys or arrows.
* 'P' key Games should be used for pause in playable with joystick control modealone. All menus and such should be possible to select using joystick alone. This makes it compatible with allows the game to be played on GX4000. It's pause button is mapped for example and to the 'P' play it without needing to press a key.
* Both digital joysticks should be selectable One suggestion is that the game allows the user to use. The Amstrad plus has both connectors, press fire on the CPC can have a second gamepad/joystick using a joystick splitter or using one of the official Amstrad Joystickscorresponding fire button on the keyboard.
The game recognises which was pressed and uses this to determine which controller will be used in game.  * 'P' key should be used for pause in joystick/gamepad control mode. This makes it compatible with the GX4000. It's pause button is mapped to the 'P' key. * Both digital joysticks should be selectable to use. The Amstrad plus has both connectors, the CPC can have a second joystick using a joystick splitter or using one of the official Amstrad Joysticks. If the game supports 2 players allow both digital joysticks to be used. * Analogue joystick on Plus should be selectable if Plus machine is used. You can detect if a Plus machine exists programaticallythrough code. Analogue joystick can be used as an alternative to a digital joystick (this avoids "Keyboard Clash" when used in 2 player games in conjunction with keyboard or another digital joystick) or to their full analogue ability where it makes sense in the game.
* It should be possible to select "No Sound", "Music", "Sound Effects" or "Music and Sound Effects" (where possible).
* If you are using overscan, consider that the position of the screen may not be the same on all monitors, so a method to centralise it before the game starts, or in the options of the game.
* It is very important that keyboard controls should be possible to redefine redefineable. There is not one perfect control scheme for all, so this allows the keys controls to the choice be chosen by the user wants, or to be able to choose from a preset list.Good presetsThere are some reasonable keyboard configurations
Directions = Up, Down, Left, Right
* Consider supporting AMX Mouse (or compatibles such as Bryce's USB mouse hardware) and Symbiface 2 Mouse where it makes sense in the game. Movement could also be used for moving to the wanted menu item and clicking the mouse button to select.
* The game should be playable on green screen or greyscale monitors in addition to colour monitors. This means things are easy to see and identify when used with all monitors. Ideally, the user should be able to choose the type of monitor. This , this will enable the game to adjust its colors to either a color maximize the display for each monitor or a green / . Where games rely on colour, consider using visual differences in the tiles so they can be identified on monochrome monitormonitors without needing to use colour but when used on colour displays they benefit from the extra colours
* A game should provide a high score list (if it makes sense) and save it to disc.
* The availability of memory expansions should be investigated. And if additional memory is found the game shall use it in some way. Examples are to add additional features or to load all levels at one at the beginning.
2,562
edits