One Switch Gaming!

Since I have been writing the report alongside the blog and development of the game, formatting it and gathering it together took a lot less time than I expected. I have spent the extra time on making the 'One Switch' control option functional.

The game now has three methods of play:

• Default (Mouse movement and clicking)
• Gaze Controlled (Same as default, except no clicking is required to turn in game)
• One Switch (Single button play)

For anyone not in the know One Switch is a method of control that relies on a single button, usually the left click or spacebar. There are no pointers, no analogue devices and the button has no analogue properties itself, it is a single, binary switch. One Switch is designed to be used by players with the most severe disabilities and usually requires a large change in the way games are played, automating a lot of the game play elements.

Fortunately for a game like Sugar Mine, the game play aspect is simple enough that it can merely be modified to be controlled through a single switch.

The big problem in this implementation was in the menus; without mouse pointers, joystick or arrow keys, it is impossible to manually select a menu option. This is an example of the aforementioned modification and automation required.

To make the menu accessible with One Switch, it has to scroll automatically through the options available and provide feedback about which option is selected.

This seemed simple and was until I got around to making the accessibility menu accessible: with drop down menus and sliders to be used, it was a little more awkward.

Nonetheless it has been implemented completely and functions: The entire game that is open and available to someone using mouse pointer and click controls can be accessed, customized and played using only a single button. I take great pride in that.

Accessibility Menu

It has been a couple of weeks since my last post and my attention has been divided in these last couple of weeks:

• An online course on Gamification I was undertaking reached its conclusion
• I built a personal website and business cards in preparation of leaving university
• Both of these as well as working on Sugar Mine.

Coming back to one of my original intentions with Sugar Mine, I have the accessibility menu implemented and functioning.



In the accessibility menu the player can customize and control game elements such as initial spawn rate of bombs, how quickly the spawn rate will increase, the initial velocity of the player and their acceleration as well as changing colour schemes.

Unfortunately the changing colour scheme only affects the menu at this moment and the high visibility scheme does nothing yet. Whilst the control scheme menu is implemented and works, it does not alter anything.

Now on to the good news: All other options and sliders function just fine and the game can be altered allowing you to set your own level of difficulty. All accessibility menu visuals and sliders conform to the visual schemes and change in real time. Any values changed stay changed when coming into and out of the menu and game.

A small change though: I had to set a default for vsp and spawnSpeed variables at the beginning of the game and reset back to them at the end, as these variables change during gameplay.

Otherwise all is well. Expotees is tomorrow and I intend to go. I'm not being exhibited but it can't hurt to be in attendance. After that the rest of the time I have available on this project will be spent writing and formatting the report. The product will be incomplete when submitted but I will work on it more when the project is over.

Power Ups!

In an effort to change up the game play of Sugar Mine a little I implemented the first (of what I hope are a good few) powerups. This first powerup is an armour powerup that when collected will save the player from game over when hitting a bomb. Also it will give them a rather nifty looking suit of armour to drill about in.

A player that has just picked up some armour.

It was mostly simple to implement but testing revealed several flaws in it. The image above is the end result of several iterations, intended to make the effect more striking and accessible. With a visual change of shapes it can be noted by players of any visual deficiency, newcomers know what to expect from the armour powerup and the powerup sequence (shown in the video below) provides a sense of actual power and change in the game.

Next I plan to include another couple of powerups and maybe change the rotation system to be a little more accurate, it still looks wrong when descending at an angle.

Destructible Background

An issue I was having with Sugar Mine was to do with the background; it was just a scrolling tile background that had no effect on the player or the player on the tiles. It broke the presence of the player I felt.

So I spent a few days looking into how to change this:

• How to create tiles
• How to move tiles
• How to remove tiles

This was just the first day of work and gave me a lot of trouble. Creating these tiles at the start was not a problem: I used a nested loop (a for loop within a for loop) to create a grid of tiles that would fill up the screen when the game started.

Moving the tiles was not difficult. I had the chocolate block parent in place and could still use the global.vsp and global.hsp variables.

Removing the tiles was easy enough, instance_destroy took care of that.

Creating the tiles on the fly, during the game, that was challenging and took several days to make it work. I tried adding entire columns and rows when blocks leave the screen, I tried adding individual blocks, using 'source' blocks to add blocks and none of it worked. It took me just over a day of work to create it and make it work the way I wanted.

After that I wanted to include the destruction of blocks based on where the player was. First the block is set to invisible and when it is, it determines the adjacent, non-diagonal blocks and sets off an alarm in each one, so it updates its sprite to provide less of a 'clean break'.

Again that took a little bit of messing around, I initially had a sprite with 5 subimages to represent the block having various states of disconnection. This would be rotated to fit. This didn't work because of the centre point (and centre of rotation) being off-centre, in the top left corner. I also had to move the block back into place.

I settled on using a sprite with 16 subimages instead, representing all possible states a chocolate block can be in. This was a lot easier as I didn't have to move or rotate the block when changing its subimages. Two unintended but positive side effects:

• I can change each one of these subimages to break up any repetitive images.
• The gloss on all of the chocolate blocks is accurate. Highlights and shadows are all on the same sides of the block.

The sprites used for the chocolate blocks.

Top: Single chocolate block used before this destructive addition.

Middle: A sprite with 6 subimages I planned to use the first time and rotate into place.

Bottom: A sprite with 16 subimages I use now. This turned out to be a lot easier for me.

This is all working out just fine now, took a couple of days to get it working properly. All else was to add a couple of offsets to the player to make it look more like the drill is breaking up the chocolate in the world.

