Development Week 7

This week I’ve been working on a few improvements. The main one being improving the swipe recognition. How I was doing it before was I was being too strict on certain conditions, mainly to do with preventing it from ray casting so often, so I’ve reduced the number of checks and instead worked out the correct conditions after I’ve done a raycast.

Here is what I’ve worked on this week:

  • Added a background behind each X and changed its colour
  • Increased the Cannons move speed
  • Commented code
  • Added elastic easing to the X snapping to a Cell
  • Added bounce easing to the X’s which get moved up
  • Started experimenting with the line renderer.


On Monday I’m presenting the game to the Mix and will be discussing new ideas and the next steps involved with development.


Meeting with Rob and Dave

This week I had a chat with Rob and Dave to give them an update on the game and to get some feedback from them before leaving for Christmas.

I have many ideas with how the game will play after a certain amount of time playing but one thing Dave suggested was not to be concerned about that just yet but focus on how the game plays now to capture the players attention for them to want to play more. I’m at a good position where I’ve got the core mechanics working, its now the case of improving what I’ve got. Some comments were

  • Speed up the cannon – Its too slow and everyone keeps using it wrong, they forget that it snaps to your finger and instead they keep swiping it, which has little effect that way.
  • Remove the negative space, add a background around the X’s
  • The player should be able to choose what X’s get removed with the bomb.
  • The next shape should be clearer.
  • Swiping X’s should be intuitive and provide feedback.

This is what I’m going to be working on next week and then I’ll evaluate how I’ve got on and then begin another round of improvements.

I spoke to Rob about how I’m finding it difficult to bring in a higher purpose, some player motivation through visual narrative because of the type of game and what it’s being made for. He said it needs a bit of personality, it looks really static on the screen, there’s not much going on and told me I should play the game Snood to get some ideas.

Snood is a game where you need to match 3 or more faces by firing a face through a cannon. Its Unique because of the different faces and their expressions that they make. If a face is fired next to one which isn’t the same then it usually frowns, or if it is the same then it will smile. It just makes it that more enjoyable to play and there’s more things moving on the screen because you can see them twitch and blink.

Its made me think how I can put something like this in the game by making the Xs become more human by moving them using the X as arms and legs. It all comes down to how well they can be animated but I can imagine them fidgeting and making noises when they get fired out of the cannon. This is something I will be experimenting with after Christmas.



Development Week 6

This week I’ve been improving player controls, adding the necessary limitations and the bomb to help clear the board. Here is a list of what I’ve done.

  • Moved the next shape and next X to the top of the screen
  • Prevented the cannon being moved so far horizontally
  • Player can touch anywhere on the bottom 3rd of the screen and 30 pixels high and the cannon will move to their finger instead of having to hold the cannon to move it.
  • Applied the Cannon and X artwork
  • Coded the bomb
  • Fixed bugs relating to X’s orientation (wasn’t noticed before because I was using a square X)


The bomb can be activated every 60 seconds. It fires out and can remove a maximum of 8 X’s, Think of a grid of 9 spaces, if it touches an X in the centre one it removes them all. This needs a good amount of play testing and feedback so that it can be balanced correctly.

I haven’t been able to complete my balancing tasks this week so they’ll be completed next week which works out well because I need to keep testing the bomb functionality and how it effects the need for the number of columns.

Over the week I’ve thought of some ideas which I’m noting down. Instead of spending points to upgrade your cannon, it will upgrade automatically as a reward. The points you can accumulate can be spent on power ups.

Power Up Ideas

  • Swipe 2 Xs to swap them
  • Fire a special X and when used in a swipe, all X’s of that colour get removed and the player is rewarded with more points.
  • Fire a special X which can be used with any colour

I played a game the other day and I only had a few spaces left, I was firing the X at all the best available spaces but the colour was just not the one I needed. I think it would be good if when the available spaces are less than 10 the colours stopped shooting out randomly but had a higher probability that it would shoot the colour you wanted.

Next week is going to be a big push to get unfinished tasks complete and to get ready for the presentation of the MVP on Thursday.

Meeting with Ryan

I met with Ryan on Thursday so we can start thinking about sounds. I had a few ideas for certain sound effects from other games I’ve played.

I thought a good starting point is to come up with sounds for the swiping shapes, cannon firing, theme music and buttons.

I like the way the Dots game plays different tones when you swipe the dots and I can imagine it working well for this. The number of Xs you swipe is between 4-5 and I remember there being a nice theme tune that was made for the mix a while back and as we know how how many Xs will be swiped something along side that could be made.

I also mentioned how a lot of games use a hit and release tone. I showed him Clash of Clans, when you touch something to highlight it, like a button, its got a double sound that acts like a hit and release to enhance the feedback that its been pressed, so something like this would work well with buttons.

We’re going to be meeting again after the 5th of January to see what he’s come up with.

Mobile UI Design

I’ve been reading ‘Professional Mobile Application Development by Mcwherter and Gowell. The book explains the problems when designing User Interfaces and provides best practices to use. Its nots specifically on games but rather all content designed for mobile such as apps and web content. I’m keeping to a specific chapter called ‘Mobile User Interface Design’ and I’ll be pulling content that I think is relevant to my project and how its going to influence my design choices.

The chapter begins by defining the limitations of mobile such as speed, bandwidth but most of all screen size and is good practice in making effective use of screen real estate. Where designers fail is trying to provide limitless information which increases the users cognitive load (mental effort and memory) whilst also diverting the attention else where with the need to navigate and re-find original content. I can begin to see this happening in shapeThemix. dev4

