Inventing on Principle - amazing video!

Started by
65 comments, last by ddn3 12 years, 2 months ago
You asked why nobody is building tools like that.
Because we can't.
No, actually, we do. In every (good) video game engine, we do build tools like this.
If you can't edit content (code+data) and immediately see the new results on your screen, then your game engine needs an upgrade.

However, if you interpret the aim of such tools to be as general and broad and impossible as you can, then yes, you're right, it's definitely unpossible. Any time anyone brings up the halting problem, they're probably off in some academic la-la land instead of actually doing something useful in reality, like upgrading my damn game engine so I can see what I'm doing.
Advertisement

[quote name='Antheus' timestamp='1329920682' post='4915495']You asked why nobody is building tools like that.
Because we can't.
No, actually, we do. In every (good) video game engine, we do build tools like this.
If you can't edit content (code+data) and immediately see the new results on your screen, then your game engine needs an upgrade.[/quote]

But you need to build the tool that will fit into whichever project you're currently building. You don't have a tool first, then as you go along, it shapes the result. That's the idea behind these concepts.

An engine inevitably limits you to whatever it was designed for. Compare this to tree concept, which starts as bunch of lines, then experimentally moves into day/night scenery of a tree in wind.

instead of actually doing something useful in reality, like upgrading my damn game engine so I can see what I'm doing.[/quote]
There are more articles from same author, including one of them mentioning the reason for these experiments.

As long as designer (whoever) needs to call onto a developer to do a tweak or do some technical bit, there's a huge impediment to creativity. Pipe dream goal of such experiments is to present tools that vanish out of sight.

In the same way one no longer needs a programmer to read mail, write docs or edit spreadsheets.

Imagine writer trying to write a new book using some text editor:
W: "I'm trying to present John as sarcastic, but the paragraph keeps breaking"
P: "Yea, the TLB is getting messed up, you've only got 4GB of RAM"
W: "Can you fix it?"
P: "Well, I could work around it if you reduce allegory to only 2 pages"
W: "But those sections define the premise"
P: "Could you rework the childhood suffering motive?"
W: "..."

Text editing is a blank canvas which doesn't limit the content written. But existing programming tools do, or at very least, we've exhausted creative potential they can realize. It's less that we cannot do interesting things with them, it's that the reach has plateaued.
An engine inevitably limits you to whatever it was designed for. Compare this to tree concept, which starts as bunch of lines, then experimentally moves into day/night scenery of a tree in wind.
No, the tree demonstration would map exactly as is onto a modern game engine. One viewport shows you your scene, the other shows you the design behind the scene, which you can tweak with realtime feedback. Playing with these controls leads to discovery.
As long as designer (whoever) needs to call onto a developer to do a tweak or do some technical bit, there's a huge impediment to creativity. Pipe dream goal of such experiments is to present tools that vanish out of sight.[/quote]Exactly! This is what we do, and that's the trend that game development has been following for 10 years. If many tasks are dependent on a coder it indicates your engine is more of a programmer's SDK rather than a modern game developer's toolbox.
We build the kind of stuff shown in these experiments every day - this is what game engines have become, so the examples in the video should not be surprising or "impossible/impractical" at all!
Just watched that video. The circuit editor is the most impressive thing. As someone that's tried to design an analog circuit he perfectly captures how complex it is to visualize the effects of small changes to a design. Especially if you compare it to what the market has for analog circuit editors which look like 1994 VB6 applications.

Exactly! This is what we do, and that's the trend that game development has been following for 10 years. If many tasks are dependent on a coder it indicates your engine is more of a programmer's SDK rather than a modern game developer's toolbox.
We build the kind of stuff shown in these experiments every day - this is what game engines have become, so the examples in the video should not be surprising or "impossible/impractical" at all!


Just a note, but doesn't Unreal let you change/tweak most everything in at least some runtime sense? I don't think you can edit the full game at runtime, but stuff like art I believe can be shown in engine as you are editing it iirc. I think it's also pretty trivial to hop into any point in a game to test while you edit (one button I think?). I'd assume CryEngine is similar, but have no experience with it. I know runtime tweaking of existing gameplay behavior is nothing taboo in the projects I've been on outside these two engine's as well--maybe underutilized, but the functionality has been there.

Looking back it seems like the problems he's talking about, while flashy, are already somewhat solved. It almost sounds like, "I'm going to make a tech demo of a less fully featured version of Unreal Kismet and brand it as my own innovation."

Exactly! This is what we do, and that's the trend that game development has been following for 10 years. If many tasks are dependent on a coder it indicates your engine is more of a programmer's SDK rather than a modern game developer's toolbox.
We build the kind of stuff shown in these experiments every day - this is what game engines have become, so the examples in the video should not be surprising or "impossible/impractical" at all!


Where is my time traveling debugger then? Just like the guy moves forward and backward, where's a tool for that? Because that idea didn't exist until a few years ago, whether in games or elsewhere and has since been patented into oblivion.

Of course purpose-specific tools have been built since day 1. Presentation is more about further reaching ideas, about concepts that really are not available today.

And considering I do have all the latest tools, I don't see anything that has moved even an inch beyond the Turbo Pascal era of tooling. But apparently, VS 2011 will be gray instead of purple?

Obviously, I can built something myself, from scratch, specifically tailored to specific problem being solved. There is definitely an incredibly advanced tree editor. But it was and always will be nothing but a tree editor. Very useful, proven in day-to-day, but still just a tree editor.

Nobody is denying that increased hardware power made dynamic programming more accessible or that specific domains have state-of-the-art tools. Ironically, programming has always been about dynamic and interpreted languages, there was just a brief phase where compiled languages offer sufficient performance edge to dominate.

Experiments like these are more about thought process that long transcends the notion of tool itself. Just like there is a universal compiler instead of one being forced to build one specifically for each individual project, or one focused on tiny subsections of problems.

Whether they're useful or not will more depend on individual project. True creativity is in very short demand these days.

The circuit editor is the most impressive thing.[/quote]

Tons of other examples, including further reasoning behind experiments.

Based on those, the guy started thinking about these concepts while working for Apple, where he realized designers were constrained by tools and still depended on programmers. I'd doubt that Apple of all things has problems keeping up with latest and greatest when it comes to design, prototyping or production. Thought it doesn't necessarily mean those experiences transfer to every other domain.

There is definitely an incredibly advanced tree editor. But it was and always will be nothing but a tree editor. Very useful, proven in day-to-day, but still just a tree editor.

It's not a tree editor. It's a rectangle, multiple splotchy circle, jagged line, single large circle editor that happens to also be able to make a tree with mountains/moon.

ph34r.png

It's not a tree editor. It's a rectangle, multiple splotchy circle, jagged line, single large circle editor that happens to also be able to make a tree with mountains/moon.


I was referring to SpeedTree or equivalent modules. Vastly superior to the demo, but in idea just a tree editor, built with disproportionate effort over past 10 years.

The demonstration suggests equivalent free form tool.

Kinda like the old spice guy. Look up, it's a tree, look down, now it's lines, look back up, it's waving in the wind. It's night. Now it's day.
That was a very cool video, I like his ideas and he's a good presenter.

Just watched that video. The circuit editor is the most impressive thing. As someone that's tried to design an analog circuit he perfectly captures how complex it is to visualize the effects of small changes to a design. Especially if you compare it to what the market has for analog circuit editors which look like 1994 VB6 applications.


There are programs like Spice that do circuit simulations already, although I do like his graphical waveform representation. However, some of his comments lead me to believe that he doesn't understand the purpose of a schematic. The symbols are there to show how the components connect together, not merely as a means of drawing a circuit on paper. I could take that schematic, and without knowing its purpose or how it works, get the components, wire them together and the design will (hopefully) work as the designer intended. His resulting "schematic" is all but useless. If I were trying to make a PCB out of that, I wouldn't know where to start!

This topic is closed to new replies.

Advertisement