Lecture Notes for CS 428 Games and Virtual Environments

Syllabus

Reading Assignment

• Read Chapter 1.1 of the Rabin book, "A Brief History of Video Games"
• Taxation of Virtual Worlds?

What's This Course About?

• An introduction to games, genres, game design
• How to design and implement computer-based games
• How to develop collaborative virtual environments
• Graphics, networking, A/I, data structures, algorithms, I/O...

How can CS reduce the effort required to develop computer games?

What can we learn about CS by studying game design and development?

What's This Course NOT About?

• Vocational/technical training for the game industry
• DirectX, Direct3D, or other platform-specific API's
• Modding or "level editing" of other people's games

What is a Game

The main definitions we will consider are

an amusement or pastime

OK, but are movies and TV games? No.

a competitive activity involving skill, chance, or endurance...

having rules, etc.

Throwing all this together one gets something like:

A competitive or cooperative activity involving skill, chance, or endurance, whose primary goals are amusement, improvement, or both.

History of Video Games

procedure main()
   write("Hello, amigo!")
end

   write("die roll: ", ?6)

   write("coin toss: ", ?["heads", "tails"])

every 1 to 3 do write("crazy")

	words := ["fish", "beagle", "minotaur", "tiger", "baseball"]
	word := ?words

	scramble := word
	every 1 to 99 do
		scramble[?*scramble] :=: scramble[?*scramble]

procedure main()
    words := ["fish", "beagle", "minotaur", "tiger", "baseball"]
    word := ?words
    scramble := word
    every 1 to 99 do
        scramble[?*scramble] :=: scramble[?*scramble]
    write("Unscramble: ", scramble)
    answer := read()
    if answer == word then
        write("correct!")
    else write("no, it was ", word)
end

Highlights of UG book Chapters 1-6, cont'd

Ascii Art:

	hangedperson := [
	"  o  ",
	"\\ | /",
	" \\|/ ",
	" /|\\ ",
	"/ | \\"
		]

    if misses = 5 then
	stop("you lose! The word was ", word)

    if find(letter, word) then
	every i := find(letter, word) do
	    blanks[i] := word[i]
    else misses := misses + 1

	w := open("hangman", "g", "size=400,400")
	DrawCircle(w, 300, 50, 25)
	DrawLine(w, 300,75, 300,150)

Chapter 3: Dice Games

	dice := [ ?6, ?6, ?6, ?6, ?6 ]
	write("The dice are: ",
		dice[1], dice[2], dice[3], dice[4], dice[5])

	write("Which dice values do you keep?")
	keep := read()

	# Reroll the dice
	every i := 1 to 5 do {
		if not find(dice[i], keep) then
			dice[i] := ?6
		else keep[find(dice[i], keep)] := ""
	}

	dice := sort(dice)

   if dice[1]=dice[2]=dice[3]=dice[4]=dice[5] then ...
   else if dice[1]=dice[2]=dice[3]=dice[4] then ...
   else if dice[1]=dice[2]=dice[3] then ...

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.

Rabin Book, Chapter 1.2

Lecture 4. This week's topics: structure types, text manipulation

How is the Homework Going?

Bolden of the Day

Rabin of the Day

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

Steve Jackson wrote an article on writing interactive fictions which may be of interest.

lecture5

Brandon's "Feel" Link

Rabin of the Day

Text Adventures, cont'd

Anatomy of a Text Adventure

