Hrmmm...Suggestions, Ideas, Pointless Remarks?

[Onideus Mad Hatter]

Well in theory it was a good idea:
http://www.backwater-productions.net/_test_platform/game/index.html

Press "4" to move left, press "6" to move right.

The question remains though...is there some way of limiting
onkeypress? Cause if you hold the key down, boy that's just all
shades of unhappy right there.

: char_l_img = 1;
: char_r_img = 1;
: start_pos = 300;
: nav4 = window.Event ? true : false;
:
: function move_left()
: {
: start_pos = start_pos - 5;
: char_l_img++;
: if ( start_pos == 25 ) { start_pos = 30; }
: if ( char_l_img == 5 )
: {
: char_l_img = "1";
: window.clearInterval(farfoos);
: }
: document.getElementById("char_div").style.left = start_pos + "px";
: document.getElementById("char_img").src = "l" + char_l_img + ".gif";
: }
:
: function move_right()
: {
: start_pos = start_pos + 5;
: char_r_img++;
: if ( start_pos == 500 ) { start_pos = 495; }
: if ( char_r_img == 5 )
: {
: char_r_img = "1";
: window.clearInterval(farfoos);
: }
: document.getElementById("char_div").style.left = start_pos + "px";
: document.getElementById("char_img").src = "r" + char_r_img + ".gif";
: }
:
: function move(e)
: {
: if (nav4) { whichCode = e.which; }
: else { whichCode = event.keyCode; }
: if( String.fromCharCode(whichCode) == 4 && char_l_img == 1 ) { farfoos = window.setInterval('move_left()', 35); }
: if( String.fromCharCode(whichCode) == 6 && char_r_img == 1 ) { farfoos = window.setInterval('move_right()', 35);}
: }
:
: document.onkeypress = move;
:
: document.write("<div id='char_div' style='position:absolute; z-index:0; left:" + start_pos + "px; top:150px; width:32px height:64px'><img id='char_img' src='r1.gif'></div>");

I tried that && char_l_img == 1 thing, but that didn't seem to cut it.
Is there some way to detect when a key is NOT being pushed?
Hrmmm...I'm at a loss on this one at the moment, I think maybe I need
to get some sleep. -_-

I might need to rethink the whole way it actually functions...maybe do
it in PHP...hrmmm...wonder if PHP has an onkeypress equivalent...

 

[VK]

I guess you never programmed for ZX Spectrum... It puts your brains
under the right angle once and for a while

The onkeydown starts the process of movement regulated by your internal
timer.

The onkeyup stops the process of the movement and clears the timer.

As the PC/Mac keyboard approach sucks from the very beginning, it's
impossible to reach a "PC Game" functionality w/o your own keyboard
driver (so say you could hold a key to keep moving forward and press
other keys to shoot/kick the enemies).

But a primitive movement is fairly simple:
....
var obj = null;
function init() {
obj = document.getElementById('Monkey');
obj.onkeydown = moveIt;
obj.onkeyup = stopIt;
}

function moveIt() {
/* Check what key is pressed
and setTimeout for the appropriate movement
function (left/right/up/down) */
}

function stopIt() {
/* clearTimeout */
}

windows.onload = init;
....

 

[RobG]

VK wrote:
[...]

windows.onload = init;

--------^

This runs when the OS loads?

 

[VK]

windows.onload = init;

This runs when the OS loads?

That would be cool...

Sorry, just a typo. Of course:

window.onload = init;

 

[Lee]

Onideus Mad Hatter said:

I might need to rethink the whole way it actually functions...maybe do
it in PHP...hrmmm...wonder if PHP has an onkeypress equivalent...

PHP runs on the server to generate pages to be sent to the client
browser. It's finished its job long before the first key is pressed.

 

[Onideus Mad Hatter]

I guess you never programmed for ZX Spectrum... It puts your brains
under the right angle once and for a while

The onkeydown starts the process of movement regulated by your internal
timer.

The onkeyup stops the process of the movement and clears the timer.

