Overview of current layout and functionality:
Since I had to create all the GUI controls from scratch I chose a design which minimized the number of GUI controls. The basic layout is fairly static containing buttons, labels, and text fields. picture of layouts
The screen is divide into three panes:
- Map pane (displays the map’s tiles and sprites)
- Side pane (shows properties of the current map and sprite details),
- Bottom pane (has buttons to toggle the four map layers, and buttons to create new, load, and save maps).
The panes’ layouts are static. All buttons and text fields are either enabled or disabled depending on the current state of the level editor. (For example the length text field and button are disabled when an intersection is open). Some buttons will open a modal pop-up dialog box. When a modal dialog box is on screen it has the focus and must be closed before any of the GUI controls on the panes can be used.
When a map is open (either intersection or level), the user can scroll/navigate through the map on the map pane using the arrow keys. The background and foreground layers are always on. If the map is a level, the user has the option of toggling the tangible and sprite layers (Intersections do not have tangible or sprite layers). Left clicking on the map will place the current background tile and right clicking on the map will place the current foreground tile. If the tangible layer in on, left clicking on the map will place the current tangible tile. If the sprite layer is on, left clicking on a sprite will select that sprite, and the sprite's properties will be displayed on the side pane.
The tileset buttons on the bottom pane open a modal pop-up dialog box which diplays the corresponding tileset (either the foreground, background, or tangible tilesets). While a tileset dialog box is open, the same the user can scroll/navigate the tileset (since tilesets can be larger than the size of the dialog box. Left clicking on the tileset changes the current selected tile type for the layer. Left clicking outside the tileset closes the dialog box. The tileset must be closed before edits to the map can occur.
Issues with current layout:
1) The level editor’s current state is not very clear to user. When I click on the map, what will happen? Will I place a background tile or a tangible tile? It’s not clear which layers are active and which layer is currently being edited. It is confusing and difficult to use. [If I had a nickel...] (Example: If both the tangible and sprite layers are toggled, the sprite layer is being edited. Then when the sprite layer is toggled off, the tangible layer is being edited.) Currently there is no distinction between a layer being visible and a layer in use for edit.
2) Since the tilesets are in a separate dialog boxes, the changing of tile type is a four click process. When editing a map, changing the tile type is frequent and a lot of time is wasted constantly opening and closing the tilesets.
3) There is no indication as to which tile type is currently selected. If the user forgets which the current tile type or if the user miss-clicks on the tileset, the user will place an unexpected tile type. [If I had a nickel…]
4) Adding, editing, and moving sprites on a map is a inefficient. When adding a sprite the user must type in the filename of the sprite. This required the user to know all the sprites' filenames and it slows down the creation process. The movement patterns of the sprites are currently enumerated with an integer number. The user must know which integer corresponds to which movement patterns. Once again to properly use the level editor the user must know specific implementation details of the game. Also, if the wrong movement pattern is picked, the user won’t realize the mistake until they play test the map.
5) Elements of the GUI controls need to be improved to enhance usability. It is unclear to the user which GUI control has focus at a given time. This causes confusion as to which GUI object the controls will affect. Also, simple features common to GUI controls are absent making the user experience slightly frustrating (Example: you can’t hold down backspace to delete a whole line of text).
6) Using arrows to scroll/navigate the map and tilesets is unintuitive and slow.
7) Having features tied to right clicking is unintuitive, and often confused (Example: the only was to delete a sprite is to right click it.)
Solutions for current layout issues:
1) Reorganize the bottom pane to have separate controls for each layer. Each layer can have it’s visibility toggled independently from what layer is currently in use for edit (though a layer must be visible to use for edit). Add an information bar at the bottom of the screen which indicated which layer is currently in use for edit. The information bar also shows other helpful information like cursor position and current controls.
2) Keep the tilesets open on the side pane and automatically update the tileset to the corresponding layer in use for edit.
3) Add a tile shadow following the cursor of the current tile type. Highlight the current tile type in the tileset on the side pane. Add the option to toggle gridlines on the map and tilesets.
4) Allow click and drag functionality for the sprites. When creating and editing a sprite, allow the user to select from a list of sprite and movements types. Give the movement types descriptions.
5) Give panes and dialog boxes titles. Allow users to hit enter to close a dialog box. When a textbox has focus, display a blinking I-beam. Enable key strokes to repeat if held.
6) Add horizontal and vertical scroll bars to the sides of the map and tilesets. Add the mouse scroll wheel to navigation controls.
7)Remove all right-click tied functionality. Add a separate button to delete sprites.
Issues with current functionality:
1)When specifying a map name, if the map name is incorrect the level editor closes. Any unsaved work is lost.
2)When specifying a sprite name, if the sprite name is incorrect the level editor closes. Any unsaved work it lost.
Solutions for current functionality issues:
1)Handle map names errors gracefully. Add warning message boxes. Detect when there is unsaved changes and prompt the user: “Do you want to save?”.
2)Have a list of sprites to chose from. Eliminate the need for the user to specify sprite filenames.
Additional features:
1)Undo button. Keep track of level editor operations and allow the user to undo simple map edits. By far the #1 complaint from our level designers was the lack of an undo button. Though this is not trivial to implement.
2)Prefabs. Allow the user to place a group of pre arranged tiles with one click. Most object on a tileset are composed of several adjacent tiles. (Example: when placing a road there is a tile for the left edge, the center, and the right edge. If the user could arrange a line of road tiles they could quickly place a whole road, rather than constantly changing tile types). The user could add tiles to a prefab grid on the side pane. Even allow users to save and load prefabs.
3)Display movement paths of sprites on the map. Have a button which toggles the paths of the sprites. This gives the user a good idea of enemy coverage without the need to play test.
4)Allow the user to change the music file associated with a map.
5)Allow the user to see an intersection and level side by side. When editing a level and an intersection separately it’s hard for the level designer to check if the seam between the two will line up (without play testing).
