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.

Character Creation

Meet Quentin, a goofy-cute dog-boy with a sweet tooth and a sit-down drill!



Quentin is the first (hopefully of many) characters that will be controlled whilst playing Sugar Mine. The above image is a sprite sheet, only the drill bit is animated at the moment. I want to get all the basic visual elements up to a standard before I go wild with extra details.

Time permitting I would have Quentin lean from side to side when the player turns, have his tongue flap about and show little animations of joy or despair when he collects a pickup or the game ends.

Before then though, Quentin is in the game and working out just fine. His little drill turns and he functions just like the arrow in previous videos. He's still a little small but the original sprites are 128x128 each so he can be scaled up at any point if he needs to be more visible.

Thoughts on this: Creating this in Illustrator, each element is kept separate. Which is incredibly fortuitous because if I had created this in Photoshop I would have to separate each element myself (which I know I would fail to do at some point) creating more work.

I bring this up because the creation of new characters and the creation of new drills can be simplified with this in mind. If I wanted to swap Quentin out and replace him with somebody new, I do not need to recreate the drill and the drill animation. I can simply redraw the character.

Better still, I may be able to combine the two in the game engine itself, allowing for even more customization and potential game play choices. I can have the player control two separate entities (character and drill) and with clever placement of centers of rotation and depth I can make it look like one character. This will not only allow a player to combine characters and drills for different visuals but I can also animate both the character and drill independently of each other.

This will be fun and interesting when I get to it.

Before then however I will be creating pickups (coins) and a prize-gumball machine to put the coins in and try to win a reward. I feel that this will provide another layer of reward for the player and encourage a greed-safety choice in the player, whether to avoid obstacles or grab more coins!

For those of you who may not know what I'm talking about, these are gumball machines. Larger version exist that hold small capsules that contain toys, sweets, temporary tattoos and the like. Thanks to http://en.wikipedia.org/wiki/File:Gumball_machines_Dallas_2008.jpg for the image.

First Menu

The first screen of the menu is in and working. The only function in it so far is to go to the game and the exit the game, but I have built what I hope is a framework I can apply to the other menu screens to make their creation faster and easier.



My goal at this point is to work on the visuals of the main game itself. First is a suitable character for the player to control, then I will work on putting in a decent visual for obstacles, then expand upon the game a little: Adding coins to pickup and a prize gumball machine to put the coins in and win some prizes.

Report and Visual Creation

I have been creating visuals for the menu system of Sugar Mine, I want the menu to look good as it will be the first impression made by the game. Below is an image of my progress so far. The background is a placeholder and will change.

Thanks to Diana Toma for her tutorial on the chocolate text (http://vector.tutsplus.com/tutorials/tools-tips/quick-tip-how-to-create-a-delicious-chocolate-text-effect/) and thanks to Tyler Denis for his tutorial on the Candy Cane pattern (http://designinstruct.com/graphic-design/text-effects/candy-cane-text-effect-using-illustrator-and-photoshop/).

I have also started to write the report on Sugar Mine. It currently only features the research, first implementation and testing of Sugar Mine but will be expanded upon as the project progresses.

Another Change

In attempting to prototype Tied, I ran into a problem that have made the project thoroughly nonviable: creation of a chain, or tying two players together requires knowledge of rigid-body physics and joint constraints and how to program these in. This I could not do in time.

First I attempted to find other solutions to the problem. I discovered that Game Maker allows for the inclusion of Dynamic Link Libraries (DLLs) to enhance functionality of the engine. If I could find someone who had programmed the joint constraints and rigid body functionality I needed, I could move forward.

Unfortunately I found no such viable option. With the engine being in a near constant state of flux and updating, most DLL's were outdated, incompatible with my version or both. Any that were both up-to-date, in the same version of Game Maker as me and functional, did not offer the function I required.

Next I tried to program in such function myself and learn how this effect could be achieved. I learned about physics sockets, joints and joint restraints, motors, axles and rigid bodies. Another problem occurred within the engine itself which I could not remedy: Implementation of real-time physics, using the in-built Game Maker physics engine functions differently than the standard Game Maker world.

This means that positioning things manually in Game Maker (i.e. incrementing the X location of an object to have it move to the right.) is impossible. In order to have an object move, there must be a defined force acting upon it.

So I learned about the use and application of forces. I learned how to use local forces to move objects, this caused another issue: Local forces applied to individual objects affect other touching objects.

This was the final point at which I admitted defeat. I could not solve this. Normally this would not be an issue in a platformer, most objects that exist in the world are either solid and immobile, move only on a fixed path or do not interact with the avatar.

However because I had two characters in the game, it would be impossible for one to act in the vicinity of the other without interference. For example: If one character was on top of the other and tried to jump, the character below would be shifted first, causing the jumping character to jump off at an unpredictable angle.

This was not acceptable and I could not find a solution. I had to change my project to produce something more viable without wasting any more time.

So here is my new project: Sugar Mine.


Sugar Mine is a one-player running game, created in Game Maker Studio. In it the player controls a large drill, boring its way through the ground in a fictional land of candy. The player must avoid hard candies as they will damage the drill and stop the player from progressing

Sugar Mine is influenced by games such as Jetpack Joyride and Robot Unicorn attack. Sugar Mine is intended for mobile platforms, but can be played just as easily on a PC.

Currently Sugar Mine is still partially functioning. There exists a player, obstacles and a termination condition for the game. I am currently creating visuals for the core gameplay and shell gameplay (the menu system).

I intend to implement a set of accessibility controls, such as in-depth gameplay customization and a high visibility mode.