This tutorial includes various image examples of typical trainer GUI's including hotkeys, buttons, images, splash screens, and much more. Also covers information of basic software design principles, showing what works and what to avoid.
If you are using a trainer creation or builder program most of this information will apply to you; however, if you are programming your own trainer (AutoIt, FreeBASIC, etc.) even more so.
I created my eleven different example images based from the various trainers I have used, created, and seen online. There are many various other things that can be changed/done; however, the examples still apply.
HotKeys
I decided to include this section first as choosing to use hotkeys or not can affect the overall look and design of your trainer.
Hotkeys are themselves not required in a trainer, as there are different ways to turn the cheats on/off. Many trainer authors use them, and many still don't.
Some trainer builder programs will however default to hotkeys instead of buttons. This is because it is easier for the original software author to program - hotkeys do no require the cheat author to name the buttons, place them in the GUI, etc.
Personally I am indifferent about including them in my trainers. In many cases though I think adding the addition text to specify a hotkey for each cheat just gets in the way.
For example my recent trainer that has over twenty cheats, no one will remember which hotkey is which - and users prefer to click buttons anyway. Also the required GUI space to include the hotkey text for each was too much.
One other point on hotkeys is that some virus scanners will give a false-positive if they are used.
Basic Usability
While it is the most simplistic trainer, it is to the point usability suffers.
For example if the user wants to know if a cheat is on or off there is no easy way to tell. As some game cheats work only at certain points in the game, and if the user thought it was on, they will miss the chance to use it.
Or if they thought a cheat for health was on, however it isn't the player dies ending the game. Just how handy will the trainer be? Very little if any.
As this trainer example is a dialog/window why is there no controls for the cheats (buttons, etc.)? The trainer dialog/window serves as nothing more than a message box.
There are some things that can easily be changed/added to help out the user without much effort on your part.
A Better Example
Check Boxes
The addition of simple check boxes for each cheat adds many new features for the user. They can now tell easily which cheat is on and off. (In the example image the ammo and weapon cheats are on).
Also the user can now interact with the trainer dialog/window, they can click the check boxes to turn the cheats on and off. This is the best button to use for trainers, due to size and easy cheat on/off readability for users.
Link
Another change from the first example is the text Created by t2Eservo is now a clickable link. This is done by checking if the text is clicked, and if so sending the user to the website specified.
In AutoIt create the text giving it the color you want (I used blue and underlined so the user thinks link), and if the mouse pointer is over the text it changes to a hand. Check if the text is clicked, and if so use the AutoIt code to open the website link -
ShellExecute("http://t2eservo.blogspot.com")About Button
The last change from Example 1 is the new button About. It will provide the user with more information about who created the trainer, and can provide instructions on how to use the trainer.
Overly Complicated
Editable HotKeys
The hotkeys are now editable by the user (by clicking the hotkey and pressing a new hotkey). This was done in the FreeBASIC programming language using the GUI builder in FbEdit - it is labeled as HotKey.
While editable hotkey's can be a great option, that's up to you, it is not necessary. If you create the trainer hotkey's with the game in mind, the hotkeys will not need to be changed.
Cheat Input Fields
The other example change is the addition of the input fields for the health, money, and ammo cheats. This type of input is found in many trainers and severs no real purpose.
While the input fields allow the user to enter any value they want for specific items (health, money, etc.), in nearly all cases it is not needed. The only real use of such a input would be in games that require a specific amount for game goals/challenges in different parts.
Other than the one valid use which is rare, input fields can easily be avoided by making your trainer write the largest value in the item when the cheat is turned on.
The key to making a great user experience with your trainers is to keep things simple. Adding unneeded controls can confuse your users, and require additional documentation/help.
If you can simplify your trainer controls, without losing usability, it will make the trainer much more usable.
Menu & Status Bars
Menu Bar
A menu bar can add usability, especially to users who are lost without one; however, they can also just over complicate your trainer.
If you chose to use one just remember to keep it simple. There is no need to create endless menus or useless menu items.
Status Bar
A status bar easily adds usability to any trainer, and even more if used to it's full potential.
One example is to use the status bar to display messages if the game is currently loaded or not. Other uses are to display information when the user hovers the mouse pointer over different cheats or controls.
Images & Icons
Background Image
A great addition to make a trainer look more professional is to use images.
Using a screenshot of the game (like Example 5), a image of the game box cover, or similar adds to the appeal of the trainer.
The thing to watch-out for though is the image file sizes. There is no need to bloat a trainer with huge or high quality images. A simple 72 dpi image cropped large enough to show the desired image is more than adequate.
Image Buttons
Adding images to the trainer buttons can be a nice touch if done right. The image can include text, or a image that is easily understood (such as a handgun for a weapon cheat button, etc).
Just make the images easy for the user to understand what the buttons are for.
In my Example 5 both the About and Close buttons use images (the text is part of the image itself). They were created for the example; however, if I planned to use a image button I would spend more time making the text more readable.
Trainer Icon
In the previous examples I used my avatar/logo image, but changed it to a tree/shrub from the game. Icons are shown in the dialog/window title bar, in the Windows taskbar, and other places in Windows.
Trainers often use two types of icons - the icon of the creators avatar/logo (to keep things consistent), or the icon of the game itself; however, of course anything can be used.
View my icon tutorial for more information about their use, and how to create/modify/extract icons.
Splash Screens
Splash screens at one point were included with every program it seemed, but has nearly disappear anymore.
In my Example 6 the splash screen is shown on top of the trainer dialog/window. It is nothing more than another dialog/window of the trainer with an image.
I chose a splash screen that uses a transparent dialog/window so only the image itself shows - this is a more advanced programming trick. A splash screen having a border-less dialog/window with a image centered inside it is often typical.
The splash screen itself doesn't add to the trainer, besides a annoying pause programmed until the screen disappears before the trainer can be used. Of course it doesn't take away from the trainer necessarily either.
The choice is yours to use one or not, but I would say save yourself the time and skip it. As the user will find out who made the trainer and whatever else you want them to know easier in the trainer. For example using text on the trainer window, or including the information in about message box or dialog/window.
Custom Dialog/Window
Custom Dialog/Window
A example of a advanced dialog/window GUI. Instead of the typical rectangle/square dialog/window, it can be any shape.
In Example 7 the dialog/window is created in the shape of my avatar/logo.
Depending on the programming language used there are various ways to create a custom dialog/window.
If you want to create a custom dialog/window try searching for the programming language using transparent GUI dialog/window, or examples of using skins (skinning is another solution).
Other examples use a dialog/window with a background image and the controls (buttons, text, etc.) are created in child window(s).
Here are some examples on the AutoIt forum - Transparent GUI and Skinning GUI's.
Text Changing Buttons
Beyond the check box buttons, text changing buttons can also be used. In the Example 7 trainer the button text lists the cheat, along with the text (Off).
This type of button is best suited for single word cheats when possible; otherwise, they look too wordy and cramped. In the Example 7 image they may have been better if they were Health (Off), Money (Off), etc.
When the user clicks the button turning on the cheat the button text changes to the cheat text and (On). In the image you can see the Infinite Ammo and Weapon cheats are the only ones on/enabled.
To change the button text use the Windows API SetDlgItemText, or in AutoIt use GUICtrlSetData.
Groups & Radio Buttons
Groups
Putting similar cheats into groups and surrounding each group using a group-box instantly makes the trainer easier to use and more professional.
It also allows less text to be used in the cheat descriptions. As the group box says Infinite Cheats there is no longer any need to add the cheats as Infinite Health, Infinite Money, and Infinite Ammo.
Now the cheat can simply say Health, Money, Ammo as the user will know they are infinite due to the group box text.
The same rule applies to the Jump Cheats as well. When grouping cheats look for a common characteristic such as the same cheat kind (like the jump), the same cheat type (infinite cheats), what the cheats apply to (a specific character, timer, stage, etc.) or anything else they share in common.
If you can not find a common characteristic for some cheats you could always use a group box text of Other Cheats.
Radio Buttons
If you have multiple cheats for the same thing, like my example for a jump cheat, use radio buttons.
Radio buttons let the user know that only a single choice/option can be used. As the jump cheat varies the jump, only one can be used at a time.
This also again allows the cheat descriptive text to be shortened, as the group box explains the cheats.
If you use radio buttons just remember to modify the button properties to the appropriate group. That way the buttons will functions as you intend them to.
Enable All - Disable All Buttons
Adding buttons to turn on, and off, all the cheats at once is a very user friendly option. The more cheats the trainer offers the more users will find such buttons a great feature.
In my Example 7, the Enable All button would turn on all three infinite cheats and set the jump to Infinite. Clicking the Disable All button would turn off all three infinite cheats and set the jump to Normal.
Besides buttons to turn on/off all the cheats, another great use is to offer the buttons for various groups as well. For example if the trainer includes many various cheats for player 1 and many others for player 2 - adding buttons to enable/disable the cheats for player 1 would be a great option.
Adding buttons to turn on/off the player 2 cheats would be as well. In either case adding buttons to enable/disable all cheats is still a great option as well.
The Disable All is especially a great button to add to your trainer as it will save your users a bunch of button clicking when there are a lot of cheats.
Message Box
The easiest way to do that is to use a simple message box.
Some information to write to the message box is the name of the trainer, what version it is, the date you created it, who you are, and a website link.
It would also be a good idea to include what game the trainer is for, and include the game version it works on.
The message box can only display text which is a bit of a problem. If you have any desire to include a image, or a clickable link to your site (after all how many people will type the website address into their browser?) you will need to use the below example of a message dialog/window.
Message Dialog/Window
As it is a dialog/window any controls can be included.
In my Example 10 I showed the same basic text from Example 9; however, the website link is now clickable and will take the user to my site.
Also I displayed my avatar/logo and included more information (which could be on how to use the trainer) in a edit box.
For the dialog/window, edit the style property to remove the WS_SYSMENU to get rid of the minimize, maximize, and close buttons. Then simply add a Ok button to close the dialog/window.
Music & Sound
Some trainer authors feel the need to include music in their trainers. The music pauses once the user switches to the game, but there is no point in adding music.
Adding music simply adds to the bloat of your trainer, and depending on how you create the trainer multiplying the size of the trainer by thousands of kilobytes or megabytes. If you are not the composer/copyright owner of the music, it can also add many legal battles as well.
Not only that, no one is interested in hearing whatever music is added to the trainer. There is nothing more annoying than music playing in a program - often overly loud late at night, in headphones, or interrupting the users other audio.
If you decide you have to include music (I say avoid it for many reasons) at the very least include a button to turn off or mute the music. I would also recommend that the music is not automatically started either.
Sloppy Trainer
The buttons are often various sizes, the controls are thrown into the GUI at random places, the spacing varies from overlapping controls to huge gaps, bad spelling, using slang, capitalization and spacing problems, and lots more.
Beyond looking horrible, usability is quite bad as well. The user will have to try and understand what the text says - or what a control does.
Example 11 is a sloppy version of the Example 8 image above. There is a huge difference from the overall look and usability.
Although I made the example overly sloppy to make a point, I have seen some trainers in the past that were close to being this bad.
If you are going to make a trainer take a few minutes to line up the controls, use a spell checker, and make it look the best you can.
No one is perfect, but at least give it some effort.
Other Resources
More resources about general software design
- Simplifying for Usability guide from the SAP Design Guild website
- Usability in Software Design from MSDN
- Design Principles from Object Oriented Design
- Seven Principles of Software Development written by DavidHooker
- User Interface Design For Programmers written by Joel Spolsky
0 comments:
Post a Comment