The coding stage of my current game project has started, and started quite well (compared to how badly coding can go - error-wise).
After a bit of messing about I've got the pixel-level bitmap data hit test working smoothly. the slight messing about I had to go through was due to my avatar's containing movie clip not being at 100% scale, this causes issues at the bitmap data object seems to always work with the data source at its 100% size for the hitTest no matter what scale the source object is at.
I've just re-hashed my control system too, to give a faster, more logical interface for the player, as the game is now a faster movement-based game. Here's how:
I'd created the functionality of moving the avatar already (see previous 'red-thing' post), but I'd disabled movement if >1 direction was being pressed. This was an easy fix for a slight bug I found in the way I had coded the input gathering. (and, I've noticed, MANY online Flash games have been published with the same problem). The issue is that when a new directional key is pressed, it overrides the current direction ONLY if it's lower in the coded order. For example if the code is as follows: (in pseudocode)
if UP is pressed, go up;
if DOWN is pressed, go down;
if LEFT is pressed, go left;
if RIGHT is pressed, go right;
Up will be overridden by any other direction; down will be overridden by left and right; left by right; and right will never be overridden.
This gives unequal directional behaviour which will confuse players, possibly causing a complete game success (enjoyment, re-play factor and possible forward potential if it's an advergame) into total failure (annoyance to the extent that the player quits playing for good, never forwards or tells anyone about the game and possibly creates negative connotations about any brand shown within the game!)
This is totally unacceptable, so I set about creating an intelligent input algorithm. The basic pseudocode I've turned into working ActionScript is the following (example of just the UP direction):
- Base logic layer:
-- When UP is pressed, upInputVariable = true;
-- When UP is released, upInputVariable = false;
- New Middle-logic layer:
-- Record previous frame's InputVariables states;
-- Compare previous and current InputVar states;
--- (If upInputVariable's state just changed to true) OR ((any other InputVarState changed to false) & (upInputState is still true))... then newDirectionRequest = "up";
- Top Movement Functionality layer:
-- If newDirectionRequest = "up", [do all the required actions to move avatar up]
If you followed that cheers for reading through it!
I'm happy with this, especially as I can see which games online haven't done this. Try it yourself, on a game where more than one direction can be pressed, experiment with which ones override the others. I've found that almost all have either not tackled the problem or used my easy fix.
More updates to follow...
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment