Notgames Forum

I´m totally blown away by this talk, I really hope for this to be the future of programming and creation tools:

http://vimeo.com/36579366


So glad to see there are smart engineers on our side!

I was up until 3am last night freaking out about it and writing a blog post:
http://www.godatplay.com/2012/02/bret-victor-is-about-to-change-game-design-forever/

The talk is brilliant and poignant, but his videogame demo is simply a logical conclusion to his article Ladder of Abstraction written in November. It's the article that's the groundbreaking part, that demo is simply some work following the method he lays out so clearly. In other words, if you think the talk is amazing, you have to read it. :)

Michael has talked about this before, and I totally agree with him. Programming is deeply flawed when it comes to making artistic work. The tighter your loop can be, the more you can sketch, and therefore the more you can use the right side of your brain.

I love the talk. And not just for the game design and programming part. His general approach to design and life resonates deeply with me. It's just how I approach games. It comes from the same indignation. That there aren't more artistic games isn't an opportunity – it's an outrage. It's morally wrong. And that's actually a very healthy place to come from when designing something. It focuses what you're trying to do.

Also, if you're interested in interaction design (I am, since it's my day job), his essay Magic Ink (http://worrydream.com/MagicInk/) is good reading too. It details another point he mentions in the talk, that good interaction design is about visualization and comparison.

While I certainly share his principle, I don't believe in his ( current? ) direction for a programming solution.

There's no need for a separate input "view" in the form of conventional code.

(http://i.imgur.com/vk5wU.png)

All authoring should be done directly on the end-product .. just like his animation tool.

(http://i.imgur.com/c0IrR.png)

Gah! :o I can't wait to watch this video!

It's like he's already onto everything we've been discussing about how great it would be to make games without programming.
http://evolutionlive.blogspot.com/2010/09/how-artists-want-to-make-games.html
http://notgames.org/forum/index.php?topic=308.0

Anyway, yeah, I'm jealous...


I know what you mean. ;) But maybe we can work together! I know this will be a very difficult challenge, and I'm sure it could benefit from some teamwork... Even if that means working on separate attempts and just sharing progress and problems and insights along the way.

Totally know what you mean. In my post I said "It's the kind of talk that TED talks merely aspire to."


I've been e-mailing him since June of last year, but he has never gotten back to me, not once. My latest was right after watching this video, where I offered to help or partner or something...

It makes me sad to think that, after all of his talk about living according to a principle and feeling wronged about the current creative process of software development, he'd just not respond. I'm guessing he's afraid to release anything until it's packaged more neatly. And that is only going to prolong the pain.

But at least someone is taking his mind-blowing concept and implementing it. All the better that it is he himself!

I wrote a nice reply to this but the browser ate it. So all I'm going to say is: I'm all for it. I'm an artist. Give me tools to make games with that an artist can use. Not thrilled with his guru-ish, inspirational-speaker thing though.

I have only seen the first 2/3s of the video so far, up until the iPad animation app. But so far, I'm afraid I must agree with Kjell: we don't need even more tools to make more pleasant. We need to replace coding with an interface that is compatible with the kinds of brains that (visual) artists have.

I also think his illustrations are kind of cheap: it's easy to show a relationship between a program that draws something and the drawing. But a large part of programming games is not about drawing things to the screen. It's about systems, logic, rules, etc. We need a way to visualize those, so we can work directly on the structure. In a way, his circuit interface is already better than the code, even without the charts stuck on them: it has the potential to show the flow of the logic. A drawing of a tree cannot do that any better than code can.

I'm glad that there's a programmer who realizes the problem. The next step now is for him to consult with the people who actually experience this problem, rather than inventing solutions based on his imaginations about the problem, engineer-style. I'm sure his ideas would help coders, people who already have enormous amounts of software tools to choose from. But it does not address his issue: creating a context where people can have and explore ideas. Much like the current situation, his work excludes artists, once again.

The animation tool is by far the most interesting. But animation tools are already a lot more accessible to artists than programming tools. It's an easier problem to solve (I have actually programmed a crude version of his system way back in the 90s; it worked in a browser).

I agree with you guys, but surely it is reasonable to think there are intermediate steps before getting there.

Engineering work is required in order to build tools that allow one to work directly on the structures. What he is doing is adding sketching to the vocabulary of the engineer. That will change the way an engineer thinks because it will use the right side of the brain more. And that will cause the engineer to think about artistic ways to work.

There are already visual programming tools, but they're stuck in the old school code/compile style of development. It is not too large of a step to add a visual programming layer on top of his software. And then you'll have something that's much more purely like sketching. So that'd be the next step.

Another step would be to take his selection feature and start tying it directly into the visual programming layer. And then you'd have direct visual editing and sketching.

I'm a coder and I'm not really an engineer. My strengths were always in the creative arts and I don't feel this has hindered me in the slightest when it comes to coding. So I'm naturally curious, what is it about coding that doesn't work for you?

This is how coding looks to me:

first and foremost before coding anything, I need to have a logical argument with myself using my spoken language - really, an inner philosopical struggle (it can take me months to resolve one little function if I am feeling particularly creative);

then I need to plan what I have decided to do and I need to visualise it. This includes drawing flow charts, connecting everything together and organising what I will be doing. You'll often see me holding my hands out in front of myself, measuring invisible objects, drawing shapes in the air. I have notebooks full of abstract drawings, too - sound familiar?

finally I need to code the damn thing in a language. Languages is a great name for them, because they're nothing but a collection of symbols used to communicate something. My girlfriend, who is a linguist, used to think me a genius for being able to code (her who speaks half a dozen languages). Then I sat her down and explained the symbols and their use as logical constructs, something she understood with her background in human languages and philosophy. Hey, what do you know - she can program. If she can, you can! [/motivational bullshit]

Sure, we can abstract programming to a higher level - not saying there is anything wrong with that. Just be aware that a higher level isn't guaranteed to change the fundamentals. Forgive me if I am making assumptions, but it sounds like a fear of working in a different medium. I don't mean that to sound as patronising as it does and I wish I could get you all in a room to explain it to you better. I don't believe programming is out of any of your reaches, especially as artists. Programmers are a diverse group (who share a common distate of bathing =D) hailing from all sorts of backgrounds and who often blossom into wildly diverging directions, from NASA engineers to Lead Artists at AAA studios.

I can only speak for myself, here. I am coding for the last 20 years of my life, so it should come natural to me... I also do painting for a couple of years. now. There is a fundamental difference between painting and coding. Coding is a very indirect way to create something beautiful. When I paint it is immediate. You paint with your guts and you code with your mind.
The only process which is the same for me is, before I do coding or painting. When I think about what I am going to paint or code, when I decide on a theme or subject. Also experimenting in code is way harder, because every line of code feels like hard work. It is not playful (to me) like working with paint. I should have get used to it, but it still feels like work. I don't know if I made something clear or if I confused you more, but you might get the picture. Also there is this thing about the right and left part of the brain, and I think coding and painting are not in the same side (at least not for me)...

cheers,
George

This is not about the difficulty of programming. This is about preferring a interface that lets you draw a line using your mouse / tablet instead of typing ..

Thanks for the reply, George. They certainly are different mediums and need to be approached differently on some level. Good point on the immediate vs non-immediate difference, too - I'm guessing that is he crux of the desire for these tools?

There are some engines DKs with visual programming, there are some SDKs/compilers that compile as you type (the example in the video is a natural extension of this process). I think with regard to drawing a line and it is coded for you, I understand the concept in principle but don't exactly agree with its entension to code - isn't that what artists' programs do already? A mesh isn't some abstract object that exists in the ether, it's structured data wrapped into a file by a program that acts as an interface between an artist and code. You could certainly tie everything together with an additional layer of abstraction, but you'd be relying on using pre-determined blocks. In essence, that's what an 'engine' with a UI is anyway, and it will come to its natural progression. I just think it is a bit wrong to assume that this would be a good way to develop interesting software - remember making 'games' is a collaborative process involving lots of creative people from many differing disciplines. As a coder, I can think of many ways to knock out the artists, too =P

I guess I see it like this:

Writing a novel using magnetic words
'Sculpting' using Lego
Painting with stencils

These things have all been done and some interesting work has arisen from them. However, I think you can needlessly limit yourself if you come to rely on tools and, ultimately, you still need to understand the fundamental concepts underlying your craft to utilise them well.

There is the famous story of some asking James Joyce if he had a good day writing. He replied he had, he had two whole sentences of words - now he just had to find the correct order for them! Perhaps coding is more like writing than painting.

I'm letting a brain fart loose here, please do not take anything too seriously. I love the artists, it's the designers I loathe ;)

Just like programming languages themselves rely on pre-determined blocks (http://en.wikipedia.org/wiki/X86_instruction_listings).


Artists / animators / musicians that rely on "limiting" tools like Photoshop / Maya / Reason seem to do just fine.

no problem, for me there is no way around coding. I love it, too.

Coding is like painting, except that you would use a telephone to give your painting instructions to a remote, neutral painter, instead of painting yourself ;)

If you are writing a novel or poetry, there still is this important power of immediacy, which is sorely missing when coding. Sometimes I get in a coding flow. Code, compile, run, code, compile, run...

Exactly! I don't think many artists would prefer this approach to the conventional way of painting :)

I'm not trying to be argumentative, but hopefully this gives you a better idea of the "other side" as it were, Fourth. :)

It comes down to the creative process. Right now there's no real way to sketch unless you are an expert programmer. It seems like many of us commenting here are not; we use programming as a means to an end.

What sketching does is take you to a state of mind that's very right-brained. It's holistic thinking, where associations are made that aren't normally made with logical thinking. Text-based language and logical thinking are left-brained, both of which are the realm of programming.

The goal then, for a more right-brained style of software development, is to not have to think about the logical side and to purely express ideas, just like sketching or free writing. One way to do this is to become an expert programmer. Another way is to use tools that do as much of the left brain stuff as possible so you don't have to.

Personally, I'm no longer afraid to learn more programming, that fear left me over a year ago. So I could become an expert programmer...but I don't want to. I know that takes time, and I'd rather spend that time designing experiences. I'd rather spend that time more directly living out my own principle.

Even so, I think there's some validity to the fear of becoming an expert programmer. It changes how you think. And that could lead to seeing certain design situations as a problem that needs to solved. That's how much of game design has worked up to this point, and if you want to go in a new direction, it's worth considering different ways to think.

Kjell, I also wrote some blog posts on the subject that might help you understand why we care about this.

http://evolutionlive.blogspot.com/2007/07/art-and-engineering.html
http://evolutionlive.blogspot.com/2009/03/google-is-future-of-games.html
http://evolutionlive.blogspot.com/2010/09/how-artists-want-to-make-games.html

I find that lately I've been leaning toward the direction of becoming an expert programmer (though I am far from it, now), rather than focusing on design. Which is interesting. My ultimate goal, however, is to make a tool like this such that I no longer need to become an expert programmer.

Not all! Both Quest3D and Max/MSP are real time. The Endless Forest is programmed live! (while people are playing it, in fact)

I agree that the compile loop is detrimental. But in a way visual programming is more compatible with live coding because you can't make syntax errors.

I would even go as far as to say that coding is one of the reasons that vidogames have not evolved. Because coding indeed requires the linear process that Fourtwall described: first thinking, then producing. But invention happens more often by accident, by responding to errors, during a process. Especially in a new medium where everything still needs to be invented, we should not be limited by the rigid ways of thinking that coding requires.

This doesn't mean that engineers need to start working in a different way. It means different people need to get access to this medium. And I guess most engineers are unwilling to release their control and stranglehold. Luckily there are some who see the benefits. Now they just need to pay more attention to us, the actual users of these
 alternative interfaces that, sadly, only they can build at this point in time.

Everything you've said sounds exactly like the typical coder/engineer.

I'll give you one very good reason why I can't code. Well, two: maths and logic. I've always had trouble with even the most simple mathematics. Game logic utterly eludes me. I tend to over-think everything which seriously impedes my ability to assemble even the most simple logical behaviours, even with visual coding. I'm not stupid or lazy (which is the usual engineer attitude toward artists). Coding, as it exists today, is beyond my grasp.

Not everything is a puzzle to be worked out with logic. Art is more than that. I'm reminded of a guy I knew at university who believed if you can put a filter on a photography that makes it look sort of like a painting, then why bother painting - it looks the same! At least as far as he was concerned.

Lots of interesting replies, thank you all for taking the time to humour my brain fart. Sorry if I can't take the time to reply to each of you individually, I have read all replies and am digesting them.

Regarding coding being a possible hinderment to the advancement of the medium. I understand that angle, you could compare it to the advances in painting technology that today frees people from having to worry about the micro-chemical level of pigments. Sure, a good painter probably still involves themself with the mixing and creating of new colours and textures, but they don't have to and, for the most part, the more technical considerations (longetivity, exposure) have a solid history/science behind them that unburdens the artist. Of course, there will always be painters whose main expression is in the exploration of new materials, but yeah... I think I understand that angle.

Coding as building blocks - definitely. Most coders never have to bother with anything other than a high-level abstraction and are themselves simply playing with a larger Lego set made of smaller pieces. The biggest advances in computer programming have been the addition of higher levels. I hold my hands up to using 'black box' librarys and APIs whenever I have to opportunity - it simply frees me up to be expressive in the code that is important to me. I almost exclusively use high level language (namely C++), too. My interest in coding, and I believe of particular interest to game design, is in Machine Learning/AI. Naturally, despite working at a high level, I have low level considerations to make (right down to bits). To use the Joyce example again, if coding is using words to express something, having an understanding and appreciation of the lower level allows me to build my own words. I still think the best work comes from many diverse people working together and I think if you really want to push the boundaries of game design, you're going to want a coder to work with.

That kind of leads me to the putting a filter over a photograph to make a painting. That's exactly how I feel, as a coder, that the gentleman in the video is approaching coding. Coding as a detriment to game design... I'm going to revisit that. Coders are a detriment to game design, coding is simply a powerful tool that is often misused (not really blaming the coders, ultimately it's an industry problem that affects all disciplines).

It doesn't matter how high or low-level you go in programming. It's still only a collection of pre-made blocks. There's no reason a visual approach or similar could not be Turing complete.

That's quite a bold statement and I am sure you must be baiting. I'll bite, though.

It doesn't matter how high or low you go in anything, it's all just blocks. We could take painting back to particle physics if we so desired. I want to say something about the other end of the scale, but I'm not sure what. I guess there is a good point in the middle of any medium that affords great creative control without micro-managing and when you push it too far upwards you lose the essence of what the medium is - like putting a filter over a photograph and calling it a painting.

Nobody knows what artists will come up with when they get tools that allow them to program. I for one am very curious! I don't see any reason for keeping them away from this wonderful technology! On the contrary!

I finally watched Bret Victor's talk. Awesome. 8)

I'm not going to wait and hope for him to release his see-what-the-code-is-doing-as-you-type-it tool, even though it looks really cool. As Michael said, I think it's a step in the right direction but what we need is visual on the code side too. These examples help give my brain some more concrete ideas to work with, and hopefully something good will bubble up eventually. :)

Those interested in Live Coding might like to have a look at Dave Griffiths' Fluxus (http://www.pawfal.org/dave/index.cgi?Projects/Fluxus).

And those that are curious about live visual programming should take a look at ThreeNodes.js (http://idflood.github.com/ThreeNodes.js/public/index.html).

(https://github.com/idflood/ThreeNodes.js/raw/master/misc/screenshot1.jpg)

Still under development, but probably the easiest ( runs in your browser using javascript + WebGL ) way to have a taste of this kind of workflow.

Field, which I mentioned in a different thread, is the closest to Victor's solution after some recent updates:
https://vimeo.com/31458737