I am kind of interested in generalizing: what if the goal were a text adventure program that let you build the text adventure, from inside the text adventure? Certainly for graphical virtual environments (MMO's, etc.) it is desirable to allow the world to be built and edited in real time. A text adventure is a logical place to start that process.

Text Adventure as Finite Automaton

class Room(name, descrip, detail, edges)
   # ... methods
initially(nm, desc, det)
    name := \nm | "unknown room"
    descrip := \desc | "You are in a nondescript empty room."
    detail := \det | "There is nothing here."
end

global rooms, current

procedure main()
   rooms := table()
   write("Welcome to the text adventure builder")
   current := rooms["void"] :=
       Room("void","You are in a dark void.","You can't see anything much.")

   repeat {
      # ... tell the situation (where the user is, etc.)
      # ... tell what the obvious actions/choices are.
      if not ( command := read() ) then stop("Goodbye.")
      argv := cmdlist(command)
      case argv[1] of {
	 # ... interpret user actions
	 }
      }
end

      write(current.descrip)
      every write((!\(current.edges)).descrip)

procedure cmdlist(s)
    L := [ ]
    trim(s,0) ? {
	while put(L, tab(upto(' \t'))) do {
	    while L[-1][1]=="\"" & L[-1][-1]~=="\"" do {
		L[-1] ||:= tab(many(' \t'))
		L[-1] ||:= tab(upto(' \t'))
	    }
	    if L[-1][1]=="\"" & L[-1][-1]~=="\"" then
		L[-1] := L[-1][2:-1]
	    tab(many(' \t'))
	}
	put(L, tab(0))
    }
    return L
end

Comments on Homeworks

• I expect 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

Lecture 6. Arcade Games.

Yes, we are moving on towards arcade games. But first:

Genre spanners: ASCII art adventures, graphical adventures

Trevor suggested that I mention graphical adventures such as "The Secret of Monkey Island". Compared with text adventures, note the delightful pictures and the easier-than-pie point-and-click menu of all the verbs that are allowed at any given point!

Bolden of the Day

Comments on Previous Homeworks

• First priority is of course correctness, then "look and feel"
• Beyond these, the name of the game also includes the most "elegant" solution. "Elegant" mostly means shortest but most readable. Try writing poetry, even a limerick or haiku, instead of a novel. This affects maintainability and extensibility.

Classic arcade games

Lecture 7. World of Warcraft

Class session was held in-game.

Lecture 8

Reflections on "World of Warcraft" Session

• Dr. Jeffery admits to having a deathwish...
• Both healers on one group, no healers in the other?
• Maximum group size was a real nuisance.
• Inter-group communication was not very good.
• Everyone needing to do their individual quests & quest turnins
• Lots of major elements of "WoW" not touched on in limited exposure

Comments on Homework #3

• 3 turned in so far
• Progress on getting Visual Studio (C#) installed, but not done yet
• Text adventures provide some underpinnings for games like WoW.
• See some more graphics games, 2D and 3D, before we try to tie it together

Rabin of the Day

Lecture 9. Misc.

Bolden of the Day

Rabin of the Day

Homework #4

Comments on Soule's Lecture

• Monsters and non-player characters need some kind of execution model.
• Good ones need to feel intelligent.
• As-written, his scouts and investigators breed for efficiency; their behavior won't probably look very sensible. Very "artificial" intelligence
• Is the goal in a game to appear human-like in intelligence?
• BDI (belief-desire-intention) is a popular human-like AI model.

BDI

• Michael Bratman
• desire+"commitment"=intention
• selection of plans from a "plan library"
• does not include how to create plans

Brick

• Brick

class Brick(x, y, color)
   method score()
      if color == "blue" then return 10
      else if color == "orange" then return 5
      if color == "green" then return 1
   end
   method draw()
      Fg(color)
      FillRectangle(x,y,45,20)
   end
   method erase()
      color := "black"
      EraseArea(x,y,45,20)
   end
   method hittest(ballx, bally)
      if color == "black" then fail
      if x-10 < ballx < x + 45 &
         y-10 < bally < y + 20 then return
      fail
   end
end

procedure main()
   bricks := [ ]
   &window := open("Brickenator", "g", "size=640,480",
                                  "fg=white","bg=black")
   row := 0
   every row := 0 to 7 do {
      if row = 0 then color := "blue"
      else if 1 <= row <= 4 then color := "yellow orange"
      else if row > 4 then color := "green"
      put(bricks, [ ] )
      every column := 0 to 12 do {
         b := Brick( column * 49 + 2, row * 24 + 12, color)
         put(bricks[ -1 ], b)
         }
   }
   every (!!bricks).draw()
   Fg("white")

   FillRectangle(320,460,40,10)
   FillRectangle(320,260,10,10) # ball
   x := 320
   y := 260
   dx := 0
   dy := 1
   px := 320
   py := 460
   score := 0
   lives := 0

   repeat {
      # erase ball at old position
      EraseArea(x,y,10,10)

      # calculate new position
      x +:= dx
      y +:= dy 
      # draw ball at new position
      FillRectangle(x,y,10,10)
      WSync()
      # bounce off paddle
      if px <= x <= px + 40 &
          py <= y+10 <= py + 10 then {
            dy := dy * -1
            dx +:= ((x+5) - (px+20))/10
          }

      # bounce off left, right, or top wall
      if x <= 0 then dx := dx * -1
      if x+10 >= 640 then dx := dx * -1
      if y <= 0 then dy := dy * -1

      # take a life when the ball hits the bottom edge
      if y + 10 > 480 then {
         dy := dy * -1
         lives +:= 1
         dx := 0
	 if lives = 4 then {
	 WAttrib("label=Bricks [game over, q to quit] score: " || score)
	     while *Pending() > 0 do Event()
	     while Event() ~== "q"
	     exit(0)
	     }
         else
	 WAttrib("label=Bricks [" ||  lives || " / " || "4] score: " || score)
         }

      every b := !!bricks do {
	  if b.hittest(x,y) then {
	      score +:= b.score()
	      b.erase()
	      WAttrib("label=Bricks [" ||  lives || " / "||"4] score: "||score)
              dy := dy * -1
	  }
      }

#      delay(1)
     every 1 to 75000

      # move paddle left or right in response to user input
      EraseArea(px,py,40,10)
      px := QueryPointer()
      FillRectangle(px,py,40,10)
      }
   Event()
end

This chapter is mostly stupid, you can safely skip it. We will give it about 5 minutes, not the 25 we've been striving for.

Arcade Game Framework

# open window
repeat {
   # erase moving objects from their old positions
   # draw moving objects at their new positions
   # read user input
   # calculate all deaths, births, and changes in movement
}

Sesrit

• Sesrit

...
/&window := WOpen("label=sesrit","size=276,510", "posx=20")
colors := table(&window)
every c := ("blue"|"yellow"|"cyan"|"green"|"red"|"white"|
            "red-yellow" | "purple-magenta" | "pink") do
         colors[c] := Clone("fg=" || c)

   L := list(30)
   every !L := list(10, "black")

How does the following game loop compare with the Arcade Framework that I proposed above?

procedure game_loop()
   game_status := 1
   repeat {
      while *Pending() > 0 do {
         case Event() of {
            Key_Left  : move_piece(-1, 0)
            Key_Right : move_piece(1, 0)
            Key_Down  : rotate_piece(1, -1)
            Key_Up    : rotate_piece(-1, 1)
            " "       : while move_piece(0,1) # drop piece to bottom
            "q"       : if &meta then exit()
            "a"       : if &meta then about_sesrit()
            "p"       : if (&meta & game_status = 1) then pause()
            "n"       : if &meta then return

            &lpress   : {
               if 15 <= &x <= 105 then {
                  if 270 <= &y <= 290 then pause()
                     else if 300 <= &y <= 320 then return
                        else if 360 <= &y <= 380 then
                           about_sesrit()
                  }
               }
            &lrelease :
               if ((15 <= &x <= 105) & (330 <= &y <= 350)) then
                  exit()
            }
         }
      if not move_piece(0,1) then {
	 if (!activecells)[1] < 2 then {
            game_over()
            return
            }
         # if we couldn't drop the piece down, insert a new piece
	 }
      # ... misc. step code

      WSync()
      delay(delaytime)
      }
end

   ...
   case nextcolor := ?["red-yellow", "red", "yellow", "green",
                       "cyan", "blue", "purple-magenta"] of {
   "red-yellow":     nextpiece := [ [1,5], [1,6], [2,5], [2,6] ]
   "yellow":         nextpiece := [ [2,6], [1,6], [2,5], [2,7] ]
   "blue":           nextpiece := [ [2,6], [1,5], [2,5], [2,7] ]
   "purple-magenta": nextpiece := [ [2,6], [1,7], [2,5], [2,7] ]
   "red":            nextpiece := [ [3,6], [1,6], [2,6], [4,6] ]
   "green":          nextpiece := [ [2,6], [1,5], [1,6], [2,7] ]
   "cyan":           nextpiece := [ [2,6], [1,6], [1,7], [2,5] ]
   }

Note on Unicon

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

GUI's

What do GUI's in Unicon look like?

See UTR 6

Coming Soon: 3D

• Blasteroids

Strategy games

What is strategy? What is tactics?

Real Time vs. Turn-based

Rabin of the Day

Chapter 3.5, Debugging Games.

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

Ogre: 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.

Checkers

Minimax Algorithm

Given a board position P we wish to calculate our best possible move. There is a tree of board positions which allows us to evaluate all possible moves. From the current position we select the next move as the child whose board position is best. But our evaluation of board positions considers further moves as much as CPU allows. Our best position, short of winning outright, will be whatever gives the opponent the least opportunity.

procedure minimax(node, depth)
    if gameover(node) | (depth = 0) then {
        return evaluate(node)
	}
    else {
        α := -&infinity;
        every child := possiblemoves(node) do {
            α <:= -minimax(child, depth-1)
	    }
        return α
end

Alpha-beta pruning

Tic-Tac-Toe and the Minimax Algorithm

L := [ [" ", " ", " "],
       [" ", " ", " "],
       [" ", " ", " "] ]

L := [ [1,1,1], [1,1,1], [1,1,1] ]

We need an evaluation function. By definition it is a heuristic function, although with simple games and extreme cases it may be that the heuristic can be proved to produce optimal results.

procedure evaluate(L, player)
   if player=="x" then { player := 2; enemy := 3 }
   else { player := 3; enemy := 2 }

   # absolute results
   # 1000 if there exists a 3-in-a-row
   # -1000 if there exists an enemy 3-in-a-row
   if numNinaRow(L, player, 3)>0 then return 1000
   if numNinaRow(L, enemy, 3)>0 then return -1000

   # heuristic opinions
   sum := 0
   # + 100  for each (unblocked) 2-in-a-row
   # - 100  for each enemy (unblocked) 2-in-a-row
   sum +:= 100 * numNinaRow(L, player, 2)
   sum -:= 100 * numNinaRow(L, enemy, 2)
   # + 10   if we hold the center square
   # - 10   if we hold the center square
   if player = L[2,2] then sum +:= 10
   if enemy = L[2,2] then sum -:= 10
   # + 2    for each corner square
   # - 2    for each enemy corner square
   if player = L[1,1] then sum +:= 2
   if player = L[1,3] then sum +:= 2
   if player = L[3,1] then sum +:= 2
   if player = L[3,3] then sum +:= 2
   if enemy = L[1,1] then sum -:= 2
   if enemy = L[1,3] then sum -:= 2
   if enemy = L[3,1] then sum -:= 2
   if enemy = L[3,3] then sum -:= 2
   return sum
end

procedure numNinaRow(L, player, n)
   sum := 0
   n := player ^ n
   every i := 1 to 3 do {
      if L[1,i] * L[2,i] * L[3,i] = n then sum +:= 1
      if L[i,1] * L[i,2] * L[i,3] = n then sum +:= 1
      }
   if L[1,1] * L[2,2] * L[3,3] = n then sum +:= 1
   if L[1,3] * L[2,2] * L[3,1] = n then sum +:= 1
   return sum
end   

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

CVE Intro

Technical Troubles

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

Lecture 13. Sim Games. FPS's. Chapter 3.7, Memory and I/O.

Sim Games

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

FPS's

• Wolfenstein 3D
• Doom
• Quake (source)

Review of HW4's

Chris's Battletanx

~212 lines of Icon

Jesse's Rubble Escape

A sort of jump-on-the-boxes-to-avoid-drowning game. Java Applet. ~800 lines.

Russ's Cosmic Conquest

A sort of Cosmic Conquest game. Flash/Shockwave. Know a lot of tools well, then you can select what you feel is the right tool for the job. ~436 lines.

Trevor's "beginnings of a top down shooter game"

~2000 lines of C

Stephen's SharpTanks

~4000 C#, built using XNA framework.

Rabin of the Day

Chapter 4.1, Mathematical Concepts.

This is CS 324 review material and you can basically skip it.

Chapter 4.2, Collision Detection.

This chapter has at least some interesting material to consider.

Lecture 15. Network and Multiplayer Games

Rabin of the Day

Chapter 5.6, Network and Multiplayer Games.

Dr. J's Take on Multiuser games

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

Lecture 16. Networking and Games

While this course isn't about networks, games use them and it is appropriate to provide a brief introduction to network programming. You should (skim chapters 1-4 and then) read Chapters 5 and 15 of the Unicon book for a discussion of network programming in Unicon.

Addition to the book! Based on our experiences writing a multiuser virtual environment, we ended up adding a new function to Unicon named ready(). ready() is like reads() except that it returns immediately with available data, rather than waiting until data arrives (it is non-blocking). In practice, ready() turns out to be essential.

The main 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

This was immediately followed by a "fork-exec" model, in which each incoming connection triggers a new process, so that multiple users can be served simultaneously. Separate server processes for each user gives good fault tolerance (one user's server process crashing might not affect others') and poor/slow communication for applications where users interact with each other via the server.

Since process creation is slow, "fork-exec" has been replaced by various newer models, including farming the work out to a pool of pre-created processes, and using threads instead of processes.

Context switching between processes is very slow, and even switching between threads is pretty slow. In addition, communication between processes or even threads is slow. For these reasons, modern multi-user servers might have each thread handling several user connections -- especially if certain users tend to communicate together a lot. The number of users per thread might depend on how CPU-intensive the server threads' tasks are in support of each user -- if the server has to do a lot of work for each user transaction, it is easier to justify a separate thread for each user.

Lecture 17. AI Agents, Rabin-style

Rabin of the Day

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 CVE.

Introduction to Second Life

• SecondLife source code page

Assignment: we will be using Second Life in the near future. Go Ye therefore and download the second life client binary, 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.

Second Life is a non-game virtual environment. It is also a platform for building different kinds of virtual environment experiences. Many people are building amazing things in-world, and many are building amazing interfaces to external resources. Here are some interesting links.

• http://uk.youtube.com/watch?v=9hte2MJ54CA

Introduction to Wonderland

• Source code download instructions

Introduction to CVE

• CVE implementation "book"
• CVE source code as of 4/2/09

Studying a VE Implementation

3D Modeling Tools?

More on Virtual Environments

Lecture 18. Virtual Environments, Dr. J's Way

Freak-out

HW#6

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.

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 CVE

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)

Lecture 19. Jeb1 Demo.

By the way, I am treating the lecture notes somewhat similarly to how I've treated Rabin, which is to say, I am selecting highlights. You are encouraged to read also the lowlights for additional depth and insight, and to ask questions.

Room Assignments for HW#6

Another 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
   }
]
}

More Thoughts on 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. But you could substitute a drawing of yourself if you preferred.

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

The notes here are just highlights on what to look for:

open("win","gl")

x-z horizontal plane, y is vertical.

WAttrib("eyepos="x,y,z", "eyedir=x,y,z")

also Eye(), and Refresh()

DrawPolygon(), DrawSphere(), DrawTorus(), DrawCube(), DrawCylinder()

PushMatrix(), PopMatrix(), MatrixMode(), IdentityMatrix()

WAttrib("light0=on, diffuse yellow; ambient gold") ...

lights: "{diffuse,ambient,specular} colorname"

materials

Fg("{diffuse,ambient,specular,emission} colorname")

WAttrib("texmode=on", "texture=map.gif"), WAttrib("texcoord=...")

and the more flexible Texture(t). Easy to use another window's contents (2D or 3D) as a texture. Possible, but currently in a preliminary and unfinished form, to "draw" directly on textures.

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

The JEB1 Demo

• jeb1.icn
• model.icn
• defaults.icn

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()

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

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 HW6 such a thing might be omitted, but 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]}
      }
]

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

HW#6

HW#7

How much more Rabin?

City of Heroes' Quest Creation Tools: a Quick Peek

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. C'est la vie. Why is this limit important for SecondLife? What does it mean for builders?
• In CVE 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 will "eat up" a measurable fraction 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 CVE software is VERY naive in this regard, not minimizing its primitives at all.

