Conspire: A Programming Environment for NOWHERE(blog.duangle.com)
blog.duangle.com
Conspire: A Programming Environment for NOWHERE
http://blog.duangle.com/2015/01/conspire-programming-environment-for.html
18 comments
I can't help to be amazed with what they're pulling off. First of all, the game prototype looks amazing, although it may be one of those forever-early-access games, because it can't be just a game. Then you see how Blender widgets are used. Wow. Then you see how he's imitating UE4 Blueprints, again, wow.
But then the reality kicks in. Shouldn't you be making a game?
But then the reality kicks in. Shouldn't you be making a game?
Leonard actually addresses that in a few a places, though I don't have a link handy right now. The short version is they're creating a game that's almost entirely defined by procedural content.
To even attempt such a thing requires a lot of good tools because they not only need those tools to build procedural content for the game but for their userbase to be able to as well.
He seems well aware of the trap here and is trying his best to avoid it.
To even attempt such a thing requires a lot of good tools because they not only need those tools to build procedural content for the game but for their userbase to be able to as well.
He seems well aware of the trap here and is trying his best to avoid it.
This forum post[0] is one of those places where he addresses that problem:
> Right now is, hands down, the worst part of development. There are no fancy graphics to show off, no intricate gameplay, no surprising AI, no badass music, just unglamorous system design that interests no one so we can get all the aforementioned stuff in a manageable form that doesn't keep becoming a sluggish and unserviceable mess. […] The importance of tooling can not be overstated. There are no tools out there for the kind of game we're working on, and it comprises 90% of what makes the game, as nearly all of our content is procedural in one way or another, and not handmade. If there's currently a lack of procedural content out there, it's precisely because of the lack of tooling.
[0] http://nowherians.com/discussion/comment/254/#Comment_254
> Right now is, hands down, the worst part of development. There are no fancy graphics to show off, no intricate gameplay, no surprising AI, no badass music, just unglamorous system design that interests no one so we can get all the aforementioned stuff in a manageable form that doesn't keep becoming a sluggish and unserviceable mess. […] The importance of tooling can not be overstated. There are no tools out there for the kind of game we're working on, and it comprises 90% of what makes the game, as nearly all of our content is procedural in one way or another, and not handmade. If there's currently a lack of procedural content out there, it's precisely because of the lack of tooling.
[0] http://nowherians.com/discussion/comment/254/#Comment_254
As an early backer of the project and fan of paniq's, I'm happy to let he and his wife go off on tangents like this, because I know whatever they build is going to be awesome. Of course, most backers are probably not as pumped about text editing environments and game dev tooling as I am :P
I was sold on the game video, then the article talks about SICP and LISP - nice! Sounds like great fun and possibly some real innovation here. I hope it's beta for a few years like Minecraft with a strong developer community around it.
Reminds me of the lofty goals of http://lighttable.com and EVE http://www.chris-granger.com/2014/10/01/beyond-light-table/
Reminds me of the lofty goals of http://lighttable.com and EVE http://www.chris-granger.com/2014/10/01/beyond-light-table/
There's Smalltalk env too, like Pharo/Squeak, the long forgotten Lisp Machine, Max/MSP and their descendant... A lot of giants on which shoulder we can see a bright future !
Wow, this (and the game videos) looks awesome!
I'm a CS student and I'm very interested in procedural generation. I was wondering if there are any particular resources you'd recommend for a beginner?
I'm a CS student and I'm very interested in procedural generation. I was wondering if there are any particular resources you'd recommend for a beginner?
If you want knowledge from the same pool Ritter's drawing from, check out this blog post[1] about fr-041: Debris by ryg. Now, keep in mind, Ritter didn't do work on Debris as far as I know, but he's spent a lot of time with the people who did, and some of the ideas in NOWHERE have their origin in that scene (a lot of it is totes original, but you're asking about procedural generation, and procedural generation is definitely a demoscene thing).
Before game dev, Ritter was known as a musician and a demoscener (if you don't know what the demoscene is, do some googling -- it's deffo worth it). The demoscene group he was part of broke exciting new ground in the mid 2000s by releasing some productions that packed ridiculous amounts of content into a very small size by procedurally generating lots of things, like textures and geometry. The greatest of these demos is called Debris[2], and some consider it the best demo ever. Ryg's article is basically a big index of articles explaining how parts of Debris were written, as well as how they work.
[1] https://fgiesen.wordpress.com/2012/02/13/debris-opening-the-...
[2] Watch it here: https://www.youtube.com/watch?v=mxfmxi-boyo
and keep in mind that everything you're seeing was rendered in real time by a single executable 177kb in size.
[3?] Also worth looking at: http://www.iquilezles.org/www/index.htm
Before game dev, Ritter was known as a musician and a demoscener (if you don't know what the demoscene is, do some googling -- it's deffo worth it). The demoscene group he was part of broke exciting new ground in the mid 2000s by releasing some productions that packed ridiculous amounts of content into a very small size by procedurally generating lots of things, like textures and geometry. The greatest of these demos is called Debris[2], and some consider it the best demo ever. Ryg's article is basically a big index of articles explaining how parts of Debris were written, as well as how they work.
[1] https://fgiesen.wordpress.com/2012/02/13/debris-opening-the-...
[2] Watch it here: https://www.youtube.com/watch?v=mxfmxi-boyo
and keep in mind that everything you're seeing was rendered in real time by a single executable 177kb in size.
[3?] Also worth looking at: http://www.iquilezles.org/www/index.htm
Awesome, thank you!
I'm just waiting for the inevitable realization when he realizes he can cut out Lua from the architecture and go straight in with Scheme.
Actually, I very much wanted to do that, the problem is that there seems to be no Scheme implementation available that offers such a tight and convenient libffi integration. LuaJIT parses preprocessed C header files with very few adjustments. Terra, which links LuaJIT with LLVM, goes the full mile and directly uses libclang to generate interfaces.
If you know a Scheme implementation that does this (including supporting a LLVM back-end in addition to a regular, possibly JIT'ed interpreter), please do not hesitate to mention!
If you know a Scheme implementation that does this (including supporting a LLVM back-end in addition to a regular, possibly JIT'ed interpreter), please do not hesitate to mention!
Gambit and Chicken are near your goal, but I don't know how far you can go with it. And there's of course GNU Guile.
Neither is suitable. Guile has the wrong license, none of these three has bindings for a no-JIT code generator like LLVM.
It's no big deal though. The Scheme -> Lua compiler is small (300 lines) the dialect is better suited for hash tables and the dynamic part is mostly a driver to generate/execute machine code at runtime.
At this point, a switch to Scheme would service purism more than pragmatism. Lua is already a good Scheme VM (has been strongly inspired by Scheme, in fact) so it'll do. At least I hope it will. ;-)
It's no big deal though. The Scheme -> Lua compiler is small (300 lines) the dialect is better suited for hash tables and the dynamic part is mostly a driver to generate/execute machine code at runtime.
At this point, a switch to Scheme would service purism more than pragmatism. Lua is already a good Scheme VM (has been strongly inspired by Scheme, in fact) so it'll do. At least I hope it will. ;-)
Hey, this is neat, I've always liked the Blender node editor, and now a clone of it is split out into its own library.
I'm also happy to see the tools open-sourced, which is sadly not common enough in the game development world.
I'm also happy to see the tools open-sourced, which is sadly not common enough in the game development world.
What is this what looks like flow style programming environment? I could not find anything about it.
previous submission: https://news.ycombinator.com/item?id=8848714
He's known as paniq in the demoscene and did the music, 2d engine and graphics for the awesome Masagin:
https://www.youtube.com/watch?v=sbQhgEJuExY