GOAL's syntax resembles the Lisp dialect Scheme, though with many idiosyncratic object-oriented programming features such as classes, inheritance, and virtual functions.^[1] GOAL encourages an imperative programming style: programs tend to consist of a sequence of events to be executed rather than the functional programming style of functions to be evaluated recursively. This is a diversion from Scheme, which allows such side effects but does not encourage imperative style.

GOAL does not run in an interpreter, but instead is compiled directly into PlayStation 2 machine code to execute. It offers limited facilities for garbage collection, relying extensively on runtime support. It offers dynamic memory allocation primitives designed to make it well-suited to running in constant memory on a video game console. GOAL has extensive support for inlined assembly language code using a special rlet form,^[1] allowing programs to freely mix assembly and higher-level constructs within one function.

The GOAL compiler is implemented in Allegro Common Lisp. It supports a long term compiling listener session which gives the compiler knowledge about the state of the compiled and thus running program, including the symbol table. This, in addition to dynamic linking, allows a function to be edited, recompiled, uploaded, and inserted into a running game without having to restart. The process is similar to the edit and continue feature offered by some C++ compilers, but allows programs to replace arbitrary amounts of code (even up to entire object files), and does not interrupt the running game with the debugger. This feature was used to implement code and to enable level streaming in the Jak and Daxter games.

GOAL's first use was for the Jak and Daxter: The Precursor Legacy game. The predecessor language, Game Oriented Object Lisp (GOOL), was also developed by Andy Gavin for Crash Bandicoot.

Since Naughty Dog no longer employs GOAL's primary development and maintenance engineer, and they were under pressure from their new parent company, Sony, to share technology between studios, Naughty Dog transitioned away from Lisp:^[2]

In all honesty, the biggest reason we're not using GOAL for next-gen development is because we're now part of Sony. I can only imagine Sony's shock when they purchased Naughty Dog a few years back, hoping to be able to leverage some of our technology across other Sony studios, and then realized that there was no way anyone else would be able to use any of our codebase. Sony wants us to be able to share code with other studios, and this works both ways - both other studios using our code and vice versa. Add this to the difficulty curve of learning a new language for new hires, lack of support from external development tools (we had our own compiler, linker, and debugger, and pretty much had to use Emacs as our IDE), etc, means that there are clearly a lot of other factors involved. Note, however, that these issues aren't really technical problems, they're social ones.

— Scott Shumaker

However, they have since resumed using it for scripting on some PlayStation 3 games, including The Last of Us.^[3]

A community project, OpenGOAL, started in 2020 with the goal of porting GOAL to x86-64 by decompiling existing Jak and Daxter: The Precursor Legacy and Jak II assets and recompiling them natively.^[4] It includes a GOAL compiler written in C++ as well as a read–eval–print loop to enable a similar workflow to Naughty Dog's original implementation.

• Naughty Dog Software: Raising the Paradigm of Video Gaming – Again…Thanks to Lisp and Allegro CL
• Jak & Daxter: The Precursor Legacy (PowerPoint) – development overview, lessons learned
• Highly detailed continuous worlds   – about the streaming world loader