Towards Virtual JEB

Among other things, compared with CVE, the JEB demos are lacking stairwells and most connections between rooms. So let's talk about that today.

Towards Avatar Refinement

More generally, what does the CVE 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 23. Pathfinding algorithms

Discussion of HW#6

The recommended way to test your room data + textures is to run your sample data on the jeb1 demo. At least one student reported the jeb1 demo not running for them on Windows. If ran for me on Vista laptop and on XP on VMware on Linux... but if you are having difficulties, see me for help, or try another machine. Oh: what image file formats are you trying to use? .gif is safe. .jpg and .png are "maybes". libjpeg worked on linux and not on windows last time I checked. Jafar claims we have libpng support, but not sure if that's gotten built into windows yet or not, either.

Integrating your model.dat into the "real" CVE sources.

Rabin on AI/Pathfinding

Lecture 24. Virtual Environment Server and Network Protocol

No Final Exam

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)

export CVSROOT=yourname@cve.cvs.sf.net:/cvsroot.cve

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 CVE

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)

EMUGA

Lecture 25. Virtual Environment - More Internals

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?

Lecture 26. Research Topics in Virtual Environments

Project News

• 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

Lecture 27. Research Topics in Virtual Environments

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

Games and Virtual Environments Virtual Expo

CVE Project Status (and SL Project Status check)

