Ruge’s Summaries for Week 9
This paper discusses the modifications made and the objectives achieved in creating the the ALICE 3d authoring framework. The goal of the project was to create a 3d authoring tool that could be used with little to know prior 3d authoring experience. It was based in a modified python environment that manipulated common characteristics to better adapt the tools for the common user. These included removing case sensitivity from the python language, removing the default integer casting of multiplication. Variations to the 3d tools included removing the access to a global coordinate system. instead users would manipulate the system with respect to the object in question which is more intuitive and also more in line with many other structured design principals. Many of the other changes involved strictly api adjustments such as unit conversion, and more intuitive time structuring and grouping. At the time the more interesting approach of the paper was the focus on the user rather than the efficency of the 3d rendering techniques.
Everquest
The Everquest paper analyzed the effect of Network Latency and Bandwidth on gameplay. I anticipated a more network protocol related topic discussing hte details of multizonal handoff and phase handling as I have read in similar WoW papers and other documents. But the Everquest paper created a testbed and analyzed how the latency affected actual play times and more import player interaction. They even examined player classes and mana rates. Looking at this information however does apply more directly to how such interactions could be applied to similar systems. The discussions of why certain playthrough times were affected by lag, define the problem with immersion very specifically. In certain instances they state that the players could no longer stay in the fight because they could see control or anticipate the monster. In affect they were no longer immersed. These simple measurements effective captured a simple quantitative metric for immersion.
DART
The DART paper summarizes the concerns of developing an AR development framework and how the DART system addresses them. It states from the beginning that there is likely no perfect answer, and this is proven today, as the tools are still constantly changing. But many of the points the paper addresses are now and will be true for the foreseeable future. Some may flex a little as other 3rd party toolkits become more plentiful, and have more abstract and available API for high level languages like javascript. Some tasks will always be better suited for work in Code rather than GUI and vice versus. Some of the tools will always (Macromedia is gone) change, but problems that they discuss, such as timing, and sensor data, may be a problem even with technology more sophisticated that we have today. Even if technology gets better, the tools we develop for will likely need to function on lower grade hardware, think of developing on military head mounts with the hope of a consumer using a LG goggle 5 years down the road.
Comments are closed.