Re: TIB: BFS Final game


[Prev][Next][Index][Thread]

Re: TIB: BFS Final game




ETTamme1@aol.com wrote:
> 
>         First, the matrix will change as the level progresses, but i am not that far
> yet.  A and B represent the set of coordinates taken from the two lists.  L1
> and L2 represent the walls in the level, L1=x var, L2 =y var.  So when you
> move the cursor, it adds one to a&b which are originally zero, then says if
> new cursor x=L1(a)<-(which var in the list) and new cursor y=L2(b) then store
> the old cursor vars as the new cursor position so you cant walk through the
> wall. Else add one to a & b, and reapeat the loop; it does this loop until it
> reaches the end of the list or encounters a matching set and therefore checked
> all of the possible walls for the cursor.  so basically, L1 and L2 contain
> every wall edge on the screen, L1 bieng x L2 bieng y, and i use a variable
> that increases by one each loop to determine the set of coordinates taken from
> L1&L2 then say if this set of coordinates =the cursor coordinates, use the old
> cursor coordinates.

Ah, thanks for the info.  By the time I got your posting I had pretty
much come to all the correct conclusions about what did what.  Here's
some of my ideas right from the top; we can both work on them and see
what we each come up with.  First of all, and probably the thing that
will have the biggest effect, is to change the getkey.  Right now you
have it getkey and then go through _ALL_ of the checks (tick tock, tick
tock) and then finally it quickly passes the getkey again.  Instead, why
not have it go through a very small - and fast - little loop that waits
until the user presses something before it actually does anything. For
example;

Instead of this:
:Repeat 0
:getkey->@
:.......
:.......
:.......
:End

Why not this?
:Repeat 0
:Repeat Ans
:getkey
:End
:Ans->@
:......
:.....

The next idea has to do with some optimizing.  Instead of using repeat
loops at the beginning, replace them with for loops.  This way you don't
need to have the X+1->X and Y+1->Y lines.

I was looking at all the lists and matrices and it got me a little
concerned.  If you add up all the bytes used for the 8x16 matrix and two
40 element lists it comes out to just around 2100 bytes!! And this is in
addition to whatever you end up with for the program!  I was trying to
figure out a way around this, and here's one idea.  Notice that the
first list has only single digit numbers in it.  Instead of using a
list, which I believe is approximately 9 x(number of elements)+9 bytes,
why not use a string.  The strings are _much_ smaller.  I think they are
roughly one byte per element.  You would run into problems representing
numbers >= 10 because of the two digit thing, but, like I said earlier,
the first list doesn't have that problem.

Right now you have this;
{3,2,2,3,4,3,....}[or whatever-I don't have it in front of me right now]
and you use A to represent the location. ie. 5->A:L1(A)=4.

Try this;
"322343.....
Now then, simply take the expression of the substring to get the number
you want.  For example;
:"322343->Str1
:5->A
:expr(sub(Str1,A,1

Now the answer variable should have the four in it - the same effect as
using the list.  However, you should be able to cut the byte size down
from about 350 to about 50.

The last big suggestion has to do with the whole idea of the game. 
Instead of having it work on the home screen, why not have it work on
the graph screen?  The reason for this is that you would then be able to
use the pixel-test command.  I think that you should be able to
completely get rid both lists by doing it this way.  Think about it; to
check to see if you are walking through a wall, simply check the
pixel-test at the next coordinate - if it returns a 1 then you are
walking through a wall.  Basically you would be checking as you go
instead of having to use up all your memory saving and remembering what
all those values are.  It should also be faster because you would no
longer have to check all of the different numbers. One last advantage is
that I think you could get more stuff on the screen.  I'm not sure how
to deal with changing the matrix size, though.  I just don't like the
whole idea of the matrix.  It's just to big.  Perhaps you could come up
with some sort of thing where it randomly creates a level?  You would
have to come up with some way of ensuring a way through it, but come on,
whatever you come up with shouldn't take nearly as much memory as that
stupid matrix.

Well, that's just a few thoughts.  I'm going to keep working on the
thing to see if I can implement some of the changes.  Let me know what
you think.

Whoa! Gotta Go!!!

Jody Snider
jody1@alaska.net


References: