Mobile & Web Games Development Final Assessment, due 29 April 2011
Mobile and web games Development
For | Alistair McMonnies
FINAL ASSESSMENT
Banner ID | B00193816, B00187790, B00186941
1
Mobile & Web Games Development Final Assessment, due 29 April 2011
Table of Contents Overview ............................................................................................................................................................ 3 Comparing to the specification .......................................................................................................................... 4 Challenges .......................................................................................................................................................... 6 Aspects of the game that went well .................................................................................................................. 7 Aspects of the game that didn’t go as well ........................................................................................................ 8 What you would change in V2 of the game ....................................................................................................... 9
2
Mobile & Web Games Development Final Assessment, due 29 April 2011
Overview We aimed to develop a Single player arcade sport game for the casual gamers market in Java ME. Before we created the game, we made our title screen / animation for a java applet. Our idea was for a hurdles game:
‘It’s the 110m Hurdles and you’re trying to get the best time possible to qualify for the Olympics in London 2012. Your training consists of 3 levels - pass them all in a good time and you will qualify’ The game is called Hectic Hurdles 2011 which involves the player performing quick button presses which will make the player run and in order to jump over the hurdles another button is pressed. If the player collides with the hurdle they are slowed down briefly. The players speed is displayed via a speed bar animation. A balance meter is presented to show the players stability while running down the track – If the run button is pressed more than once in the same button presses the balance meter moves in that direction.
Our original idea was to track the time in seconds which it takes the player to reach the finish and display the highscore from time it takes to cross the finish line and having the possibility of taking the sum of the 3 attempts and calculating an average time to qualify for the Olympics. Win Scenario: Players will win if they come first during the race or complete the level within the time limit. Lose Scenario: Players will lose if they do not complete the race within the time limit or are unable to get first place. The player can be disqualified if they run out their lane by losing balance. The games major Influence was “Track and field” (for Nes, Commodore 64, Arcade...) For our assessment 1, we created a java applet version of the introduction screens of our game.
For the title Screen, we created the character – named Percy Beard – to run repeatedly across the screen - from left to right
3
Mobile & Web Games Development Final Assessment, due 29 April 2011
Comparing to the specification What we said would be in the final game
Key presses (rapid presses to make Player run), Balance Meter, Speed Meter, 3 Attempts, Score board to display current, high score & time
Our original Structure Design
4
Mobile & Web Games Development Final Assessment, due 29 April 2011
Our aim was to get a game playable in Java ME following this design. The final game implements the game canvas and player/hurdle classes however, we were unable to get a computer running against Percy thus the Computer Sprite class was not created. Rotation of the hurdle on collision would not rotate the way we required – the solution was to set it invisible and reset its position to allow the game to continue. The balance meter: coding proved difficult and time constraint meant we could not afford to attempt something here. The specification states that only one level needed to be playable, we failed to get our 3 levels however; this was replaced by an option to restart the game at the end for another try.
In the original specification we intended to have a heart sprite that will gauge the speed of the player. Thought the sprite was added to the game, it does not work properly by showing the speed of which the player is running.
Sound effects, we originally planned to have sound when the players jump. But we opted to not add that since we do not conform to anyone’s expectations from a game.
5
Mobile & Web Games Development Final Assessment, due 29 April 2011
Challenges We found a number of challenging elements during the development of our game.
Firstly, we had trouble setting the correct speed for Percy’s run. This value had to allow the run to be smooth enough to handle the key presses of the two run keys while add to the distance travelled value. The rate that the hurdles travelled was also a small problem we faced. We found that keeping the hurdle at the same speed was not helping the game to become a casual game – it took a fair bit of skill to jump the hurdles in this case – so, we decided to change the rate every time a hurdle crashes into the player or goes off-screen. This funnily enough tied in with our game title “Hectic Hurdles” and also gave the player a chance of jumping the hurdles like a real athlete in a fair but challenging manner. (the player would now need to watch their speed in order to clear them instead of running at full speed constantly which is a good thing) Limiting the screen boundary was proving a difficult task as Percy was not behaving well. It was only after a few other parts of coding were implemented that we saw this problem developing. If you were to jump when running up to the boundary, Percy would jump through it and would be lost forever. We eventually got this handled properly by setting a boundary in the section of code which makes Percy jump. Remaking the screens to fit the horizontal emulator orientation (originally designed for a vertical screen) The screens needed to be made into a sprite sheet, and making the text readable – with such small screen to display this - was a challenging task. The Keys intended for use with the mobile were not implemented in the final game. (4 and 6 to run were substituted by the left and right arrow keys). We could not get the Number pad numbers to be recognised on pressing them, so we eventually settled for the use of arrow keys to navigate menus and play the game with.
6
Mobile & Web Games Development Final Assessment, due 29 April 2011
Aspects of the game that went well The overall outcome of the gameplay met our expectations.
Our team performed well getting sections of the game completed on a weekly basis - Team working worked very well on this particular project
We organised our resources online using a wikispace to centrally store all versions of our coding and images/documents. With version control being implemented, it was easy for us to work on separate sections of the code at home and group the parts together. We would meet online and share ideas/code regularly and attempt to get as much done as possible during the lab sessions.
Similarly, the design of our game code came together nicely which gave us a playable game we hoped to end up with. The artwork was also a feature of our game we thought went well – it brought out the games retro feel.
Thinking about how we were going to create the game before hand was a big benefit when we started coding in Java ME. We eventually made our Game Title Screens into a sprite sheet which went well and saved more memory getting used up for storing more images.
The important aspects of the players attributes such as running and jumping and colliding with other sprites generally worked well – even though we were unable to get the hurdle falling over.
The Players main features were implemented effectively. The player can increase their speed according to key presses and also jump over the hurdles (working collision rectangles to check for collision). The planning for this helped us code these properties properly.
Introduction screen was cleaned up from our applet version ( toned down transparent menu)
The images were updated with appropriate keys to be pressed and made clearer for the mobile devices screen.
7
Mobile & Web Games Development Final Assessment, due 29 April 2011
Aspects of the game that didn’t go as well The Missing features that we failed to implement due to either time constraints or coding problems/errors
Initially we planned to have a computer player to compete against players but due to the lack of time it wasn't added
Unable to implement the number keys of the phone to control the player / navigate the menu
The balance meter was not included due to the time constraint – idea was there but not fully coded and was left out of the final game
The hurdle would not function like we desired when it collided with Percy.
The Method of scoring was altered somewhat, due to the way we coded the game (ie instead of having the 3 attempts to beat the clock/score) At the same time we had not though deep enough about exactly how we would code this feature.
8
Mobile & Web Games Development Final Assessment, due 29 April 2011
What you would change in V2 of the game In regards to planning the next iteration of “Hectic Hurdles� our first objective would most like be to implement features that were supposed to be in the first game but didn't make it. The features that to be considered would be the balance meter, a CPU opponent to race against, proper implementation of the speed monitor and more tracks to race on with increasing difficulty.
A fully working balance meter is a much desired feature to the game as it would require the player to carefully time their arrow key presses to keep on track and not stray off course which would result in a disqualification, ending Percy's dreams. This means that the player will have to consider their timing when running rather than mashing the arrow keys to go faster, which itself is not a good idea since it will give the user a tougher time to jump over the hurdles. All in all, simple implementation of the balance meter gives the user a little bit more of a learning curve and requires a bit more thought without making the game too difficult.
A CPU is also a very important as it gives the player a clear objective, where the player needs to come first place to progress. We could allow the player to choose the difficulty of the CPU they're up against at the menu or have the CPU increase in difficulty as the player progresses to the next track. Ideally it would be best to include both features with CPU getting increasingly more difficult while sticking to the chosen difficulty level (e.g. the difficulty of track 3 on easy will be the same as track 1 on hard.) Giving the speed monitor more functionality could add some interesting features to the gameplay. For example the player may need to keep an eye on it so as to avoid expending too much stamina which will cause the player to run slower in the long term. Again it would fulfil a similar goal to that of the balance meter, to get the player to think a little more about what they're doing rather than mashing the buttons to go forward.
Adding more tracks to the game is must, to make the game last longer. As the player progresses to the next stage, things will get more difficult (with the conditions of the course as well as the CPU) as the frequency of hurdles and the speed at which they come on screen will increase. They may also come on screen at random intervals rather than at the same frequency, which players would eventually get used to. We would change the approach we had if we were to create another Java ME game. Before coding the game the group would write pseudo code for the game. This will give a better idea on what we would need to add in the coding stages as well as giving a clear indication of how it could be done. It will allow us to work faster, since there would be a guideline, instead of figuring it on the spot.
Throughout the programming stages of the game code became more difficult to read due to the addition of new features as well as keeping code that was not in use. Taking away code that doesn’t do anything or is not in use will give the group less code to look through as well as not being confused by its purpose. To help the group understand the code better and help ease of finding what each section of code does comments will need to be added.
9