This week I’ve worked on randomly generating the colour, target shape and improving certain bits of the code. On Thursday I met with Ryan, Tom and Lucy to show the current state of the game. The mechanics are slowly being implemented. Currently the player is able to aim and fire a random coloured X which snaps to the closest available position in a grid. There is a random target shape to make and when swiping the Xs the system recognises what shape has been made. Unfortunately I haven’t got it to a stage where the swiped X’s are removed and the ones below move up. I’ve tried to jump ahead this week, that task is actually due next week but I wanted to get it done this week so I could get the game in a loop because the player cant progress without X’s being removed but unfortunately this hasn’t worked out well. I’ve been having problems with it and its been quite frustrating, so I’m going to see if Chris can spot something that I’m missing or forgetting to do.
But the team really likes the prototype and are very happy with the progress so far. I think everyone has a clearer image of how the game will look thanks to everything being brought together now such as the cannon designs, colour pallete, game flow, art style, design doc and the prototype starting to react to user inputs.
One of the things I wanted to highlight was the change of one of the controls with the cannon now being able to move instead of rotate. I showed both examples so they could feel the difference and they agreed it was easier to aim. I also got some opinions from the kids at Creative Computing Club who also agreed on the preferred aiming method. Some comments were:
- Couldn’t see the next coloured X very well
- Shapes are not clearly displayed, only as lines
- Cannon doesn’t move fast enough
- Don’t know when the cannon fires
Obviously a lot of the game components are just place holders which I explained but I also got some interesting comments. Not knowing when the cannon fires was one, its slightly concerning because the steady rate of fire is a big component in the game and if players don’t like that then I need to find a way to indicate a moment or two before when the cannon is about to shoot. Finding the correct starting speed of the cannon is important, I don’t want it to be really slow but at the same time I don’t want it to be too quick leaving little room for it to be upgraded.
I’m slacking a bit on my research. I’m finding it hard balancing research and comms with development time. I’m going to be restructuring my timeline in accordance with this. My main focus is to get the MVP complete before Christmas and presenting it to The Mix and be in a position where I’m happy to continue and start thinking about deeper decisions about the game in the new year.
Overall I’m feeling slightly worried the main reason being the coding issue, I feel the game is at a stand still until this is sorted which I don’t like, so this is what I’m going to focus on.
The comments for my proposal were generally very good however there are some key areas were I need to improve. I don’t allow myself enough time to proof read my writing causing me to miss-spell words and occasionally make little sense which causes me to misrepresent my thoughts and conclusions. I need to make sure I read through my work and make sure the reader understands what I’m trying to say. The best way to do this is to get someone else to proof read what I’ve written which from now on I’ll be doing, which shouldn’t effect too much of my time. I’ll also be following some interesting advice about introducing elements too quickly. I wrote that I will be avoiding it but its not necessary a bad thing its just the game and the elements need to be paced precisely so the player is hooked. How I Shepard the player through the mechanics is the difficult part, making it easy to learn and paced in a way so the player is constantly succeeding instead of of being overwhelmed and failing when they first play. Its something which I’ll need to take seriously if I want this game to be a success, putting the research that I’m doing in to practice.
The main improvement that’s needed for the dissertation is regarding my marking criteria, its too ‘diffused’ and needs to be condensed focused on the specifics of what I want to achieve. On Wednesday I had a meeting with Dave, the main purpose to go through marking criteria. Some of the bullet points I made were unnecessary that’s specifically on Game Design and would be expected of me anyway such as
- How enjoyable the game is that takes into consideration of it being a simple game with a few but refined mechanics.
- Refining the controls so that they are easy to use and creates a fun action for the target audience to play with.
- How well the game matches the target audience.
These are things that I need to achieve regardless.
What I need to focus on is the purpose of the game which is to create awareness for The Mix. Keeping this in mind what’s critical is, how I’ve negotiated with The Mix, the understanding of what they do, their brand image and applying all that to the game I’m creating that targets their audience which influences a positive feeling towards the organisation. I’m also spending a lot of my time programming which I think needs to be looked at so I’m going to be setting a meeting up with Chris to see where I can go from there. I feel a bit less confident about it because I don’t get to go to his scripting lessons and I know their must be better ways of coding certain things that I’m unaware of which would effect my mark if I don’t apply it.
I’ll be re-writing my marking criteria after these meetings once I’ve got a better understanding.
I also showed Dave Sam’s work. He liked it, but pointed out a few problems such as it didn’t show the title of the game and colours feel really cold. I think the actual task has been a really good success but it probably isn’t wise to decide on anything just yet. What I’ll be doing next is asking for a couple of designs with the same layout but using different combinations of colours so we can visualise a range of different styles. Dave also wanted to know why a cannon? Its a hard one to answer, especially if you haven’t got a reason. If I’m honest it was chosen because it fulfilled a purpose which was to fire an X to a location and it made the player aim. But Dave pointed out that anything can aim, it doesn’t have to be a cannon. I see his point, the cannon has no relation to The Mix what so ever but I also don’t want to add something that is silly and which a player would question the use of. This somewhat boils down to the narrative behind the game which we were also talking about, at the moment the game has none, which also goes against one of the 8 core drive I’m following, ‘Epic meaning and calling’. The player wont feel like they’re fighting for something or that there’s not a greater purpose. This is something that is very difficult to answer which I wont be doing today. Its something I’m going to be thinking about for a good month. Its difficult because whatever it is needs to relate to The Mix in a positive way.
Overall the meeting was good and I’ve come away thinking about the game more deeply and that I need to encompass something else that the player can attach to so they don’t just play the game and feel without a loss if they toss it away.
A few days ago Sam emailed me some work that I asked him to do which you can see here.
I asked him to create a mock up of the game layout and main menu working off previous designs and the new assets that have been made with the decided colour scheme. He’s done an excellent job of producing this pdf showing the sleek design and art style and also positioning relevant information for the player to know. I’m meeting with him on Monday to discuss it with him, what’s good and what needs to be improved.
This week has been a bit of a rush to get things done. This is mainly because of a few design issues and the massive task of recognising the shapes being swiped which has taken all day.
I’ve managed to code the grid system which works off one point and a gap length so it only takes two seconds to change the whole size of the grid. Its made in a way so I’m only looping through 5 cells to check whether the X is in a close proximity and then it snaps to it. Because I’m using AddForce() to fire the X out of the cannon I don’t actually use a speed variable which I do need when I’m using MoveTowards() so I calculated the magnitude of the velocity from the rigidbody2D to get the speed which I can use on the method so its a smoother snap.
The task which has taken the longest by far is the shape recognition. Here are the steps it takes
- Checks when first X is touched
- Checks if its correct colour
- It then does one Raycast at a specific moment to find the next X – checks the distance between the last x position and finger position is between a value thats close to the gap between X’s. However it needs to make sure that its not going diagonal because it will fire a raycast at nothing so I need to make sure that the finger position is between the width OR height along the axis.
- Once the Second X has been touched it then starts to record the direction combination. It does this by comparing columns and rows.
- Once the number of X’s touched equals the target shape combination length it then compares all of the combinations with the recorded combinations
This has taken a very long time to achieve but its working very well and I believe its fairly optimised.
I havn’t been able to do any research this week which is unfortunate but I am on track with development. I’ve got a lot of improvements to make however and sorting them design issues out. I think I’m about 1 day off target at the moment but next week I’ve got some simple tasks of randomly generating the shape to make and the colour so hopefully I can gain some time. I want to do it early anyway because I’ll need that bit working for Thursday when I show it at The Mix.
I’ve come across a problem with the relation between the angle of the cannon and the outer columns. When the middle columns get too long, the way the X snaps to an available space prevents a clear shot on these outer columns. This means that there needs to be a different way of aiming the cannon.
I’m suggesting the obvious solution to enable the cannon to move left and right on the X axis to get to these outer columns. The player is still aiming the cannon and from initial play testing it feels a lot easier. This will effect the flick input to shoot faster as the player cant now shoot and aim at the same time, they have to move the cannon and then shoot. The rhythm I’m trying to achieve will not be affected in this.
From play testing its given me fresh ideas on how to upgrade the cannon by increasing its movement speed especially on the first minute of game play will feel really rewarding. I can also design it so the players finger doesn’t have to be on the cannon but instead somewhere along the same axis and the cannon moves towards it reducing the effects of the player not being able to shoot and aim at once.
I’ve let the team know and we’ll be discussing it more in detail next week where I hope to also get some feedback from the kids at Creative Computing Club.
At this stage of development I’m going to be using four shapes.
- ‘L’ Shape
- ‘Z’ shape
The first 3 require two columns but the line shape only needs one. I see the line shape as one which the player looks forward to seeing to remove X’s from a near complete column. I remember in Tetris that this shape was always good for removing many blocks and saving you from failing. I think four is a good number to start with and will be one of the questions I’ll be raising for feedback to see if that’s enough. Any other shape will require more X’s so this will need much play testing when it comes to it.
I have decided to allow the possibility of swiping the shape in its mirrored form. For example swiping a backward L can be accepted for an L shape objective. After some discussion from colleagues at Uni and some other people, most suggested it was slightly unfair that I was not going to allow this. It would also require more information for the player to know straight away and if they didn’t know they would be left confused as to why it wasn’t working.
The way I’m going to code this is to calculate the previous X that was touched and the current X that is being touched and finding the direction between them being either “left”, “right”, “up”, or “down”. Each shape would have every possibility in the way it can be drawn coded into a multi-dimensional string array.
After the last touched X for the shape to be swiped, I’ll compare the the actual swipe combination with the possible swipe combinations and if one has every combination correct then it will return true. As there is a target shape I wont need to run a for loop on all the shapes but just the correct index for the target shape.
Working out the combinations has been mind boggling especially with the L shape. Not only can they be drawn from 4 different orientations but also mirrored as well as swiping them from 2 different starting points.
I believe I’ve written them down all correctly or else I’ll be pulling my hair out from all the bug fixing I’ll be having to do.
On Monday I had a meeting at The Mix with Samuel who is in his 10th year of Education. He was recommended to me by The Mix because of his previous awesome work that he did in one of the workshops he attends. He has some skills in Photoshop, Illustrator and has done some work on creating boards. He showed me his game he made in Scratch and also his webpage he coded in HTML. Its some excellent work that he’s done and he’s only in year 10!
I’m getting him involved with the art style and theme. I’m first setting him a few challenges of creating a mood board for the game screen layout and laying out the Main Menu. I’ve given him lots of information on what to do and he knows how to contact me if he gets stuck.
Its really awesome to have him on board, he’s really eager to help and he’ll play a key part in play testing the game.