12 comments

[ 3.0 ms ] story [ 39.0 ms ] thread
I am intrigued because the readme at Github mentions Naughty Dog using it for level shading and such, and I was recently impressed to hear anecdotal evidence of them, for the longest time, using Lisp and now MzScheme/Racket (they are really using the former because they have not been able to update their codebase substantially) to stitch everything together for building all the media into a test environment for games, going back to Jax. And they have been doing so as late as 2013, if you believe the ND employee who talked at RacketCon.

http://con.racket-lang.org/2013/danl-slides.pdf

It sounds like they have quite a ... heterogeneous environment.

This framework is used for making tools, Lisp, or rather their own variant of it, is used in-game as a scripting language and goes all the way back to their Crash Bandicoot games on the PS1.

I believe I read somewhere that since coming to the PS3 generation they started moving more of their systems to C# and C++ in order to be able to share more code with the other Sony WWS.

Ironically, my impression, and with the caveat I have not had enough time to complete watching the Naughty Dog talk from RacketCon, is the opposite.

Rather, the guy who moved it from Common Lisp to Racket informed the audience it is actually used like an advanced templating system to allow the system/core devs to interface with sound engineers and programmer-designers (not artists, but the guys coding the art into Maya3D templates and what not) to generate proper header and class structure for their C++ engine. These guys are not the core C++ devs, so they needed something to streamline their work for many test builds and that could be used to assist programmers that were not trained or designated for core systems programming (with C++ and all that entails). This actually irritated one guy in the audience, and made me laugh because CL variants have many more native code compilers, and the native C transpiler in Racket (although useful) is touted as something you would use (it is for systems porting), because their JIT and native code compilation receives a lot more work.

Anyway, this is all here-say. I would say watch the video and read the slides. Although Racketeers will be disappointed that this dev from ND, sometimes apologetically, admits they used MzScheme and had not really moving ahead with updating to later Racket versions (hence the name change) or many other features.

The description says it's for Windows. Anyone know what's blocking it on Mono? Or possibly they've just had a Windows-only target for management reasons and didn't investigate Mono yet?
AAA game studios are mostly Windows based, specially given the way gaming culture works, so most probably no one ever tried anything on Mono.

Additionally, the readme also has references to DirectX dependencies.

Since this is related to tools surrounding games there probably isn't much point to make it really cross-platform. If your designers and developers are using Windows anyway investing resources in a Linux version doesn't help anyone. The games themselves run on other platforms anyway and don't care where the levels were designed.

A few things that won't run on Mono are pointed out in the readme as well: »You must have Windows 7 or later to run the circuit, FSM, statechart, and timeline editors, due to their use of Direct2D.«

Thanks for pointing out the Windows dependencies from the page!

Lots of people are doing game dev on Mac and Linux, though not so much on the big game studio dept. For example you can do Unity dev (& target all platforms) + iOS dev + Android dev on a Mac pretty well.

Well, this is Sony open-sourcing an until-now internal tool. Which means that up until now their only interest was to satisfy their own developers. Who are most likely on Windows.
Nice to see memory safe languages gaining a stronghold on big game development studios, even if mostly tooling related.
This is impressive, comes with a lot of samples, and has the UI components every game studio needs for their tools (timeline editor, state machine editor, proper tree view, etc). Samples compile and run out-of-the box in VStudio2010. Also comes with a PDF detailing why .NET is a better choice then Qt, but I don't quite buy that ;)
its not even a fair comparison, because it's not comparing .NET with Qt, it's comparing ATF (the name of this toolset) with Qt.

so it's like saying "using our 3d game engine is easier to build games than pure opengl", which makes sense because it was made for it. now when they compare ATF with another toolset like it build in Qt then it will be a fair comparison.