Adding Mouse Support to Project Spaghetti’s Menus in GameMaker

We got a lot done for mouse support over the last week with a little overtime, so we’d better step you through the changes to expect after last week’s episode.

First, we brushed up the mouse movement effect, giving it a slightly different look when being held down as opposed to first being clicked. We didn’t want to just have no effect, because then the player couldn’t be sure if their clicking in the right mouse button to move the cowboy was doing anything, but we also didn’t want to keep repeating the click effect, because it was too distracting, so we went with a different effect for sliding the mouse. Then, rather than creating a new particle script for every color we need, we created one script, where the color could be specified. This cuts down on time and possible debugging of problems in the future. We also brushed up the sprite, making sure the middle of the crosshair icon fell right on the mouse’s center.

Next, we fixed the problem we left at the end of last week’s episode, where a player could click off the playing field, confusing the cowboy into moving back and forth as he tried to reach his destination. At first, we tried to expand the radius of the mouse drop object (the one used to determine when the cowboy has reached his destination). Although making it bigger did solve some problems, it made movement awkward for players, as they began to stop short of the empty playing field where they were clicking. So our final solution was a combination of three smaller solutions: 1) If the player clicked on the top third of the screen, outside the playing area, the “mouse drop” destination marker shifted down to the playing field to prevent the cowboy from trying to mosey off the field. 2) We tested whether the area under the mouse was outside the playing field or over an obstacle, like a barrel. 3) We created a different mouse drop object based on whether the area under the mouse was open field, or obstructed, making a larger radius for obstructed areas and a pinpoint for open areas. Problem solved.

The final adjustments we made to the mouse were: 1) Update the player direction properly based on whether the player was using a keyboard, a controller, or a mouse, and, in doing this, we ended up accomplishing a task we had set aside for this week’s episode: making the player aim towards the mouse. This should help with the mouse shooting and dodging tasks we’ll be tackling on the show. And we also 2) Hid the mouse pointer when the player wasn’t using the mouse. We also added a sleep effect, so if the player doesn’t continue to use the mouse, the pointer disappears. Whether we run with this or not is something we’ll decide in the future, as there might be times when the pointer disappears even though the player still needs it.

With all of the in-game mouse configuration out of the way, we jumped into navigating the menus with the mouse. The only solution that worked with our current menu scheme (which draws text to GameMaker’s UI layer) was to manually specify all of the coordinate ranges to “listen” to for mouse movement and clicking. The menus work fine, but we’re a little uneasy with this implementation, as all of those manually inputted coordinates could break the moment we add a new menu option or change things around. We’re also not entirely sure whether it will work properly on a touch device, so we’re thinking of scrapping the display text menu scheme in favor of laying out clickable menu items in the menu room. At the very least, it’ll be much easier to edit, but it could also save us bugs down the line once we make the change. For now, we’re running with it.

One last thing we did manage to fix was making sure the player could navigate the menus with whatever device they preferred by keeping track of the last device being used, whether the keyboard, controller, or mouse, and branching the menu reaction logic based on that. For example, if a player presses the Enter key while on an object that isn’t affected by the Enter key, they hear a small buzzer to indicate the action isn’t possible. However, with the mouse, because menu selection is handled differently, the usual logic needs to be turned off to avoid the buzzer sound when the player performs a perfectly acceptable option.

Phew, that was a lot of change! Although we felt it was stuff better accomplished between shows, we didn’t want to leave you in the dark as to any of the changes made. You can see the individual tasks as well as a few comments if you hop over to Project Spaghetti’s Trello page and check the list under Episode 31: Overtime.

Hope to see you for this week’s episode!