As the PC/Mac keyboard approach sucks from the very beginning, it's
impossible to reach a "PC Game" functionality w/o your own keyboard
driver (so say you could hold a key to keep moving forward and press
other keys to shoot/kick the enemies).

But a primitive movement is fairly simple:
...
var obj = null;
function init() {
obj = document.getElementById('Monkey');
obj.onkeydown = moveIt;
obj.onkeyup = stopIt;
}

function moveIt() {
/* Check what key is pressed
and setTimeout for the appropriate movement
function (left/right/up/down) */
}

function stopIt() {
/* clearTimeout */
}

windows.onload = init;
...

Ahhh, thank yas! I shall copy your code, test it, rip it all apart,
test it some more, rebuild it from scratch, poke it with the testing
stick again and hopefully I should have a new working version by this
evening. My gawd I love this shit...*shudder*...I think I have an
obsession with technology, I can't seem to get enough...graphics,
networking, video, web design, gaming, programming it WANTS to be
learned...ALL of it!

Once I've got the game thing finished I'm gonna integrate it into my
new true liquid website:
http://www.backwater-productions.net/alt.2600/index.html

I might change the subject though, I originally made it for alt.2600,
but I've been thinking about turning it into a kind of retro Nintendo
esque site.

 

[Onideus Mad Hatter]

I guess you never programmed for ZX Spectrum... It puts your brains
under the right angle once and for a while

I prefer Mt. Dew to put my brain into the right angle.

I decide to try it my own way first and fix what I had, this is the
result:
http://www.backwater-productions.net/_test_platform/game/index.html

: char_l_img = 1;
: char_r_img = 1;
: char_ar_img = 0;
: char_al_img = 0;
: start_pos = 300;
: nav4 = window.Event ? true : false;
: left = null;
: right = null;
: attack = null;
: pos = "rightface";
:
: function move_left()
: {
: start_pos = start_pos - 5;
: char_l_img++;
: if ( start_pos == 25 ) { start_pos = 30; }
: if ( char_l_img == 5 )
: {
: char_l_img = 1;
: window.clearInterval(left);
: left = null;
: pos = "leftface";
: }
: document.getElementById("char_div").style.left = start_pos + "px";
: document.getElementById("char_img").src = "l" + char_l_img + ".gif";
: }
:
: function move_right()
: {
: start_pos = start_pos + 5;
: char_r_img++;
: if ( start_pos == 540 ) { start_pos = 535; }
: if ( char_r_img == 5 )
: {
: char_r_img = 1;
: window.clearInterval(right);
: right = null;
: pos = "rightface";
: }
: document.getElementById("char_div").style.left = start_pos + "px";
: document.getElementById("char_img").src = "r" + char_r_img + ".gif";
: }
:
: function attack_right()
: {
: char_ar_img++;
: document.getElementById("char_img").src = "ar" + char_ar_img + ".gif";
:
: if ( char_ar_img == 3 )
: {
: char_ar_img = 0;
: window.clearInterval(attack);
: attack = null;
: }
: }
:
: function attack_left()
: {
: char_al_img++;
: document.getElementById("char_img").src = "al" + char_al_img + ".gif";
:
: if ( char_al_img == 3 )
: {
: char_al_img = 0;
: window.clearInterval(attack);
: attack = null;
: }
: }
:
: function move(e)
: {
: if (nav4) { whichCode = e.which; }
: else { whichCode = event.keyCode; }
: if( whichCode == 100 ) { if ( !left ) { left = window.setInterval('move_left()', 35); } }
: if( whichCode == 102 ) { if ( !right ) { right = window.setInterval('move_right()', 35);} }
: if( whichCode == 32 )
: {
: if ( !attack && pos == "leftface" ) { attack = window.setInterval('attack_left()', 75);}
: else if ( !attack && pos == "rightface" ) { attack = window.setInterval('attack_right()', 75);}
: }
: }
:
: document.onkeypress = move;

