*Summary:* - define the *core* mechanics of your application - this is really important - if you are to 1) finish your prototype fast and 2) have it realistically represent your vision, you have to ensure that you define the *core* mechanics and only the core mechanics - when working (coding, designing, etc) keep focused on the core mechanics at all times (avoid "urgent" things that pop up) - follow a process (helps you keep focused on the core mechanics) - he recommends the design sprint process - most important thing: experience building an app in 24 hours (or a few days) a couple of times, what you learn from the experience will be far greater than watching any video or reading any book on fast prototyping. Thanks so much for the talk! I really enjoyed it! Great presentation!
Sorry about the audio on this everybody, I feel like it really diminishes the work I put into this talk. What is that noise? It is most likely caused by too much compression in mixing. Compression amplifies low audio levels and limits high ones, so it's used in situations where speakers can be varying distances away from the mic and might have different speaking volumes. This way you always hear what the speakers are saying, at a predictable volume level... The tongue smacking sound you hear throughout the entire speech is mostly due to lazy audio engineering & bad compression management.
Didn't even notice on mobile. Great talk Mark!! Really liked the part about "Minimum Viable Interaction". That's a really helpful way to think about a game MVP
Ben, you made my day. That's what I was really shooting for. Sorry it was so rushed. Originally I had thirty minutes to do the talk and then RIGHT before- "btw, do it in 25 so the next speaker has time to set up" :P
The most difficult thing about prototyping is deciding which directions to focus on in your MVP in order to be able to test it properly. For example - if you were building an Angry Birds prototype, which parts could you skip without making it lose it's appeal? Would it be fun without physics? With bland placeholders instead of art? With just 1 level?
Hm, I think Angry Birds is very much a derivative game, gameplay-wise it is basically a clone of earlier very similar flash games. It's selling point was the better visuals and polish as well as the fact that it was released on mobile. I think the MVP for an Angry Birds style game though could definitely do without graphics or levels and just be flinging boxes at other boxes - When that game turns out it be a good experience (and I think it would) you can probably safely consider throwing more time and money at the game to polish it.
Yeah, a prototype of a simple box-flinging game would at least prove if users found the concept okay or bad. But as you said - Angry Birds is derivative of many similar games that came before it, most of which never made it. Which makes me wonder how many of those games went through prototype testing and were shut down because they weren't popular enough and called "just another box flinging game". In conclusion: it seems very hard to do a prototype testing for an idea which aims to become an improved version of an existing product.
High dopamine can cause dry mouth. This could be caused by the body's own natural physiology, or may be due to taking dopamine reuptake inhibitors like Adderall or Zenzedi. Most likely the speaker is on Adderall.
I do rapid prototyping but the biggest problem is how to analyze the results. If something is not popular right away, how do you distinguish between if it's a bad idea or just needs more polish? Cause many ideas will not be interesting until they reach a certain level.
@@awesomedata8973 Here the problem is the target public was expecting something similar and not a new product. I think the best is find differents kind of person (I mean if you make a game do not find just gamers to test your prototypes, it is not interesting and people with thinkings are always a small part of your friends (target them))
In prototyping, real prototyping the answer should not be polish, ever, you may need to work on communicating something more clearer but that's not polish... i think people are getting first playable (or MVPs) confused with prototyping... in prototyping you should be focusing on the minimum amount of presentation to get the idea across, why? because you need to be ready to throw stuff out and sadly the more time and energy you spent on something the harder it is to realize it needs to go... here's a bayonetta prototype thats a good example, there's no polish but all the ideas and mechanics present are communicated clearly enough... th-cam.com/video/DgRUJqrBVIM/w-d-xo.html
Good talk, you're like the version of me that actually made it :/ I also grew up playing Squaresoft and designing on Mario paint in the snow and attended Digipen, but I dropped out and never got into the industry. I especially liked the bit about "urgent" vs "important", that's not just great advice for managing a project, that's great advice for life. PS Whatever audio problems people are talking about didn't distract me from the presentation at all.
This is what happens when you have relatively good mics and bad post sound mixing, or no post processing at all. It might've sounded perfectly fine at the place, but they should've do some sound processing afterwards. Not the only conference releasing talks and having this same "problem" (probably just lack of post conference resources or will to do some work before uploading the video).
ECGC (East Coast Game Conference) is sponsored by Epic Games in Raleigh. SiegeCon would probably be the next closest in Atlanta. PAX East is in Boston. The only other place to find game jams in the middle of NC is by joining small local game dev groups. ecgconf.com/
It's so weird because when he showed that thing with making the car and the bike and whatnot, I started to think of how things would turn out if someone inexperienced just worked within their limited skillset whenever they made something. One of the FIRST examples I thought of was It's Such a Beautiful Day and World of Tomorrow, and how Don doesn't seem to want to deviate from making stick-figures but still manages to create some beautiful stories with each movie. And then he mentioned it and I felt really special.
The problem with that classic prototyping analogy "1. bike 2. motorbike 3. car” rather than ”1. wheels 2. chassi 3. car" is that you have to spend time building handlebars for a bike, and less time on your end goal.
But you learn more making a complete bike than you do a partial car. This allows you to build more quickly in the future, and even if you complete the car at the same time as if you had just focused on the car, you have much more experience building finished products (even if they're small).
Great point. I think this is very dependent on two things: 1) Level of experience 2) Level of funding If you have low levels of experience and funding, you'll never make a car, so make a bike and build up revenue + experience first. If, on the other hand, you've got plenty of experience making cars and you have the funding to make cars, go ahead. Don't waste time on bikes, just make the best car you can. Then test + improve on it anyway after prototyping until it's a truly great car! It's still iterative, but you get to the end faster and more efficiently. Applying that to games, it makes sense starting out to make pong, then breakout, then pinball. But if you have already made pinball 5 times, just make a pinball prototype, and then iterate and improve on pinball. Making yet another pong probably won't help unless you're trying something radically new and different (new physics system, new engine, etc)
Considering the overwhelmingly positive comments, does anyone really find this idealistic approach to work at all? Like sure, if you already have a large successful company and want to optimize the processes, it surely does help, but isn't the high-level overview of how you should plan things just impossible if you aren't already an expert? Scrum surely is a good process, but how just saying "use scrum" help anyone? The hardest part is actually learning the things from implementation standpoint, getting educated in drawing and properly using the tools, having several years of experience in marketing to know what sells and what's just another copy of what people made thousands of times... Like for example if you want to implement something in a game engine, even though you can tell yourself that you'll do it on few hours, but you may learn that there's a bug, improper documentation, or that your approach doesn't make sense at all, and you'll be lucky if you succeed in a week; plus you may learn that it makes no sense to continue until you learn something new that may make the rest of the development way easier (or even possible at all), so you can be constantly fighting the dilemma of whether to spend time on actually improving your skills, or trying to implement a workaround asap. And if you can make something in 30 days that a pro would do in one afternoon, because he doesn't repeat the mistakes anymore, doesn't it become a mere training exercise? Instead of being a "business model"? Shouldn't learning be an ever-increasing necessity in our world of rising complexity, where plans or schedules often make no any sense at all (until your processes are already flawless, which should be the goal anyway), because you can't predict how long it'll take to learn something? I mean don't get me wrong, if you specialize or just get educated before starting to make the game, the tips are definitely worth something, plus you usually don't start from scratch. Nevertheless, I don't like how this high level presentation tries to convey the oversimplified idea, which most people may definitely misunderstand. And on the other hand, for those who are actually experienced, tips like "use agile methodology" should be absolutely obvious by now, this isn't a year 2000. I mean, all I'm saying is that this presentation lacks any useful specific examples of day-to-day issues, along with not presenting any metrics to prove and specify who does this apply to.
Yeah an MVP is not a prototype it's more like what we used to call a "first playable"... prototyping will not guarantee any viability, or for that matter be even a product and that should be ok, iterate and try again or move on... month prototype is rapid?
I'm sure what this guy is trying to say is very helpful. But the way he is saying it is not very relatable or personal. It's very "pseudo" proffesional, meaning it got all these points and diagrams that no one is gonna remember or want to cognitively understand. And the examples he gives doesn't help explain anything. This guy just spent 25 minutes saying, you need goals!
*Summary:*
- define the *core* mechanics of your application
- this is really important
- if you are to 1) finish your prototype fast and 2) have it realistically represent your vision, you have to ensure that you define the *core* mechanics and only the core mechanics
- when working (coding, designing, etc) keep focused on the core mechanics at all times (avoid "urgent" things that pop up)
- follow a process (helps you keep focused on the core mechanics)
- he recommends the design sprint process
- most important thing: experience building an app in 24 hours (or a few days) a couple of times, what you learn from the experience will be far greater than watching any video or reading any book on fast prototyping.
Thanks so much for the talk! I really enjoyed it! Great presentation!
Thank you!
@@markaaronbarrett not a problem!
Sorry about the audio on this everybody, I feel like it really diminishes the work I put into this talk. What is that noise? It is most likely caused by too much compression in mixing. Compression amplifies low audio levels and limits high ones, so it's used in situations where speakers can be varying distances away from the mic and might have different speaking volumes. This way you always hear what the speakers are saying, at a predictable volume level... The tongue smacking sound you hear throughout the entire speech is mostly due to lazy audio engineering & bad compression management.
@Mark Barrett
That sound is very distracting. But good talk.
Ram, thank you for the kind words. Sorry about the bad audio.
@@markaaronbarrett yeah thanks for this talk, see this talk every once in a while and its always useful
@@someone-js6pg That means a lot to me!
Didn't even notice on mobile. Great talk Mark!! Really liked the part about "Minimum Viable Interaction". That's a really helpful way to think about a game MVP
Excellent yet simplified process. For a novice to game design, this made it so clear how to approach prototyping
This is one of the most practical talks I've ever seen. Holy crap. Real relatable information that both inspires and informs. Very well done.
Ben, you made my day. That's what I was really shooting for. Sorry it was so rushed. Originally I had thirty minutes to do the talk and then RIGHT before- "btw, do it in 25 so the next speaker has time to set up" :P
great talk, not just for game dev but project management in general
The most difficult thing about prototyping is deciding which directions to focus on in your MVP in order to be able to test it properly. For example - if you were building an Angry Birds prototype, which parts could you skip without making it lose it's appeal? Would it be fun without physics? With bland placeholders instead of art? With just 1 level?
Hm, I think Angry Birds is very much a derivative game, gameplay-wise it is basically a clone of earlier very similar flash games. It's selling point was the better visuals and polish as well as the fact that it was released on mobile.
I think the MVP for an Angry Birds style game though could definitely do without graphics or levels and just be flinging boxes at other boxes - When that game turns out it be a good experience (and I think it would) you can probably safely consider throwing more time and money at the game to polish it.
Yeah, a prototype of a simple box-flinging game would at least prove if users found the concept okay or bad.
But as you said - Angry Birds is derivative of many similar games that came before it, most of which never made it. Which makes me wonder how many of those games went through prototype testing and were shut down because they weren't popular enough and called "just another box flinging game".
In conclusion: it seems very hard to do a prototype testing for an idea which aims to become an improved version of an existing product.
What an ASMR talk...
I had no idea what you were talking about until I started listening in my car as opposed to on my phone 😆 eeeeeee
@@Kevintendo haha
oh no... OH NO I CAN'T LISTEN TO IT 😂
"The impediment to action advances action. What stands in the way becomes the way"
I went out to drink 4 times during listening to him in the hopes that he'll take a sip as well. He didn't :(
LOL nice insight xD
Lol...that bottle is a prop
i can hear his mouth going dry
Water is right THERE!
Seriously, good talk, I would be to scared to even go on stage
This is golden. The audio issues aren't the speakers fault. Shit compression to blame
Drinkkkkkkkkkk it man! good for both of us.
There is a lot of mouth sounds in this one
High dopamine can cause dry mouth. This could be caused by the body's own natural physiology, or may be due to taking dopamine reuptake inhibitors like Adderall or Zenzedi.
Most likely the speaker is on Adderall.
nope
smh, its some kinda of reverb or feedback. Every word has the same effect. Its his previous word's attack decaying across his new word.
It sounds like he has pop rocks in his mouth.
Almost an ASMR video
I do rapid prototyping but the biggest problem is how to analyze the results. If something is not popular right away, how do you distinguish between if it's a bad idea or just needs more polish?
Cause many ideas will not be interesting until they reach a certain level.
@@awesomedata8973 Here the problem is the target public was expecting something similar and not a new product. I think the best is find differents kind of person (I mean if you make a game do not find just gamers to test your prototypes, it is not interesting and people with thinkings are always a small part of your friends (target them))
@@awesomedata8973 ^That was a great read!
In prototyping, real prototyping the answer should not be polish, ever, you may need to work on communicating something more clearer but that's not polish... i think people are getting first playable (or MVPs) confused with prototyping... in prototyping you should be focusing on the minimum amount of presentation to get the idea across, why? because you need to be ready to throw stuff out and sadly the more time and energy you spent on something the harder it is to realize it needs to go... here's a bayonetta prototype thats a good example, there's no polish but all the ideas and mechanics present are communicated clearly enough... th-cam.com/video/DgRUJqrBVIM/w-d-xo.html
@@awesomedata8973 cool read but has very little to do with prototyping and more to do with marketing.
17:49 Didn't make sense not to live for fun!
Your brain gets smart but your head gets dumb...
some
body once told me
@@iLikeCoffee777 So much to do
, So much to see.
So what's wrong with taking the back street?
@@sethtaylor7519 You'll never know if you don't go
You'll never shine if you don't glow
Anyone is here to get ready for a game jam? GMTK 2020 maybe ?
14:48 -- "when he made this he had no job ... used crappy equipment that no one else knew existed in the school where he was working"
Maybe he was working for free without a contract?
Thank you so much for this valuable talk!
Crazy good talk
bit sensitive mic, but so far a pretty good talk :3
Fantastic rundown of a clear process
Good talk, you're like the version of me that actually made it :/ I also grew up playing Squaresoft and designing on Mario paint in the snow and attended Digipen, but I dropped out and never got into the industry.
I especially liked the bit about "urgent" vs "important", that's not just great advice for managing a project, that's great advice for life.
PS Whatever audio problems people are talking about didn't distract me from the presentation at all.
Great Talk! Thanks Mark!
Really great talk. Thank you.
Thank you
This is too meta for me, somebody please translate it to bro-speak so I can understand!
Really?
Don't let your dreams be dreams. Just... DO IT
@@oels9507 lol
Where can i find the boy or girl game to play?
I really liked the talk, super informative and insightful. But is someone smacking their lips the entire time next to the mic?
I think it's just a super sensitive mic. I really liked this talk too.
i think it's just his mouth being very dry
I agree. Great talk, dry mouth
While watching I was willing him to grab that bottle and take a sip... Didn't work obviously. ^^
This is what happens when you have relatively good mics and bad post sound mixing, or no post processing at all. It might've sounded perfectly fine at the place, but they should've do some sound processing afterwards. Not the only conference releasing talks and having this same "problem" (probably just lack of post conference resources or will to do some work before uploading the video).
Really good!
Very inspiring
thanks gaming Nicholas Cage C:
lol
lol, I thought he looked more like Ross from Friends myself.
please gdc, get a pop filter on that mic up there
I wish I could find Game Jams in Charlotte NC. Anyone know any?
ECGC (East Coast Game Conference) is sponsored by Epic Games in Raleigh. SiegeCon would probably be the next closest in Atlanta. PAX East is in Boston. The only other place to find game jams in the middle of NC is by joining small local game dev groups. ecgconf.com/
Ludum Dare is global, every month with major ones every 3mo-6mo... can do solo or build small team or form local meetup
Geoffrey Perrin try this: itch.io/jams
Plenty to choose from.
0:22 check, check aaaand check!
Don Hertzfeldt, nice.
It's so weird because when he showed that thing with making the car and the bike and whatnot, I started to think of how things would turn out if someone inexperienced just worked within their limited skillset whenever they made something. One of the FIRST examples I thought of was It's Such a Beautiful Day and World of Tomorrow, and how Don doesn't seem to want to deviate from making stick-figures but still manages to create some beautiful stories with each movie. And then he mentioned it and I felt really special.
Neat! Thanks!
He sure knows how to make us engaged
Yo is that a metallic toad in the thumbnail?
Good talk, but could have cut out the majority of the motivational speaker but in favour of case studies and tips on prototyping.
I keep coming back to this video because of the title... and because I can't listen to more than 90 seconds of his dry lips.
I put in top_favorites list. Thanks
14:48 "No job" 14:58 "School where he was working". Checks out.
The problem with that classic prototyping analogy "1. bike 2. motorbike 3. car” rather than ”1. wheels 2. chassi 3. car" is that you have to spend time building handlebars for a bike, and less time on your end goal.
But you learn more making a complete bike than you do a partial car. This allows you to build more quickly in the future, and even if you complete the car at the same time as if you had just focused on the car, you have much more experience building finished products (even if they're small).
@@CorvusPrudens Not to mention, you can sell a bike to get money to build a car later.
Great point.
I think this is very dependent on two things:
1) Level of experience
2) Level of funding
If you have low levels of experience and funding, you'll never make a car, so make a bike and build up revenue + experience first.
If, on the other hand, you've got plenty of experience making cars and you have the funding to make cars, go ahead. Don't waste time on bikes, just make the best car you can. Then test + improve on it anyway after prototyping until it's a truly great car!
It's still iterative, but you get to the end faster and more efficiently.
Applying that to games, it makes sense starting out to make pong, then breakout, then pinball. But if you have already made pinball 5 times, just make a pinball prototype, and then iterate and improve on pinball. Making yet another pong probably won't help unless you're trying something radically new and different (new physics system, new engine, etc)
It sounds like there's Pop Rocks in his mouth.
Yes, it does, and it is so annoying.
Carefully avoiding putting out a fire by avoiding the immediate impulse to take a sip of water. I really wanted to listen to this video, but I can't.
Considering the overwhelmingly positive comments, does anyone really find this idealistic approach to work at all? Like sure, if you already have a large successful company and want to optimize the processes, it surely does help, but isn't the high-level overview of how you should plan things just impossible if you aren't already an expert? Scrum surely is a good process, but how just saying "use scrum" help anyone? The hardest part is actually learning the things from implementation standpoint, getting educated in drawing and properly using the tools, having several years of experience in marketing to know what sells and what's just another copy of what people made thousands of times... Like for example if you want to implement something in a game engine, even though you can tell yourself that you'll do it on few hours, but you may learn that there's a bug, improper documentation, or that your approach doesn't make sense at all, and you'll be lucky if you succeed in a week; plus you may learn that it makes no sense to continue until you learn something new that may make the rest of the development way easier (or even possible at all), so you can be constantly fighting the dilemma of whether to spend time on actually improving your skills, or trying to implement a workaround asap. And if you can make something in 30 days that a pro would do in one afternoon, because he doesn't repeat the mistakes anymore, doesn't it become a mere training exercise? Instead of being a "business model"? Shouldn't learning be an ever-increasing necessity in our world of rising complexity, where plans or schedules often make no any sense at all (until your processes are already flawless, which should be the goal anyway), because you can't predict how long it'll take to learn something? I mean don't get me wrong, if you specialize or just get educated before starting to make the game, the tips are definitely worth something, plus you usually don't start from scratch. Nevertheless, I don't like how this high level presentation tries to convey the oversimplified idea, which most people may definitely misunderstand. And on the other hand, for those who are actually experienced, tips like "use agile methodology" should be absolutely obvious by now, this isn't a year 2000. I mean, all I'm saying is that this presentation lacks any useful specific examples of day-to-day issues, along with not presenting any metrics to prove and specify who does this apply to.
Great talk!
This is like a class from Klaus in Umbrella Academy
Yeah an MVP is not a prototype it's more like what we used to call a "first playable"... prototyping will not guarantee any viability, or for that matter be even a product and that should be ok, iterate and try again or move on... month prototype is rapid?
the entire time i was watching the water bottle, hoping he'd take a sip so I could listen to the talk without hearing his mouth noises.
Meeeh
I'm eight minutes in and so far it's been all waffle.
I'm sure what this guy is trying to say is very helpful. But the way he is saying it is not very relatable or personal. It's very "pseudo" proffesional, meaning it got all these points and diagrams that no one is gonna remember or want to cognitively understand. And the examples he gives doesn't help explain anything. This guy just spent 25 minutes saying, you need goals!
Lol, brutal. Thanks for watching and taking the time to leave feedback.
Great talk!