OpenGOAL: Port of Jak and Daxter, written in GOAL, a custom Lisp by Naughty Dog | Hacker News Reader

OpenGOAL: Port of Jak and Daxter, written in GOAL, a custom Lisp by Naughty Dog

github.com

381 pointsmsk-lywenn109 comments

Related talk by Dan Liebgold from Naughty Dog, at RacketCon 2013:

https://www.youtube.com/watch?v=oSmqbnhHp1c&t=55s

Starting at around 10m into the talk, Liebgold says their DC language for TLOU (to get what they most needed from a DSL even if using C++ instead of GOAL) was implemented in Racket.

For anyone not familiar with TLOU, it was a critically-acclaimed game, and my personal all-time favorite game for storytelling that somehow grabbed me. (I dislike all zombie franchises, but at a key point towards the end of the nonlinear narrative and playing in the game, I was surprised how much I really wanted to protect the kid. Which I'll partly attribute to a Lispy DSL that helped them execute immersive storytelling in a zombie stealth shooter.)

https://en.wikipedia.org/wiki/The_Last_of_Us#Critical_respon...

This is one of the Racket success stories. They seem to happen because someone already knows they want a Lisp, they end up picking Racket without needing anyone else's permission, and the people using it are capable of designing and building whatever missing pieces they need.

TLOU is “The Last of Us”

In the cause of Naughty Dog, it was Andy Gavin who introduced Lisp and GOAL and was one of the co-founders of Naughty Dog. He came from MIT and was a student of Rodney Brooks.

https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

https://all-things-andy-gavin.com/2011/03/12/making-crash-ba...

If someone hasn't seen it, his episode on Ars Technica's War Stories was awesome. He seems to be a hacker's hacker. It's a fascinating story because it's not really how I personally work (internally), so it's fun hearing someone describe just diving in like that.

https://www.youtube.com/watch?v=izxXGuVL21o

https://www.youtube.com/watch?v=pSHj5UKSylk

It was my understanding that Racket wasn't in use anymore at Naughty Dog. It would be cool if there was an update or someone who knows (I know Dan is no longer at Naughty Dog), because unfortunately the tale of Lisps in companies is normally that it eventually gets replaced or set aside (where new stuff is built in something else).

> because unfortunately the tale of Lisps in companies is normally that it eventually gets replaced or set aside (where new stuff is built in something else).

Any sufficiently advanced Common Lisp or Scheme program will eventually be rewritten in C++, Java, Python, or JavaScript.

Why? Is there a reason other than "most people don't know lisp and it's cheaper not to teach them?

In my experience, companies are deathly afraid of doing something even perceived as different when it comes to software. And my experience has been at places developing advanced novel hardware, so I would always try to point out the discrepancy. Why are people willing to try new things and train on advanced hardware projects but software gets relegated to the least common denominator? If it's not Python, C, or C++, it's a hard sell to try anything else, no matter the many multipliers that could come from switching.

I think it makes sense. When I start a new project, I tend to limit the number of risks I'm taking at a time. If I'm using a brand new language, I'm probably not going to also use a brand new database. If I'm going into a brand new domain I'm completely ignorant of, I'm going to use non-risky tech. And so on.

Could it be a lack of trust in the capability for learning new (old) things? The thinking, that a software developer is but a script kiddy?

I wish it were so simple, yet I think the rapid advances in the last 10 years or so in Java, C++, and JavaScript, which developers have been expected to learn and keep up with, are sufficient to more than cast doubt on that. The changes on whole are nearly broad enough to count as new languages. If that's not enough, then there's the mobile development side of things, which have seen actual language shifts in Objective C to Swift and Old Java to Kotlin.

That's probably part of it.

Another possible factor: When I was at Google there was a similar phenomenon where any sufficiently complicated Python system seemed to get reimplemented in something with static types. A problem we had with Python (and I imagine this would be true of most Lisps -- yes, I know typed Racket exists) was that once a system got too big to keep in your head all at once, large-scale refactoring became almost impossible without the help of static types.

I agree that static types is certainly a barrier. My day job is in a dynamic language for the first time ever, and it's certainly been a challenge and learning curve for me. It's in Elixir, so I just seemingly annoy everyone by putting typespecs on everything. Haha. Even if Dialyzer isn't ran, it still provides some documentation on what's going on where.

My personal opinion is that there aren't any huge barriers to making static and dynamic types meet more in the middle. There's the gradual typing approach like that in Racket and Typed Racket, but I feel that most of the times dynamic languages are really just dealing with fairly simple anonymous unions. Like a function make take a string or float and return some data structure or a boolean value.

yup. fortunately, static typing support in python has made significant progress on both tooling and language fronts in the past few years.

Successful programs tend to attract reimplementations, and those are probably written by different kinds of people than the originals.

People even completely rewrite older Java programs into newer Java programs, changing large parts of the technology stack...

> Any sufficiently advanced Common Lisp or Scheme program will eventually be rewritten in C++, Java, Python, or JavaScript.

I'd change that: `s/sufficiently advanced/sufficiently profitable/g`

The state of advancement is no indicator that something needs to be maintained, while the state of profitability is a reliable indicator that something will be maintained.

> unfortunately the tale of Lisps in companies is normally that it eventually gets replaced or set aside

Wikipedia page on GOAL says exactly this happened.

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

Sounds exactly like the sort of thing execs think when buying a company but then don't include in their due diligence.

I used to work for a company which got bought out and it turned out that the technology that they wanted us for was exactly the one piece of our code that we white labelled.

Was does white labelling mean?

I would guess they got it elsewhere and just resold it under their own brand (at least that is what it broadly means in hosting).

I can highly recommend the interview with Jason Gregory of Naughty Dog from Handmadecon 2016. He gives a lot of insight into the reality of working with the scheme-based format in recent-ish times.

https://guide.handmadehero.org/hmcon/2016/05/

My impression isn't that scheme is being passed out just because Sony doesn't like it, but also because the language has issues. On the other hand, it seems they're putting a lot of effort into getting the nice scheme features, like hot reloading, in their C++ environment.

I love hearing Gavin talk about solving problems, even decades afterward, he seems genuinely excited.

GOAL / games written in Lisp have been a lifelong obsession. I used to search for hours for any scrap of information about the language. I would have traded a lot for this repo when I was 19.

Thank you to the authors for fulfilling a teenage dream. Please consider doing Last Of Us next —- I once downloaded it and tore it apart for any signs of lisp, but it was all compiled bytecode. That’s where I gave up, but it looks like you took it one millennium further by reverse engineering the bytecode from Jak and Dexter to make your own port that compiles to the same bytecode. If you have infinite time, you could theoretically do this for last of us too, and also last of us 2.

Naughty Dog transitioned away from GOAL after they were purchased by Sony. Uncharted and TLOU are mostly written in C++.

All the scripting in Uncharted and TLOU is still in lisp. Well, actually, it's scheme now. They use M-something... It's the core of Racket.

Edit: MzScheme

MzScheme hasn't be a name for Racket for at a decade+. Maybe the earliest Uncharteds? Racket now uses https://en.wikipedia.org/wiki/Chez_Scheme which vaguely rhymes but there's no relation.

Uncharted! That’s the one. Didn’t they do a video long ago about uncharted + lisp? I seem to remember them talking about some interesting benefits they got out of it.

Although the engine is mostly C++, the bits that aren’t are usually the most interesting. And the most impactful. So it would be neat to analyze, if for no reason other than archaeology.

I remember seeing a video like that too, but I don't remember what it was or where I saw it. Doing a brief search didn't show up anything.

I remember they were talking about the combat system specifically.

I crossed paths with someone who joined ND around the time they were purchased by Sony. According to him, Sony told them "You will be working with other Sony companies. They will not be using GOAL. Switch to C++."

Sounds like Viaweb after Yahoo.

What is it with Large Video Game Producers like Sony or EA interfering in studio internal technical detail decisions?

I distinctly remember EA pushing the Frostbite engine on bioware and thus ruining the franchises in production (MassEffect Andromeda/ Anthem).

Is this just another case of visible external costs (engine licensing) vs invisible internal costs (complete restructuring/retraining of existing pipelines/ engine rewrites)?

In the case of Sony and Naughty Dog, it's my understanding that Naughty Dog serves two purposes. One is that they are a game studio that makes games but the other is that they're a technology development studio that exports common tech for other Sony game studios to make their games with. While I'm on the side of Lisp and C++ makes me itchy, I can understand why that would be a hard sell.

Naughty Dog had very good reasons to avoid alienation that would come by sticking to their custom languages (not necessarily Lisp). Only one person on the team really properly knew how the GOAL compiler worked and how it interacted with the rest of the Naughty Dog toolchain, and that person would have to leave the company at some point. Remember that, since they are under the Sony umbrella, they would have to share technology around with the other teams. They were aware this could turn into an issue, and mention it in some interviews and e-mails: https://www.neogaf.com/threads/why-did-naughty-dog-abandon-g...

It's a "can't win" scenario in that the presumed advantage of a large org is that studios can share tech and therefore get an edge in deploying it across all titles - but they can't do it in a way that's really optimized to anyone's particular situation. Depending on the structure and communication flows the game teams can feel like code was "thrown over the fence" at them, or they feel chained into a method of asset production, builds and testing that is, for their purposes, extremely costly. Generalizing an engine has always been a very hard, two dimensional problem:

1. If you're pushing the platform, you need every part of the asset pipeline to be optimized for it, and probably lower level runtime optimizations too.

2. If you're doing something well within the constraints, your bottleneck is on implementing the specific types of assets that will make your game unique. As games get more featureful more and more micro-categories of assets show up - bits of UI text, custom behaviors, scene transitions, camera movements and so forth.

3. If you do 1, then 2 becomes more challenging because you made more optimizing assumptions, so the game production may fall off schedule due to lousy tooling making it hard to actually test anything in-game. If you focus on 2, you don't have as many reusable parts, and you're adding pressure to optimize near the end of the dev cycle, which can result in catastrophic bugs from changing assumptions in the asset-code mix, like "we tightened when we load in streaming assets. This broke a cutscene trigger because now it loads at the wrong time."

And then you add in an external tech group and you have another layer of communication to deal with, so the design or art teams can't just grab a coder and say "hey, this workflow sucks, give me a little support on this." Whether it's in the org or third-party, it's the same problem: you really need engine coders on staff to handle some things.

But the case can always be made: "if we have an internal engine group we can put all the smartest people in one place and have them develop the next-gen graphics." And once you have that group, it's politically necessary for the management to make its tech as widely deployed as possible, otherwise, why budget for them? The engine teams at large publishers who follow this kind of hard separation are known for having relatively cushy, high-profile gigs, while game teams are disposable bodies that churn out necessary but low-value features. Conflicts of interest and fiefdoms emerge from that. Some of them do enforce rotations and other protocols to lower the barriers.

re: a deleted comment saying that last of us only had lisp in their dialog system and nowhere else:

I swear I remember a YouTube video from naughty dog about lisp, and that it was about one of their later engines. But at this point I think I just hallucinate parens wherever I go, so maybe not.

Bet it was the most extensible dialogue system ever though.

> That’s where I gave up, but it looks like you took it one millennium further by reverse engineering the bytecode from Jak and Dexter to make your own port that compiles to the same bytecode.

If I'm reading this right, the original Jak and Daxter was written in a Lisp, too? If so, that's pretty cool and I wouldn't have guessed.

It was written in a Lisp/C mashup and compiled to MIPS assembly.

Same people wrote ITA Matrix (aka Google Flights) in Lisp.

But GOAL didn't have a GC, so it might not really count as Lisp.

Are you sure? GOAL was created by Andy Gavin, a co-founder at Naughty Dog who never worked at ITA to my knowledge.

Edit: I was just randomly watching this video (https://www.youtube.com/watch?v=cHkk9isDfg4), and Dave Baggett came up. When I searched his name, it does look like he was a co-founder of ITA after leaving Naughty Dog.

The predecessor to GOAL was GOOL and was 100% Andy's work. We used it to code the logic for the objects in the Crash games (critters, platforms, etc.) and I actually wrote the entire load/save UI in it as well! I assume GOAL was also all Andy but I don't know that for sure because I only worked on the Crash games.

ITA's use of Lisp was driven by our co-founder and Chief Scientist, Carl de Marcken. He wrote the prototype in LispWorks, then the production code in Allegro, and then we finally ported everything to CMUCL when Franz essentially tried to extort us for a tax on our entire business. (We couldn't imagine this would become the norm for consumer "apps" five years later, but that's another topic entirely.)

Ultimately the MIT AI Lab circa 1993 was the source of the decisions to use lisp for both these commercial products. At the time, the lab's culture was still very much influenced by all the work done there and in spin-off companies in the late 80s commercializing lisp, e.g., at Symbolics (first registrant of a .com domain name!)

At INKY (my current startup) we use Python. By 2010, when I started the incubator that evolved into INKY, it was pretty clear that scaling a development team on a lisp stack was going to be really difficult.

Thank you for the history and background! It's great to get it from a first-party source.

> Ultimately the MIT AI Lab circa 1993 was the source of the decisions to use lisp for both these commercial products.

I suppose another example is iRobot, where there's a custom Lisp-like language used, at least in the earlier robots. My understanding is that it's not used as much anymore if at all.

> ITA's use of Lisp was driven by our co-founder and Chief Scientist, Carl de Marcken.

I chuckled at his website that states "I retired long ago and almost certainly do not find whatever commercial project you want help with interesting".

> At INKY (my current startup) we use Python. By 2010, when I started the incubator that evolved into INKY, it was pretty clear that scaling a development team on a lisp stack was going to be really difficult.

If you were to start it today, with the developments of languages like F#, Elixir, and Clojure, do you think you'd have a different decision or outcome? I'm just curious, as a hypothetical.

GOAL does have a GC, though particularly primitive, and is definitely a lisp (there can be lisp without GC, it's just an unnecessary failure of design to not have one)

Funny, because there's an old run and gun PC game "Abuse" that was famous for being one of the first commercial Lisp-scripted games, but very little has been done with its open-sourced codebase since its Lisp code is notoriously hard to work with.

So, it's not GOAL, but I've been starting to work with https://fennel-lang.org and Love2d, and there's a twice-yearly Lisp Game jam that happens.

I've found that I like Fennel (and Janet as well, both created by the same author, though they have different maintainers) quite a bit. Turns out that having simple semantics and a very regular syntax makes for a language that makes writing basic code feel nice.

given the amount of interest in the hobby lisp game dev community it would be super cool if naughty dog/sony (or whoever own the license now) open sourced GOAL

This is what makes OpenGOAL and video game archeology so mission critical. It isn't just preservation of digital culture. I think there are real insights to be gained.

Next step is to make a cookbook of classical Game AI techniques (monte carlo tree search, goal oriented action planning) in GOAL. Then it becomes a package anyone can use, like PhysX and RAD tools ;)

Abuse was mostly written in Lisp. 2d side scrolling action game from the 90s that was unusual in being commercial with a brick and mortar release but also supporting Linux. It uses keyboard for direction mouse for aiming at the same time, which was also kind of unique at the time. The code is open source, complete with modernization, but you have to dig around for it nowdays.

https://en.wikipedia.org/wiki/Abuse_(video_game)

The ars technica extended interview with Andy Gavin is a great watch (mentions lisp from his time at MIT) https://www.youtube.com/watch?v=pSHj5UKSylk

I absolutely loved Jak and Daxter and still run through it every few years. I think it was the peak of the 3D platforming era. Jak 2 with its fantasy take on GTA was excellent, too.

I'll never understand why, compared to the other Naughty Dog franchises, it was basically dropped and forgotten. Or why Ratchet and Clank was favoured (comparitively bland and boring imo).

I’m floored and amazed. I’ll certainly look into contributing but…how did the devs acquire a language spec for GOAL? My understanding was that that was the major blocker of these types of projects for years.

OP also posted https://blog.jakspeedruns.com/opengoal-project-update-septem... a while back. It has a section on "How is this possible?"

Whoa, that is crazy!

TL;DR for folks is that they left a lot of debug information in the build. The C code was compiled with no optimizations (and included debugging symbols), and GOAL uses a string-based table for global functions/variables/types, so they're starting with all those for free. Plus they don't think the GOAL compiler did too much tricky-to-undo optimization either.

Just curious... what makes you look at this and want to contribute? I'm interested in why people do these unlicensed emulation projects at all and it sounds like you have at least one answer as your motivation.

As far as I know, GOAL/GOOL remains the only time Lisp has ever successfully been used in a video game. Given Lisp's near-mythic status of productivity, it at least piques my interest to see how ND might have used it creatively in the codebase.

That and I've always wanted to check out the language after Andy Gavin (ND founder) talked it up on here [0]

[0]https://news.ycombinator.com/item?id=3152131

> As far as I know, GOAL/GOOL remains the only time Lisp has ever successfully been used in a video game.

'Abuse' had a substantial lisp component.

Cool, thanks for sharing that.

I had no idea Andy Garvin was on hn, but makes sense :)! I had a vague memory that Super Mario 64 also used lisp and when I googled, I found him again [0].

You've likely seen this, but I recently watched and loved this extended interview with him about making Crash Bandicoot [1]. Really made me want to look more into making video games.

[0]: https://news.ycombinator.com/item?id=2474833

[1]: https://www.youtube.com/watch?v=pSHj5UKSylk

Yeah it's rather amazing what Lisp applications in the 90s contributed to. https://en.wikipedia.org/wiki/N-World is the software mentioned in the comment, the modern equivalent being Blender. The Credits section of that page has some great classics like SM64, FF7, Banjo-Kazooie...

It also had great tutorials and documentation: http://www.aaronjamesrogers.com/misc/nworld/N-World-Intro.ht...

It's a shame that its successor Mirai https://en.wikipedia.org/wiki/Mirai_(software) just kind of vanished. Its main claim to fame is Gollum's face. Chronologically it's not that different from Blender, which also imploded around the same time in the early 2000s, but Blender was able to go open source and survive and have another 20 years of development to get where it's at today. I don't know that the world would look all that different if Mirai had been able to take a similar path, but at least there'd be a cool modern 3D modeling tool in Lisp.

I worked on Banjo Kazooie and the claim that N-World was used for it is incorrect. We used Maya for all modelling. They did a demo to the BK team once and it went really badly for them. What they demoed to us was so far from being competitive with Maya that it was almost laughable.

Thanks for the correction! I guess another instance of Rare just doing it better than Nintendo ;) I've been trying to track down any source for the original rumor without success, the random IP seems to have made it up. Did you ever get to see much of their later Mirai tool? Though I would also believe Maya was quite far ahead at that time too.