• there is a new http://www2.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

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 avatars into giant flashlights.

Look at Homework #4

Startup Time

Tiling textures

Making Textures Tile Properly

• http://www.highpoly3d.com/writer/tutorials/tileable/seamless.htm
• http://astronomy.swin.edu.au/~pbourke/texture/tiling/

Viewing Volume

Project Ideas

How Not to be Objective (text Chapter 8)

• Peripheral Awareness
• Informal Meetings - how to rig things to make this happen more often?
• Learning by Watching - how to make it easier to watch others do tasks?

Subjective virtual environments

Flexible Roles in a Shared Space (text Chapter 9)

"Kansas" - 2D, programming environment for the language "Self". Self is a delegation-based descendant of smalltalk.

"Field of view in most CVE's is so narrow that other avatars are usually off-screen".

• Roles may be implicit or explicit
• Roles may be temporary, have term duration, or be persistent
• Roles may be supported by explicit tools or locations
• Roles tend to evolve/change over time
• Roles may be associated with awareness information categories

Capabilities could be used anywhere in a CVE, but perhaps the user interface is a sufficient place for them. A capability can itself have a visible manifestation (like the piece of chalk, or the microphone). A "capability tray" might hold (and allow easy sharing) of a user's entire capability set.

Avatars

Social Interactions in Multiscale CVEs

social presence

how you look shapes/influences how others will treat you (social conventions)

Yo's avatar

Yo Sep has got an avatar that with a single stroke (head images) achieves more reality than the CVE in this 2002 paper.

ants and giants

it is easy for us to exaggerate differences in size, if we have a reason to do so. If you want to see microdetails, become an ant. If you want to walk from here to Albuquerque and see the Organ and Jornada ranges in a single hike, become a giant.

multiscale collaboration

for large complex structures, different collaborators may need to work/view the world at different scales (seeing different levels of detail). Example: software architects vs. designers vs. coders

dynamic sizes

a user might shrink or grow themselves to fit a situation

size in social domination

bigger individuals tend to dominate social situations

size in natural life

We all start out life as "newbies", and gain in size and ability. Ability in a CVE might include: movement speed, viewing distance and detail, having keys to certain rooms...

"size" in unnatural CVE life

More avatar upgrades might include ability to teleport, walk through walls, fly, etc. Besides size, avatars with more abilities might stand out via color, glow, louder (Jurassic Park-style) strides...

communication-centered vs. artifact-centered collaboration

CVE balances and supports both, but it is artifact-centered collaboration where it will shine or fail.

but avatars need (in general) to be visible

bad things happen in CVE's with invisible users

external min and max?

others' view of you may need to be capped, even if your own view of the world scales wildly

scaling is more than just calling Scale()

in general, smaller = render fewer details please. wire frames?

proxemics

study of proximity. Asymmetrical proximity when avatar scales are varying. Giant will "feel" that ant is far away, ant will "feel" that giant is real close.

proximity ranges:

• intimate = < 0.45m
• personal = 0.45-1.2m
• social = 1.2-3.6m
• public = > 3.6m

Two (or more?) avatars?

One for action, one for conversation? Daemon avatar, a placeholder for conversation (intercom) while one is elsewhwere.

Changing viewpoints

See from your daemon's eyes; see from others' eyes to know what they are looking at/talking about/referring to.

Scale-based semantic representations

Besides "adding detail" as a user shrinks and gets closer to what they want to look at, the representation may change (solid→molecule→atom→particle). The hard part would be to see relationships between objects at different scales/ representations.

imposters

at a distance, a much cruder representation of an avatar works fine

Designing Interactive Collaborative Environments

WWW3D and Web Planetarium

Big problem with scalability (too many pages to view). Cluster pages together into 1 sphere per site.

WWW3D shows very little page contents, mainly shows links; color codes pages by how recently they were viewed. Web planetarium uses the first image in the page as a texture (often a logo or person).

From public demo: users avoided following links to "warp" new sites into the 3D layout. They preferred to wander around a landscape that is already created.

The Blob

• mouse gestures (stroking, pulling, etc)
• "Local Tools" approach, not "menu and palette" approach. Each item may have several state attributes, and remembers them when set down.
• Forcing collaboration example: both users have to click an item in order to get/select it. But, its better to "encourage" than to "enforce" collaboration.

Robot-Human collaboration

• "deictic references", e.g. "this object here".
• Robot semi-autonomous; this is a collaboration tool not a remote control tool.
• division of labor between robot and human is fluid
• sometimes, too many details in the model is bad, focus detail around the job at hand.
• Pfinder, MIT Media Lab, extracts 2D+ information about people from a video feed (tracks hands, head, center)
• Path objects, which can be illuminated or autofollowed.
• PDA 2D map as aid to 3D navigation?

Trouble in CVE-Land

• configure script bogus? It had control-M's on it that caused some shells to choke (e.g. fedora core 3) but not others (updated)
• server connects but doesn't answer - a new kind of hang (fixed by killing and restarting server; needs investigation)
• server won't start at all? check if someone else owns the port
  their zombie iconx = you must use a different port
• can't run /sbin/lspci? Unicon version issue?

Tele-Immersive Collaboration in the CAVE Research Network

• EVL at UIC
• Their focus: "high quality collaboration" with few (< 8) users on powerful computers when bandwidth is plentiful.
• CAVE: an immersive 10x10x10 VR room using projection on walls.
• 3D shutter glasses, not heavy goggles; shutter glasses also report user's head position to VR system.
• 3 button "wand" in place of mouse; wand reports user's hand position to VR system
• High end silicon graphics workstations to drive displays
• Applications in C/C++ and OpenGL/Performer
• Several people can go in the same CAVE, but only one controls Eye position and carries the Wand.
• Tele-immersion = CVE's using VR hardware
• Capture and transfer gestures, audio, and video among collaborators? At least: CG versions of collaborators which show head and hand position. adequate for tasks, no good for negotiation.
• CALVIN - used CAVE to do multiuser architectural design. "mortal" and "deity" modes. "deity" mode sees the big picture, simcity-style, and good for gross manipulations; "mortal" mode better at fine manipulations.
• NICE - a virtual environment for young children; main activity is gardening.
• Non-humanoid avatars (e.g. bunnies); mouse-mode; ability of one avatar to pick up and carry another avatar.
• Persistent server; changes happen even when humans are not logged in.
• Giving a newbie a flower to welcome them to the environment
• Using the "hokey pokey" to test network quality
• Avatar nametags to tell which user is from where
• Virtual webcam for world monitoring
• Applications: car designers, meteorology, oceanography, medical education, history, virtual tourism,
• NICE suffered from lack of a clear goal; Round Earth (a successor to NICE) had a specific goal of teaching kids that the earth is round (woohoo); one kid sees the surface of a planet as an astronaut; the other sees the whole ball and plays the role of "mission control".

Lessons:

• having only one hand is a liability
• other remote users' avatars can block your view! \ignore command may want to do more than block chat.
• Long "beam" pointers are handy when pointing at distant objects
• Users will want to know what they look like to others.
• "Audio is the most important communication channel to maintain the shared collaborative space".
• Avatars need (at least crude) mouth movements corresponding to audio, so folks can see who is talking.
• People feel very bad when they accidentally walk through someone else; collision detection between avatars is important. However, when situations get crowded, the same collision detection can be a pain, so perhaps it needs to be dynamic. A body in motion is less of an obstacle than one at rest?
• Americans tend to gesture more than some cultures; gesturs inferred from real world (i.e. hardware VR) need exaggerating to be clear in the CVE.
• Newbies generally require a tourguide.
• Bad jitter is worse than bad latency

Future Work for the CAVE Folks

• Asynchronous work support in the CVE requires more study.
• "Vmail" - recording of an avatar talking and referring to objects in the virtual space. Recording most naturally belongs to the networking layer.
• Virtual sticky notes.

What I learned from this year's Halloween

Managing Dynamic Shared State (SZ Chapter 5)

consistency vs. throughput

it is impossible to allow dynamic shared state to change frequently and guarantee that all hosts simultaneously access identical versions of that state"

shared repositories

Variation: distributed shared repository, in which different dynamic state is managed on different machines. "Virtual" centralized repository.

Idea: how consistent your information about others is can be proportional to their importance to you or their proximity to you; this doesn't have to be a boolean visible/too-far-away condition. What about updating with frequency proportional to distance? Server could compute: should I send user X's move to user Y? with probability = (1.0 - distance) * (1.0 - direction)

frequent broadcast

Specific machine "owns" the object for which it broadcasts updates; more complicated for others to modify the state of that object. Works best in a LAN setting (many early LAN games used this model).

Concept: "lock lease" = locks that automatically timeout.

Latencies of 250ms are not uncommon on WANs.

Jitter = variation in latency from one packet to the next.

state prediction (dead reckoning)

prediction = how we calculate current state based on previous packets. commonly using derivative polynomials (velocity, acceleration, and possibly "jerk"). order 0 = state regeneration technique. order 1 adds velocity. order 2 (with acceleration) is "the most popular in use today". Note: if acceleration is changing each packet, using it generates a lot of errors. Good to disable acceleration dynamically when it is not helping, maybe use it when it is nonzero and consistent for 3+ updates in a row.

