 To obtain the graphic details seen in the game , Rubin , Gavin , and Baggett researched visibility calculation in video games that followed Doom and concluded that extensive pre @-@ calculation of visibility would allow the game to render a larger number of polygons . Following experimentation in free @-@ roaming camera control , the team settled with a branching rail camera that would follow along next to , behind , or in front of the character , generally looking at him , moving on a " track " through the world . Because only 800 polygons could be visible on the screen at a time , parts of the game 's landscape would be hidden from view using trees , cliffs , walls , and twists and turns in the environment . Because the production used an entirely Silicon Graphics and <unk> @-@ based tool pipeline , the programmers used $ 100 @,@ 000 Silicon Graphics workstations instead of the $ 3 @,@ 000 personal computers that were the standard at the time . Gavin created an algorithmic texture packer that would deal with the fact that the 512 x 240 video mode left too little texture memory . Meanwhile , Baggett created bidirectional 10x compressors that would reduce the 128 @-@ megabyte levels down to 12 megabytes and allow them to be compatible with the PlayStation 's 2 @-@ megabyte random access memory . The levels proved to be so large that the first test level created could not be loaded into Alias PowerAnimator and had to be cut up into 16 chunks . Each chunk took about 10 minutes to load even on a 256 @-@ megabyte machine . To remedy the situation , Baggett created the <unk> , a level design tool where component parts of a level were entered into a text file , with a series of Adobe Photoshop layers indicating how the parts were combined . To code the characters and gameplay of the game , Andy Gavin and Dave Baggett created the programming language " Game @-@ Oriented Object LISP " ( <unk> ) using LISP syntax . 