Currently the shapes and next X is located at the bottom of the screen and from playing it and receiving feedback it starts to get slightly annoying because your thumb is hovering over the next shape so you have to keeping moving your thumb out of the way to re-find the shape. It would be much better to have these located at the top of the screen where the player will already be looking when scanning the X’s on the grid. Another problem is the fact you have to touch the cannon to move it requiring you to look at the cannon to re-find it. It would be much better to touch anywhere on that 3rd of the screen and the cannon will snap to your finger.

The book encourages you to limit the features available on the screen, which I’ve tried to keep to from the beginning. At the moment there are very few distractions. “Help uses fight cognitive distractions with a clear information hierarchy” (McWherter, J. and Gowell, S, p90) . I need to make a clear visual hierarchy for the most important components in the game being the arrangement of Xs, the next X coming out of the cannon, the cannon itself and the target shape. The main colour on the screen is from the grid of Xs so its already holding the main focal area. “Users will be drawn to larger items, more intense colours, or elements that are called out with bullets or arrows; people tend to scan more quickly through lighter colour contrast , less-intense shades, smaller items, and text heavy paragraphs” (McWherter, J. and Gowell, S, p90) . The next X is the next important object and will need something else to attract its attention. I like the idea of displaying text saying ‘Next colour’ and in a font that’s bold and really stands out and then using an animation on the X when it changes. The cannon will be the largest object in the game and will be interacted with the most. It will also be on a groove which will act like a track that the cannon will roll along so it should be fairly noticeable to the player.

The book goes over the gestalt principles and things to keep in mind when making icons or leading the player towards something.

  • Proximity – When objects are grouped together they are viewed as one.
  • Closure – When enough of a shape is drawn the player can fill in the gaps preventing the player becoming over loaded with too much detail.
  • Continuity – Users are compelled to follow one object to another because their focus will travel in the direction they are already looking at.
  • Figure and Ground – There needs to be enough to distinguish the object from the background.
  • Similarity – dissimilar objects become emphasized

Using these rules will help reduce player confusion.

The main message I’m getting is to start with a minimalistic approach and to get that right first before I start adding more and more objects to the game. The objects I am still unsure about are where the menu, upgrades and the score will all be displayed, but I must prioritise my visual hierarchy and to get that right first before deciding on these locations.

McWherter, J. and Gowell, S (2009) ‘Mobile User Interface Design’, in McWherter, J. and Gowell, S (ed.) Professional Mobile Application Development. New Jersey: John Wiley & Sons, pp. 89-116.

Development Week 5

This week I fixed the major issue I was having with the code which removed the swiped X’s and move the ones below into an available space which I’m very happy about. I’ve also made a counter which logs how many shapes you’ve made and stores points. Lastly I’ve coded the fail event. This was tricky at first but I used a simpler method by increasing the row count by one so when the 8th row gets hit by an X an event is then triggered which causes everything to stop and where I’ll be displaying a new screen showing the score and other important undecided stuff.

The game is now working as a whole, the player can sit there and swipe away X’s like I did for 20 minutes in one go without failing! I’ve had comments from kids at CCC that its a game which they would play if they were bored or wasn’t busy doing anything which was good to hear.

There are some improvements that need to be made with the current system:

  • Cannon needs to stop moving beyond a certain point where the grid ends
  • X’s need to be placed on the grid from the beginning to reduce the sluggishness
  • Swiping X’s need to be less precise
  • Feedback is needed when your continually swiping X’s so the player knows the they’ve just swiped over an X.

The improvements are being logged and will be fitted in with the iterations I’ll be doing further in the project.

I’m slightly off target but have re-evaluated my timeline in accordance with this. If you go to my Project page you can visit links to different areas of the project.

I’ve got 2-3 weeks before I have to present the MVP to the people at The Mix. I’m going to be focusing on adding the assets, coding the bomb and balancing a few elements of the game. Overall I’m still on track with development tasks and in 2 weeks I’ll be in a good position to start thinking of usability, rewards, upgrades and player progression as well as catching up with a few unfinished tasks.

Meeting with Chris

On Wednesday I met with Chris to see if he could help me with a few problems I was having and to also go through my marking criteria.

I was having trouble with part of the code which removed the X’s and moved the ones below into an available space. There is a number of different steps involved.

  • Find the column for each swiped X and add to a list
  • Remove Duplicates
  • Run a for loop for each column
  • Push each cell that’s in use in the column into an array
  • Record the row value of each swiped X and store the lowest and highest
  • Then count how many in the specific column that got swiped
  • From this you can work out how many rows the X’s below need to move up.
  • Next check if there are any X’s that have not been swiped but are underneath the X’s that have been swiped.
  • Move them up and remove the swiped ones.
  • Re-calculate the available spaces for the next fired X to snap to.

Chris managed to help me out. There were were actually two problems. One was that the some values weren’t being changed in time and another I wasn’t checking with one of the for loops which held the swiped X’s to see if that X was in the column. So it would be resetting values again when it was doing the second or third column.

This has been a big hurdle and has effected my timeline but I am glad it has now been fixed and I should be able to gain some time back in the next 3-4 weeks.

I also spoke to Chris about my marking criteria, there were a few things on there which didn’t really make sense and would be difficult to mark. So from this we decided on me being marked on two things. Keeping the code neat and tidy and well commented and also what I’ve done or used certain techniques to keep within a frame rate benchmark that works well for mobile devices.