The trick I found was to set the interval variables to null and then
only allow it to engage the function if they were. And then at the
end of each function it would reset the interval back to null so it
could engage again. Essentially the earlier way I had it was just
running dozens of the same interval every time the key was pressed.

The onkeydown starts the process of movement regulated by your internal
timer.

The onkeyup stops the process of the movement and clears the timer.

Hrmmm...timers...I'll try that later, see if it works any better than
my current methodology.

As the PC/Mac keyboard approach sucks from the very beginning, it's
impossible to reach a "PC Game" functionality w/o your own keyboard
driver (so say you could hold a key to keep moving forward and press
other keys to shoot/kick the enemies).

I find it works better if I alter my keyboards repeat delay settings
to the shortest setting. The major problem with my current ver is
that if a key is held down and you push another key once, then
everything just stops, so like you said, only one button at a time
essentially.

But a primitive movement is fairly simple:

<snip>
Will using onkeydown eliminate the prior problem I mentioned, or does
it function just like onkeypress?

And if it works no differently what about combining the two? For
example what if I used onkeydown for the movement, but then in the
move function could I include an onkeypress function that would handle
the sword movement. Or do the functions onkeydown and onkeypress
cancel one another out (or rather, take the place of one another)?

 

[VK]

Will using onkeydown eliminate the prior problem I mentioned,

or does it function just like onkeypress?
And if it works no differently what about combining the two? For
example what if I used onkeydown for the movement, but then in the
move function could I include an onkeypress function that would handle
the sword movement. Or do the functions onkeydown and onkeypress
cancel one another out (or rather, take the place of one another)?

Nothing will eliminate this problem because of the driver limitation I
just mentioned. It takes us rather far from JavaScript, but just to
make the picture clear:

ZX Spectrum and Atari (the great old) as well as Nintendo and Co (the
great new) have a keyboard driver based on so called "agressive
scanning". It means that from your program you may read the state of
*any key*. So user can hold 8 keys and hit the 9th one, and you can
still read it. So it doesn't have a keyboard IRQ (like PC). But you may
set up say "spacebar IRQ" (something very strange for PC terms).

PC's (back to IBM PC) decided to use much less convenient but more
resource effective scheme with passive listening of keyboard IRQ's. It
means that you cannot produce a new keyboard event until when the old
key is released. Well, no one thought about Doom or Halflife that time

To overpass the limitations of this approach, later they had to add
more and more modifiers on the keyboard (Ctrl, Alt, then divide them on
left and right control keys etc.)

Still this scheme is not usable for any more-or-less complex game. So
usually any game starts from installing its own keyboard driver. But
JavaScript doesn't let you this plesure. So I see two main options:

1) Use keys together with modifiers. Say RightArrow means go right,
Alt+RightArrow means go right and hit with the sword and so on.

2) Try to use Quake approach where the movement is regulated by keys,
and extra actions by mouse.

 

[Onideus Mad Hatter]

Nothing will eliminate this problem because of the driver limitation I
just mentioned. It takes us rather far from JavaScript, but just to
make the picture clear:<snip>

I gotcha, I found a way around the problem though, rather than rely on
the keyboard for movement I'm simply going to create graphical
controls on the screen, so you can move your mouse over them to
control the left, right and stop movement and then I'll just use the
keyboard for like the jumping and attack...essentially that'll
simulate how old Nintendo controllers work (a and b buttons single
tap...unless you have turbo).

 

[VK]

I'm simply going to create graphical

controls on the screen, so you can
move your mouse over them to
control the left, right and stop movement
and then I'll just use the
keyboard for like the jumping and attack

It's your game (in all meanings of it), but I'm finding this approach
rather odd from the common gaming practice. Usially a primitive
<left/right/top/down> movement in arcades is always regulated by some
"physical" input device (keyboard keys in our case). Gamer needs a
continuos tactil sensations for the movement, otherwise you're forcing
him/her to continuosly switch the attention from the game field to the
navigation panel and back. I can tell in advance that your game will be
*very* irritating for the most of the users. They can rather easy to
forgive you to be "killed" because they could not get out the sword on
time. They get bazurk of "being killed" because they couldn't go to the
left on time because your interface was to fancy for it.
If you decided to be a game writer, remember The Rule One:
"The movement is the King, all other is after that".

