Alice Community  

Go Back   Alice Community > General Discussion > The Lounge

Reply
 
Thread Tools Display Modes
ITSE1429 Lab3-RE
Old
relliott44444
Junior Member
 
Status: Offline
Posts: 11
Join Date: Sep 2014
Default ITSE1429 Lab3-RE - 11-20-2014, 05:57 PM

LAB 3 Observations

All,

The lab was exciting and interesting. It was also frustrating. Since Lab 4 and Game Project build on the success of the Lab 3 I felt it helpful to collect my thoughts, analyzing the good and the challenges.

First, the most frustration occurred when the using "watch this variable" and "watch this parameter". At many points during development, when those were enabled, my Lab3 program 'worked'. I would then make only one change: "stop watching..." etc., and the logic would fail. I actually figured this out by use of PRINT statements to observe variables, toggling the "watch" feature.

My interpretation is that my logic was violating local/global stack and enabling watch exposes this. I resolved this by careful re-design of logic to avoid mixing local and global variables. Eventually, the "watch" usage became a non-issue.

Then I just want to offer some guidelines for Lab3. I started by making simple pseudo code/ipo type of flow. But first I had to get some concepts in line with the features in Alice.

I. The basic torus movement is from up (in sky) to landed (on ground). In order to provide for repetion I defined an Alice world with DUMMY objects. Background on dummies - they have been around for as long as I can rememebr in programs that interface visually. While their precise role in logic varies, the idea is that visibility to humans is an attribute, not a requirement.

II. My first 'dummies' would be the home and destination locations for the torus, so to speak. So torus_home is a dummy at the arbitrary point in sky where it starts from. Similarly, torus_destination is a dummy at the arbitrary point on ground where the torus is heading towards. So I put these into the world. It is much easier to conceptualize the torus movement now:
Torus move down to torus_destination;
Torus move up to torus_home.
I can make this into a loop and hence do it repetively until some condition (infinite or 10 or whatever)

my first method
do while ctr Not >10
move torus down towards... etc..
move torus up towards... etc.
increment ctr

I built this to get started.

III. I have left the cone out of consideration. In keeping with the dummy object idea, I define a cone_home dummy object. This gives me a place to both leave from and go back to. I actually do not even have to move the cone. Another advantage is that my cone_home and torus_destination are distinct but CAN occupy the same exact point. My cone and torus are not interacting just yet.

I added the cone and the additional dummy.

IV. Things are about to get interesting so I use 3D-text to display the counter in my loop.

V. What defines "caught"? In the most simplistic way it means the distance between things is (relatively) very small (may be 'small' positive number, zero, or 'small' negative number). For my purposes, close proximity means 'caught'. I can construct this into if/else and use available functions. A lot of experimentation may be needed. Support for this effort may be found in "watch variable/parameter" and Print statements (previous caveats apply).

VI. Testing my "caught" logic would need the ability to change the cone position. I also needed to define / refine rules:
a. One torus journey is from its home to destination
b. One and only one "caught" will count per torus journey from its home to destination
c. A torus' journey ends when it arrives at destination (on ground).
d. There are built-in Alice events to control object movements (Mouse, arrow keys, etc.)
e. Cone movement is restricted to being horizontal (sideways) but infinite, on surface of ground.
f. Cone movement is independent of a torus journey.

VII. As mentioned, my attempts at logic to support this appeared to work at various times but I needed to get the variables/parameters correct. A staged development approach payed off eventually and will also segue into the next assignment activities.

As a result, the MMP game developers are taking note of these astounding capabilities and scurrying back to their drawing boards. I will try to go easy on them in future programming activities.

Talk to you all soon.

Richard
   
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump



Copyright ©2024, Carnegie Mellon University
Alice 2.x © 1999-2012, Alice 3.x © 2008-2012, Carnegie Mellon University. All rights reserved.