Wednesday 13 February 2013

Near end sprint reflection



This graph depicts the previous 18 days which include 4 days of sprint 4 and the rest of sprint 5.

It is clear from the graph the declining days of work remaining. The backlog of tasks have been gradually ticked off the to-do-list - despite some features being added during the sprints (see day 6/7)

I have slack already built into my system here - if the last 5 days don't go according to plan. Another 7 days with potentially 126 hours to work on before the playtest day/week.


Saturday 9 February 2013

Status report



As expected, things are going well due to well thought out design and ensuring the more work done means less to do later on - this philosophy in Agile has been precisely correct.

Simplicity - the art of reduce the amount of work not done is essential.
This famous saying on simplicity of design comes from Antione de Saint-Exupery: 
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away"

This entails a few factors of agile software development which I have come to view as "the important one" if you are to truely integrate agile: it means the staff should be enthusiastic, conscientious, ambitious and amicable: It means that the staff should be a team. XP and SCRUM highlight the importance of these traits. Simplicity of the development is crucial - especially when you are planning in short iterations. Keeping things obvious yet not too basic is what aids the continuity of the overall project to everyone involved.

Simple organisation, simple communication and simple design elements - refining processes that work, and expanding on failed processes - ensuring they do not disrupt the development again during the project by reflecting and evaluating the people (ie. Me) and anyone else involved.




Although I still haven't finished: still plenty to do but it is achievable  I have now got enough time to reflect, evaluate and make it better before testing the game.



Still to accomplish these features >
* Code levels logic (chamber 2 and 3 (4)(5)) - speed of bg scroll, enemies and objects, spacing etc
    - door reset, chamber text setup, reseting varaibles for the next chamber
* Coding logic for back to menu and next chamber next button logic for 2,3(,4,5)
    - button press logic
* Get the sound looping
* improve imagery quality
* see if I can re-fractor anything - a final clean up at the end 

Friday 8 February 2013

Friday development



I decided to improve on the design of the end game sequence first before starting anything today - merely because I was in the creative art mood. That's a particular aspect of working singularly in an agile framework: while agile encourages knowledge sharing and working together with each others skills, in a single team it is up to the person to choose what is the next ingredient to add to the project - priority tasks obviously take place first of course, but the flexibility actually does empower the workforce (me).


I also meant to record on the blog that  few weeks ago I searched for some free web edit tool for art (similar to photoshop or aftereffects, both of which I am familiar) I found this site Pixlr. http://pixlr.com/express/ It has served my art well as it has added what I think as the spice that I promised in my original spec - to provide a richly detailed, vibrant game that is visually pleasing. In a traditional linear approach, getting new software onboard would be troublesome: yet another benefit of agile.



> Good lot of coding done in the space of an hour or so. The code is a variation of another part of the coding I have already done so it should work alright. Now, to test it!





Still to accomplish these features >
* Code levels logic - speed of bg scroll, enemies and objects, spacing etc
* put in end door for chamber finish
* Coding logic for back to menu and next chamber next button logic
* Tidy up 





19:10
' The functions for blue and red magic are now working! Now to set the exit door for the end of chamber 1, set up the well done screen then code the level logic for a next level 


Thursday 7 February 2013

Sprint to the finish



Well, the dev has started with a refresher on what has happened. I know that if I put my mind to coding full out this week I can finish the game. I have already got most features built into the game ad unit tests have proven that its just a matter of producing the correct logic to integrate into the game itself.

The final screen layout has been made






















>I have identified a bug with the jump and attack - pressing both make the player lock onto its attack sprite which means the player cannot jump. More on this later....

I am now working on the blue/red magic attack and the glow when the player presses the correct blocker button. I will then fix the jump attack freeze bug. Next, the ordering of the enemies. Then level end with buttons for next or back. And finally speeds for next levels and fin screen



18:55

Bug fixed. I had put an extra check for a jump when the attack function is clicked which isn't needed.

21:11

Got the game replaying when the players health is lost! The back to menu function will take a bit of though for the design of the code which I will do tomorrow but it is possible!

Next is for coding an actual level and having the door that opens to the next chamber present in the gameplay. .. .. . ..









Tuesday 5 February 2013

More work on the game



Still to accomplish these features >
Code hp collision logic (simple variable)
* Create tutorial screen for playing the game
Create sound 
End game sequence
* and add sound?
* Code the red/blue magic attack 
* Code levels logic - speed of bg scroll, enemies and objects, spacing etc
* Code end game (with skip and next button code)


Tutorial screen



I had a few problems the sound when I tried it on the tablet. It would not work. The browser failed to load the game a number of times which was worrying. 

I decided that risks should be assessed again. I have got over a week to get it done. More than enough time tonight to resolve the issue (what ever it would be) so I pressed on.
I decided to create a version without the sound code. It didn't work. I then assessed if the host site dropbox may have been down for maintenance but it wasn't. The code utualises the hmtl5 sound player which my have been unable to be processed quickly enough.

I then put a version on the actual device which works. Since giving it a bit of time to sync with dropbox, I tried it again and it worked on the browser with the sound. Dropbox has done this a couple of times when heavy code is saved to it. I believe that this is all that was wrong as it works fine now.


> Good design prompted even good code design - I was able to eliminate a section of code which was duplication.


Sunday 3 February 2013

Development



Experiencing a slight problem, I have successfully coded the hp logic which means when any one of the enemies touch the player his hp will run down one at a time (changed from the unit test code)

But the end game scene will not load - I donno what is wrong. Luckily, the planning agile allow for has reduced the level of stress that it would put an entire team under in a traditional software development - ie following the ad hoc or waterfall methods. But I still have not got any further with the problem.





## Resolved the screen image problem. I was trying to eliminate the scene which was tieing up the entire program. I changed the logic to visibility of nodes and it now works fine. Hopefully I will be able to get the screen sized properly now and I can tick that part off for todays development.

















Still to accomplish these features >
* Code hp collision logic (simple variable)
* Code levels logic
* Create tutorial screen for playing the game
* Collect Flesh of the gods
Create sound and add sound?
* End game sequence

Friday 1 February 2013

More Development



I have identified a few aspects of the previous sprints which should make the final one easier to follow.




Took a photo of crc card development I done at the beginning of development.
some details changed since then.


Thursday 31 January 2013

The final sprint



The next sprint (which should be the final one) will take place this weekend and end in 2 weeks
(if anything should go wrong (which is dang well shouldn't) I could still get the results by adding on another development week before the presentations begin in order to gather the results)
  • Start 3rd - Ending 17th 
  • Communication of playtest 10th
  • Printing off specification forms (next week)
  • Playtest week (18th - 22nd)


Still to accomplish these features >
* Code hp collision logic (simple variable)
* Code levels logic
* Create tutorial screen for playing the game
* Collect Flesh of the gods
Create sound and add sound?
* End game sequence


Project review


I decided it would now be best to review the project since the sprint has now ended.


I reckon that the programming this current sprint has boosted it greatly from what it was before.
Problems that were permanently issues or persisted upon themselves were resolved and plans put in place for the next "game". Agile is working well.The mix of SCRUM, XP, APM and considering DSDM/FDD is
getting things done efficiently, tolerably and with fineness.


I have documented what has happened with this sprint. Time is an important factor but making sure you are able to do the work is of more importance. This can only be achieve by 'good short term thinking/planning'. In the APM book by Jim Highsmith he states that:


Responding to change over following a plan. This statement reflects the agile viewpoint characterized further by:
·         Envision – explore versus plan-Do
·         Exploration versus production
·         Adapting versus anticipating” 

This in a sense reflects what XP inspires developers to be like when creating software. Risk taking to achieve a goal while knowing what can be done due to the flexibility and short term thinking of the entire project.


Tuesday 29 January 2013

New features and design


Incremental design is working well. Testing here.. adding there: it seems to be getting the work done rather fast and the results are showing positive outcomes of what I have achieved thus far. This can only be a benifit of the agile framework - both from the sponsor and developers point of view!

The programming addenda for the following sprint week is as follows >

* The run animation for the player 
The game code design and revamp of the story introduction 
* redesign of the button layout for the screen 
redrawn slides for the introduction of the game + skip function 
Code collision from unit test coding  
Add in the mummy and boulder sprite; create a spider & bat sprite 
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 
Create ceiling blocks
* Set up the attack functionality
* Create chamber way blocker(s) ( set up gameplay for left/right change) - up from ground 
* End level sequence (win - to start the next chamber lose - to either play again or return to the main menu)

Still to accomplish these features >
* Code hp collision logic (simple variable)
* Create tutorial screen for playing the game
* Collect Flesh of the gods to unblock the way to the exit
* Code left and right functionality 
Create sound and add sound?

* End game sequence



I am now at a stage to consider the design of each chamber.


1: Block......bat......block.............block.......block.....bat........boulder......bat......block
2: Bat.....block.....boulder.......bat.......block........bat........bat......block.......bat.......boulder
3: Bat.......block.....mummy.....boulder.....bat.......block......bat......mummy.......block.....mummy......boulder
4: Boulder......block....bat.........bat.......mummy.......block.......boulder.....bat.....boulder.. bat.. block..
5: Block....bat......mummy.....boulder....block.......bat......boulder......bat......block.....mummy...bat..block

1 = slowish speed , 2 = moderate, 3 = fast, 4 = faster, 5 fastest


Monday 28 January 2013

More progress



My attempt at the attack function wasn't far wrong.



// Create a new class that extends Sprite
var attacker = pulse.Sprite.extend({
 init: function(params) {
 this.lastMoveElapsed = 0;

   // Override the params with a texture source.
   params = params || {};
   params.src = 'res/punch.png';
   this._super(params);
   this.size = { width: 65, height: 81 };
   this.visible = false;
   attack = false;
 }
,update : function(elapsed) {
if (attack == true) {
    this.visible = true;
    this.lastMoveElapsed += elapsed;
    this.position.y = player1Inst.position.y-5;
    this.position.x =  player1Inst.position.x+32;
    player1Inst.visible = false;
 if(this.lastMoveElapsed >= 500) {
this.visible = false;
attack = false;
ArrowButtonATTACK.visible = true;
punch.position = { x : player1Inst.position.x-10, y : player1Inst.position.y+20 };
player1Inst.visible = true;

   this.lastMoveElapsed = 0;
   }
 }
this._super(elapsed);
}
});



The game is now playable to an extend.





(WEBCAM)





(PHONE)


Apologies for the crap recording. I am going to try and get better quality video caps for the presentation  in March.

Friday 25 January 2013

Attack function


Next up is the attack function.

I have re desinged the game slightly since changing the genre of the game from 2.5 plat former to enchanting 2.5D innovative runner game.

The Flesh of the god statues which where orginally going to be collectables such like coins in Mario games. But now they will be spread out sparingly in each chamber - their purpose is not to boast a score, or reduce a bosses hp but to magically unblock the path.

So, the player could run for an age and miss collecting a Fotg statue and contiunue runnnign avoiding enemies and will eventaully not be able to continue running so they must run back the way - hitting the blocker will end their game to the current chamber or option to quit to menu




The programming addenda for the following sprint week is as follows >

* The run animation for the player 
The game code design and revamp of the story introduction 
* redesign of the button layout for the screen 
redrawn slides for the introduction of the game + skip function 
* Code collision from unit test coding  
* Add in the mummy and boulder sprite; create a spider & bat sprite 
* 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 
Create sound and add sound?
* Create ceiling blocks
* Set up the attack functionality
* Create tutorial screen for playing the game
* Create chamber way blocker(s) ( set up gameplay for left/right change) - up from ground 
* Collect Flesh of the gods to unblock the way to the exit
* End level sequence (win - to start the next chamber lose - to either play again or return to the main menu)
* End game sequence




The blocker will be look more magical. Preliminary design 




These blocks will fall from the ceiling and will mean that the player must jump over them (they remain there when he turns)

The attack function will be coded as follows:

var Attackpower = pulse.Sprite.extend({
init: function(params) {
  this.lastMoveElapsed = 0;
},
update: function(elapsed) {
if(attack){

  this.lastMoveElapsed += elapsed;
  if(this.lastMoveElapsed >= 4000) {
    this.visible = true;
    this.position.x = Player1Inst.position.x; 
    this.position. y = Player1Inst.position.y;
    this.move(1, 0);
    this.lastMoveElapsed = 0;
    }
  }
this.visible = false;
 }
)};


this means that when the attack button is pressed and the attack boolean variable is set to true, the attack power will be visible and shoot out for a duration of 4 seconds from the players x and y co-ordinate then it will disappear.


The tutorial screen should convey the following information:

The player moves at a constant rate in order to race to the chamber to beseech a blessing 
The player can move left and right (when they are displayed on screen) to dodge Sets magic 
The player can jump or attack 
The aim is to get Kareem to the end of each chamber ad eventually confront Set 




Thursday 24 January 2013

Health bar working

I tinkered and fought with the coding of the spritesheet animation but couldn't get it coded efficiently enough:

In order to create a nextFrame illusion I had to create all different frames as new animations which wasn't coded well and wasn't reliable either.. (too many instances in the hp class)

I have since changed this so that a texture of the hpGems is re-used code in different sprites which allows me to set the visiblility of them easily instead of creating a huge spritesheet file  - It worked out well actually with some persistence. I also decided that the player should have 6 chances instead of 8 to add a bit of difficulty to the game.


Now, I will continue with the features planned the other day. Since then I have created storyboards to highlight what features should be grouped together.



Monday 21 January 2013

Collision progress



I have made some progress with the collision detection.

I have got it now that the player checks to the anchor point of another sprite and can then react to the overlap of the sprites.

I tried the rectangle collisions but had to collaborate with one of the game engine developers to see if the game engine was at fault as my code was ok to him. He is currently reviewing a section of my code to see what has went wrong. I should hear back from him at some point. In the meantime, I am going to work on the logic for getting the enemies to appear on the screen.

Sunday 20 January 2013

Development time


Bat sprites are done and working in the unit test code.

Boulder sprite is done and working (rotates with code)
Mummy sprites are done and working


Spider sprite is done 


Hp sprites done and working in unit code



Exit door

Now, to tackle the coding side of things - merging the unit test with the game code shouldn't be difficult!


17.15
The collision detection works but I have just concluded that it works merely because it checks the sprites x position not actually when it touches (duuh!!) Time must now be invested into researching how to code this. A break is in order ...


18:02
Dreamed up this bit of code - In theory this will work, not tested it yet BUT, it will be inefficient to use compared to the method that the engine uses to check collision - but it is a fall back 

If ( Sprite.position.x >= this.x-5 || Sprite.position.x <= this.x+5 || Sprite.position.x == this.x && grounded){
// Reduce health bar by one, make enemy non visible and reset its position 
}

Saturday 19 January 2013

Progress for today so far.



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 >

* The run animation for the player 
The game code design and revamp of the story introduction 
* redesign of the button layout for the screen 
redrawn slides for the introduction of the game + skip function 
* Code collision from unit test coding 
* Add in the mummy and boulder sprite; create a spider & bat sprite
* 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 
* Create sound and add sound
* 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. 

Friday 18 January 2013

New screens are done.



I had been contemplating for a while whether to get someone else to do the art work that was more skilled than myself so I could work on with other parts of the project but decided that I would have enough time to complete this task - and it turns out I did!

One draw back of trying to get someone on board at this time in the uni year is the workload. No-one has any time to spare. Nonetheless, I was able to communicate with a few folk and tell them of my plan for the game; but as I said workload plays a part in the 'No can do answers'. Since there seemed like no time to waste I decided it would be best if I done them.


I will post up my final results at the end of the working day ( seems to be about 11/12/1/2 until 9/10/11 which is a good 7-9 hours so far since Wednesday which appears to be working as I am getting a lot of work becoming functional, organised and enhanced - which is exactly what agile promises  - robust, quality software completed on time in a flexible way for the workforce to handle effectively.


18:30
I have done a unit test to ensure that the animation will work in the main game file. It took me a while to figure out how to code the frame setup but I got there in the end.



The programming addenda for the following sprint week is as follows >

* The run animation for the player 
The game code design and revamp of the story introduction 
* redesign of the button layout for the screen 
redrawn slides for the introduction of the game + skip function 
* Enemy sprites - Obstacles such as boulders, footmen of anubis, chamber wall chunks, 
* Setting up the attack functionality
* Left and right involvement in the gameplay 
* Sound 
* End sequence


Tomorrow

Collision detection - again another new part of the learning. I reckon I know what to do but - simply checking if 
if player.x == guard.x; then a variable is set to true, the HP HUD reduces by one and the game play continues until dead


Thursday 17 January 2013

Coding success prompts new features pronto!



Got alot done today again - and theres still another hour left in my working day.
Just to re-iterate here:



The programming addenda for the following sprint week is as follows >

* The run animation for the player 
* Enemy involvement - obsticles such as boulders, enemies, chamber wall chunks
* The game code design and revamp of the story introduction 
* redesign of the button layout for the screen 

Then if all goes well, the follow are what would be left - hopefully the following week will be able to take care of these issues

* Left and right involvement in the gameplay
* Setting up the attack functionality
* End sequence


Tomorrow
I plan to make unit tests for the animation - which means another curve to add to the learner graph for the project!
I also plan to draw new revamp slides for the story.



That's a good thing about single development in agile; it seems to get things done quicker than relying on team effort and the right type of amicable "person" to get the job done well. When one aspect of development is done, you can just go straight onto the next.

New screen layout







After examining my code, I am gonna use today as a re factoring day as the code I have is beginning to get a bit cumbersome on the processing power of the tablet/browser.

I have designed in ink, which has been replicated using llucid chart diagram

If I refactor the code like so, I will be able to remove sprites completely from memory - instead of layering them on top of each other on the same scene. This should improve frame rate for the gameplay with an increased response time to the pulse engine update.

See below:




Wednesday 16 January 2013

A bit of design





After a bit of a test play, a refactor of obsolete code, a merge of the menu parts, a consideration of the art work to display the story  introduction, a tidy up and polish of some sprites the new revamped screens above show exactly where the game is heading: gameplay! Finally, I am ready to code the game play and get some levels up and running.

Incremental design with XP has played a great part in developing the game so far. I have realised that the up arrow resides above the android systems applications button which disrupts the game from time to time when the player clicks it accidentally. What I am planning to do is move the two right buttons up to the centre of the screen so that A) the player no has as much screen visible and B) the problem should not persist and the gameplay can run smoothly.


The programming addenda for the following sprint week is as follows >

* The run animation for the player
* Enemy involvement - obsticles such as boulders, enemies, chamber wall chunks
* The design and revamp of the story introduction
*redesign of the button layout for the screen

Then if all goes well, the follow are what would be left - hopefully the following week will be able to take care of these issues

* Left and right involvement in the gameplay
* Setting up the attack functionality
* End sequence



17/01/2013 00:05
The title screen layout revised



Monday 14 January 2013

Development of the demo begins in full scale

I've ran into a a problem with the development kit which I planned on using - It was working alright until I tried it earlier today. There is a problem with the SDK locating the JRE. Apparently this issue has not been fixed according to the news online and I was trying to fix it myself for a while.

I decided that in order to progress with the game, I would change my SDK (even if for the moment) to the Eclipse IDE.


Eclipse offers the same as Titanium in terms of development so it is not a huge loss nor a new gain.