You may also think of the WRML approach, where the cursor point defines
the point where the hero is trying to come to. Despite it already
prooved its questionability, "something is better than nothing".

 

[VK]

Thinking back, the best possible approach would the oldest one:

1) The Rule # 1 is still in the effect (you move your hero by the
keyboard)
2) Right under the game field you have a bar with icons defining your
hero's "mode". Say you click on the icon with the sword so he would get
sword, icon with fire to start spitting the fire and so on.

 

[Onideus Mad Hatter]

It's your game (in all meanings of it), but I'm finding this approach
rather odd from the common gaming practice. Usially a primitive
<left/right/top/down> movement in arcades is always regulated by some
"physical" input device (keyboard keys in our case). Gamer needs a
continuos tactil sensations for the movement, otherwise you're forcing
him/her to continuosly switch the attention from the game field to the
navigation panel and back. I can tell in advance that your game will be
*very* irritating for the most of the users. They can rather easy to
forgive you to be "killed" because they could not get out the sword on
time. They get bazurk of "being killed" because they couldn't go to the
left on time because your interface was to fancy for it.
If you decided to be a game writer, remember The Rule One:
"The movement is the King, all other is after that".

You may also think of the WRML approach, where the cursor point defines
the point where the hero is trying to come to. Despite it already
prooved its questionability, "something is better than nothing".

Well, first I thought about doing a left click = move left/stop, right
click = move right/stop...but then I suddenly remembered that Macs
only have one mouse button so that wouldn't really work. And the
problem with the WRML approach is that you have to fly the mouse all
over the screen and so control isn't as precise. Technically with my
current approach there is a degree of tactile movement, you simply put
your mouse on the nav and then move slightly to the right to move
right, slightly to the left to move left and in the middle to stop.

....certainly not perfect, but if I want to make a game like this in
JavaScript I don't see as I have much choice...of course on the other
hand I could just give a big "**** you" to the Mac users out there and
make it PC, two button mouse compatible only.

I dunno, at this point going the Neopets esque route with Flash might
be a better alternative...although I would really like to not help
fuel the Macromedia monopoly any more than possible. I might just
shelve this idea for awhile, move on to something else.

*Hatter calls it a night.* -_-

 

[Lasse Reichstein Nielsen]

make it PC, two button mouse compatible only.

Not all browsers (read: mainly only IE) allows you to capture right
clicks, so that's not a viable strategy for cross browser scripting
either.

/L

 

[VK]

I dunno, at this point going the Neopets esque route with Flash might

be a better alternative...although I would really like to not help
fuel the Macromedia monopoly any more than possible. I might just
shelve this idea for awhile, move on to something else.

It's up to you, man. Actually an arcade game writing on high level
languages gives you some priceless experience, because it's very
"dirt-sensitive". So it puts you in the condition where each
fault/uneffectiveness counts up to the level you game becomes too slow
to be usable. (Just important to not make it a sense of you life

If you want to use run-time sounds and scene transitions, there is
nothing to be ashame of moving to Flash.
As well as you don't need to be ashame of using C++ instead of
JavaScript to write a complex destop application.
Or by using multi-threaded Java applet to get multiple data from the
server instead of torturing heartlessly the threadless JavaScript.
Each language has its niche, and runtime miltimedia effects is really
not one of JavaScript. (which *doesn't* mean it cannot do it at all !)

 

[Thomas 'PointedEars' Lahn]

As the PC/Mac keyboard approach sucks from the very beginning, it's
impossible to reach a "PC Game" functionality w/o your own keyboard
driver (so say you could hold a key to keep moving forward and press
other keys to shoot/kick the enemies).

Rubbish, learn about PC keyboard scan codes. It is the script engine in
combination with the insufficient browser DOM that is the bottleneck here.


PointedEars