derivative polynomials don't take into account our knowledge about the semantics of the object. Separate dead reckoning for each class of virtual object?

convergence = how we correct error. instead of "jumping" to correct, we might smoothly adjust. goal = "correct quickly without noticable visual distortion". "snap convergence" just lives with the distortion.

linear convergence: given the corrected coordinates, predict where the object will be in 1 second. Now, compute the prediction values for the object so that it moves from its current, erring position to where it is supposed to be a second from now. (what if this runs through a wall?)

To do better: use a curve-fitting algorithm, maybe a cubic spline.

Reflections on a MOO scenario

• out of curiosity, thinks Dr. J, how usable/useful would our CVE be if we supported non-3D operation?
• commands "look" and "look becki". Do we need them? ("look" describes the room you are in. "look user" describes someone).
• "blink": a good name for an "I am not afk" command.
• "idle driving into the lab": tells others why you are afk and maybe gives them an idea of for how long.
• "wave", "nod", "laugh" etc.
• "paging": sending a message from another room; is this term more evocative than "tell"?
• advantages of MOO-mode: requires little CPU, unobtrusive,...
• major feature: avatar sits there listening to all conversation in a room even when you are not there, all you have to do is scroll backwards to review it (extra client commands to help with this)
• "persistence underlies the development of a notion of place - and places can make people feel like they belong and want to go back"
• "MOO room" = "project" or "group" area for chat. User-creatable.
• multiple avatars, having an avatar in a room means one is recording what's happening for later review.
• alert = key < 1 minute; daydreaming = key < 5 minutes; idle = afk < 1 hour; staring into space = away > 1 hour
• summaries during your absence: help you know whether to scroll back and look at the logs, and if so, what (or who) you are looking for.
• MOO downsides: whispers promote secretiveness; potential for disastrous typing mistakes; rooms promote and make conspicuous the social cliques, and perhaps make them subject to scrutiny.
• "more effort has gone into the creation and support of persistence mechanisms than any other type of development".

Real-Time Interactive Project Topic Selection

• soccer game - Raj Sekhar
• avatar movement/actions and appearance - Hani Amjad Iyad
• object initiated actions - Brian - elevators, etc.
• improved scene rendering - Varma and Karthig
• ssh tunnel and network experiments - Ravi
• sword game - shyam and anil

Reading Assignments

• [Zyda 2005] IEEE Computer September 2005, "From Visual Simulation to Virtual Reality to Games", Michael Zyda Google for the title.
• the TOP paper

All About Display Lists

In the case of 3D windows, we might use a similar strategy but instead keep a display list, which is a data structure that contains all the data about all graphics operations that have been performed since the last time the 3D window was opened or erased.

OpenGL has a display list concept, but its display lists would not be easily manipulated from the Unicon application level, so we maintain our own display list as a regular Icon/Unicon list. Each element of the list is a list or record produced as a by-product of a 3D output primitive (either a 3D function call, or an attribute that was set) written on that window. Unfortunately, the elements of the display lists are somewhat underdocumented at presents, so we will describe them in detail here.

Display Lists blindfolded

L := WindowContents(w)
every i := 1 to *L do {
   writes(i, ": ", image(L[i]), " -> ")
   every j := 1 to *(L[i]) do writes(image(L[i, j]), " ")
   write
   }

Display Lists with the headlights on

Flaws in the current Display List abstraction

Extending Texture(w, x) to Texture(w, x₁, x₂)

We will run out of texture memory sooner or later, but it needs to be later.

tex := Texture(w, s)
...
Texture(w, s, tex)

How soon? Well, I put the prototype code into ~jeffery/unicon/unicon last night, but it isn't tested or checked out on Windows yet. I'll try for ASAP.

Working in AlphaWorld (Churchhill chapter 15)

• Goal: use a off-the-shelf CVE for work collaborations instead of pure social.
• AlphaWorld vs. Blaxxun: AW less flexible, less visually appealing, but Blaxxun (VRML based) had problems: special/weird browser, poor performance... AW was a much smaller/faster browser.
• Reason voice chat is so important is so you can talk and "work" (i.e. type) at the same time. With text chat you have a major task- and window- switching issue.
• A Major feature of AW: extensibility
• Participatory Design: users and designers (of content) are one and the same. Who gets write permission? How easy is it to report a bug or request a change?

Lessons from Blaxxun

• spatial properties not used after initial exploration
• objects were not designed/built by users, had nothing to do with their topics of interest. No reason to interact with the world.
• lack of access to documents, no screen space available for other windows, led to a deficiency of content needed for collaborations.
• lack of privacy
• passers-by would hurl verbal abuse during business meetings!

Lessons from AW

