Why a shooter you ask? And why be so ambitious? Great questions, lets answer them.
Well, the shooter was actually (like alot of the other projects) inspired by the simpler games we used to play in arcades and on old Nintendo's at home, simple and fun. But a shooter would be something that would involve alot of moving parts, allow players to show off some gaming skills and yet still be within the realm of what we could do with javascript. Also, its horribly hard to make a story for a puzzle game without being totally off the wall. So a sci fi setting naturally let me be a little more creative (to the limited extend i took the story to). Also, once having talked it over with Nate and assured him we could actually get user input (keystrokes) and move the units and enemies around he agreed we should jump on the idea.
Something Ive always liked to do, and Nate as well from what he had told me about previous games he had made, is to take the simple controls given by the code and push them into doing things which aren't immediately accessible to the programmers. So this was based on the knowledge that we could move objects around the screen independent of user actions, as well as being able to respond to commands from the user. Im really glad the game was able to fulfill almost every single objective we had started the project with. We have enemies, their lazers, our ship can fire, our ship can move, and we've also got collision detection for all of these.
Thursday, April 5, 2007
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.
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.
Death's Progress : Week 1 (repost)
With Nate out of contact for the weekend, my progression was negligible because we had yet to meet and decide on what our objectives and respective responsibilities were for the week. After speaking to Professor Sana about an extension I decided that the first challenge to knock out of place was to (1) Decided how objects would be controlled on the page (2) Make them fall at a controllable speed, individually (3) Allow for mutliple objects to be on at once and controlled by a single position check. Also, making a page that would show how the game would be looking (at least in a static state) when we finished.
Needless to say, the first step was the easiest. The second became a challenge of combating various browser particularities to DHTML objects (layers in this case). However, with the help of suggestions from the last project (error console, placing alerts to see the code's progress) I was able to finish step 2.
Or, I thought I had. Again, running from the desktop and uploading then running a page is always different. So tinkering was done with file name's and src properties until that too worked. That was all finished early yesterday (thursday) morning. The real difficultly occured with part (3), because suddenly I started to recieve an error pertaining to what was placed in the "layer - width:_____" variable. It had to be with a "px" at the end, where that hadnt been a problem with my single object code. So after adding only "px" where necessary and seeing no results I was out of time due to exams and the studying that needed to be done for them. Now I sit after further fiddling with the code and similar non-results. Realizing something will be better than nothing I am crossing my fingers that Nate is not sick AND out of touch again over the next week so we can get further along before the next entry than my sorry skills have brought us.
-Paul Warren
Needless to say, the first step was the easiest. The second became a challenge of combating various browser particularities to DHTML objects (layers in this case). However, with the help of suggestions from the last project (error console, placing alerts to see the code's progress) I was able to finish step 2.
Or, I thought I had. Again, running from the desktop and uploading then running a page is always different. So tinkering was done with file name's and src properties until that too worked. That was all finished early yesterday (thursday) morning. The real difficultly occured with part (3), because suddenly I started to recieve an error pertaining to what was placed in the "layer - width:_____" variable. It had to be with a "px" at the end, where that hadnt been a problem with my single object code. So after adding only "px" where necessary and seeing no results I was out of time due to exams and the studying that needed to be done for them. Now I sit after further fiddling with the code and similar non-results. Realizing something will be better than nothing I am crossing my fingers that Nate is not sick AND out of touch again over the next week so we can get further along before the next entry than my sorry skills have brought us.
-Paul Warren
Game:Initialize (reposted)
Like many other groups we drew inspiration for our small game from the myriad of those that have come before. We wanted something that would be unique, a challenge, and yet something doable and that others would find fun. So it was proposed that an attempt be made at a scrolling shooter style game by myself, and Nate allowed himself to be talked into it. I pledged to create an entertaining storyline which would provide a humorous backdrop to the game's otherwise familiar mechanics, and we both agreed to split the rest of the work down the middle (and then skewed the load towards our own strengths).
REMAKE
For some reason, google and I got in a fight and it refuses to acknowledge my old blog account because it wasn't registered to a gmail address. So I got locked out and am simply reposting the original two entry's along with this week's, please bear with me and lets hope the google mafia accepts my pitiful acceptance of their blogging protection ring.
Subscribe to:
Posts (Atom)