alan's multi-user skunkworks
works in progress
something stinks around here
skunkworks
item ideal gas law game
view current version
current admin

alpha prototype: bouncers v1 | v2
multi-user prototype v1 | v2 [D8 source]
admin tool v1 [D8 source]
competitive teams v1 [D8 source]

purpose provide students simulation of multivariable system (ideal gas law) and tools for modeling through multiuser environment
notes july 13
Basic idea hatched by Paul S with input from Mike K. Needs to present overview of rules of system (simulation on computer, or allow students to manipulate one var at a time). The game involves teams applying pressure, temp, and numbers of particles. Teams might compete to each achieve a different pressure as goal.

july 14
Demo of bouncing particles with constant velocity inside a bounding chamber- chamber can be enlarged but not yet shrunk! Ultimately will have capbility to specify number of particles and relative initial velocities.

 

july 17
Demo can now be adjusted to change width by left and right side location changes. Second version allows controls for number of particles

july 25
Discussions with Paul S and Mike K about the animation issues. Bounding ball model is okay for student's visualization, provided upfront modules explain it as a "ideal" representation. Bouncers demo is slowed by calculating for collisions; agreed that is is acceptable to do collisionless which makes the speed reasonable. Each particlde will represent 1 mole of gas molecules, and the basic volume will be 22.4 liters, making it atmospheric T&P. All variables will be displayed as guages. Perhaps collisions could make particles change size for 3D effect?

july 29
Re-programmed particle behavior to be object-oriented, animation now will fade in and out for more of a 3D effect. The fade-in and out is linked to the initial random generated velocity, so that slow moving particles fade slower than fast moving ones. Application now allows change of volume, number of moles of gas. The Multiuser Library functions are used to enable a listing of group members as well as provide chat communication. Underlying Mult-user architecture is built on James Newton's Whiteboard example from the "goodies" example from the Director 8 CD.

aug 1
Because the cut and paste Multi-user code was top heavy and too complex to modify, I created from scratch a simpler series of commands using a single parent script to create a global reference to the MU connection, and to do some simple data tracking (user name, group entered, etc). This allowed be to keep the chat and group list behaviors from the D8 library, with some modfications that removed the reference to the MU Xtra instance from the actorlist and referred to the ones in my own global.

This is now the first working multi-user prototype.

I also developed a generic front end login that could be used for any MU application we create here (at CREATE!). This features the flexibility to have editbale fields for the password and server IP, but hides then if we choose. It also allows us to define the name of the movie that we will connect to and options to have users transferred there in a single MU group, or from a list of groups that we pre-define, or randomly chosen from a list of groups we pre-define. The settings can be changed by editing HTML parmeters.

Also added now is a sliding scale to set a temperature, so all of the controls are here. The next step is to develop a cool looking interface.

aug 4
Demonstrated thed prototype to the online chat of Director MU developers, with about 5 people at onnce manipulating.

Worked out some problems in the data being synchronized. One possible situation is where the first user in a session makes many changes, and users that arrive later will not see these effects. The application now makes use of MU Database objects to track what changes in V, n, T have been made, so later users will get the most recent snapshot.

The logic is that when a user logs on, we check the number of people in the group who are sharing this space. If that number is 1 (no one else is in there), the values of the variables are read from a database object atribute that contains default values. this then become written as the curent values, as well as any changes made by this and subsequent users. Later entering users just read in the current database attribute.

By using the database objects, the information persists on the server and we can develop a special application for the instructor to edit the default values, check in and monitor the current values, and maybe adjust them while the students ar working on them.

aug 8
The new interface is created with a representation of a glass chamber and a control panel to change the settings. I decided to keep a simple mechanism of pressing increase/decrease buttons for the 4 controls (left side chamber wall position, right site chamber wall position, gas molecules, temperature) rather than creating sliders and nozzles to turn.

In using this, I fiind that one could get focussed on just matching the target pressure and not thinking about why I might be clicking a certain button. Next version may be the two team competing version?

aug 10
Newest version demonstrated with the weekly Multiuser Developers Online Chat; with as many as 6 simultaneuous users from across the US it was difficult for one person to itroduce cnahes when others where all doing so at the same time. Perhaps it needs some sort of vote/consensus mechanism for ewach group to throttle some of the rapid activity?

aug 14
New competitive version allows two teams to use the same space, trying to achieve different pressures.

aug 21
Updated the working multi-user prototype version to use the same database application object methods as the competitive team version. This will allow our instructors tool to update the list of available groups via a web admin interface.

aug 22
The administers tool is about 90% ready. This is what an instructor will use to create/modify/delete studetn groups, to set or change the initial conditions for each group, to monitor/display the live data from active groups, and to send messages to the chat window of any or all groups.

aug 24
Modified and cleaned up the loading graphic elements for the working multi-user prototype, changed interface as per suggestions from Paul S to move the display readouts to the top of the chambe and exapnd the communications text area along the bottom. Also, the color of the chamber is now tied to the temperature, hot is red, cold is blue, and less hot or cold is more transparent.

It still needs some things to possibly reduce too much input from users. One thought is to "punish" excessive clicks on any control (more than 10 clicks on the temperature control in a given time frame would "lock" a user out of using it for say 2 minutes. Another is to tally each group's "click count" with some sort of weighted scale.

aug 25
The help button is now active (although the pages are not written yet). The behavior on the help button allows specification of a full or relative (to the .dcr file) URL for the help files. Since many will be the same, the help pages will be located in the mu_help directory on the web server.

feb 18, 2001
Current version running off a MUS server in my office at maricopa. Cleaned up user interface with a blue backdrop for the current data. Fixed problems with reacing the target pressure. Attempted a button to freeze action (store a copy of the actgorlist and reset actorlist to void) but it ran into a bad funk trying to communicate this over the server.

Admin interface now has a view to see all users in a selected group, and a multigroup display to list current datya on any or all selected groups.