• Sheer size allows for privacy: uninvited do not just happen by
• land-claim metaphor; you stake out 2D land before building in 3D on it
• Build tool integrated into regular viewing client, not a separate tool.
• Building your own space is a huge value-add for collaboration, mainly if you can populate it with useful content, e.g. URL's.
• AW was used in conjunction with BSCW.
• Easily implementable 3 grades of accessibility a la UNIX (ugo)
• Using stable public technology makes a project open -- they don't have to maintain the servers, accounts, etc.
• Individual ownership of objects was central in text-based MOO's but lost/dropped in many 3D CVE's.
• Build-by-copying. You can't create new objects, but you can copy and then modify existing objects.
• Clicking on or bumping into 3D objects "scriptable" with user-defined response (e.g. pulling up a webpage).
• Informal "chance encounters" are not chance at all, they are people we half-expect to meet, and benefit from meeting occasionally.
• AlphaWorld-based document navigation better than BSCW text interface; 3D navigation benefits scalability of file system access?!
• Creation of memory of the space came from using the space daily.
• Ease with which users can add their own rooms is crucial to a CVE's success
• Frontier Hypothesis - plentiful land waiting to be settled
• "New World Times" - server problems? A "giant meteor crashed into the virtual world, destroying everything..."
• Dr. J idea: give users disk space proportional to time spent in the CVE for customization.
• Value of the CVE to your friends depends on your being there a lot.

Resource Management

Singhal/Zyda assert that it is the Net resources that comprises the "cornerstone" of Networked Virtual Environments. All of the resource management in a NVE can be viewed in an information-centric way. The resource utilization for any category is: how much information is that resource using/processing.

Network-Centric View

Resources = M x H x B x T x P, where
M = Messages,
H = Hosts (destinations/message),
B = Bandwidth (bytes/message),
T = Timeliness (1/latency),
P = Processor (cycles/message)

Resource Tradeoff Techniques

Compression

lossless vs lossy, internal vs external

Packet aggregation

Can reduce bandwidth up to 50% at a cost of worse timeliness. Compare timeout vs. quorum vs. hybrid approaches to packet aggregation. Aggregation servers: might be organized by physical lan, msg type, teams, region

Visibility of Data

Area of interest filters, subscription-based, multicasting. Aura-nimbus approach allegedly performed poorly in MASSIVE

Level of Detail

Far away = small inaccuracies invisible

Server Clusters

CPU bottleneck or network bottleneck? client (group) partitioning, or region/zone partitioning

A Component Framework

A Unified Component Framework for Dynamically Extensible Virtual Environments

• From the "America's Army" game team at NPS
• NPSNET-V, fifth generation multiuser network game architecture?
• Java/XML, XML mainly for serialization that resists version conflicts
• upgrade components at runtime, never bring system down
• everything is upgradable except for a small "microkernel"
• strict hierarchical containment resembling file system directories
• "most important pattern" = Model-View-Controller
• Other projects: Bamboo (VR98, multilanguage multiplatform pluggable VE), JADE (Java Adaptive Dynamic Environment),
• replace() and retire() methods: cooperative handshake between old and new versions of a component

A bit more on Model-View-Controller

• Model: contains the state
• View: depicts the state to the user
• Controller: modifies the state

Downsides: three mirrored class graphs, instead of one; the "model" class is potentially all representation w/little behavior

Cursive: Controlling Avatar Gesture Using Pen Gesture

• (handwritten) mouse/pen gesture translated into avatar gesture
• separate symbolic and expressive parts of gesture
• user picks from a fixed set of gestures (symbols), but gets to convey expressiveness, e.g. via speed, size, or slant, of character (or if you had a tablet device, the pressure of the pen on it).
• How easy would it be to do a trivial version of this? What about other, lower-level gesture mechanisms? How many avatar gestures would be useful in our app?

• use fairly small patch of window in an "avatar area"
• base purely on press-drag*-release sequences in that area
• "size" based on pythagoras equation on the bounding box
• "speed" based on sum of &interval times (could use sequence of &intervals)
• want a few gestures, without a full handwriting recognition package
• compare w/ Palm pilot Graffiti: a simplified symbol set
• raise hand, lower hand, smile, shrug, etc.

Opening Comic

Things Our CVE Needs "Real Bad"

• more server state; server keeping track, e.g. of door states, blackboard states, user states; backing this up on disk
• network commands that provide ability to transmit (efficiently) blackboard contents and changes to server and thence to interested clients.

In Class n-User CVE Demo

• The server is too fragile. The VM code to handle lost connections appears to have a bug. In addition the VM on the client should probably be extended to close network connections on program termination, apparently just calling exit() is not very friendly.
• Some avatars' heads look much better than others (Gustav and Yo, for example. The difference is not original resolution in pixels, but rather, a solid background allowed more colors for the actual face. Adding JPEG support for textures, or using a 24-bit BMP format, would fix this without having to edit/redo the images manually.
• Performance - I couldn't tell whether the network or the server limited client performance; we won't know until the clients' performance and user interface have been tuned. It was OK with 5.

Q: Why and for what, do we need file transfers?
A: User-supplied textures. New data and code files. Patching the executable.

Features We Need to Integrate

• blackboard/whiteboard
• configuration files (config GUI screen)
• map window
• groups
• accounts/passwords
• user state
• VOICE - www.cs.nmsu.edu
• texture objects
• API support for manipulating the display list
• API support for manipulating the event pending list

Features We Need to do Starting From Scratch

• patcher
• file transfer
• corridors
• document sharing
• MIME types - fire off external programs
• transmit avatars @ runtime

Features we Wish we Could Do, But not Anytime Soon

• room builder/ room decorator
• ghost (or multi) avatars
• much better avatars
• Icons for education - assignments, labs, exams, discussions