Re: Hrmmm...Suggestions, Ideas, Pointless Remarks?

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;
....

VK wrote:
[...]

windows.onload = init;
--------^

This runs when the OS loads? :-)

--
Rob

windows.onload = init;
This runs when the OS loads? :-)

That would be cool... :-)

Sorry, just a typo. Of course:

window.onload = init;

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.

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".

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.

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 !)

VK wrote:

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