Patch Battle
category: general [glöplog]
At the deadline, we organized the first installation of a "Patch Battle" competition. Four contestants competed with the tool of their choice, including Blender, Cables, Tooll, and Touch Designer. Kb was kind enough to host the event.
This competition is similar to a shader showdown but with a couple of crucial differences:
- Prompt Generation: Before the event, each participant writes down a set of 5-10 prompt words. For each round, the host draws two random prompts from that pool. At the deadline, those prompts were "Plattenbau+glyphs," "black vs. white + noise," and "acid + mountain." These prompts worked amazingly well as they prevent participants from rehashing and lead to very creative results.
- Round Structure: There are three rounds, each lasting 10 minutes. It's an insanely tough challenge, but all participants managed to produce results for all rounds and agreed that 10 minutes seems to be the perfect duration.
- Explanation Time: After each round, the participants get a minute or so to explain their patch. This makes it much more approachable for the audience and provides a valuable learning experience.
However, there are some areas that need refinement:
- Voting Complexity: The voting system was overly complex. While the speed bonus was interesting, it distorted the overall results. Audience voting was also confusing. Consider replacing it with live voting and highlighting the prompts to improve clarity.
- Participant Count: It's unclear how to handle situations with too many or too few participants. Define a clear protocol for such cases.
- Skill Level: Some participants suggested that the competition's skill level is too high, especially when core authors of the respective tools are competing. This might discourage beginners from participating.
Despite these challenges, the enthusiastic reactions from both the audience and the organizers indicate that we may have struck something valuable here. It could be worthwhile to establish this as a new competition category for other parties like Revision and evoke. The setup is straightforward, with one hour seeming to be an ideal duration. After 2 or 3 occurrences, the competition can potentially reach an exceptional level of quality. It's also an excellent opportunity to showcase the impressive power of real-time demo tools. (Keops of MadWizards has already committed to participating in Revision, and we may also find a Notch user to participate).
What are your thoughts on this proposal, and do you have any suggestions on how to refine the rules further?
This competition is similar to a shader showdown but with a couple of crucial differences:
- Prompt Generation: Before the event, each participant writes down a set of 5-10 prompt words. For each round, the host draws two random prompts from that pool. At the deadline, those prompts were "Plattenbau+glyphs," "black vs. white + noise," and "acid + mountain." These prompts worked amazingly well as they prevent participants from rehashing and lead to very creative results.
- Round Structure: There are three rounds, each lasting 10 minutes. It's an insanely tough challenge, but all participants managed to produce results for all rounds and agreed that 10 minutes seems to be the perfect duration.
- Explanation Time: After each round, the participants get a minute or so to explain their patch. This makes it much more approachable for the audience and provides a valuable learning experience.
However, there are some areas that need refinement:
- Voting Complexity: The voting system was overly complex. While the speed bonus was interesting, it distorted the overall results. Audience voting was also confusing. Consider replacing it with live voting and highlighting the prompts to improve clarity.
- Participant Count: It's unclear how to handle situations with too many or too few participants. Define a clear protocol for such cases.
- Skill Level: Some participants suggested that the competition's skill level is too high, especially when core authors of the respective tools are competing. This might discourage beginners from participating.
Despite these challenges, the enthusiastic reactions from both the audience and the organizers indicate that we may have struck something valuable here. It could be worthwhile to establish this as a new competition category for other parties like Revision and evoke. The setup is straightforward, with one hour seeming to be an ideal duration. After 2 or 3 occurrences, the competition can potentially reach an exceptional level of quality. It's also an excellent opportunity to showcase the impressive power of real-time demo tools. (Keops of MadWizards has already committed to participating in Revision, and we may also find a Notch user to participate).
What are your thoughts on this proposal, and do you have any suggestions on how to refine the rules further?
watched it on the stream, seemed interesting, could probably use some refinement on the format: rounds could have used a little more time, the elegance vote was a bit subjectively awarded, etc.
would be interesting to also compare how the shader and tic80 coders would fare against it with similar constraints, but i understand the main purpose of this was to focus on using a patching tool in particular.
i particularly liked that the guests had some time to explain what they did and their thought process behind it. would be cool to have this archived at livecode.demozoo.org, hope you saved your patches in between rounds. :D
also, all your noise entries should have been disqualified, none of them looked noisy on the end result :P
and you probably meant kiero not keops on your post :)
thumbs up for the concept!
would be interesting to also compare how the shader and tic80 coders would fare against it with similar constraints, but i understand the main purpose of this was to focus on using a patching tool in particular.
i particularly liked that the guests had some time to explain what they did and their thought process behind it. would be cool to have this archived at livecode.demozoo.org, hope you saved your patches in between rounds. :D
also, all your noise entries should have been disqualified, none of them looked noisy on the end result :P
and you probably meant kiero not keops on your post :)
thumbs up for the concept!
The whole voting thing was too complex. Pandur suggested a single vote and after some thought I concur.
I didn’t think about the whole archival aspect of that competition. But that’s a great idea. I scrapped my patches, but it would have been great to keep them for reference. Also having a repository of video captures of battles with different tools might be interesting to review for tool designers like myself.
Haha kiero. Of course. I was drunk. It was loud lalala
Would love to watch zoom participate too.
I didn’t think about the whole archival aspect of that competition. But that’s a great idea. I scrapped my patches, but it would have been great to keep them for reference. Also having a repository of video captures of battles with different tools might be interesting to review for tool designers like myself.
Haha kiero. Of course. I was drunk. It was loud lalala
Would love to watch zoom participate too.
This was a great idea, there's definitely something there.
Like PS, I would have liked to see a live coder in the mix. I would love to see a future iteration of this where participants can bring whatever their tool of choice is, whether it's a public node based editor, or some obscure code driven personal engine.
Like PS, I would have liked to see a live coder in the mix. I would love to see a future iteration of this where participants can bring whatever their tool of choice is, whether it's a public node based editor, or some obscure code driven personal engine.
I should have clarified that more: for me this is not about “patching” but using procedural tools to generate (real-time) visuals. Shader coding would be a completely valid means to that. In fact LJ asked a similar question: regarding libraries instead starting from scratch: my hope is that the random prompts will keep things interesting. There are no shortcuts. There are just better tools. It doesn’t matter if your typing or clicking.
is there a video of the event somewhere?
Quote:
<3I should have clarified that more: for me this is not about “patching” but using procedural tools to generate (real-time) visuals. Shader coding would be a completely valid means to that. In fact LJ asked a similar question: regarding libraries instead starting from scratch: my hope is that the random prompts will keep things interesting. There are no shortcuts. There are just better tools. It doesn’t matter if your typing or clicking.
Video is recorded but I have to upload it.Techniker ist informiert.
i found it a refreshing alternative to shader showdown stuff, my two cents:
- the explanation and elegance round were vague. imho you can even consider dropping that part as with glsl showdowns there are no post in-depth code reviews either. as long as the node names are readable on the stream, i guess it can be experienced similar as watching glsl code emerge. maybe some live narration of what's happening might be nice.
- the difference between the tools -and particularly how modular they are- might be apples vs pears under time constraint. tooll seems to have the effect/plugin is a node approach while cables is more modular, so the latter will have more grunt work to go through. unfairness aside, it either more interesting or more boring to watch to see those intricate details, depending on what's being done.
- the random topics draw stuff is nice, perhaps also something for glsl showdowns to avoid competitors just riffing off the same kind of visuals each time (or practiced work).
- so focus on the eye candy part, perhaps make the time a bit longer to work on each patch.
(- (and perhaps one day) every 10 minutes a loud car honk for a chair shift to the right so you have to continue someone elses stuff... might also be fun for glsl showdowns :D)
- the explanation and elegance round were vague. imho you can even consider dropping that part as with glsl showdowns there are no post in-depth code reviews either. as long as the node names are readable on the stream, i guess it can be experienced similar as watching glsl code emerge. maybe some live narration of what's happening might be nice.
- the difference between the tools -and particularly how modular they are- might be apples vs pears under time constraint. tooll seems to have the effect/plugin is a node approach while cables is more modular, so the latter will have more grunt work to go through. unfairness aside, it either more interesting or more boring to watch to see those intricate details, depending on what's being done.
- the random topics draw stuff is nice, perhaps also something for glsl showdowns to avoid competitors just riffing off the same kind of visuals each time (or practiced work).
- so focus on the eye candy part, perhaps make the time a bit longer to work on each patch.
(- (and perhaps one day) every 10 minutes a loud car honk for a chair shift to the right so you have to continue someone elses stuff... might also be fun for glsl showdowns :D)
I admit when I first saw photos of a "Patch compo" I had no idea what this was about. My initial guess was that you get a broken demo and you need to figure out what's wrong with it and make it run (->patch it). Then I found this topic and I was even more confused. Then I found the live recording on youtube, and now I have SOME idea what this is, which seems to be bring a tool and do *something* somewhat connected to the keywords, but.. I have questions :)
But first of all, I love the idea! It seems like a shader showdown for non-coders, or maybe like the constructors' championship in Formula 1 but for demogroups?
Second, I absolutely do not understand what the name stands for. Maybe I've been living under a rock, but I have never heard the word "patch" in this context before. Is it a term for a group of nodes? Or a loose assembly of whatever you need to show something procedural on the screen?
Moving on, the rules seem to be a tad... loose?
- I guess whether your end result animates or not is up to you, but how you present your scene is not laid down in any rule as far as I can tell. So is it one scene or can it be multiple? Or one scene with multiple camera cuts? Or whatever you can manage in 10 minutes?
- Can you prepare in advance for the compo with a generic template project or frog textures (*wink*) that you can start with? (think texture or object libraries, pre-built postprocess chain, etc.)
- What you have to show in the end is not set either, but the consensus seemed to be showing the nodes and the render view/viewport next to or on top of each other. What if the used tool doesn't have nodes or not every part of it uses nodes or can't show everything on one screen?
As for the actual event:
- Definitely drop the applause-based voting. That may work in a shader showdown with only 2 people, but it doesn't have enough granularity for 4 people.
- Also, very few people in the audience can judge the elegance part. As kb aptly put it on the stream, those people in the know are the ones participating, and I guess that's why you resorted to just letting them discuss it in the end :) But despite it being all fun and games, this might lead to awkward situations. That said, the explanation part is (or sounds) probably interesting for everyone, so keep that, but don't score it as a separate category.
- Speed points were completely unnecessary in my opinion, two of the participants could have reached more total points if they would have just thrown up their hands at the very first second. Would have been a dick move of course, but yeah. If you wanted to highlight the usability of a tool with this, I think the 10 minute limit just solves that by itself, since the more optimized a tool's UX is, the more and nicer things you can do with it during that time.
- All in all I agree that one single score after having the explanation and showing the end product would be enough.
Oh and one last thing: don't play music with vocals/speech samples while the participants are doing their explanations :)
But first of all, I love the idea! It seems like a shader showdown for non-coders, or maybe like the constructors' championship in Formula 1 but for demogroups?
Second, I absolutely do not understand what the name stands for. Maybe I've been living under a rock, but I have never heard the word "patch" in this context before. Is it a term for a group of nodes? Or a loose assembly of whatever you need to show something procedural on the screen?
Moving on, the rules seem to be a tad... loose?
- I guess whether your end result animates or not is up to you, but how you present your scene is not laid down in any rule as far as I can tell. So is it one scene or can it be multiple? Or one scene with multiple camera cuts? Or whatever you can manage in 10 minutes?
- Can you prepare in advance for the compo with a generic template project or frog textures (*wink*) that you can start with? (think texture or object libraries, pre-built postprocess chain, etc.)
- What you have to show in the end is not set either, but the consensus seemed to be showing the nodes and the render view/viewport next to or on top of each other. What if the used tool doesn't have nodes or not every part of it uses nodes or can't show everything on one screen?
As for the actual event:
- Definitely drop the applause-based voting. That may work in a shader showdown with only 2 people, but it doesn't have enough granularity for 4 people.
- Also, very few people in the audience can judge the elegance part. As kb aptly put it on the stream, those people in the know are the ones participating, and I guess that's why you resorted to just letting them discuss it in the end :) But despite it being all fun and games, this might lead to awkward situations. That said, the explanation part is (or sounds) probably interesting for everyone, so keep that, but don't score it as a separate category.
- Speed points were completely unnecessary in my opinion, two of the participants could have reached more total points if they would have just thrown up their hands at the very first second. Would have been a dick move of course, but yeah. If you wanted to highlight the usability of a tool with this, I think the 10 minute limit just solves that by itself, since the more optimized a tool's UX is, the more and nicer things you can do with it during that time.
- All in all I agree that one single score after having the explanation and showing the end product would be enough.
Oh and one last thing: don't play music with vocals/speech samples while the participants are doing their explanations :)
@maali, thanks for your thoughts!
@zoom, as always, things need some refinement after the first try. The name, although catchy, is a little misleading. I think that Rosi from Berlin's Node Institute came up with the idea to bring VVVV and TouchDesigner users together. They call their pages "patches," leading to words like "patching" and "patcher."
Regarding the rules, I'm still making up my mind between "anything goes" or keeping it more specific. Before the competition, I had a discussion with Oni about competing with Wacom and Photoshop. Although you could create something by drawing an image or even a sequence, I think that Blender was actually a better choice and produced more interesting results.
On pre-built assets and libraries, this will probably remain a topic of debate. I hope that the random prompts prevent unfair shortcuts, but some areas like online asset stores, AI-generated assets, etc., will probably be frowned upon. Regarding the templates, I think that is perfectly fine; whatever gets the job done faster leads to a better workflow.
I think nobody will care. Switching between different views is just fine.
Regarding the event, all valid points! But I'm still amazed at how smoothly it went considering that everything was quite improvised. (kb only learned about his "luck" half an hour before the event.)
The main question remains: Would you participate with Addict? 😄
@zoom, as always, things need some refinement after the first try. The name, although catchy, is a little misleading. I think that Rosi from Berlin's Node Institute came up with the idea to bring VVVV and TouchDesigner users together. They call their pages "patches," leading to words like "patching" and "patcher."
Regarding the rules, I'm still making up my mind between "anything goes" or keeping it more specific. Before the competition, I had a discussion with Oni about competing with Wacom and Photoshop. Although you could create something by drawing an image or even a sequence, I think that Blender was actually a better choice and produced more interesting results.
On pre-built assets and libraries, this will probably remain a topic of debate. I hope that the random prompts prevent unfair shortcuts, but some areas like online asset stores, AI-generated assets, etc., will probably be frowned upon. Regarding the templates, I think that is perfectly fine; whatever gets the job done faster leads to a better workflow.
Quote:
What if the used tool doesn't have nodes or not every part of it uses nodes or can't show everything on one screen?
I think nobody will care. Switching between different views is just fine.
Regarding the event, all valid points! But I'm still amazed at how smoothly it went considering that everything was quite improvised. (kb only learned about his "luck" half an hour before the event.)
The main question remains: Would you participate with Addict? 😄
Quote:
The main question remains: Would you participate with Addict? 😄
I'd certainly would love to give it a try if I can make it to a demoparty where this is a thing, although not with Addict; we've had apEx for quite a few years now, and now the brand new Archon, but I don't blame you for not keeping up with BoyC's speed of tool iteration rate :D
Haha. Deal!
Quote:
(maali)every 10 minutes a loud car honk for a chair shift to the right so you have to continue someone elses stuff... might also be fun for glsl showdowns
+1 that's a funny idea
I'd just like to add that as a not-a-real coder, I enjoyed watching this live - i've been meaning to look into cables, and this is the push for me to actually try and learn stuff :)
I liked how it was fun to work out who was using what by trying to indentify the UI they were using - trivial for you coder gods i'm sure, but the discussion on our seating row opened up new learning paths :)
I liked how it was fun to work out who was using what by trying to indentify the UI they were using - trivial for you coder gods i'm sure, but the discussion on our seating row opened up new learning paths :)
