Co-starring Casey Muratori. Topics: Animation Programming, Language Design, What makes code more or less understandable, Techniques for being a productive programmer.
1:18:00 I did not understand what's wrong with decibels. There is no other unit that you would read and understand it "oh, it's that loud, gotcha". Sound is simply unintuitive to measure altogether; you have to actually hear it. One thing that you subconsciously feel when dabbling with volume is when there's a constant sound and you are changing the distance to it, the volume changes. I guess you could potentially make a slider that taps this knowledge and make it so sliding it makes it as loud as it would be from 0.01 meters to 100 meters away but I am not sure it be that great either? A big problem is that 1 plus 1 does not equal 2... IDK, any thoughts on this?
I mean, it's just funky in multiple ways simultaneously. 10dB difference is a 10x difference in "power". But a 10x difference in *amplitude* is actually a *100x* difference in *power*. So in the definition of the unit you have 3 different arbitrarily-chosen factors of 10 which are all doing different things in different directions on a log scale, which is just a recipe for disaster. And of course none of that has anything at all to do with human perception of loudness, which is a different thing entirely and can't be mapped to decibels at all. The end result is that if you're going through decibels as your unit, you generally need to do multiple potentially complex transformations back-to-back to get from any value that you'd actually care about to any other value that you'd actually care about, at least some of which are going to be confusing and therefore error-prone. Also, because it's a logarithmic scale, there is no true 0 point. 0dB is just whatever arbitrary reference point you define it to be, and a *signal strength* of 0 always corresponds to -INF decibels. This makes it a fundamentally unsuitable unit for volume controls, because if the volume slider is a linear ramp in dB space, you can never smoothly ramp down to 0 volume. There will always be a hard cutoff at the very bottom of the slider, regardless of the chosen reference points.
@@notnullnotvoid Thank you for the elaboration on decibels, power and amplitude :) As a user, I don't care about the "complex transfomations", I use intuition. Otherwise, I'm not sure it is that complex?
27:00 - It can't be the direction is turning wrong if it doesn't do it some of the time. Doesn't make sense that it works some of the time, but then not other times...
If you're talking about the code quality of the compiler, I'm sure that you'll be in good hands. If you're talking "general industry code", not sure what to tell you other than I've got war stories for days about how little care goes into "enterprise code".
To build a good language, see if it comes naturally to younger people. If they can take it and use it pretty straight forward, like picking up Lego's and build something then, you will have a language people want to use, not sure how efficient that is, but if it comes natural and they can just jump in and start moving objects, placing objects, it does a lot of the collision detection, and so on, then it will be easy for them to get on with it. Also you need it to feel like people can personalised the art of it easily, in that if every game they make it looks like the same as every other game made by that language or program or game, then it will not be useful to those that want to do something massively different, so you can't have it be like lego's they just drop down, other then to underlay under their art. So you could have many objects they select from, but then they input the parameters of that object to fit animations. So you would basically have an environment separate from the art side. Build everything in an environment that can just be dropped in, which is basically all the code side, then have the art side of the system in which is overlaid over objects. Then you could have generic art they can select or they can add in their own art style some how, you could make a way for them to easily draw or changes shapes and make unique art. Not sure if this comment is helpful, but that is where I would start. Basically it would need to be more like a website CMS, in which most of the code is done, and most users get to play more with the art side/content and build a game. Basically then coders could make objects and the people using it could just take those objects and apply them to their art work, if enough objects are made. So basically you would be making more of a physics engine with easy ways to create art and animations. I guess that isn't really a language though, it's a game development system which makes it easier to make games.
It sounds like you're laying out a new game engine of sorts, which is fine, but it's not the goal of Mr. Blow's language, and it's also probably not the way to make truly innovative games. You suggest to create building blocks/objects that others can use to build. With building blocks, you enable lots of creation possibilities, but you also constrain and limit what can be created to things made from your blocks. You can't build everything from Legos. You can only build Lego structures from Legos. Lego structures are great for younger people, and are great for introducing someone to building physical things. In the beginning possibilities offered by lego will far outweigh any of the limitations. But eventually you might want... you know, a sphere or something, or something that isn't structurally weak due to being comprised of hundreds of tiny pieces. You get the picture... Building blocks are great for making something fun and interesting, but unless they are pragmatic simple blocks that model reality as it is they will end up limiting the creator's creativity instead of enabling it. From what I've seen Mr. Blow is trying to create a language that doesn't get in the way of the programmer, allowing them to create without too much unnecessary complexity.
@@bartholomewjoyce I think it would be a way to make innovative games. Say you want a new object and it doesn't exist, you create it share it on a library and people can then use that object for themselves. So basically you're creating the cogs in the background that make the game work, the more cogs that are made the more diversity there is... and so as long as people always built those cogs, you would have innovation. Additionally the art work or animations could also be their own. The only hard bit would be on how animations collisions and sizes could be a random shape, so you would have to have ways in which to make sure animations could easily be overlaid on top of objects. It would be as innovative as those willing to learn how to program and develop objects in that environment want it, if they could also tweak the physics engine, and have a lot of control over the parameters then they could do all sorts. The aim would be to remove a lot of the programming for artists, while also give coders the ability to code and make new objects. It makes sense in my mind. Basically it would be as innovative as much as people want to program code. Generic art could be used by coders that don't want to do art much, or they could hire an artist to do innovative art. Same with artists and objects that aren't in the libraries. I know he was specifically talking about a language but I think if you want it easier to make games then you would have to build a development system that made it easier to build games. But yes a lot of languages are a lot of work to do what would seem like it should not to difficult to code. So I agree we need better coding languages so I'm glad he is doing that. I just meant if you want it to be easier for people to build games, you could make an open source free development system which everyone works on which makes it easier for all developers long term. The legos was a metaphor. Say you have star shapes, and planets, and many objects in which you can change status effects, literally change planetary physics, you would be building objects and models in which people can adapt and use, while creating their art style and overlaying it, or game style. The whole point would be to allow it to be massively easy to build something without having to go through debugging and basically pull up objects change parameters and get it to do what you want. Kind of like a library of objects and environments, that people can either use the generic art styles or make their own art styles. The whole point would be to make it easy for people to overlay their own art and get it running in a game without hours of coding, par when no objects existed for what they needed, then then create one or pay someone to create one, and it's added to the library for anyone to use. It would allow creative people to really get on, without having pay walls or what ever else in the way, and in this would make it easier for all developers because they don't have to buy loads of objects or give all their profits up to make their game. I disagree, I think if the system is designed to allow new code to easily be added or new art/animations, then it wouldn't limit creation anymore then building from scratch would limit them, the only difference is if it's made right they then have access to loads of objects off the bat, rather then simply starting from scratch and building their own libraries from scratch in which no one can use those really, because there is no uniformed system structure.
There are plenty of engines with more extractions to make it easier to make stuff though. Also, you should probably google what Jonathan Blow thinks about abstractions
@@ITR I get that but I meant build an engine that is open source that anyone can use would improve the chances of innovation and cooperation within the development community to build something all could easily use without restriction of money or having limited access to this, the aim would make it easier for people to work together. But it wasn't just about that it was also about building a system that is so easy to use a child could pretty much do it or a teenager that is very creative, and it would be so straight forward that they could just flow, in the same way that if you had a big box of legos, the only limitation is their imagination and the constraints of the legos, but I already address how to remove these constraints in a development system or engine by allowing coding of new objects to be added or even the environments themselves and allowing any art style to be added, and I said that hard bit would be merging the coded objects with the art style and animations. In the end you need a way to make it easier and more natural to create if you want to increase creativity. I will look up videos on "what Jonathan Blow thinks about abstractions". :)
AAAAAAAAAAAA. How could I missed it while I was watching your old videos, so now I need to sleep, I'll watch it tomorrow. John, you are breathtaking. Greetings from Russia.
I've got a pretty good understanding of decibel values at this point. What worked for me is to learn the name of all the individual typed of dB and LUFS measurements, and then learn what they mean individually. After that, you can put together the ideas to a nice structured web in your head. dB, SPL, A, B, C, dBFS, Amp., RMS, LUFS, LUFS-I, LUFS-M, LUFS-S. All these separate concepts need to be learned, and then you might be lucky enough to have it click.
abstraction is not a bad word or a concept… designing the animation to just be about the interpolation of something following a pattern over a period of time is GOOD… rather than to plaster entities everywhere. “need to know” is a good thing!!… seems to be a case of ‘animator has too much information’ … There is something immensely gratifying in watching an intelligent discussing between intelligent and respectful people …. …. …… … ….. lots of food for thoughts… 🙏🏻
10:00 do the reflection is right? Try to project a line from his harms to the mirror, normally it should get a 90° angle and the right harm should be the left, on the reflection, right?