Alternate Visuals

I spent today working through some alternate visuals for the game, taking colour blindness into consideration. I remade all the current menu assets I have, swapping out colours that were diminished or unusuable under the effects of certain colour blindness types.

This took quite a while for some elements. For example in the menu transition when the menu is being eaten, I had to select each piece by hand, deselect all the bits I didn't want colouring and alter it. Then save it. Twice.

Also I had a small issue with mis-alignment. My original images were not aligned properly, so when the animation (Main menu to game) was played, the menu would seem to jump a little. I countered this by replacing them with an offset. Of course when I created my new images, they had no such offset and the 'jumping' occurred.

I got the cause wrong and went back into illustrator, again recolouring each image for the transition and ensuring they lined up perfectly. No better.

After digging through the code to rediscover the process of swapping images in and out I found the offset code and erased it. Problem solved.



This is an image showing the main menu buttons next to each other. I only recoloured menu items as they the only visuals important enough at the moment as to need recolouring. Later in the project I will get around to the characters and obstacles.

For now though, I feel I need to work on the gameplay some more. The game becomes stale very quickly and this is a more pressing matter than visual profiles.

HUD Implemented

The HUD is in place and works just fine. I used a similar background for HUD elements as I did for the buttons on the main menu. Whether this will cause confusion or not I don't know, I will need to test this.

I have separated out the cherry bombs that spawn in the game, now they spawn and snap to the nearest 128 pixel horizontal increment.

Also included is a pause button in the top right hand side of the screen. It sets all speed variables to zero, prevents interaction of any kind (except to unpause) and even the cherry bombs stop emitting sparks. However the coins and the drill still animate, I will need to correct this.

Another miscellaneous addition is a sign on the main menu that displays the players last attained depth and coin count. This does not display if the user is playing for the first time and will allow the player to see how far they have been able to go in the game.

Here is a video of the latest version of Sugar Mine:



Next on my list of concerns is accessibility. The majority of the interactive elements of the game have come together and now I feel I should step back and make sure that the game can be played by anyone who wishes to do so. The accessibility section of the main menu has not been created yet, but creating it will also give me a chance to refine my pipeline for new assets and restructure my code in a more efficient and easy to follow fashion.

Accessibility options I have noted down to implement so far are:

• Visual Profiles (Deuteranopia, Protanopia, Tritanopia, Achromatopsia and Hi-Visibility)
• Control Profiles (Mouse Only, Keyboard Only, One Switch and Gaze Controlled)
• Turning Sensitivity (If using One-Switch or Keyboard only profiles)
• Obstacle Spawn Rate (Start)
• Obstacle Spawn Increase Rate
• Coin Collection Mode (Location/Automatic)
• Starting Speed
• Acceleration
• Sound/Effects Volume control

I have considered implementing a tutorial but I think it is almost needless. Most of the game elements are very straightforward and bear resemblances to how people would treat the objects in the game: Avoid bombs, collect coins. I may add a small graphic at the start that says 'Click to turn!' or something similar, but I feel that would be a much later addition.

More Visuals

Follow up on the last post, both Quentin and the drill are in place and working as one. I had to change how they are controlled in order to avoid errors though. I'll explain:

With just the arrow in place, the code for movement and scrolling was all in the one script: The vertical speed increases every step (up to a maximum), if the left mouse button is held down then the arrow rotates to face it, the rotation of the arrow (and a boolean directing left vs right) is used to drive a horizontal speed and reduce the vertical speed accordingly. At the end of it the vertical and horizontal speed are used to make the background scroll up and move the obstacles and coins accordingly.

Player movement is an illusion, the place doesn't move anywhere. Everything else in the world moves. It seemed like a logical choice both in prototyping, development and looking forward. Creating a large world manually would take too much time to implement.

My maths on the vertical vs horizontal movement speed needs tweaking. When going at the extremes of speed the background does not exactly match the characters' direction. If this will be an issue I do not know, only testing with others will tell.

But the characters work out just fine. All the rotation code, collision code, spawning of obstacles and coins, collision with obstacles and updating speed variables is held in a parent 'Drill' class. There is a parent 'Character' class which holds the same rotation and collision with obstacle code as the Drill parent.

Making the character and drill rotate correctly was easy as they were both developed in Illustrator on the same canvas, so could be separated and use a rotation point in the centre of their imported images, which lined up when combined in game.

Today I created the coin pickup and animated sprite:

The coin took me a lot longer than I intended because I tried to use a personal logo for the obverse face and give the coin two sides. It took about an hour of messing about to get it working and even then the visual style was too dissimilar. I considered it an indulgence, let it go and moved on. I was able to make this full rotation easily by making gratuitous use of Copy -> Paste -> Reflect in Illustrator. Once the first five frames were made, the rest could be duplicated from that.

Also created were visuals for the main obstacle in the game: A Cherry Bomb!

The bottom image may be a little difficult to see, but it is a series of 6 images making a spark effect for the cherry bomb. Whilst it doesn't have a fuse and does not burn down, the sparks are bright enough and vivid enough to get the message across.

The cherry bomb spawns in a random position with a random rotation, then each 'step' the cherry bomb will spawn in between one and four sparks, again with a random rotation but all start at the tip of the cherry stalk. The sparks themselves check each frame to see if the animation has completed; If it has, it destroys itself.

I realize that making the gumball machine at this point is a bit of an indulgence, so I decided to create a HUD first instead. The game is in need of one and outputting just text to the screen is not good. Even though I managed to get a fancy font working.