Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical Breakdown of a new NES game written in Lisp

dustmop.io

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Technical Breakdown of a new NES game written in Lisp

#41

Post by cheez »

reikonomusha wrote: post #13

This was an incredibly enjoyable read. A lesson to take away is that many of the ideas of Lisp can be taken advantage of without reeling in the entirety of an existing stack. Writing a Lisp parser is easy. Walking Lisp code is easy. Serializing Lisp code is easy. Adding a new primitive is easy. Adding very basic syntax transforming macros is easy. All of these are virtually trivial if your host language is a Lisp, as…

They used Lisp to generate machine code. They didn't parse lisp at all. Imagine writing a library in your favorite language to do what they've done.

Re: Technical Breakdown of a new NES game written in Lisp

#42

Post by saagarjha »

asguy wrote: post #40
djmips wrote: post #35

Earlier quoted context omitted.

Hard reasons. Forth implementations on the 6502 uses a stack and require more RAM than Co2 which uses a compiled stack. I feel like Co2 would compile to faster code but of course I haven't benchmarked this. The reason I feel this is so is that I way I understand compiled forth is that the 'words' are still threaded so you don't escape the interpreter overhead. Soft reasons. Co2 takes away the chore of parsing, in For…

> Forth implementations on the 6502 uses a stack and require more RAM than Co2 which uses a compiled stack. I don't know what you mean when you say this. Could you elaborate? Any function call is going to require putting the arguments somewhere. > The reason I feel this is so is that I way I understand compiled forth is that the 'words' are still threaded so you don't escape the interpreter overhead. Indirect/direct…

> I don't know what you mean when you say this. Could you elaborate? Any function call is going to require putting the arguments somewhere.

There's a footnote in the article that might be helpful:

> this is thanks to a "compiled stack", a concept that's used in embedded programming, though I had a hard time finding much literature about it. In short, build the entire call graph of your project, sort from leaf nodes to roots, assign to each node memory equal to it's needs + the max(children)

Re: Technical Breakdown of a new NES game written in Lisp

#43

Post by saagarjha »

ngcc_hk wrote: post #22
scrollaway wrote: post #9

Earlier quoted context omitted.

The other side of that coin is that on mobile the article is painful to read and the layout is horrible. For what it's worth I hate medium as well. But I would recommend ghost.org if you want to go with self hosting.

Seems ok reading in my mobile safari, not even using reader mode.

The code causes the page to scroll horizontally, unfortunately. Not a big deal, though: Reader Mode solves this on the client-side, and the website just needs to add CSS that lets the code scroll.

Re: Technical Breakdown of a new NES game written in Lisp

#44

Post by reikonomusha »

cheez wrote: post #41
reikonomusha wrote: post #13

This was an incredibly enjoyable read. A lesson to take away is that many of the ideas of Lisp can be taken advantage of without reeling in the entirety of an existing stack. Writing a Lisp parser is easy. Walking Lisp code is easy. Serializing Lisp code is easy. Adding a new primitive is easy. Adding very basic syntax transforming macros is easy. All of these are virtually trivial if your host language is a Lisp, as…

They used Lisp to generate machine code. They didn't parse lisp at all. Imagine writing a library in your favorite language to do what they've done.

They did parse it, albeit indirectly, by Racket’s reader. Co2 is a language, not a bunch of function calls, so it’s not quite the same as building a library in your favorite language. The article even gives examples of new syntax they produced.

Parsing Lisp in Lisp is so easy because it’s free.

Re: Technical Breakdown of a new NES game written in Lisp

#45

Post by fouc »

Looking at the code examples of the entity system in this article made me wonder what it'd be like to code a MUD in this language or in lisp generally.

Does anyone know if there are any MUDs out there coded in lisp? I didn't find any good results in google aside from the MPI lisp-like language built on top of FurryMUCK.

Re: Technical Breakdown of a new NES game written in Lisp

#46

Post by bitwize »

j_m_b wrote: post #2

One of the advantages of lisp is REPL-driven development. I imagine you can't just edit a fn, eval it and then see the changes immediately. What is the workflow like when creating a NES game using co2?

I dunno about Co2, but the last time I heard about a project like this -- Naughty Dog's GOAL -- they absolutely could compile GOAL on the fly on the development PC and send it immediately to run on the PS2 dev kit inside an already running game. REPL-driven development directly on a game console. It was awesome.

Re: Technical Breakdown of a new NES game written in Lisp

#47

Post by cheez »

reikonomusha wrote: post #44
cheez wrote: post #41

Earlier quoted context omitted.

They used Lisp to generate machine code. They didn't parse lisp at all. Imagine writing a library in your favorite language to do what they've done.

They did parse it, albeit indirectly, by Racket’s reader. Co2 is a language, not a bunch of function calls, so it’s not quite the same as building a library in your favorite language. The article even gives examples of new syntax they produced. Parsing Lisp in Lisp is so easy because it’s free.

https://github.com/dustmop/co2/blob/master/compile.scm#L3689

Indeed, it's almost trivial.

Re: Technical Breakdown of a new NES game written in Lisp

#48

Post by jasperpilgrim »

djmips wrote: post #33
jasperpilgrim wrote: post #3

This is impressive. I appreciate you documenting the development of it and giving an overview of what's going on inside. I wish there were more blog posts like this. Have you reached out to the Racket community about the game and co2? Also, would you say this Lisp is geared more toward people who already know 6502 assembly, and not toward people who just want to write a NES game in a Lisp?

With only looking through the article and being a 6502/NES programmer myself, you can't escape having to know 6502 and the NES hardware to write a NES game. This Lisp is cool and it will certainly smooth the process and is a good fit for an Adventure game and other parts of NES game development where you aren't counting cycles (like UI).

Good to know. Assuming it's true that 6502 asm is not too difficult to learn, co2 looks like it would be fun to work with on a simple game. Really neat project.

Re: Technical Breakdown of a new NES game written in Lisp

#49

Post by 320x200 »

fouc wrote: post #45

Looking at the code examples of the entity system in this article made me wonder what it'd be like to code a MUD in this language or in lisp generally. Does anyone know if there are any MUDs out there coded in lisp? I didn't find any good results in google aside from the MPI lisp-like language built on top of FurryMUCK.

A bit tangential, in relation to MUD-like games and Lisp. The original author of co2 (that is to say before it was developed further by OP), has worked on a multi-user interactive fiction with some of the other persons who worked on this NES game. For that he used mzscheme to run a server side virtual world of bots/NPC interacting with the players via a browser/javascript client.

You can find some information there:

https://archive.bleu255.com/nakedonpluto/about/

https://gitorious.org/naked-on-pluto/game-server (cert expired)

https://gitorious.org/naked-on-pluto/game-client (cert expired)

Re: Technical Breakdown of a new NES game written in Lisp

#50

Post by TurboHaskal »

ska wrote: post #27
TurboHaskal wrote: post #8

Earlier quoted context omitted.

Most Lispers and some Schemers are quite pragmatic in that regard. With the former favouring OOP and looping over recursion and the latter using imperative code when it matters. With developer mindshare flocking to the Haskell view of FP, for the Lisp family, only the Clojure users seem to still hold purity in high regard.

With the former favouring OOP and looping over recursion Not my experience at all, fwiw.

While I will not try to debate your experience, I will provide some extra context for my previous assertion:

You cannot program in CL without using the CLOS. Most CL books go into great detail explaining it and the MOP, they are also full of looping constructs, even using GOTO. The only exceptions are Graham's books.

In open source, it is frowned upon to use recursion as TCO is not part of the standard. Some functions are even inlined for better performance.

Post reply on HN