No the demo went so badly for them that we never invited them back. I kinda felt sorry for them. They had no clue how uncompetitive they were compared with the tools we were already using. One of the two demo guys kept going on about how better it was because it was using Lisp. While also acknowledging that it was missing pretty much all the features we needed. The “it’s easy to implement yourself because Lisp!” argument was laughable given that Maya already had the features we needed and used every day.

> They had no clue how uncompetitive they were compared with ...

Sadly not that uncommon in Lisp advocates for a number of different things even today... though I think that's been slowly changing as more Lispers either become aware of what's out there, or come with experience of what's out there and bring that knowledge with them to Lisp. The reverse direction seems to happen at least as slowly -- I've commented before that a JRebel setup is very close to bringing the still largely unique interactive development mode of Lisp over to the Java world, but it's also in important ways not fully there and may never be. Meanwhile many other languages don't even care about that development style at all.

> The “it’s easy to implement yourself because Lisp!” argument was laughable

I guess this would be kinda analogous to when Blender first added Python support, if they told everyone to just do expected things themselves. It may be true that such-and-such task is relatively easy to implement (if indeed it's possible to do at all without changing something about the application itself) but it's also just a terrible thing to focus sales on when the value seems like it'd mostly be measured by how useful the tool is to non-programmers.

I hadn't really looked much at the "Wide Open World" doc on the archive since it's not mentioned in the other docs except vaguely in like one spot I had to search for, but if a customer had heavy scripting needs to accomplish things not already provided or easily done with the graphical tools, now the customer's not only being sold on a graphics tool but also on learning to program in Lisp using their bundled xemacs. And as you note it's even worse when that work is already done in another tool that can't be integrated with. Though I see they provided an FFI so there could be a possibility of integrating C code the customer or others wrote. If a customer was expecting to have to do a bunch of new custom stuff regardless of tool maybe it'd have made more sense... But now at least I have an additional insight into why they weren't very successful.

I'm appreciating anew a lot of things the last products I worked on got right in terms of providing a good enough and frequently improving out of the box set of components and workflows while paying some attention to competitors to see what key things were lacking on either side, while streamlining development and deployment of custom components, and also providing a platform for customers to share their own custom work with each other either openly or by putting a price on it.

Not only that but Maya already supported custom code. I wrote a few plugins for Maya to export models and animations to our own optimised-for-N64 format. I wrote it in C (BK was all written in C). Maya also had (has?) a scripting language (called MEL I think?) that other teams used. It apparently made it super easy to do even advanced stuff. So given that, the “Lisp advantage” made even less sense. I must admit (again) that I felt really sorry for them. It is hard to watch somebody failing that badly doing a demo. But I will also say that making a sales call without first figuring out what they were up against (Maya) was a bad move. They had no clue what they were competing against. I think you are right that the “Lisp is awesome” thinking let them down the wrong path.

I believe one of the generations of Age of Empires has it's AI written in lisp

Age of Empires 1 had AI scripts that were written as production rules in a very Lisp-like syntax. (You can still find some online.)

Not sure if they integrated a full Lisp or Scheme system, but since the rules were not arbitrary source code, nor doing unification, etc., they could have just hand rolled a custom reader, and written the rule engine itself in C...

Abuse, a 1996 PC side scrolling shooter, had a good chunk of it written in lisp.

https://github.com/antrad/Abuse_1996/tree/master/data/lisp

Zork ZIL was pretty Lispy (example at [1]). Whether it qualifies as "a Lisp" depends on your definition.

[1]: https://github.com/MITDDC/zork/tree/master/zork

Zork ZIL was based on MDL, which was a Lisp derivative with "More Datatypes than Lisp", developed at the Dynamic Modeling Group (on the MIT-DM PDP-10 running ITS) by MIT's Project MAC (which the MIT AI Lab split off from).

https://en.wikipedia.org/wiki/MIT_Computer_Science_and_Artif...

https://en.wikipedia.org/wiki/Incompatible_Timesharing_Syste...

HN discussion: Zork source code, 1977 (github.com/mitddc)

https://news.ycombinator.com/item?id=23108626

https://github.com/MITDDC/zork

About MDL:

https://en.wikipedia.org/wiki/MDL_(programming_language)

>MDL (programming language)

>Paradigms: Multi-paradigm: functional, procedural, reflective, meta

>Family: Lisp

>Designed by: Gerald Sussman, Carl Hewitt, Chris Reeve, Bruce Daniels

>Developer MIT Project MAC

>First appeared: 1971; 51 years ago

>Final release: 105 / 1980; 42 years ago

>Typing discipline: Dynamic, strong

>Scope: Static, lexical

>Implementation language: MDL

>Platform: PDP-10, VAX, Apollo/Domain

>OS: ITS, TENEX, TOPS-20, BSD, AEGIS

>License: Open-source

>Influenced by: Lisp

>Influenced: ZIL, Planner, Scheme, Common Lisp, Java, Prolog, Smalltalk; actor model, interactive fiction

>MDL (Model Development Language, or colloquially also referred to as More Datatypes than Lisp: or MIT Design Language) is a programming language, a descendant of the language Lisp. Its initial purpose was to provide high level language support for the Dynamic Modeling Group at Massachusetts Institute of Technology's (MIT) Project MAC. It was initially developed in 1971 on a PDP-10 computer on a time-sharing operating system named Incompatible Timesharing System (ITS). It later ran on TENEX, TOPS-20, BSD, and AEGIS.

>The initial development team consisted of Gerald Sussman and Carl Hewitt of the Artificial Intelligence Lab, and Chris Reeve, Bruce Daniels, and David Cressey of the Dynamic Modeling Group. Later, Stu Galley, also of the Dynamic Modeling Group, wrote the MDL documentation.

>MDL was initially called Muddle. This style of self-deprecating humor was not widely understood or appreciated outside of Project MAC and a few other early citadels of information technology. So the name was sanitized to MDL.

>MDL provides several enhancements to classic Lisp. It supports several built-in data types, including lists, strings and arrays, and user-defined data types. It offers multithreaded expression evaluation and coroutines. Variables can carry both a local value within a scope, and a global value, for passing data between scopes. Advanced built-in functions supported interactive debugging of MDL programs, incremental development, and reconstruction of source programs from object programs.

>Although MDL is obsolete, some of its features have been incorporated in later versions of Lisp. Gerald Sussman went on to develop the Scheme language, in collaboration with Guy Steele, who later wrote the specifications for Common Lisp and Java. Carl Hewitt had already published the idea for the language Planner before the MDL project began, but his subsequent thinking on Planner reflected lessons learned from building MDL. Planner concepts influenced languages such as Prolog and Smalltalk. Smalltalk and Simula, in turn, influenced Hewitt's future work on the actor model.

>But the largest influence that MDL had was on the software genre of interactive fiction (IF). An IF game named Zork, sometimes called Dungeon, was first written in MDL. Later, Reeve, Daniels, Galley and other members of Dynamic Modeling went on to start Infocom, a company that produced many early commercial works of interactive fiction.

>In 1980 Marc Blank and Joel Berez adapted the MDL language to create a subset called ZIL (Zork Implementation Language) which was used extensively by Infocom to create their award winning games.

     <DEFINE EXIT-TO (EXITS RMS)
             #DECL ((EXITS) EXIT (RMS) <UVECTOR [REST ROOM]>)
             <MAPF <>
                   <FUNCTION (E)
                      #DECL ((E) <OR DIRECTION ROOM CEXIT NEXIT DOOR>)
                      <COND (<TYPE? .E DIRECTION>)
                            (<AND <TYPE? .E ROOM> <MEMQ .E .RMS>>
                             <MAPLEAVE T>)
                            (<AND <TYPE? .E CEXIT> <MEMQ <2 .E> .RMS>>
                             <MAPLEAVE T>)
                            (<AND <TYPE? .E DOOR>
                                  <OR <MEMQ <DROOM1 .E> .RMS>
                                      <MEMQ <DROOM2 .E> .RMS>>>
                             <MAPLEAVE T>)>>
                   .EXITS>>

The MDL Programming Language Primer, Michael Dornbrook, Marc Blank:

http://publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-29...

The MDL Programming Language, S. W. Galley and Greg Pfister:

http://ifarchive.org/if-archive/programming/mdl/manuals/MDL_...

The MDL Programming Environment, P. David Lebling:

http://ifarchive.org/if-archive/programming/mdl/manuals/MDL_...

Zork's ZIL targeted the Z-machine, now implemented on everything.

GOOL-level code used to be maybe not common, but also not uncommonly implemented in some form of a lisp (these days it's pretty much all Lua). Naughty Dog continued using Lisp for those purposes at least throughout Uncharted series.

There are some indie games done in Lisp, including at least one small Visual Novel released on Steam and another currently in development (2d platformer called "Kandria").

Several games, both indie and not, used Lisp as development tool - this includes games like "What Remains" (hn link: https://news.ycombinator.com/item?id=20930986 ) as well as numerous tools used IIRC at Nintendo.

Lisp was used for some code for the original NES, there was a presentation about it but it looks like only the reddit thread[0] linking to it still exists.

[0] - https://www.reddit.com/r/programming/comments/6e6zwn/i_had_n...

> Given Lisp's near-mythic status of productivity

I have seen a lot of claims of this but no real evidence? And I know Lisp quite well (having implemented my own versions of Lisp for fun). If Lisp truly is way more productive than other languages, why haven’t we seen lots of Lisp software out-competing software written in other languages? Surely a few Lisp guys could outcompete everybody else if Lisp is as super productive as claimed.

This is not an "unlicensed emulation project". In fact, it's not emulation at all.

It looks like they don't have a full goal spec, but are relying on the copious debug and runtime type information, as well as the simplicity of the original goal compiler (and arguably the simplicity of lisp itself) to come up with something close that's semantically equivalent.

There's a lot of snippets posted over the years on various forums. Nothing much, a few pages to get a hint of the syntax and the basics. Once you've picked apart the loader/runtime[1] the dynamic nature of the Lisp runtime system allows the system itself to hint a lot at how things originally went together. (e.g. type information is always present, state machines are explicit and easy to spot)

[1] http://www.codersnotes.com/notes/disassembling-jak/ (my old article this is based off)

I love projects like this. Well done to everyone involved.

On a related note, back when I was engine programmer for a PS2/Wii/Xbox engine I remember my boss always coming and saying "How do we get it to draw more in the distance. Just like Jak and Daxter!". It was a high bar to reach.

Note that the original GOAL compiler was written in Common Lisp (specifically Allegro CL). I wonder if the sources are still existing?

Between this, SM64 PC, and OpenLara, old-school games are fertile ground for custom code mods and general hackery-dackery. Probably illegal (but for the OpenLara engine, maybe) but still so cool.

And out of this we get a free implementation of GOAL, long thought lost!

This might interest you: https://github.com/zeldaret/oot recently reached 100% byte matched decompilation.

https://osgameclones.com

That's so cool. Just a few months ago I reversed a bit of the GOAL runtime in an effort to understand how it worked (aap/goal on github) but I didn't dream of seeing everything decompiled. great work

If we get Jak 2, I'll die happy.

This. Jak 1 was okay but 2 was outstanding.

I just saw that there is sales on PS Store. So if you own a PS4 grab the whole collection with all 4 Jak games. But yeah, an open source JAK would be unbelieavble.

I've read that the PS4 ports are bad and that the PS3 ones were the way to go. I haven't compared myself, though.

Can someone explain the significance of this to me? I'm not caught up on this topic.

Jak & Daxter was a very good, technically impressive 3D platformer that came out in the early 2000s for the Playstation 2. It was developed by an American studio called Naughty Dog, who was famous for previously making the Crash Bandicoot games and has since gone on to make the acclaimed Uncharted and Last of Us games.

Certain kinds of techies were particularly enamoured with Jak & Daxter because, at a time when console devs rarely spoke much about the tech behind their stuff, and at a time when games were almost universally programmed in C/C++ with bits of assembly language, the developers of Jak & Daxter openly discussed how they had written the bulk of the game logic in a custom Lisp dialect they called GOAL, which itself was built with Common Lisp. If you don't know what Lisp is or understand why that's cool, well - Lisp is a very interesting programming language that pioneered a lot of incredible ideas in computer science and that certain hackers develop a real connection to, including one of the biggest names behind this site/Y Combinator, but has always struggled a bit in the market. Seeing it used in a AAA game production like this was, for those hackers, really exciting; maybe because it might be the beginning of an industry-wide move towards Lisp (which never happened), or maybe just because a Lisp success story like this was vindicating.

This appears to be a (work-in-progress) source port of the game and the GOAL language, produced with a lot of reverse engineering work. So it's neat to finally get to see first-hand this GOAL Lisp stuff that we've heard about for years, and if the project reaches completion it'd also make for a great way to play the game on modern hardware or mod it.

Thanks! I loved playing this game growing up. I had heard later on that it was a technical achievement, but didn't realize they made their own dialect of Lisp.

Very cool projects. I love how the original game had debug menus, and the newly–written renderer (which uses opengl) _also_ has debug menus (looks like it’s based on Dear ImGui, but I haven’t looked at the code yet).

https://www.youtube.com/watch?v=5zGok-jEWO4&list=PLWx9T30aAT...

One of the pleasures of using Lisp for a game is not necessarily needing to add such UIs, or anything else special, to achieve interactive changes; you just change the code and recompile while it's running and see the differences. Unhandled bad bug throws you into the debugger? Debugger doesn't unwind the stack, just pauses the thread. You can inspect stuff, there might be relevant pre-made resolutions you can choose from (restarts) and continue, or you can fix things up however and recompile, and resume at any point in the call stack.

But fully fleshed out debug UIs are cool and useful in the large. There's a guy who's been integrating a bunch of C++ stuff including Dear ImGui into a Lisp engine, see: https://twitter.com/borodust/status/1443647135765962763 and https://twitter.com/borodust/status/1446569651236921346

Yes, having a repl is a superpower. But soon enough you learn which things will find you the most bugs, so you start making a menu out of them. Teleporting to levels, spawning mobs, etc.

In this case they were debugging the render, to fix problems that result in game’s own graphics being unusable. So they added their own system on top, so that they can inspect the data being sent to the gpu, turn on wireframes, etc. It’s a delightful look at what all of computing is going to look like in a thousand years, with layer upon layer of tooling as new generations of engineers adapt older programs to work on new systems. Remember “A Deepness in the Sky”?

If you look at https://youtu.be/6dJhyVqqq5Q?t=63 you can see even the original debug menus have extra options!

Nice to see this has an advertised Nix build!

I hope to return to https://github.com/NixOS/nixpkgs/pull/72366 at some point, so all arches can be built similarly!

I had never heard of GOAL (as in https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp) before... briefly wondered what GOAL (as in https://en.wikipedia.org/wiki/GOAL_agent_programming_languag...) had to do with anything. Naming things is hard...

A side note. I have been fascinated by NWN Toolset since its release. I wonder if we ever get a chance to look at the full pic of the scripting language. There are some reaearches online though.

I see the github code breakdown is 70% CL and 30% C++. The comment below says the original GOAL compiler was written in CL. Is it the same goal here? What's the C++ part in this project?

The decompiler code is written in C++ [0], because you have to start with something.

https://github.com/water111/jak-project/tree/master/decompil...

Makes sense, thank you.

This is great! I've wanted to play Jak 1 since I was a kid but its interlacing issues make it quite visually unpleasant to look at on a modern screen, even using emulation.

Oh my, Rock Village is on fire!

Will be watching with intense interest, Jak & Daxter was my childhood.

This is the kind of project I wish I had the technical chops for.

Might be a daft question - will people eventually be able to write their own PS2 games using this engine?

This port is for x86-64, not the PS2. If anything you'd see people using this for their PC games. But realistically probably nobody's gonna do that.

Right, got it. I was feeling a bit slow yesterday. Thanks!

All the Jak games were amazing. I wonder why the genre has almost died now?

I enjoyed both Crash 4 and Psychonauts 2 . Genre is not as popular as the PS2 days but is not dead yet.

I wasn't keen on Crash 4. I appreciate they were trying to do something different, but whacking up the difficulty and having to scrap the lives system to compensate just felt lazy and disappointing. Striking a reasonable difficulty balance is one of the main challenges in game design and to me, they failed it.

I think Crash 2 was about the sweet spot and what they should aim for. Once you got good, you could sort of flow through the levels smoothly.

This is really great to see!

Ratchet and Clank port when

421c7bab81ac33663640dd3b0407356bb1c9eb5d

Reply on news.ycombinator.com