Reasoning behind the original GOAL after all?

[csotiriou]

Hello, I just found out about this project, and I am really fascinated by the work behind it.

I read here that one of the reasons behind OpenGOAL is to figure out why Naughty Dog wrote an entire language just for J&D. So I would like to ask two questions, considering that the project has progressed much:

1. After investing time to OpenGOAL, has anyone figured out exactly what made Naughty Dog create a different programming language instead of developing a toolchain around popular programming languages that would allow them to achieve the same task? Are there actual merits behing GOAL after all?

2. Also, do you believe that there is there anything in GOAL currently that is worth creating a game engine around it if we take into account how much has the industry progressed since the PS2 era? (in case some other developers in the long term future want a new challenge)

Personal (maybe false) opinion Maybe a new language is that GOAL provided many debugging capabilities like hot reloading, advanced scripting functions, and some abstractions to improve performance. That may have been feasible by creating a toolchain on top of C++, but it may have come at a cost of creating an abstraction layer, which could result in a performance penalty, especially in the debugging section. But, this is just an assumption, and I would like to know the opinion of the OpenGOAL developers since they have more experience with GOAL.

PS. Thank you for OpenGOAL, which seems to be a perfect example of devs that love technology and compilers and allow others to feel the same.

[water111]

That's a great question.

If I was going to develop GOAL today, I'd very strongly consider using an existing language as a base. There are frameworks like LLVM that can handle optimization and code generation, and you'd just have to write a front-end for GOAL that generates LLVM-IR. This would be a lot easier, and could give you great performance. LLVM is the backend of the clang C++ compiler, the rust compiler, and the Julia programming language.

In 1999, there was no LLVM. The only programming language that existed for the Playstation 2 was a port of GCC from Sony. My understanding is that this port was very buggy, especially at first. The compiler would crash, and would generate incorrect code in some places, particularly when working with the 128-bit integer registers. There were weird constraints like only being able to use 10 of the 32 floating point registers in inline assembly. That said, I'm pretty sure ND could have made a GOAL compiler that generated C code, and fixed bugs in GCC as they went.

So I think they went with a totally custom language for a few reasons:

• avoid the buggy GCC from Sony
• support loading code at runtime. You can do this with C, but the process of loading in a new object file will likely take ~10's of ms, and cause frame drops. With GOAL, you could run a linker process in the background that slowly links in new code over many frames.
• very good support for assembly. The whole language was designed around being able to mix together high level and assembly code. Jak 1 probably has many 10,000's of lines of assembly, which I believe is only possible because GOAL makes it very easy to write. The inline assembly in C/C++ is much worse.

For your second question: Yeah I think there's plenty of stuff in GOAL that's still good, and missing from modern game development:

• the ability to run code at a REPL and easily inspect things
• tools to more easily control data layout of types
• tools to easily build and lay out data at compile time. They can do things like store an object in a file, load that file, then call a virtual method on that object. And all this is done very efficiently, without needing some extra pass to deserialize data.
• better inline assembly is nice, but these days compilers are pretty good, and the sort of optimizations they made don't matter as much on modern CPUs.

[csotiriou]

Awesome response, thank you very much. I suppose that if you were to do this today you would use LLVM and write a front end on top of it…?