Lecture Notes for CS 404/504 Games and Virtual Environments

• Lectures 2 + 3
• Lecture 4 + 5
• Lecture 6 + 7
• Lecture 8 + 9
• Lecture 10 + 11
• Lecture 12 (no lecture 13, too unlucky)
• Lecture 14 + 15
• Lecture 16 + 17
• Lecture 18 + 19
• Lecture 20 + 21
• Lecture 22 + 23
• Lecture 24 + 25
• Lecture 26 + 27
• Lecture 28 + 29

What's This Course About?

• How to write computer-based games
• How to develop collaborative virtual environments
• Graphics, networking, A/I, data structures, algorithms, I/O...

What's This Course NOT About?

• Vocational/technical training for the game industry
• DirectX, Direct3D, or other platform-specific API's
• How to use "level editors" or tweak other people's games

History of Computer Games

Game Development via "Natural Evolution"

Requirements Analysis	The gamer has an idea, not found in current games Idea is explored, and a "vision" for a new game is realized.
Design	Game User Interface. File formats. Network communication protocols.
Implementation	Coding and Art. Ratio varies. Art is overwhelming coding in modern commercial games.
Testing	Hire gamers at $6/hour to test your game. Alpha and beta test.
Release	Release your game through a publisher and distributor, or via internet.
Maintenance	If you get this far, you are more successful than 98% of game efforts.

Actually, the waterfall model is "all wrong" for game development, which should probably follow a "natural evolution", meaning working prototypes start out with textual depictions of core game logic, proceed to simple graphics, and then evolve more powerful 3D and multi-user capabilities. This week's topic: basic introduction to Icon and Unicon

Parlor games: Dice, Cards, and Board games

Announcements

• MY OFFICE HOURS on Tuesday will have to reschedule to avoid a conflict. How about Mondays @ 3-4pm?
• Do not miss Thursday's class, we'll have a very special guest-talk from Ivan Lumala of Microsoft about their new game programming environment for the rest of us.
• Please turnin both PAPER and ELECTRONIC copies for the homework that is due Friday.

Brief Summary of Rules of Yahtzee

More generally: I welcome input where the Game Book needs additional material, and when it is missing something, I welcome questions. But when you need some info like this, please use google and dig it up.

Text Adventures and ASCII Art Games

Most computer games are simulations of some imaginative situation. The computer both (a) allows more detailed simulations than players can manage using pencil and paper, and (b) frees the player from the need for a referee or game master.

Text Adventures

The ORIGINAL text adventure Infocom games (Java applets) Hamlet adventure (original cia.icn) improved cia2.icn

Anatomy of a Text Adventure

ASCII Adventures

Comments on HW#2

• 14 submissions, others are missing?
• 9 points possible, 8/9 was an A
• graphical sophistication of solutions varied widely
• format your code for printable hard copy
• indent 3-4 spaces per syntax level
• Best Practices:
  • animating the dice so they "roll"
  • printing out message showing available categories each time
• Bugs to Avoid
  • no paper copy; paper copy with unreadably small font
  • turning in with syntax error
  • not writing enough output for user to tell where they are and what they are doing, user getting "lost"
  • not reading the rules carefully, scoring wrong
  • not checking input carefully
  • making it unclear how to quit; quitting awkwardly
  • if answer == 'y' (no character literals in this language)
  • not using +:=, -:=
  • not using case str of { "this": { ... } "that": { ... } }
  • not using x < y < z
  • if find(2&3&4&5, !dice) ...
  • using $include when you should link

Classic arcade games

• Brick
• Sesrit

Announcements

• There is a job opening at hp. Did you all get the notice?
• Six text adventures were submitted as of 1pm, with varying degrees of novelty.
• 3 XNA homeworks submitted so far, one without resources (avoiding a 50mb turnin?), one with a build problem (missing font), one that I could actually run...
• Instructions if you are in the half of the class playing "Rope-A-Dope": finish and turnin when you can, you will lose one point per day.

Unfinished Business with Sesrit Rotation

• Blasteroids

Note on Unicon

1. Consider the following code abstracted from a student HW3 submission:

   L := ["bullets", "rice", "beans"]
   flag := 0
   every
      {
      if !L == "beans" then flag := 1
      }
   

   I will say: this code works. What is interesting about it?
2. Someone made a friendly remark on Tuesday, suggesting that they be allowed to abandon Unicon and focus on C# / XNA for the semester. In the virtual environments part of the course, we are going to face some substantial technical challenges whichever language we use. My class discussions, and homeworks at that point, will be based on a particular virtual environment written in Unicon. While I am open-minded towards allowing student projects in other languages, I am doubtful of the likely result.

Strategy games

What is strategy? What is tactics?

Real Time vs. Turn-based

Example Old-School Turn-Based Strategy Games

• Empire (ascii art) (description)
• Ogre and G.E.V. (microgames)
• Civilization (there was a boardgame prior to Sid Meier's PC games, but Sid Meier's Civilization is quite a bit different)
• SPI and Avalon Hill Games (detailed simulations of the most famous battles in history, Civil War, WW II, etc.)

Writing your own Ogre game

class Hex(row, col,    # integer row and column #, used in x,y calculations
          terraintype, # for ogre: "normal" and "impassable"
          units,       # list of (0-or-1, or 0-or-more, check rules) unit objs
          exits)       # list of 6 adjacent hexes
   method draw()
      # draw the terrain
      if terraintype == "impassable" then {
         Pattern()
         }
      FillPolygon( vertices... )

      # draw the edges
      DrawLine(vertices...)
      every i := 1 to 6 do {
         if exits[i] === &null then {
            # draw the impassable edge
            }
         }

      # draw the units
      if *units > 0 then # draw what is on the top of the stack
         units[1].draw()
      if *units > 1 then # draw "multi-unit stack" decoration
   end
end

Homework 3 grading status report

The next homework assignment: a strategy game

WoW in-class test and server survey

Ogre game example (cont'd)

Brief Review of Ogre Game Rules

Now What?

Unit class

class representation for Units, including Ogres. Let's design it now.

user input

translation of mouse actions on the map into events on (row,col) hex locations.

execution of game rules

turn sequence; movement and combat

AI

The game can be two-player with no AI, but the most fun scenario is where the computer plays the Ogre and you the puny human plays the humans trying to survive. Alternately, you could be the Ogre, and let the computer try to survive.

Example Real-Time Strategy Games

• Warcraft (not World-of, just Warcraft)
• Dune II, Command and Conquer
• Dozens of me-too games, including many great ones

Trouble in Denmark?

Technical Troubles

People compiling and linking Unicon programs can get cryptic errors

If you are not able to include standard include files, or link standard library modules, you probably haven't added unicon/bin to your path. In extreme cases (if a library directory had binary file corruption or was copied from a different host platform OS or architecture) you might have to recompile your libraries.

People running Unicon programs can get cryptic error messages like this one.

Cryptic Unicon error messages are actually pretty darn useful.

People running XNA applications can deliver programs that won't run for me! Dr. J still hasn't been able to view one of the XNA

Nontechnical Troubles

Dr. J has not taught you well enough

Help Dr. J by asking more questions

Macromedia flash recordings of your XNA program don't really allow me grade you properly.

I need to be able to compile and run your programs myself

RPG's

Role Playing is some stupid exercise used by psychologists and counselors to try to get people to see situations from different points of view. But Role Playing Games starting with Dungeons and Dragons applied that basic technique to imaginative first-person gaming.

Example Pencil-and-Paper RPG's

• Dungeons and Dragons, Tunnels and Trolls, Bunnies and Burrows...
• Micro-RPG's (Melee, Wizard)
• Traveller (SCI-FI), and Shadowrun (Cyberpunk)
• Vampire the Masquerade, and other monster-genres

Example PC-based RPG's

• Rogue, hack, nethack, moria
• Diablo
• Icewind Dale, Neverwinter Nights

VIRTUAL CLASS on Thursday this week!!

Sim Games

• Hamurabi
• Taipan
• SimCity
• The Sims
• Sid Meier's Pirates!

FPS's

• Wolfenstein 3D
• Doom
• Quake (source)

Status Check: how is homework going? Need any help?

Microsoft Game Development in CS Education Recap

• A look through the proceedings.

I spent last Thursday through Saturday cruising the Caribbean sea from Orlando down to the Bahamas and back, listening to talks on game development given by Microsoft people as well as professors and other industry partners (EA, GarageGames, AMD). Microsoft sees game development as a recruiting tool for CS studies and careers. There were a lot of talks about XNA, DirectX version 10, etc. GarageGames gave a talk on TorqueX, a free commercial grade 2D game engine which works with XNA Game Studio Express. A representative from the National Academy of Sciences gave a talk arguing that games were actually better than lectures at education; we remember stuff better when we are emotionally involved at the time we hear it. Recruiters from EA gave a strong preference for a real CS degree with plenty of math -- don't think that you'd have as many employment options if you ran off to videogame school and skipped the hard stuff. AMD pointed out that desktop PC's will soon be like the Xbox 360 -- many CPU's and/or GPU's. By the end of the year, it will be pretty easy to buy a desktop PC with 2 quad core processors (8 CPU's) and a quad-GPU graphics config.

