[rfk-dev] Getting this train moving
Peter A. H. Peterson
pedro at tastytronic.net
Thu Nov 1 07:20:57 PDT 2012
Quoting Peter A. H. Peterson:
> > I just implemented a compression/expansion behavior, with the robot
> > able to explore the new space after expansion. If, while the resize
> > handler is trying to compress the playfield, an object lands on
> > another, the following message is omitted:
> >
> > You crushed the simulation. And the robot. And the kitten
>
> I think people should playtest this and respond.
Ok, I have some bugs:
0. The success message (YFK!WTGR!) should appear after the animation,
not before or concurrent to it.
1. Resizing is still a bit wonky. Several examples follow:
a. Resizing a window horizontally with the mouse led to a message
about an unknown key direction: "Invalid input: Use direction keys or
q."
b. Why does resizing happen vertically but not horizontally?
c. Resizing can lead to spectral NKI. I resized vertically up and down
a few times, and then went to touch an NKI, and it vanished without a
trace!
d. If the window is resized between the start screen and the play
field, it gets confused. I just escaped the game grid! Oh wait, I'm on
the other side.
e. Given that the repositioning of the NKI and robot is very slight
anyway, why don't we just expand the field but not move the objects?
Or if we want to be clever, center the objects in the field or something.
It bothers me that if I start rfk, then maximize it, then de-maximize
it, I can crush the simulation although I really only put it back the
way it was. (But I would be fine with crushing the simulation if you
resize lower than the field, even if objects do not specifically
collide.)
What if I had a long running game and I was super close to ascencion?!
--
Peter A. H. Peterson
Graduate Student Researcher
Laboratory for Advanced Systems Research
University of California, Los Angeles
More information about the rfk-dev
mailing list