Tuesday, March 20, 2007

Death's Progress : Week 2

After a week of tragedy and ill health, Nate and I finally synced our schedules and sat down to move our game from the demo stage I had created earlier into a real live working game.
The first order of business was to solve one of the biggest oversights of the demo: the fact that it only kept a single object on screen at once and the funky difference in speed between the first object and all that followed it. First we addressed the coding which had originally just been put in place to hold up the workability of the code . For instance "
function initialize()
{ createobj();
return;}

function createobj()

{ tracker[0] = "1"
layer="obstacle_1"
" was a static variable, it would only handle that one obstacle falling at a time instead of allowing the game to create and control several. Now it reads "
function run()

{ initialize(); t=setInterval("move()", 40);}

function initialize()

{ var eyedee = "obstacle_" + RA[pointer];
createobj(eyedee);
if (pointer>3)
{ pointer = 0 }

else
{ pointer++; }
u=setTimeout("initialize()",Math.floor(Math.random()*waittime));
"
Which allows for us to control the layers we created in the original html, and also it checks to make sure the "obstacle_" is not already in use through our RA array and "pointer" variable (what i had previously just been trying to use an array for). Nate also pointed out that I had spelled "default" wrong in my switch code, whoops...
I explained what "
hposition = Math.floor(Math.random()*600);
if(hposition-objwidth<=0) {hposition=0;} else { hposition = (hposition-objwidth);}
"
was used for in my original code(to make sure that the objects didn't get positioned off the screen to either side by assuming the object would run off the right side of the page, then checked to make sure the shift left didn't move it off the left side completely). And that, along with the majority of the rest of script was left intact from the first iteration of the code (much of which will be gutted once we get the game up and running).
Next came the major change to the code, and this was in the way that the obstacles were handled, moved, and replaced/hidden.
My original code simply moved the obstacles, one by one, down the page until they reached bottom at which point their layer was turned "hidden" and then reused for a new image at the top. It was controlled through "
function move()

{ if(vposition>(620-.5*objheight))
{ clearTimeout(t);
document.getElementById("obstacle_1").style.visibility="hidden";
end();
}
vposition=(vposition+6);
document.getElementById("obstacle_1").style.top=vposition;
t=setTimeout("move()", 40) }
"
Unfortunately, the timeout function meant there were discrepancies in the speed of the obstacles, and also made handling multiple moving objects very difficult. The answer was, of course, a "for" loop which could run through all of the present obstacles and move them down the screen at once, stopping along the way to check it had reached the bottom.
function move()
{
for(var i=1;i<6;i++) num =" parseInt(document.getElementById(">=(620-document.getElementById("obstacle_" + i).style.height))
{
document.getElementById("obstacle_" + i).style.visibility="hidden";
}
else{
document.getElementById("obstacle_" + i).style.top=(num+6);}

This became the "move()" function now, and I was definately appreciating having Nate's experience in coding and the various work around's and functionality that would have taken me much longer to figure out (if ever).
Originally however, he had wanted to pass a variable along through the "setInterval()" function, but this was not allowed by javascript and we were left to ponder a work around for that which would allow us to look at and move each obstacle without much more code to work around it. After a good half hour we decided that instead of passing the variable along we would just do all the work within the function called by "setinterval" and that is "move()" how you currently see it.
The next part of the code is purely magic on Nate's part as he and I had to split up for classes, the one thing that was glaringly absent was any sort of interaction with what could in no way be yet considered a "game". Nate looked up the javascript coding which would check for key input, and mapped the movement of our protagonist's ship to the "4" and "6" numpad keys (apperently arrow keys have no ASCII code). thus giving people something to finally do about all those obstacles which were now plummeting onto their heads. We had finally created "death from above" as well as a way of which to avoid it.

Next entry, look for: details on our collision, firing and the other gimmicks we are trying to insert and utilize to make our game the best. Also, I am in charge of our game's storyline and theme, so I will be updating a fair amount of lore and adding story elements to the page so that our player's immersion is not just for that "twitch" factor of gaming goodness.

Paul Warren, Signing off.

No comments: