I have created a new Health points HUD which I will be turning into a sprite sheet later in the day.
I am now going to try my hand at collision detection. Hopefully this will go well and I can crack on with the gameplay . . .
.... Now an hour later and no further forward regarding collision detection,but I now have my mummy sprite sheet working in the game -
Right on to collision detection, boulder sprite sheet, chamber wall chucks sprite and beyond!!
Another aspect of agiles flexibility is that it offers that security to work on other projects if things are going okay. Such a situation has occurred as I have signed up for a position as windows 8 developer which means i have to create a game before the 4th of February Since the SCRUM and XP methods which I am using to keep development following nicely, offer such a flexibility, I should be able to do both projects concurrently.
17:55
Collision detection didn't work in my game code. But, after creating a unit test it works fine. I'm gonna take a break from this for now.. working on it constantly is not good: XP recognises this aspect of the workforce which again is a positive, and Im sure I'll see the benefits when I return!
Figured out what was happening - The function update was only reacting to the inital collision thus was only moving the player once (not repeatedly as I was expecting)
to deal with this I created Velx and Vely variable which controls the entire movement. Next is the situation of visiblity which I reckon should work just the way it is.
I have decided that the left and right functions will be taken out as the game does not suit the style of game play now that it is a runner game.
When I code the game according to the unit test, I should be able to get the game near completion quite easily.
The programming addenda for the following sprint week is as follows >
*
*
*
*
* Code collision from unit test coding
* Add in the
* Set up the attack functionality
* Make the Hp bar a sprite sheet (should take more than reducing the brightness of some of the beads)
* Create a chamber door exit level sprite
*
* End level sequence
* End game sequence
Tomorrow:
I will be concentrating on the coding of the collision detection and adding in a boulder, bat and spider sprite so that chamber 1 (level one) will be complete. I will then make a chamber door to exit the level and make a point of telling the player he/she is on level 2
Monday:
IF ALL GOES WELL PREVIOUSLY I will be coding a second, third and fourth level of the game. (ie. faster running, more frequent enemies, frequent variety of enemy heights - force attack or force a jump. When these levels are coded I will make an end sequence which will end the game and let the player decide to play again or return to the menu.
Tuesday:
IF ALL GOES WELL PREVIOUSLY I will be working on what to add to the game to enhance what was stated in the specification - to make a successful, fun to play, HTML5 game for the Galaxy tab 2 7.0 - this could entail a boss level, new enemies, gems to collect, a high score etc...
Beyond Tuesday I plan to work strictly on Agile until Friday. But this doesn't mean the end of development for the game -- in fact, the norm is that you will meet errors during these three days that might extend the time of development; or then again perhaps not. I will be working on the game during my next sprint on the 30th of January - since I can afford the time to concentrate on other things that are just as important - and make it functional, memory efficient, highly playable and complete. This sprint may be a 2 week sprint as I can make the game in February also. I need to have the game complete to test at the end of February. 2 weeks before this week (No later than Thursday the 14th of February) I will communicate to folk that I am hosting a play test session and if they could spare 5 minutes to test my game and give me some feedback.
No comments:
Post a Comment