A talk that I regrettably missed (because I couldn't tell what room it was being held in) talked about using MMRPG's as the application for a database class based on SQL. Many commercial MMRPG's are based on SQL back-ends.

A talk that I didn't miss covered a free academic game engine developed at University of North Texas. While I probably am not ready to adopt their entire Microsoft-based engine and toolset, they are using a 3D model file format (with export plugins available for major tools such as Maya and Blender) called S3D that we will probably use in this class in the next few weeks.

On Multiuser games

• TCP, IP, and UDP
• (internet) ports
• packets and streams
• latency and bandwidth
• clients and servers
• synchronous and asynchronous

Addition to the book! Based on our experiences writing a multiuser virtual environment, we ended up adding two new functions to Unicon named sysread() and syswrite(). They are like read() and write(), except: sysread() returns immediately with available data, rather than waiting until data arrives (it is non-blocking). syswrite() sends data immediately, rather than buffering up data to be written. In practice, sysread() turns out to be essential. Lecture 15. Network Programming

News

A few words on what is coming down the pipe

Our next "unit" in this class will be on 3D graphics. I will assume no prior knowledge on your part, and we will work through several examples, and you will have an initial homework on basic 3D graphics programming topics.

I posted the file format document for the S3D model file format to the class web page. It is a pretty easy format, either you or I will write the parsing code, after which for a second 3D graphics homework, you will write rendering code to draw models in this format.

The missing networking buzzword: Protocol

Two major families of protocols: stream-oriented and packet-oriented. The internet protocols IP, TCP, and UDP are packet-oriented and specify the exact binary layout of data within fixed-size headers, followed by variable-length data payloads which can be either binary or textual. For example, IP specifies 20 byte headers.

Packet-oriented protocols tend to be efficient; the network delivers C/C++ structs intact. Packet-oriented protocols are more effective when working on a homogeneous set of machines (all the same CPU, etc.). Machines with different byte ordering or CPU wordlengths benefit less from, and have to be careful of bugs when dealing with such binary data.

Stream-oriented protocols are usually more human-readable, with ASCII text line-oriented message formats. For example, HTTP protocol sends its headers as a sequence of lines with a easily readable format like:

Fieldname: value
Fieldname2: value2

Network programming examples from the Unicon Book

Review chapter 5. Be able to describe open() modes "n", "na", "nl", "nu", "nua". read about the select() function.

Connecting in Unicon

   f := open("machine:port", "n")

Once the connection is open, the program has a file opened for reading and writing. Care must be taken to design communications so that no deadlock can occur where both sides are waiting for the other. In many client- server applications there is a strict request-response format to the communications.

Receiving a Connection in Unicon

In any case, a server requests an incoming connection from a client with

   f := open(":port", "na")

   f := open(":port", "nl")

Accept mode "na" will block until a connection is received. Listener mode "nl" will open an incoming connection partially ("listening") without waiting for a connection; it must be used with the select() function. When a listener is passed in to select() as one possible communication that might happen, and when an incoming connection actually occurs, the "listener" is converted into a regular opened connection. This is handy in servers, and enables them to serve multiple callers without having to use "threads".

select()

while *(L := select(f1,f2,f3,timeout)) =  0 do handle_timeout()
every f := !L do {
   ... handle a read on one of f1, f2, or f3 where input is available
   }

Look at the Examples in Chapter 15 of the Unicon Book

Scalability and multi-user gaming

bandwidth

this is the "easiest" limit to remember, most of us know our internet connection can only transmit so many bytes per second, so transferring big files will take time. What you need to add to that knowledge is that during the same connection, bandwidth fluctuates wildly as other internet traffic varies. Also, across a WAN the bandwidth is limited by the "weakest link", so on my office machine with its gigabit network, connectivity to NMSU is only 1.2 megabits/second, and this factor of 800 slowdown varies from second to second (from 800X slower than the computer's NIC can handle to 1600X to infinity). Compressing files might take many billions of CPU instructions but still greatly speed up a large transfer; it is a typical bandwidth-reduction mechanism.

latency

the delay between sending and receiving packets also varies from very low to very high. Typical across campus latencies might be 50ms (up to 20 times per second? up to 10 round trips per second?), while latency across the internet is often in the 1.5 second range. Multiuser games have to be designed to not depend on low latency; for example, a "heartbeat" to keep all players in sync is a tempting idea, but if local client redraws waited for such a heartbeat, you would not get a high enough refresh rate for a smooth animation. Dead-reckoning is a typical latency-compensation mechanism.

# of packets

The bandwidth may be near infinity, the latency may be no problem, and the network may still impose limits: each packet costs the OS a lot of processing time to handle, whether it carries 6 bytes or 1.5KB or more. Packet aggregation is a typical packet reduction mechanism.

GPU

A GPU may easily be a limiting factor on the # of users. If graphic updates/changes are proportional to # of users, or # of polygons to be displayed is proportional to # of users, adding more users will gradually break the client's ability to update, starting with low-end non-GPU computers and working up even to high end machines. Level-of-detail is a typical means of compensating for limited GPU resources.

CPU

A CPU may easily impose a limit on # of users, CPU's handle core gameplay and user interaction plenty fast, but games tend to dump lots of extra work on the CPU, assuming it is an infinite resource. If you are on a low-end CPU, you may save CPU cycles by NOT doing a lot of the other limitation-reducing techniques which suck CPU resources. Switching to more efficient algorithms and data structures, and doing profiling and performance tuning are other typical CPU-saving techniques.

Main memory

Main memory is usually a major bottleneck in modern computing systems.

OS

Any time you interact with the operating system will greatly slow your program down. Whole careers have been built on the art of reducing the number of OS calls. For example in MS-DOS days the standard thing to do was to skip the OS and write directly to video memory for fast graphics. In modern UNIX and Linux systems, processes were too slow so threads were invented, and OS threads were too slow so "user threads" were invented.

disk

A program that spends time waiting for disk I/O may not be able to sustain game-level refresh rates. Many disk operations can be avoided by leaving files' contents in main memory, and only writing changed items out to disk periodically.

How to Handle More Users - discussion of processes and threads

Lecture 16. Virtual Environments. Second Life Intro.

Midterm Exam Discussion

Agenda

Although many virtual environments are games, other virtual environments are used for serious purposes. Potential research in this area might conducted in order to

1. advance the state of the art in graphics realism in CVEs
2. advance the state of the art in scalability (handle more users)
3. apply CVE technology to new uses or application domains
4. advance the state of the art in virtual object behavior, virtual character AI or simulation of virtual groups and societies
5. reduce the cost of developing and experimenting with CVEs

During this phase of the course, we will be looking in some depth at two software systems: Second Life, and VIEW.

Introduction to Second Life

Assignment: we will be using Second Life in the near future. Go Ye therefore and download the second life client, and create your free account. Read through second life tutorials in preparation for an assignment that asks you to create one or more virtual objects. See if you can figure out how virtual buildings are constructed.

Introduction to VIEW

3D Modeling Tools?

More on Virtual Environments

Hard Technical Subjects in CVEs

Because writing a CVE is potentially so incredibly technically challenging, there is a danger that the only people who can do it are large multi-million-dollar industry labs. In this class we are interested in CVEs as vehicles for both direct and indirect research:

• research results that enhance the value/usefulness of CVEs (CVEs as a direct research domain; communication/interaction/etc.)
• research results that reduce the difficulty of writing CVEs (CVEs motivate research in programming languages and systems)

CVEs as Places for Action and Interaction

• textual chat; talking and listening
• by seeing each other, waving, smiling, etc.
• by following each other to specific locations or shared experiences
• by manipulating objects in the virtual environment. The objects might correspond to real-world artifacts: files, printers, etc.
• by creating new objects or spaces in the virtual environment.
• by recording an experience for others to view at a later time
• ??? how about some suggestions ???

Collaborative Work

• A CVE exists for a Purpose; people use it to Do Something.
• CVE's are inferior to real-world collaboration facilities. Under what circumstances do they make sense?
• A CVE provides a shared context among users. They should be able to see the same things.
• A CVE supports awareness of others: users should see each other.
• A CVE enables communication between users.
• A CVE might allow multiple, flexible viewpoints.

Shared Context

Awareness of others

There is foreground awareness and background awareness. Things should be in the background unless/until they start interfering with what you are doing.

Background awareness may include users' real locations and schedules, whether they are at their keyboard and looking at the screen at the moment, what task they are performing, etc.

Communication

CVE's and Entertainment

With a compelling proof-of-feasibility like Everquest in mind, we cannot help but believe that a CVE will soon dominate many fields of remote communication and endeavor. It is only a matter of time before CVE's are used for distance education, virtual dating and sex, live theater, circus and other public performances, as well as major meetings such as conferences, associations, and the activities of governmental organizations. Lecture 17. 3D Graphics.

Link of the Day

• http://blog.wired.com/geekdad/2007/03/turn_your_kids_.html
• Someone's Top 10 Games List

Reading Assignment

Parallel Concerns

• collect raw data for our virtual CS department
• learn about 3D programming
• learn about 3D modeling
• learn SecondLife's capabilities
• learn stuff about VIEW

SecondLife tidbit of the Day

Raw Data

There is one other kind of raw data I'd like you to collect: yourselves. I want to push beyond the crude avatars I've used previously, and model ourselves in crude, low-polygon textured glory.

On Coordinate Systems

To anyone who gets confused about a positive axis running from right to left or from top to bottom instead of what you were expecting: this just means that your perspective is turned around from those used by the world coordinates. If your character rotates 180 degrees appropriately, suddenly positive values go the opposite direction from before and what was right to left is the more familiar left to right. The point: world coordinates are different from your personal eyeball coordinate system, don't confuse them.

A Common Coordinate System

measure its x and z using FHN,
• measure its y (how?)
• identify its exits (doors and openings) and for each exit,
  • its connecting room
  • its x,y,z, height, and plane
• collect textures for floor, walls, ceilings, doors, decorations
• identify major obstacles (essential virtual objects in the room)

Sample Room

Room {
name SH 167
x 29.2
y 0
z 0.2
w 6
h 3.05
l 3.7
floor Wall {
texture floor2.gif
coords [29.2,0,0.2, 29.2,0,3.9, 35.2,0,3.9, 35.2,0,0.2]
}
obstacles [
   Box { # column
      Wall {coords [34.3,0,0.2, 34.3,3.05,0.2, 34.3,3.05,0.6, 34.3,0,0.6]}
      Wall {coords [34.3,0,0.6, 34.0,0,0.6, 34.0,3.05,0.6, 34.3,3.05,0.6]}
      Wall {coords [34.0,0,0.6, 34.0,3.05,0.6, 34.0,3.05,0.2, 34.0,0,0.2]}
      }
   Box { # window sill
      Wall {coords [29.2,0,0.22, 29.2,1.0,0.22, 35.2,1.0,0.22, 35.2,0,0.22]}
      Wall {coords [29.2,1,0.22, 29.2,1.0,0.2,  35.2,1.0,0.2, 35.2,1,0.22]}
      }
   Chair {
          coords [31.2,0,1.4]
   	  position 0
	  color red
	  type office
          movable true         
         }
   Table {
         coords [31.4,0,2.4]
   	 position 180
	 color very dark brown
	 type  office
       }
   ]
decorations [
   Wall { # please window
      texture wall2.gif
      coords [29.2,1.0,0.22, 29.2,3.2,0.22, 35.2,3.2,0.22, 35.2,1.0,0.22]
      }
   Wall { # whiteboard
      texture whiteboard.gif
      coords [29.3,1.0,3.7, 29.3,2.5,3.7, 29.3,2.5,0.4, 29.3,1.0,0.4]
      }
   Windowblinds {
           coords [29.2,1.5,0.6]
           angle 90
           crod  blue
           cblinds  very dark purplish brown 
           height 3.05
           width  6
   }
]
}

Modeling Yourself

Evolving yourself gradually

• We could stick you in the as a bouncing sphere smiley face, or as a space marine or other precreated hardwired appearance
• We could stick you in as a lego-man with your real face in a square on the front
• What we would like to do is progressively model yourself in more detail until you are satisfied with the approximation.

Chad and Eric Say ...

1. You should start by learning to draw, and draw detailed sketches of front, side(s), and rear of your character.

Since we aren't artists, I will settle for digital photos

2. You should draw a polygon outline (profile) from the side view. The number of polygons might initially be low (20-30?). Each is an (x,y).

3. You extrude yourself by taking each (x,y) and making a right and left side (x,y,z) from it. z's can be taken my measuring your front view width, or measuring yourself in RL.

4. You map textures

5. You refine iteratively by editing vertices and adding surfaces.

Overview of Unicon 3D Facilities

From the CVS logs, it appears that since the report was last revised, a new function WSection() was added, along with JPEG texture support, and the ability to blend textures and colors. More improvements are under construction (fonts, transparency...).

The JEB1 Demo

Unicon has built-in graphics capabilities; the 2D facilities were written mainly by myself with help from some folks at the University of Arizona, and made portable thanks to an M.S. student at Arizona. The 3D facilities were designed and implemented by myself and former NMSU student Naomi Martinez, who did her undergraduate Math degree at NMSU.

To create a window, one calls open() with mode "g" for 2d and "gl" for 3D. If one assigns the opened window to the special keyword variable &window, it becomes the default for all subsequent graphics operations. One can pass additional attributes to the window at create time. In the following example, a window size 800 pixels wide, 750 high is given, along with a gray background. The "inputmask=k" specifies keypress and release events are to be delivered individually, instead of the usual merging of these events to form ASCII characters. If the window can't be opened, the program exits with an error message.

procedure main()
    &window := open("JEB1", "gl", "size=800,750",
		    "bg=grey", "inputmask=k") | stop("can't open 3D window")

Most attributes can be changed afterwards using function WAttrib(), which takes as many attributes as you like. The following line enables texture mapping in the window:

    WAttrib("texmode=on")

Assigning a value to a variable uses := in Unicon. Most of the rest of the numeric operators and computation is the same as in any programming language. In 3D graphics, a lot of real numbers are used. In the jeb1 demo, the user controls a moving camera, which has an (x,y,z) location, an (x,y,z) vector describing where they are looking, relative to their current position, and camera angles up or down. Initial values of posx and posy are "in the middle of the first room in the model". The rooms have min and max values for x,y, and z so:

	       posx := (r.minx + r.maxx) / 2
	       posy := r.miny + 1.9
	       posz := (r.minz + r.maxz) / 2
	       lookx := posx; looky := posy -0.15; lookz := 0.0

Unicon has a "list" data type for storing an ordered collection of items. There is a global variable named Room which holds such a list, a list of Room() objects. We will discuss Room() objects in a bit. This is how the list of rooms is created, with 0 elements:

    Rooms := [ ]

The code that actually reads a model file and creates Room() objects and puts them on the Rooms list is procedure make_model(). We defer the actual parsing discussion to later or elsewhere.

procedure make_model(corridor)
local fin, s, r
   fin := open(modelfile) | stop("can't open model.dat")
   while s := readlin(fin) do s ? {
       if ="#" then next
       else if ="Room" then {
	   r := parseroom(s, fin)
	   put(world.Rooms, r)
	   world.RoomsTable[r.name] := r
	   if /posx then {
	       # ... no posx defined, calculate posx/posy per earlier code
	   }
       }
       else if ="Door" then parsedoor(s,fin)
       else if ="Opening" then parseopening(s,fin)
       # else: we didn't know what to do with it, maybe its an error!
   }
   close(fin)
end

The following line steps through all the elements of the Rooms list, and tells each Room() to draw itself. The exclamation point is an operator that generates each element from the list if the surrounding expression requires it. The "every" control structure requires every result the expression can produce. The .render() calls a method render() on an object (in this case, on each object in turn as it is produced by !). Note that our CVE will probably want to get smart about only drawing those rooms that are "visible", in order to scale performance.

    every (!Rooms).render()

Lecture 19. Jeb1 Demo.

What About Ceilings?

A: OK, you caught me! There was no special ceiling syntax; before now a person had to put a decoration up there in order to change the ceiling. However, ceilings are very much like floors, so I went into model.icn procedure parseroom() and added the following after the floor code. We did not talk about the parser before now; for you compiler buffs it is a handwritten parser akin to a recursive descent; at syntax levels where many fields can be read, it builds a table (so order does not matter) from which we populate an object's fields. So the table t's fields correspond to what the file had in it, and the .coords here is the list of vertices which the object in the model wants.

   if \ (t["ceiling"]) then {
      t["ceiling"].coords := [t["x"],t["y"]+t["h"],t["z"],
                t["x"],t["y"]+t["h"],t["z"]+t["l"],
                t["x"]+t["w"],t["y"]+t["h"],t["z"]+t["l"],
                t["x"]+t["w"],t["y"]+t["h"],t["z"]]
      t["ceiling"].set_plane()
      r.ceiling := t["ceiling"]
      }

ceiling Wall {
texture jeb230calendar.gif
}

User Input, part A

   repeat {
      if *Pending() = 0 then { # continue in current direction, if any }
      else {
         case ev := Event() of {
	    Key_Up:    cam_move(xdelta := 0.05)		# Move Foward
            ... other keys
            }
         }

Events may be strings (for keyboard characters), but most are small negative integer codes, with symbolic names such as Key_Up defined in keysyms.icn.

$include "keysyms.icn"

jeb1 File Organization

Compiling is about the same on Windows and on Linux, it looks like:

unicon -c model
unicon jeb1

The Line Between jeb1.icn and model.icn

model.icn

Wall() is the simplest class here, it is just a textured polygon, holding a texture value and a list of x,y,z coordinates, and providing a method render(). Every object in the CVE's model will provide a method render().

class Wall(texture, coords)
   method render()
      if current_texture ~=== texture then {
         WAttrib("texture="||texture, "texcoord=0,0,0,1,1,1,1,0")
         current_texture := texture
         }
      (FillPolygon ! coords) |  write("FillPolygon fails")
   end
initially(t, c[])
  texture := t
  coords := c
end

Class Box() is more interesting, it is a rectangular area with walls that one cannot walk through, and a bounding box for collision detection. Doors, openings, and other exceptions are special-cased by subclassing and overriding default behavior. Rectangular areas are singled out because they are common and have easy collision detection; when a wall goes from floor to ceiling, collision detection reduces to a 2D problem.

Box() has methods:

• mkwall() (to make walls)
• render() (to draw)
• disallows(x,z) to assist in collision detection

Class Door() is not just a graphical object, it is a connection between (2) rooms, which can be open (1.0) or closed(0.0) or in between. It supports methods:

• render() to draw the door
• set_openness(o) to specify how open (ajar) the door is
• add_room(r) to attach a room to the door
• other(room) to compute the other room
• allows(px,pz) to check whether the door is open enough to walk through.
• start_opening(), delta(), and done_opening() when the user activates the door, as the door is opening or closing, and when it finishes. The direction toggles each time, between opening and closing.

Class Room()

class Room : Box(floor, # "wall" under our feet
	   ceiling,     # "wall" over our heads
	   obstacles,	# list: things that stop movement
	   decorations, # list: things to look at
	   exits,	# x-y ways to leave room
	   name
	   )

   method disallows(x,z)
      if /minx then calc_boundbox() 

      # regular area is normally OK
      if minx+1.2 <= x <= maxx-1.2 & minz+1.2 <= z <= maxz-1.2 then {
         every o := !obstacles do
            if o.disallows(x,z) then return
         fail
         }
      # outside of regular area OK if an exit allows it
      every e := !exits do {
         if e.allows(x,z) then {
            if minx <= x <= maxx & minz <= z <= maxz then {
               # allow but don't change room yet
               }
            else {
               curr_room := e.other(self) # we moved to the other room
               }
            fail
            }
         }
      return
   end

   method render()
      every ex := !exits do ex.render()
      WAttrib("texmode=on")
      floor.render()
      ceiling.render()

      every (!walls).render()
      every (!obstacles).render()
      every (!decorations).render()
   end

   method add_door(d)
      put(exits, d)
      d.add_room(self)

      # figure out what wall this door is in, and tear a hole in it,
      # for example, find the wall the please door is in,
      # remove that wall, and replace them with three

    every w := !walls do {
       c := w.coords
       if c[1]=c[4]=c[7]=c[10] then {
          if d.x = c[1] then write("door is in xplane wall ", image(w))
          }
       else if c[3]=c[6]=c[9]=c[12] then {
          if abs(d.z - c[3]) < 0.08 then { # door is in a zplane wall
             # remove this wall
             while walls[1] ~=== w do put(walls,pop(walls))
             pop(walls)
             # replace it with three segments:
             # w = above, w2 = left, and w3 = right of door
             w2 := Wall ! ([w.texture] ||| w.coords)
             w3 := Wall ! ([w.texture] ||| w.coords)
             every i := 1 to *w.coords by 3 do {
                w.coords[i+1] <:= d.y+d.height
                w2.coords[i+1] >:= d.y+d.height
                w2.coords[i] >:= d.x
                w3.coords[i+1] >:= d.y+d.height
                w3.coords[i] <:= d.x + d.width
                }
            put(walls, w, w2, w3)
            return
            }
         }
       else { write("no plane; giving up"); fail }
       }
   end

   method add_obstacle(o)
      put(obstacles, o)
   end
   method add_decoration(d)
      put(decorations, d)
   end

Event Handling

   method message_loop(r)
   local L, dialogwins, x
      connections := []
      dialogwins := set()
      every insert(dialogwins, (!dialogs).win)
      every put(connections, !dialogwins | !subwins | !nets)
      while \r.is_open do {
	 if x := select(connections,1)[1] then {
            if member(subwins, x) then {
	       &window := x
	       do_cve_event()
	       }
            else if member(dialogwins, x) then do_event()
            else if member(nets, x) then do_net(x)
	    else write("unknown selector ", image(x))

	    # do at least one step per select() for smoother animation
	    do_nullstep()
	    }
         else do_validate() | do_ticker() | do_nullstep() | delay(idle_sleep)
	 }
   end

   method do_cve_event()
   local ev, dor, dist, closest_door, closest_dist, L := Pending()
      case ev := Event() of {
	 Key_Up: {
	    xdelta := 0.05
	    while L[1]===Key_Up_Release & L[4]===Key_Up do {
	       Event(); Event(); xdelta +:= 0.05
	       }
	    cam_move(xdelta)		# Move Foward
	    }
	 Key_Down: {
	    xdelta := -0.05
	    while L[1]===Key_Down_Release & L[4]===Key_Down do {
	       Event(); Event(); xdelta -:= 0.05
	       }
	    cam_move(xdelta)	# Move Backward
	    }
	 Key_Left: {
	    ydelta := -0.05
	    while L[1]===Key_Left_Release & L[4]===Key_Left do {
	       Event(); Event(); ydelta -:= 0.05
	       }
	    cam_orient_yaxis(ydelta) # Turn Left
	    }
	 Key_Right: {
	    ydelta := 0.05
	    while L[1]=== Key_Right_Release & L[4] === Key_Right do {
	       Event(); Event(); ydelta +:= 0.05
	       }
	    cam_orient_yaxis(ydelta)	 # Turn_Right
	    }
	 "w":       looky +:= (lookdelta := 0.05)  #Look Up
	 "s":       looky +:= (lookdelta := -0.05) #Look Down
	 "q": exit(0)
	 "d": {
	    closest_door := &null
	    closest_dist := &null
	    every (dor := !(world.curr_room.exits)) do {
	       if not find("Door", type(dor)) then next
	       dist := sqrt((posx-dor.x)^2+(posz-dor.z)^2)
	       if /closest_door | (dist < closest_dist) then {
		  closest_door := dor; closest_dist := dist
	          }
	       }
	    if \closest_door then {
	       if \ (closest_door.delt) === 0 then {
	          closest_door.start_opening()
	          }
	       else closest_door.done_opening()
	       closest_door.delta()
	       }
	    }
	 -166 | -168 | (-(Key_Up|Key_Down) - 128) :    xdelta := 0
	 -165 | -167 | (-(Key_Left|Key_Right) - 128) : ydelta := 0
	 -215 | -211 : 	lookdelta := 0
        }

      Eye(posx,posy,posz,lookx,looky,lookz)

   end

Lecture 20. 3D Modeling, Part 1

JEB Update

Note: if you haven't turned one in yet, it is either because (a) you don't feel comfortable that you understand what is required (in which case you should be asking), (b) you are having technical difficulties (quite plausible, in which case you should be complaining or asking for help), or (c) you are a slacker, or are working on other courses, in which case I should just ding you lots of points for lateness. Let me know if you are in the (a) or (b) category, otherwise I'll figure it is (c).

S3D File Format Overview

Lecture 21. 3D Modeling, Part 2

Fun for the day: jeb2.zip and view.zip

Student question for the day: my room is not a perfect rectangle, it has an extra column jutting out on one of the walls, what do I do?

Answer: in HW7 such a thing might be omitted; in HW8 you might get around to including the column as an obstacle (a virtual Box) in your .dat file. The obstacles section is also where things like bookshelves and tables might go.

obstacles [
   Box { # column
      Wall {coords [34.3,0,0.2, 34.3,3.05,0.2, 34.3,3.05,0.6, 34.3,0,0.6]}
      Wall {coords [34.3,0,0.6, 34.0,0,0.6, 34.0,3.05,0.6, 34.3,3.05,0.6]}
      Wall {coords [34.0,0,0.6, 34.0,3.05,0.6, 34.0,3.05,0.2, 34.0,0,0.2]}
      }
]

Where we left off: Dr. J took a first pass at HW8 and the Final Project descriptions. Dr. J said: you really need to see some sample S3D files in order to get a feel for the beauty of the S3D file format. Dr. J had to update the s3dparse.icn a lot when testing it on real S3D files. Real S3D files may have various nonfatal "bugs". There was even a bug in the S3D file format document.

We also took a look at the desperate situation vis a vis creating 3D models (a difficult job performed by experts with much training) and our need to build such models for our games and virtual environments. Let us continue from there.

As you recall, Dr. J has the following normalized texture images of himself. Dr. J is 5'9" (1.75m), his elbow-elbow width is approximately 24" (0.61m) and his front-back is 11" (.28m) at the belly.

Dr. J Model 0 - Stuck in a PhoneBooth, Hardwired Code

    drawavatar( ? (world.Rooms) )

procedure drawavatar(r)
    # place randomly in room r
    myx := r.minx + ?(r.maxx - r.minx)
    myy := r.miny
    myz := r.minz + ?(r.maxz + r.minz)

    # ensure a meter of room to work with
    myx <:= r.minx + 1.0; myx >:= r.maxx - 1.0
    myz <:= r.minz + 1.0; myz >:= r.maxz - 1.0

    PushMatrix()
    Translate(myx, myy, myz)
    WAttrib("texmode=on","texcoord=0,0,0,1,1,1,1,0")
    Texture("jeffery-front.gif")
    FillPolygon(0,0,0, 0,1.75,0, .61,1.75,0, .61,0,0)
    Texture("jeffery-rear.gif")
    FillPolygon(0,0,.28, 0,1.75,.28, .61,1.75,.28, .61,0,.28)
    Texture("jeffery-left.gif")
    FillPolygon(0,0,0, 0,1.75,0, 0,1.75,.28, 0,0,.28)
    Texture("jeffery-right.gif")
    FillPolygon(.61,0,.28, .61,1.75,.28, .61,1.75,0, .61,0,0)
    PopMatrix()
end

Dr. J Model 0.1 - Stuck in a PhoneBooth, S3D File

// version
103
// numTextures,numTris,numVerts,numParts,1,numLights,numCameras
4,8,8,1,1,0,0
// partList: firstVert,numVerts,firstTri,numTris,"name"
0,8,0,8,"drj"
// texture list: name
jeffery-front.gif
jeffery-rear.gif
jeffery-right.gif
jeffery-left.gif
// triList: materialIndex,vertices(index, texX, texY)
0, 0,0,256, 1,0,0, 2,256,0
0, 0,0,256, 2,256,0, 3,256,256
1, 4,0,256, 5,0,0, 6,256,0
1, 4,0,256, 6,256,0, 7,256,256
2, 7,0,256, 6,0,0, 1,256,0
2, 7,0,256, 1,256,0, 0,256,256
3, 3,0,256, 2,0,0, 5,256,0
3, 3,0,256, 5,256,0, 4,256,256
// vertList: x,y,z
0,0,0
0,1.75,0
.61,1.75,0
.61,0,0
.61,0,.28
.61,1.75,.28
0,1.75,.28
0,0,.28
// lightList: "name", type, x,y,z, r,g,b, (type-specific info)
// cameraList: "name", x,y,z, p,b,h, fov(rad)

S3D Rendering, Version 0

Design note #1: parsing and rendering constitute enough behavior to go ahead and make a class (or maybe a built-in) out of this.

Design note #2: while we can make a generic S3D renderer fairly easily, to animate body parts (legs, arms, etc), our model will need to insert Rotation capabilities at key articulation points. We will consider this and the S3D part mechanism after we get "out of the box" into a higher polygon count.

Performance note: in "real life" there are polygon "mesh modes" that would allow several/many triangles in a single call. In hyper-real life, I am looking for a student research assistant to implement S3D file loading and rendering in C as built-ins for Unicon. Note that I have begun planning a u3d file format as a minor simplification based on s3d.

procedure draws3d(r)
   loads3d("drj.s3d")
   # place somewhere in room r
   myx := r.minx + ?(r.maxx - r.minx)
   myy := r.miny
   yz := r.minz + ?(r.maxz + r.minz)

   # ensure a meter of room to work with
   myx <:= r.minx + 1.0
   myx >:= r.maxx - 1.0
   myz <:= r.minz + 1.0
   myz >:= r.maxz - 1.0

   PushMatrix()
   Translate(myx, myy, myz)
   WAttrib("texmode=on")

   every i := 1 to triCount do {
      tri := triangleRecs[i]
      v1 := vertexRecs[tri.vi1 + 1]
      v2 := vertexRecs[tri.vi2 + 1]
      v3 := vertexRecs[tri.vi3 + 1]
      Texture(textureRecs[tri.textureIndex + 1]) |
	 stop("can't set texture ",
	      textureRecs[tri.textureIndex + 1])
      WAttrib("texcoord=" || utexcoord(tri.u1,tri.v1) ||
	      "," || utexcoord(tri.u2,tri.v2) ||
	      "," || utexcoord(tri.u3,tri.v3))
      FillPolygon(v1.x,v1.y,v1.z, v2.x,v2.y,v2.z, v3.x, v3.y, v3.z)
      }
   PopMatrix()
end

Getting Rid of the Telephone Booth

"The CVE is Too Fast"

In the "old days" gamers put in delays by having the computer count up to some number (say, a thousand) obtained by trial and error. This technique is bad because CPU speeds change from computer to computer. What we want is not CPU time, either, we want wall clock time, with sub-second precision (100ths of a second would probably be good enough). In Unicon, we want gettimeofday() which returns a record with the current time in seconds and microseconds. At 30 frames per second (33 milliseconds) the animation is pretty smooth, and we can afford to slow it down; at 60 frames per second (17 milliseconds) our monitor isn't going to go much faster even if our eyes and fingers could keep up.

   thistimeofday := gettimeofday()
   thistimeofday := thistimeofday.sec * 1000 + thistimeofday.usec / 1000
   if (delta := thistimeofday - \lasttimeofday) < 17 then {
      delay(17 - delta)
      }
   lasttimeofday := thistimeofday

   timetimeofday := gettimeofday()
   thistimeofday := thistimeofday.sec * 1000 + thistimeofday.usec / 1000
   if delta := thistimeofday - \lasttimeofday then
      velocity := 0.05 * delta / 10
   lasttimeofday := thistimeofday

On Mouse Events

The keywords &lpress/&ldrag/&lrelease correspond to the left mouse button. A typical sequence would have an lpress, 0 or more ldrags, and an lrelease. Keywords &x and &y give the mouse location at the event. There are some other attributes (&meta, &interval) you can use, e.g. to detect doubleclicks. Lecture 22. SecondLife and Stuff

SecondLife

Compared with World of Warcraft, there is nothing to do, and everything to do. Instead of your character becoming skilled in pretend fishing, in SL you might yourself become skilled in creating virtual content, and getting paid for it.

User-Created Content

Creating 3D Primitives

You can't own land without a premium ($10/mo, or 6/mo on yearly subscription), so you may want to start in a sandbox. Dr. J went ahead and subscribed so as to buy some land we can work on. It turns out for your first purchase of land you can buy 512 square meters at a steep discount. Is that enough for our building? Dr. J tried to buy his 512 sq. meters this afternoon, but the "search" tab wasn't finding any available. I have to try again later, so in the meantime, let's find a sandbox.

Discussion/demo of creating an orange ball in SL goes here.

Off-hand, this looks like a very reasonable and general mechanism for making virtual things, and a lot nicer than writing code by hand for everything. It would be interesting to study their "file format" (or perhaps their network protocol) for such objects. The axes (z is up, instead of y) is probably intuitive to everyone except programmers.

LSL

The LSL is documented at http://lslwiki.net/lslwiki/wakka.php?wakka=HomePage

LSL is vaguely Java-ish, but not really very similar despite their claims. Every script is a "finite state machine", more in the software engineering design sense than the theory of computation sense. The set of events that can happen is predefined/hardwired in LSL; very different from Java where you define what methods your object responds to.

default {
touch_start(integer total_number) {
   llSay(0,"Hello World");
   }
}

default
{
    state_entry()
    {
        //llSay(0, "I am the avatar of hoops!");
    }

    touch_start(integer total_number)
    {
        llSay(0, "Woo hoo.");
        llSetColor(<1,0.7,0.7>, ALL_SIDES);
        state bouncing;
    }
}
state bouncing {
       touch_start(integer total_number)
       {
           llSay(0, "Ho boy.");
           llSetColor(<0.5,0.25,0.25>, ALL_SIDES);
            llApplyImpulse(llGetMass()*<0,0,15>,FALSE);
           state default;
        }
}

Minor aside: Linux computers behind CSAC can run the JEB demo. Add /net/faculty/jeffery/unicon/.bin.linux to your path to get Linux x86 Unicon binaries, and then compile away.

SecondLife update

Some obvious statements:

• the 1520m has a maximum number of primitives allowed, something like 345, maybe a little higher. This is not enough primitives for a "detailed" representation, even though I paid "a lot" of money for the land. Second Life is a land of crude approximation. This is OK.

  If we divided it into ... 15-17 students, it might mean for each student you could put at most 20 primitives in to represent your room. This is starting to sound comparable to the level of detail supported in VIEW, although VIEW has no cost and no hardwired, externally-imposed limit. Think about what 20 primitives you could use. Note that a complex object like a table might consume more than 20 primitives (in VIEW, the more detailed office tables are perhaps 34 primitives). Why is this limit important for SecondLife? What does it mean for us?

• In VIEW our entire concern so far has been internal to our building, but in SecondLife the building must obviously include an exterior. In fact, the exterior may be kind of important, and may eat some of our allowed primitive count. Also, we have to include primitives for internal connections that aren't yet present in anyone's .dat but are needed to provide full connectivity. I am not sure Second Life's teleport capability is precise enough for us to reach our unconnected rooms (what a cool idea for dungeons/torture chambers). Upshot: you may have less than 20 primitives.
• Given this hard limit on primitives, we can't afford to duplicate any walls between adjacent rooms. The jeb* demos and VIEW software is VERY naive in this regard, not minimizing its primitives at all.

Towards Virtual JEB

Among other things, we need to talk about stairwells and connections between rooms. So let's talk about that today. I am going to hypothetically add a stairwell portion (incorrect, but illustrative).

Towards Avatar Refinement

More generally, what does the VIEW Avatar class look like and how easy will it be to tuck our S3D-based avatar graphics into the existing class structure? As originally written, an avatar consists of only a few major parts, with legs and arms having hands and feet, but not (for example) knees and elbows. A previous student group semester project did add knees and elbows but up to now their work hasn't been merged into the main source code base.

Proposal: add S3D "parts" for each avatar body part in the model. Write a new subclass of Avatar and of Body Part to work off of (and be populated from) the S3D data.

Notes on the .dat parser/model constructor

procedure parseroom(s,f)
local t, r
   t := parseplace(s,f)

   r := Room(t["name"], t["x"], t["y"], t["z"],
	      t["w"], t["h"], t["l"], t["texture"])

Procedure parseplace() builds the table (a set of fieldname keys and associated values). The place is terminated by a "}", when it is by itself and not part of a field (parsed here by parsefield()).

procedure parseplace(s,f)
local t, line
    t := table()
    while line := readlin(f) do line ? {
	tab(many(' \t'))
	if ="}" then break
	if &pos = *&subject+1 then next
	parsefield(t, tab(0), f)
    }
    return t
end

procedure parsefield(x,s,f)
local field, val
   s ? {
      tab(many(' \t'))
      (field := tab(upto(' \t'))) | {
	  write("fieldname expected: ", image(tab(0)))
	  runerr(500, "model error")
      }
      tab(many(' \t'))
      val := parseval(tab(0),f)
      if field=="texture" then val := world.find_texture(val)
      if (field == "action") then {
	 /(x["actors"]) := []
	 put(x["actors"], 1)
         }
      x [field] := val
    }
end

procedure parseval(s,f)
local val
   s ? {
        tab(many(' \t'))
	if val := numeric(tab(many(&digits++"."))) then return val
	else if ="Wall" then return parsewall(tab(0), f)
	else if ="[" then return parselist(tab(0), f)
        else return trim(tab(0))
    }
end

If we chase inside parselist() we would find that other virtual objects must appear inside a list object, while Walls do not. It seems odd (and bad design, basically) to single out Wall() here as a special syntactic entity.

Dr. J should add additional notes here on parsewall() and parselist().

Lecture 24. A Virtual Environment Server and Network Protocol

Virtual CS Project Update

Source Forge

While we are on that topic, how many of you have used CVS (Concurrent Versioning System) before?

Initial Checkout

1. Get a copy of CVS. Although GUI CVS clients are available, Dr. J officially endorses command-line CVS clients, even on windows, see http://www.cs.uidaho.edu/~jeffery/win32/ and http://unicon.org/cvs.html
2. Obtain a SF ID, e-mail it to Dr. J (Dr J adds you to cve developers)
3. setenv CVSROOT yourname@cve.cvs.sf.net:/cvsroot/cve
4. setenv CVS_RSH ssh
5. cvs -z3 checkout cve
6. (say yes about connecting to cve.cvs.sf.net)
7. (type your sourceforge password when requested)
8. (cve subdirectory with entire project code is downloaded)

Getting Updated from Other Folks

• cvs update filename

Committing Your Room Updates

• cvs commit -m "reason for update" filename

The Server and Protocol

Developing n-User Chat Capabilities

• chat window is utterly stupid, doesn't use GUI classes
• server seems to recognize logouts pretty well; may need more work
• client does not currently handle disconnects/reconnects
• fairly easy to reorganize the main event loop to where it feels slow

Brainstorm Session: Server State and Network Protocol

Take a Look at the Rest of VIEW

A CVE Network Protocol, draft

Following Execution Across the Net

	 put(grouping, moveuid || "part " ||  name || " " || dir || " " || ang)

   method flushnet()
      if session.isUp() then {
         session.Write(grouping)
         grouping := list()
	 }
   end

# server.icn::run()
         if not (L := select( socket_list, Ladmins )) | *L=0 then next
...
                  if buffer2 := Tsock_pendingin[sock] || sysread( sock ) then {
...
                     buffer2 ? {
                        while buffer := tab(find("\n")) do {
                           ExecuteCommand( sock )
...
            "move":   {
           dynStHandler.saveAvatarState(Cmds,sock,Tsock_user, parsed[2])
           dynStHandler.getRecepientUsers(Cmds, sock, Tsock_user,
                          Tuser_sock, TrecpUser_sock,
                          "AvtMove",parsed[2])
           sendtoSelected(sock, TrecpUser_sock, parsed[2], "move", 1)

Lecture 25. Virtual Environment - More Internals

SecondLife News

I want to write down the SL user names, and set a specific meeting time, for those students planning on a SL-based semester project. SL projects should be more than just "I uploaded my room textures to SL". We need to define a scope together that we are happy with.

VIEW/CVE News

VIEW/CVE Source Code: the Next Level of Detail

System Challenges for CVEs

• Glueing together the solutions for individual components of the problem is not guaranteed to work.
• Latencies will be inevitable; consider how to best deal with them from a user's perspective.
• Distributed Legible City - bicycle VR with audio link
• Potential criticism of our CVE: nothing to do or talk about it while inside? Of course one can talk about the CVE itself, as a technical or artistic achievement, but what else?
• The behavioral quality lacking in VE's isn't due to lack of high-powered AI but due to the need for simple behaviors to be modeled within large numbers of everyday real-world objects.
• Environmental properties - how much ordinary behavior can be applied to all objects, because it is a property of the environment?
• Use multiple inheritance (environmental behaviors + object-specific behaviors)
• not just an Environment: a range of environments.
• Formally separate the (virtual) Reality, from each user's perception of it.

Understanding Network Requirements for CVEs

• Almost all network requirements derive from user behavior.
• Do users speak at the same time? That takes a more bandwidth than simplex audio
• Users are moving 15-45% of the time, and speaking 5-30% of the time. Can we use that to calculate bandwidth at the server? Greenhalgh's numbers are around 2KB/sec for motion (for 6fps), 2KB/sec for audio. This would be marginal on a 56Kbit modem (40Kbit connection = ~4KB/sec). Greenhalgh mentions, though, other systems are much cheaper for motion.
• Peak bandwidth will be higher if users' activities are highly coordinated. For example, if users are all instructed to do something at the same time.
• Three key actions: user movement, user audio, and discovering new objects and users. Invent methods to make these cheap; invent methods to scale them to users' bandwidths.
• Design a system to be as general as possible; only optimize heavily-used parts.
• DIVE idea: use standard WWW servers to serve up our data? Alternate: use a SQL database to serve up our data?
• MASSIVE-1: on 10Mbit ethernet, maxed out at 14 users

Distributed Architecture Implications

• indoor vs. outdoor
• zone structure
• who can see what and whom
• how many users? (more requires being able to restrict what's transmitted)
• the dynamics of the world (can you blow up walls?)
• the extensibility of the virtual world - can new objects be introduced on a live server, or only by shutting down, recompiling and sending out new executables to all users?

Project News

• I have had a cold these past few days.
• My father died unexpectedly last Friday.
• I got the CVE project stairs to the point where I could walk down from 2nd floor into the CSAC last night. Currently working on the staircases from 2R down to 1, adding more folks' rooms, and fixing location and texture problems, such as bogus y-values, textures too large and not power of 2, etc.
• Observations: perspective obviously needs tweaking.
• Status check: what rooms are in what state?
• What next: server and making your accounts!

Reading Assignment

Network Protocols for CVE's (Greenhalgh)

• Unicast vs. multicast (IP multicast, Deering and Cheriton)
• Reliable vs. unreliable (unreliable OK for audio!? unreliable OK for moves) (what properties of a given communication make it OK to be unreliable?)
• selective reliability
• Disadvantages of client/server: server will do more processing than a multicast router would. server limits scalability of the system.
• Greenhalgh's experience: servers haven't been a major bottleneck.
• Advantages of client/server: single network connection, more effective congestion control, more reliable, ability to combine/piggyback messages to a given user, server can perform extra processing/filtering on messages, for example, summarize a sequence of messages in a single message.
• General heuristic: use multicast for unreliable location connections, client/server for everything else

Presence in Shared Virtual Environments (Buscher et al)

Methods of locating someone else in virtual space. Some of these are graphical, some textual, and some could be either. Perhaps some CVE's would eschew some of these techniques in order to be "realistic". What other methods can you think of?

• Landmarks ("meet at the bridge")
• Coordinate systems ("meet at 538,-111")
• Virtual "GPS" (computer provides pointer to any person you specify)
• "Yelling" (computer provides approximate direction of person when they ask)
• Teleporting them to you, or you to them
• Peeking (being able to look at their screen, i.e. through their "eyes")

The Problem with 3D Environments

• Reduce 3D down to 2D navigation (most of the time)
• Provide automatic navigation (most of the time)

Themes

Avatars

Bandwidth, scalability, and fundamental limits of hardware

Augmented virtual reality

City of Heroes

Project Status

• CVS version of our code reaches ground floor (I think) but I haven't hooked everyone up yet, nor have I gotten to basement or 3rd floor.
• Is ceilingtile.gif the same as csacceiling.gif? More generally: how do we find all the duplicates, and systematically replace whichever duplicate is inferior with its superior twin?

Obvious Things About Commercial Game CVE's

• MMRPG's are a spectacular technical and commercial success. Everquest introduced or popularized many technical concepts as well as a genre and business model which others like City of Heroes have imitated and improved upon. The per-boot update patching model is a good example.
• These games are very large, complex, expensive, and demand a high powered computer, especially a powerful graphics card. Everquest II will not run on my laptop with 64MB dedicated NVIDIA 3D chips; WoW does, and so does City of Heroes. Guess which games I am more likely to subscribe to?
• These games use surprisingly little network bandwidth, but latency is a huge problem, as is server scalability for large numbers of users
• MMRPG's are high-powered chat engines. There are multiple simultaneous sets of users you are chatting with: individuals, people in your immediate vicinity in 3D, people in your "zone", people in your per-session "group", people in your persistent "guild"
• The graphics and chat are competing with each other for space and user attention.
• The world is real-time. Chatting can get you in trouble if a monster comes up and starts attacking you while your keyboard is tied up in a long chat.
• The graphics has a lot of static stuff that just sits there and doesn't "do" anything...pro: makes the world more "immersive"; con: users can't burn it or chop it down, blow it up, etc. and this detracts from the realism. Newer games have less static stuff; Half-Life 2 brags about how you can destroy everything you see.
• Playing the game over a period, your character in the virtual world becomes substantially more powerful. The main Thing to Do is to try and acquire more power and/or more fame amongst your peers. This is a mixture of "experience" mainly acquired by killing monsters, and acquiring powerful magic items.
• The "zone" system really detracts from the realism

Unobvious Things About Game CVE's

• You pay $12-15/mo, it is not obvious that it should cost this much
• You pay periodically for new content (new zones, new creatures), the monthly fees are mostly pure profit.
• The graphics have gotten a Lot Better over time; machine requirements have gone up more gradually
• Success == More Players == Worse Gameplay == Drives people away. Scalability limits are partly social.
• The "Missions" in City of Heroes succeed in some senses, but are a major failure in many ways. They give players something to do, but because Everyone can do them, they violate the immersive realism, warp (verging on ruining) the economy, and cause exhaustive off-line cheat-reference-websites to be an important (nigh unto essential) part of serious gameplay.
• People play the game very differently to meet very different personal needs. There are people escaping real life, people seeking human contact, people trying to feel competitive/superior...
• Grouping with total strangers for random acts of violence is not realistic...but is by far the best and sometimes only way to advance. Play would benefit from an ebay-style alignment rating system.
• Because everything in the world is static except the players, the immersive reality is compromised by e.g. killing the same person or monster over and over again.
• Because players can't affect changes (build houses, take over cities) the world experience is controlled by Sony, not by players, and the rate of new content is slow, and the place becomes boring over time.

"Environment" Imposes Some Essential Features on CVE's

a CVE has a virtual world

This is a large space, typically with many locations and objects. Its goals are: make the user feel they are in that place, and make the user feel that within that place, they can accomplish their goals.

a CVE has time, and persistence

Things that happen in one CVE session affect later sessions. There is no "pause" button; the virtual world is happening whether you are there or not; things happen while you are out. Users do not ever "start over".

a CVE is reactive

CVE's content is user-controlled. Users do whatever they want, rather than following a script.

Additional "Desirable" Properties of CVE's

a CVE should be "realistic" as possible

laws of physics, day/night, weather, and graphical realism are all examples where the CVE doesn't have to work the way the real world does...but most CVE's will be more "immersive" and understandable to users if they reflect the real world.

a CVE should scale to handle "as many users as needed"

other people are a primary aspect of our real environment, and allowing only 4 people, or 16 people, isn't very realistic

a CVE should be richer than necessary

is it a "place", or just a chat/teleconferencing program?

Anatomy of a CVE

Users must be able to communicate

This implies Internet or other transport layer, plus common language or robust translation capability. "Language and translation" apply to both the network communication protocol and the human users.

Clients must be able to "render" the virtual world usefully

This implies sophisticated graphics software and a minimum hardware platform. In this class, I believe we can obtain or write sophisticated graphics software, but let us ask: do we all have access to minimum hardware?

Users' views of the virtual world must be (somewhat) consistent

There is a big problem if the time grows too long between your doing something and the time other users see what you do (latency). Some actions are more important than others in this regard.

New CVE Concept of the Day: Goal Assistance

In real-world-based CVE's, there may not be "missions" but there may still be goals, such as: complete a homework assignment so that it passes an automatic submission tester.

One interesting point is: people cannot always remember the details of their goals: where to go, what to do, etc. They sometimes wind up writing down the instructions they were given by a (computer-controlled) character in the game. It is sort of obvious that the computer should provide assistance with this task, provide some of the capabilities of a Personal Digital Assistant, such as a Todo list. City of Heroes does this rather nicely. Lecture 28. Future Trends in Games and Virtual Environments

Class Project Demos in Lieu of Final Exam

CVE Project Status (and SL Project Status check)

• there is a new http://www.cs.uidaho.edu/~jeffery/setup-cve.exe; CVS has a lot of additions/changes
• brief discussion of Inno Setup
• how to try out Mac binaries?
• server virtual.cs.uidaho.edu status
• account creation

Scalability of CVE's

Robinson et al distinguish between upward scalability (more people) and sideways scalability (different people). Besides scaling users and groups, they argue for more different kinds of objects in CVE's, especially objects with real-world presence (machines, printers, files), where manipulating the object in the CVE causes real-world work to get done.

Should all this work happen inside the CVE? Robinson argues for the 3D part of a CVE to be only one of many different collaboration programs, complementing other forms such as document viewers, web, and audio/video connections. In support, they observe that the 3D CVE's usually overemphasize the people, while other applications usually underrepresent them.

They are arguing that all our mainstream applications should become CVEs and propose a VIVA architecture along these lines. There are many pros to this approach, such as accessibility and interoperability when 3D graphics are not available, from the web or a PDA, etc. What are the drawbacks to trying to make all our regular applications CVE's? Do Robinson et al identify those drawbacks?

Videoconferencing: a perpetual prince, but never a king?

Other ideas:

• A lot of energy is devoted to describing how they allow people to be aware of other people visiting the same webpage at the same time (big deal).
• No Fixed Starting Point; VR, web, word processor, etc. are all equal citizens of their CVE.
• VR's main or only value: background awareness of others. (Do you agree, or disagree?)
• Server-based architectures are limited by the server CPU, while peer-to-peer based CVE's are limited by the network capacity.
• Some CVE's support 3D if available; 2D otherwise.

Besides "master servers", VIVA uses at least 6 kinds of special-purpose servers. Traditional services of "VR servers": spatial data processing, collision detection, awareness and authorization services, environment partitioning. Dynamic repartitioning is seen as central to scaling to more users.

[Snowdon96]: A review of distributed architectures for networked virtual reality. Virtual Reality: Research, Development, and Applications 2(1), 155-175. gives a reference architecture consisting of:

• distributed system services (name server, trader, time service, resource discovery agents)
• security services
• object support services
• core VR services, e.g. collision detectors, world servers
• non-core VR services: application object
• user interface services
• other supporting services

Where we are at in the course so far

Notes while trying to test your HW#K

What, Binaries?

Of course I am very uninterested in binaries, I want source code and any resources (e.g. .gif files) bundled up (.zip is probably best, .tar or .tar.gz or other common formats OK).

Missing makefile?

Turn in everything I need to compile and run your program correctly, if you can. This would include a makefile or batch file in the .zip that you turn in.

Runtime error?

It is not uncommon in Unicon to get runtime errors, don't be panicked by them but do get practiced at reading them. A sample one is

Run-time error 107
File cve.icn; Line 244
record expected
offending value: &null
Traceback:
   main()
   make_SH167(...parameters...) from line 73 in please8.icn
   Room_add_door(...parameters...) from line 19 in please8.icn
   {&null . coords} from line 244 in cve.icn

Lecture 29. Future Trends in Games and Virtual Environments

• Please (!) participate in course evaluations; last I checked we were at 43%.
• BarBQ this afternoon, class will be "short"

CVE Status Report

• Hattrup added to CVE, Riley in progress, Jafar on deck.
• If what your room looks like in CVS is better than what you turned in, it will replace it for HW8 grading purposes.
• Multi-user / account creation somewhat more functional
• CVS and www.cs.uidaho.edu/~jeffery/setup-cve.exe updated
• Generalization from NMSU required reduction in "two-dimensional thinking"

CVE's Using Symbolic Acting (McGrath/Prinz)

• "chance meetings", "recruited conversations"
• sensing what people are doing and when they are available to chat (how do we build automatic "available to chat" sensors into our CVE?)
• ignoring people politely when we are busy

Symbolic Acting

In between silence and talking there is a continuum comprising mutual sense of presence, body movement, mutual gaze awareness, and the trajectory of body motion (towards someone, away from them, on a route unrelated to them, etc.). "Sleepy mode": avatar looks like an ice cream cone.

Contact Space and Meeting Space: the lounge versus the seminar room. The big difference is whether others can interrupt.

Nessie world: different rooms for different working contexts. Avatars are Lego puppets. Agent avatars signal time of day (waiters, janitors?), active virtual furniture shows external values and activities (temperature? stock values?). Projecting the CVE in the background: on the wall, or maybe on the root window?

Experience results: the "meeting space" won't be the focus during meetings, the focus is on the material presented, documents being reviewed, etc. People will want to customize their avatars, but do not need (or want) them to look exactly like in real life.

Who is talking in the CVE? Small window size means this vital information may need to be exaggerated.

When is symbolic acting unfortunate: when it embarrasses you publically, because you want to quietly working on something else (say, surf a website) while in a meeting in the CVE in another window. Sometimes you don't want the system reporting your every action to others!

More issues: security can be a problem; no one wants to have another account to login to; contact space needs to cooperate/integrate with e-mail, telephone, etc.; contact space needs to be accessible via PDA/cell phone, etc.

The Forum is not just chat, it is the ability to comfort, monitor, increase awareness, and observe others.

Dr J's idea of the day: "selecting" (clicking on) another avatar with your mouse might send an acknowledgement message to the other person, to let them know you are looking at them and they have your attention, as a precursor, if they wish to chat.

More on Modeling 3D Spaces

This course is not about 3D Graphics: we won't be covering advanced algorithms for photo-quality rendering like they use in the CG movies. But, everybody can learn enough 3D graphics to be useful for your project.

Some 3D Geometry

In practice, complex objects are composed from simpler objects. Each simpler object that is a part of the more complex object is given by specifying their location and orientation with respect to the complex object. This is how, for example, you might attach an arm to a torso, or attach different pieces to a table or lamp or whatever.

Location and orientation are more generally given by the operations Translation, Rotation, and Scaling. A basic result of early work in computer graphics was to combine and apply all three operations via a single matrix multiplication. We don't have to write the matrix multiplication routine, see CS 476 or a linear algebra class for that. We can just enjoy the fruit of their labors as manifested in our 3D graphics library (OpenGL) and a higher level API built on top of it.

At some point the "outermost" objects (say, an entire table or an entire person) are placed into the virtual world by similarly specifying the object's location and orientation with respect to World Coordinates.

Rendering an object in room coordinates example:

PushMatrix()
Translate(o.x, o.y, o.z) # position object within World Coordinates
o.render()		 # object rendered in Object Coordinates
PopMatrix()

Drawing Primitives

These primitives are further flexified by the Scale() function. When stretched (via scaling), primitives like DrawCube() can handle any rectangular shape.

Lighting and Materials

OpenGL has 8 lights, which can be turned on or off, positioned at specific locations, and can feature any mixture of three different kinds of light: diffuse, ambient, and specular. Diffuse seems to be the dominant light type, with the others modifying it. In the example:

   WAttrib(w,"light0=on, ambient blue-green","fg=specular white")

In addition, if you are not using a texture, the "fg" attribute for an object can include an object's appearance under the three kinds of light, and can include a fourth kind of light, emission, where the object glows all on its own.

   Fg(w, "diffuse light grey; ambient grey; _
          specular black; emission black; shininess 50")

One thing that was added recently to the 3D facilities is the ability to blend the texture and the fg color when drawing an object ("texmode=blend"). One thing that is going to be added in the future (as soon as I get a student to help) is to add a set of predefined / built-in textures ( "brick", "carpet", "cloth", "clouds", "concrete", "dirt", "glass", "grass", "grill", "hair", "iron", "marble", "metal", "leaf", "leather", "plastic", "sand", "skin", "sky" "snow", "stone", "tile", "water", and "wood").

Bad News? Midterm Exam?

Introduction to Networking in Unicon

Reading: Unicon book, chapters 5 and 15.

Networking support in Unicon was designed by Dr. Shamim Mohamed (Logitech, Inc. of Silicon Valley) with a little help from Clint Jeffery, implemented for UNIX by Shamim Mohamed, and ported to Windows by Li Lin (M.S. student) and Clinton Jeffery. These capabilities are simple, easy to use communication mechanisms using the primary Internet application protocols, TCP and UDP. Unicon also has "Messaging facilities", providing support for several popular network protocols at a higher level than the network facilities (HTML, POP, ...), done by Steve Lumos (M.S. student).

Networking for Non-nerds

Besides the IP number identifying a particular machine, most Internet services specify a port at which communication takes place; the ports serve to distinguish different programs or services that are all running or available on a given server. The ports with small numbers (say, the first few hundred) have standard services associated with them, while higher numbered ports can have arbitrary server-defined associations to custom applications. Ports providing standard services can usually only be run by the administrator of a machine; ordinary end users can generally use higher numbered ports.

Client-server and Peer to Peer

Configuring CVE's for Object-Focused Interaction (text Chapter 7)

• Engage with and share visible objects in the 3D environ
• many activities require talking and monitoring each others' conduct while looking at and using some workplace artefact.
• Earlier we said, selecting someone else should tell them they can chat with us. And we've said, we should see each others' cursors moving around within a shared text editor. More broadly this chapter is saying, we should be able to see what object others are selecting when it is not us; other users should not just have an avatar, they should have visible lazergaze, or a VR cursor. In RL we detect all this by watching each others eyeballs, but it will be hard to manage that in a CVE, we have severe resolution loss.
• Embedded video views that are dynamic texture maps attached to virtual objects
• Avatars should be able to point their arms in any direction they please; head should tilt to face that direction, to reinforce pointer. Lazer gaze, or glowing or highlighting the object-gazed upon, would be a more extreme method.
• Narrow field of view (55-60 degrees, 1/3rd of humans' normal viewing angle) can often cut out visible features of the other avatars (tunnel vision) (compare with driving a car; we need turn signals and frequent manual checks where we turn and look behind our car).
• Slow speed of movement makes it worse; harder to make quick glances.
• "peripheral lenses" extend avatar's field of view
• Beyond lazer gaze, other users fields of views can be made visible by making avatar