Could This Asset Be Code?

[@aarthificial]

Help me make more videos like this: www.patreon.com/aarthificial The source code for this video is available at github.com/motion-canvas/examples

[@ultimaxkom8728]

Quite the enlightening lesson. Thanks.

[@gabryx7]

Hey, I sent you an email to apologise for being an absolute dickhead on GitHub. I was definitely acting like a dick on gh issues and I wanted to publicly apologise on that issue (I think it was a PR) but couldn't. Anyway yeah I was being a douchebag honestly and then eventually got too busy and forgot to reply to it (or delete the comment).

[@timquestionmark]

"This couldve just been a function" is the programming equivalent of "this meeting couldve been an email"

[@JorgetePanete]

could've*

[@EthMiC_]

@@JorgetePanete i am annoyed now

[@somebody4545]

​@@JorgetePanete clodu'ev

[@DuoVersal]

@@somebody4545ouecd’lv

[@Pixaurora]

@@somebody4545 **coul'ved

[@cateinum4047]

This video is a good illustration of Greenspun's tenth rule: "Any sufficiently complicated program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp"

[@rahul9704]

I also (more literally) end up writing yet another Lisp every time one of my projects gets sufficiently large enough, then I have to convince myself to let it go because I'd be the only person to understand it.

[@Dysiode]

That is the crux of the problem with so many DSLs :) And given enough time away from it /you/ wouldn't even understand it@@rahul9704

[@spookyconnolly6072]

lisp and smalltalk are the coolest runtjmes that prevent me from regretting choosing programming

[@Daniel_Zhu_a6f]

i wish, i was taught this sooner. this and not using OOP.

[@albertweber1617]

This is especially true with unity. The best dialogue manager has its own interpreter. The timeline is Turing Complete. There are at least three node graphs that can definitely be expressed in lisp.

[@Tomatech]

In a way, the spectrum between assets and code parallels a spectrum between artists, designers, and engineers. (Nearly) all games need pure assets and pure code, but Ideally there should also be some level of designer-friendly middle ground, even if its as simple as way of grouping textures into a frame-by-frame animation, or a way of defining data files for game stats instead of hardcoding them

[@PRIMARYATIAS]

But this will also require a team of engineers to maintain all the code to support those tools for the designers, Thus the fundamental “problem” will never go away as this is basically how computers work. Scripting languages with hot reloading lie exactly at the middle ground. Writing custom UI for every little thing can lead to lots of churn and feature creep as you can’t really build “everything” the designers will ever want, It will require a constant feedback loop back and force between the engineering team and the designers and will actually add work as those tools will always have some flaw of being not too general or too restricting. What I ideally want is a scripting language with built in spline and color editors and maybe also a graph plotter and the rest to remain the same as standard coding. This is the most sane approach I see for this middle ground.

[@JorgetePanete]

it's*

[@lucbloom]

Tools for easily developing content are OK in my book. Assets to set up the game and its logic not so much.

[@beskamir5977]

That is actually a really good point. As both a programmer and artist, I've never really seen much purpose for most of the stuff between those two extremes in game development. I can just as easily make purely data or purely code assets. So my only real selection criteria for which I'll use, is what is the most efficient option available, and that's usually an extreme rather than something that tries to be both data and code.

[@NeZversSounds]

I kind of disagree. Make tools to create assets and data, not logic.

[@bike_n_fish]

I think the overall gamedev experience is being on a boat where a wave is "I SHOULD MAKE A FUCKING EDITOR FOR THIS" and where the bottom of the wave is "IT WASN'T USEFUL"

[@jameender]

The animation quality is so insanely good 🔥

[@Cred_official]

Thanks to motion canvas

[@OctagonalSquare]

Yeah I just made a comment about that. He uses motion canvas and it’s so nice! I need to switch because the animations on my last video for my second channel took forever lol

[@mr.johnson8974]

He doesn’t just use motion-canvas, he created it

[@uujuju5737]

​@@mr.johnson8974both

[@Cred_official]

@@mr.johnson8974 Indeed, a wise man

[@RenderingUser]

Easily the most underrated gamedev channel in all of KZbin. Every single video on this channel is quality content. That's pretty rare for KZbin channels

[@ItsMorze]

Gatekeep

[@RenderingUser]

@@ItsMorze whyyy?

[@kuroc5116]

Agreed. His stuff is top notch. He discusses less of just the game idea and how he did it, but rather look at it block by block, a bit like NoDayShallEraseYou, the dev of DDS

[@ItsMorze]

@@RenderingUser too good for the common folk

[@RenderingUser]

@@ItsMorze and who's to say who's the common folk? I want his videos to reach every game dev

[@BackForwardPunch]

I’ve had this experience with a lot of jack-of-all -trades game engines. It’s not just that your game isn’t the same as anyone elses, it’s also just that each person’s brain works differently. Being able to structure things in whichever way is most efficient and sensible to you is going to be a better way then blindly following restrictive conventions of a premade editor.

[@bike_n_fish]

That's a great advice and any gamedev will learn it one day

[@your_sweetpea]

This is a big part of why I find myself deeply frustrated by Godot, honestly. I want to like it and keep revisiting it, but the model it uses just refuses to click for me. I understand it, it just doesn't match how I structure the game in my head at all.

[@JorgetePanete]

else's*

[@delphicdescant]

@@your_sweetpeaThat sort of experience is probably why I keep returning to just writing my own engine code. You can sacrifice control of the model to use a pre-made engine, but then all that pre-made engine really does for you is the stuff that, in my opinion, was never the hard part of making a game. It loads assets, has a scene graph, has some rendering boilerplate, probably includes some third-party physics engine that you can include in your own code just as easily - none of that stuff is the hard part of game dev, so I feel like I might as well do that stuff myself and then have control over my model when I have to do the hard part that I'd have to do either way.

[@BackForwardPunch]

@@delphicdescantI feel like avoiding the hard parts is the trap people get into (including me) A lot of engines help a lot in the first steps of making a game and being able to see the assets, interact etc... but the hard parts like actual behaviors and level design still have to be done by you.

[@rahul9704]

This awakened something in me. I'd been arguing for months with my sister who uses Unity that it's easier to model logic in code; it's just two different mentalities it seems. I've come across the same dilemma about assets as code, and feel vindicated in my own belief in code being a better medium to express myself.

[@mz-power9587]

There's a class i would want to take. About game mechanic design. But the professor makes students use unity visual scripting for that. I find code a lot more idiomatic and easier to read then a graph. Some stuff with editors I find faster to just code.

[@Donvermo]

I've had this very same realization myself while trying to implement a custom level editor for my game in Unity the other day. What started out as me trying to create all of these cool custom inspectors and scriptable objects turned into the realization that the vast majority of work that I was doing was working around the self imposed limitations of the engine. Re-writing everything into a self contained program that only interfaced with the engine at the very edges not only made it faster and smaller in size, it greatly reduced the complexity and the velocity at which I could develop because of it. Thanks for the awesome talk, I feel validated :)

[@xiondisc]

It’s been interesting seeing how humbled you’ve become in learning about professional game development. How it’s helped you evolve your approach to game design. It almost feels defeatist, like you’ve given up on something you love, but obviously it’s just a compromise for the sake of productivity over passion. I have a lot of respect for you. Please never stop making these incredible animations.

[@igrb]

Absolute banger, never really thought about how scripting was both data and logic at the same time; ty for making this

[@cavemaneca]

The editer serves as translator to help people who don't know the code still create game behavior, or to visualize complex relationships between components. It really shines when you have a larger project with team members of various skill levels. So it makes perfect sense for a solo developer who prefers straight code to not need one. However, it also makes sense when a solo developer who has a hard time coding instead spends that time doing the "difficult" work extending an editor so that it can do more of what they want.

[@windwalkerrangerdm]

I was under the impression that writing custom editors and shaping your inspector windows or whatnot was done for the specific purpose of being able to transfer the design process to the designers. So that they can fiddle with knobs and sliders and thingamagics to make the game more fun. In theory, at least. I worked with XNA for a year so I know what it feels like to work without an editor environment, but I think it doesn't matter which is what as long as you are productive. Unfortunately, everything has boiled down to productivity.

[@aarthificial]

Absolutely agree! It's a shame it took me a while to realize this.

[@PRIMARYATIAS]

When you program your games in a compiled language it is always a good practice to integrate some third party scripting language to iterate fast on some stuff and if it expanded over time into something that would be more appropriate to be in the “foundational” part of the game then a porting should be done. Lua is the most common one to integrate but there could be some other options like AngleScript, JavaScript or some other Scheme and Lisp flavors.

[@yjlom]

@@PRIMARYATIAS better yet: write your scripts in that same compiled language (it needs to have fast enough compile times) and hot reload libraries with dlopen or equivalent greatly simplifies the interaction layer and makes integrating into (or separating from) the engine a very easy ordeal

[@windwalkerrangerdm]

@@yjlom All of this somehow ties into the moddability of the game as well I presume?

[@yjlom]

@@windwalkerrangerdm indeed (btw I should probably have mentioned it earlier, but I've never made a published game so do take my takes with a grain of salt)

[@hampe1337]

I'd say the 3 perks from using scriptableObjects in this case is: 1. You can change your params very easy during runtime and see them take effect immedietly without needing to recompile / rebuild. 2. Since scriptableObjects are serializable you can generate them / use them with other type of tools, externally created, or internally within Unity. 3. For situations where you have teams working on games you can provide a layer of abstraction which makes changing the data easier for someone who might not be a software developer. If anyone has some more insights or doesn't agree with these points I'd love some feedback!

[@qwfp]

I think it's easy to go from one extreme to the other one. There are many concepts that are simpler to reason about when they are visualized as not just code (obvious example being 3D meshes, but also 2D structures such as dialogue graphs). Just because it can be represented as code, doesn't mean it should. And spending time optimizing the workflow (be it by converting code to assets, or assets to code) is probably a bigger issue than the underlying problem itself (speaking from experience ;)). But I agree that sometimes it is better to just use code directly, so everyone should evaluate their specific situation by themself!

[@TheApmenard1993]

For smaller projects that aren't online multiplayer on multiple platforms this is great. From that other lens though, assets are something that can be updated without changing the core application and requiring publishers or mobile app stores to revalidate. They allow designers to create things with little support from developers after initial implementation too. The difference between big and little infrastructure on game dev is really interesting

[@BBSplat]

I should really check out Bevy. I've been learning Rust through toy problems like Advent of Code for a while now, and made a little egui tool to help with something at work. Setting up data structures that allow the type system to strictly enforce invariants just tickles my brain in the perfect way. This video makes it super clear how this could be useful for game development, too.

[@pixelpastiche]

Jeez these animations are so smooth and look great! You should make an opensource library for animating just like it someday so that other people can benefit from making their own text beautiful with the same aesthetic. Love the video btw.

[@Xeros08]

It's called Motion Canvas, he already did

[@ndykhng]

@@Xeros08 woosh

[@pixelpastiche]

@@Xeros08 Yes... that’s the joke.

[@SmotheredByLove]

Fascinating video - as usual! As an artist who needs editors and graphical interfaces to be able to achieve the more technicals aspects of my work, I appreciate my engineer and developer coworkers for creating that layer between the worlds of asset and code. This way we can communicate using a shared language and find the solutions to reach a common goal.

[@WeslomPo]

That's funny thing, because I write code like you show in last part of your video. And ECS frameworks is a key feature to make something like that. I love to code and code editors :). Cool video!

[@DanDeebster]

I love how you've used animation to reinforce what you're saying, like how you switch from the background being hard-edged red/blue Voronoi regions into a gradient when you're saying it's a spectrum. Great stuff.

[@DrakiniteOfficial]

Duuuude, the animation in this video was so slick. I can only imagine just how much time it took to do all the animation.

[@sechmascm]

He made it with his own tool, motion canvas. Which would make it much easier to do these kinds of graphics. Really cool concept

[@lawrencejob]

This is extremely wise and applicable way beyond game dev. All companies struggle to define and handle their data.

[@CyberWolf755]

As a UE dev/programmer. I use both blueprints scriptiong and C++ code. Each has their strenght from accessability and iteration of blueprints to the power and performance of C++. I think you can have a good mix of both. Especially for animation and AI, a graph or tree is easier to visually parse than to have a bunch of files open either in tiny windows or hidden behind tabs. It's an interesting mental exercise to have. Deciding where in the data/code gradiant you want your system to be and how to react when you need to adjust that idea in practise.

[@machelul]

In small teams more code is probably an option and even a need, on bigger teams with varying degrees of coding skill, having visual tools is a must to prevent problems and streamline the process.

[@JTCF]

Nice to see some recognition for Bevy! Have been watching your Astortion devlogs and it kinda inspired the visual style I have in mind for my game.

[@benjoe1993]

Great video because it doesn't say "you should do this" but rather makes you question why you do things the way you do them. Perfect approach. Why Unity and similar engines go the asset way is because they are made for bigger teams with dedicated game designers who might not know how to code. It might take less code and compile simpler if you just write the functions out as is but if there's a designer who wants to tweak values or change up the behavior of certain parts then they need some kind of editor to speed up that part of the process. Also if you write stuff in code it might be a bit harder to iterate on stuff. I get that it might be quicker to write code but it's not as easy to read. It's much simpler to click on a "Take Hit" node and pull a line to the "Apply Knockback" node than looking for where exactly the take hit takes place and then figuring out how to apply the knockback with the correct function and what parameters it needs in order to apply correctly, at the correct time to the correct entity. Yes if you organize the code well then it's not a HUGE issue but with multiple people or with a long enough development cycle it can be slower on the long run. So where the line should be between asset and code is purely based on project and team size and composition.

[@4forfour]

20 seconds of bevy already got him rethinking every aspect of coding

[@_hallowed_]

The quality of the animations in these videos is genuinely unbelievable!

[@RenderingUser]

How did I almost miss this video. And why is the animation so good

[@JDihlmann]

Every time I see a video from you, I'm so blown away by the quality of the animation and visual explanation that I forget to focus on the content.

[@NeZversSounds]

OMG, I knew about this functional programming pattern, but it wasn't this obvious to try it for state machines. Thank you!

[@YuutoGaming]

aarthificial just Drop a boom shell out of nowhere, the quantity of content, animation, and narrative is insane

[@GoodOldQuestion]

Yeap, that's what he does from time to time...

[@simplegamer6660]

you meant quality, right?

[@ChaineDeQualite]

Lately I've been trying to make custom tools in Unity but string references annoy me quite a lot and for a long time I've had a hard time finding a way around them. Unity's input system solves this by generating a C# class that represent your asset with the compromise that it takes a second or two every time you save. It's pretty useful and allows to have an editor that generates an asset without any string references. On top of that, you can hardcode everything if you want to. This makes me think that maybe tools like this should be designed as an API first, and them adapted into an editor to make easier for fast iterations, non-programmers and debugging. I'll try to do that for my current and future tools. Anyway, thanks for the video, I always learn a lot watching them and I can't wait to see what you do next!

[@UpsilonX]

Absolutely love gamedev videos that go into architectural concepts like this. Please make more!!

[@nextProgram]

That's funny, I had the exact same realization awhile ago. I was working on a system for creating boss battles using a complex system of custom assets that let you define things like phases, attacks, timing, etc. I finally realized that it would be much simpler and faster to write if I just program the boss battle manually. I'm not sure why, but I feel like we always think we're not being good programmers if we just go with the simplest option. But the fact is, most of the time the simplest option IS the best.

[@hackticdev]

The production quality on this video is so high. I seriously need to learn Motion Canvas so I can make my own videos this good

[@Dysiode]

Great overview! I'm a full-stack web engineer so a lot of the asset/code gradient is intuitive to me, and I think you explained it great! One example from the earlier web days is Webpack vs. Gulp. Webpack uses configuration files to define how to compile your web app, while Gulp you're writing standard javascript the entire way. There's all sorts of pros and cons, but the "I love to code" part of me finds Gulp's model very attractive. The Webpack/Rollup/Vite configuration based model has settled into the defacto standard, so I'm sure there's a good reason for using it instead, but I haven't looked into it. I think the reason an editor is so desirable is because it's /visual/ which makes complex ideas like the animation graph easier to comprehend. I think though there should be more/easier tooling that builds information from code, or, and I understand this is the holy grail of development, tooling that is able to modify or generate that clean representation. Anything that makes the raw code accessible for when you need to do something dirty.

[@CrabGuyy]

Love me some functions and functional programming instead of classes and OOP

[@thomaspeterson5547]

Great video, as always. Using several langs in your examples really helps drive home how universal the concept is

[@kadrilac]

When your videos show up on my feed, my smile grows instantly

[@Salloom99]

New perspective unlocked. The quality of the video is top notch, loved every second of it ❤

[@rhyboy1]

The animations are so next level…

[@98ahni]

Considering that my job is to make these tools/editors for the team, I say; Yes, that does need an editor, no matter what it is!

[@CoolGabrijel]

This video has changed my way of thinking. So it also falls somewhere between data and logic! Neat!

[@zoladkow]

Nie wiem jak wypadnie ostateczna gierka, ale Twoje filmiki juz sa swietne 😁

[@metaphoricallyspeaking]

Incredible, as usual. I know I'll be rewatching this soon for animation ideas!

[@UnofficialFoneE]

As always, your animations are sooo slick! My opinion certainly lies in the middle. In this case, representing something through code might be clearer to the dev, but yields more code. It's really just trading complexity and at the end of the day it should largely come down to preference. Errors/bugs will inevitably be made both ways and so the skill of the user and experience using the tool seems like it should decide which method to use. Now obviously, us programmers have a big bias towards scripting, but as they say: the best code is no code… Don't code bugs kids :)

[@sugrado]

inner-platform effect

[@falwiuhf]

Awesome video! Another issue I found up about regarding this topic is searchability. I'm highly familiar with Unity; I've worked with it for a decade. Recently, I have jumped into quite a large project that I haven't worked on before, and I've noticed that Unity UI and editors encapsulate a lot of data that otherwise should have been easy to find. That makes understanding the data flow extremely difficult. It's hard to notice if you worked on a project from day one, as you know where all the different parts are, but for an ongoing project, it makes it a bit harder to figure out different parts of it. As you said, it's all a game of compromises, and Unity is quite good for what it does, IMO.

[@ShinSpiegel]

Long long time ago I left a small comment asking, "why did you choose this, since you are rewriting pretty much everything"... Now I'm seeing ya on Bevy, which allows you to make the way you want, "almost from scratch", This is a fresh air, and by the tone of the video, looks like you are having fun with this change. Like usual, thank you very much for the amazing video (and by the excellent quality of the video), hope to see more content. Thank you again.

[@wchorski]

Visual editors help me get comfortable with configuration without having to always be digging in the docs, and having that 'switch to code' really helps me break into any new tech. except for shader graphs. god bless GUI node based shader graph editors

[@tinysnaket]

I love unity engine because it's way simpler than other engines to create my custom asset. If we rewind back 10 years, almost every custom asset requires you to make your own editor. Unity, Unreal, Godot are more a universal Game Creator rather than a pure Game Engine like Bevy or Raylib or the long dead Flash.

[@cerulity32k]

I'm remaking Just Shapes and Beats, and I've found that having functions to construct a level is so much easier than defining a layout in something like JSON. For one, I can have as many factory functions and build helpers as I see fit, and I can introduce as much custom logic as I want.

[@TheBelgarion01]

It's insane how good your animations are

[@gareths]

The flexing with motion canvas is staggering. I gotta watch this a few more times hold on

[@peterhuijsen]

Beautiful video! I'm constantly impressed by the content you produce and the concepts you cover. Keep it up!

[@sutsuj6437]

03:26 Rust mentioned let's go!

[@idedary]

Now that you use Rust, I can finally understand the code showcases lol

[@AgainPsychoX]

So good video again, I need to take walk now and rethink all my game-dev experience.

[@partlyawesome]

I'll definitely be looking at that motion canvas video thing you were talking about. Hell, a tutorial/walkthrough might make a good video!

[@Sofia-rh7ji]

I'm currently developing a language that's specifically for game development. One major feature is that the accompanying data storage format can include complex logic written in the form of closures or even function definitions in the exact same language that are just-in-time compiled. Since the jitc times are really small, the only real downside is that it makes it WAY easier to decompile your code & requires you increase binary size a significant amount (it's quite variable how much it increases binary size, things like exposing types with generics adds a lot more than small stuff, like just exposing functions that return primitives).

[@lucbloom]

Sebastian Lague wants to have a word with you… But seriously, I love doing it in code. It’s so much easier to find stuff and the compiler checks your work.

[@joshbishop]

I am a simple man: I see aarthificial uploads, I click on video, I like video.

[@Sancarn]

We need more low-code pro-code hybrid languages I feel. Like Enso, but for this game enginge stuff it would be awesome for designers and coders to work better together.

[@TheGrifdail]

An argument in support of assets files and tool: Tools shape the way we think about things. The same data can be perceived in totally different way. For instance the animation controller you showed, is arguably easier to understand at a glance than the code. I also played with behavior tree. Writing then with code feels very different than manipulating them through a visual tool.

[@kartopod]

The editing in this video is unreal

[@sah4pok633]

You makes videos as I wanted it for years, it's cool

[@lukesaynor3582]

So cool to see shaders in use in this video!

[@dedenapraia]

Amazing ! Awesome use of Motion Canvas ! and very interesting topic

[@ihalseide]

Cool video, reminds me of Lisp trying to span the entire code/data spectrum. I heard that there was some kind of space-limited game programming/demo scene competitions back in the day… and a team made a FPS called kkrieger that generated all textures when the game started using functions and pre-existing files on windows. This is very related to the space (data) versus time (computation) trade off in programming

[@thewhitefalcon8539]

These competitions still happen. Revision 2024 over Easter weekend, end of March - are you going?

[@randomlegodev]

good golly motion canvas is lookin flippin polished!!!

[@micka190]

Loved the "I'm not recommending this. I just love to code, so I enjoy it this way." bit. There's a lot of devs on KZbin who never end-up making anything, because they've convinced themselves that they need to remove all "bloat" from their projects. It's refreshing to see a channel that actually talks about how there's a cost to everything and that these decisions come with pros and cons. Keep up the good work!

[@neomaxp]

Great video ! Also by my experience, the use of "assets" is mainly caused by : 1. a misunderstanding of the development kit: in Unity, the editor and all the components available but it is also true in other field of programming 2. thinking this code can be reusable: often "can be reusable" does not mean "will be reused" aka over engineering 3. wanting too much "code quality" by removing code: not a great way, as you example shows, we can simplify code without using assets Also Unity editor coding is cumbersome.

[@MrNickPlaysminecraft]

I use Unity, and when developing systems like you're describing, I make the code very general but secure, never (aside from maybe setting files) with .json or .yaml type formats. It allows for a performant system that is adaptable in the editor so new content can be easily customized with little worry of breaking the system. I find that to be the right balance for me because a purely code based version would be much too rigid, and unless I'm in the final optimization section of game development, isn't worth compromising adaptability for. I recommend Code Aesthetic's video on premature optimization.

[@aarthificial]

Throughout this video, I never mentioned optimization as an argument. Premature abstraction/generalization is as problematic as premature optimization.

[@vividescence]

I'm very curious on your thoughts on use of interpreted animations in a language like C#, where *everything* is JIT-compiled. I think this is why Unity is so focused on Assets, personally, since by default, the Unity engine uses C# (there's also the ability to compile the C# code into C++ code via the IL2CPP library, but since we assume that not everyone can use that, it would track that compilation is the exception)

[@razveck]

Your videos are amazing! I love the presentation and your explanations. Keep doing good work!

[@kaibennett9077]

Motion Canvas is looking absolutely amazing!!

[@FugaceFugite]

One of the best compromises is a visual editor for assets with a function to export to code. It's even better if it supports feeding code that it can then merge with the rest. Assets are generally much easier to tweak and produce when working with a team, especially in the context of outsourcing that production ; they can also be changed without the need to recompile/rebuild the executable, which can be a huge benefit. A pure code approach is generally much more performant and more adapted to solo devs up to small teams of developers or otherwise code capable members, but removing all the standards and guides that the asset format and visual editor add, it will require more care to make sure everyone is using it correctly. In the end it's all just compromises, compromising for different contexts.

[@cinderwolf32]

I have always wanted to get into game development but find game engines with assets and visual editors as the focus to be difficult to break into.

[@yoloyojick]

After videos like these I being like: *holds his knees, curled up in a ball and mutters:* "Don't rewrite AnimatedSprite from scratch, don't rewrite AnimatedSprite from scratch, don't rewrite AnimatedSprite from scratch..."

[@ukrustacean]

Rust + Bevy GameDev, we are cooking it hard!

[@ZealanTanner]

This is a pretty incredible video, well done

[@evanmakesstuffdev]

There is so much value to reducing assets into code, but honestly, making game tools can be more fun than making the actual game. Let me program this super convulted dialogue system instead of focusing on making my game fun.

[@mehmeh8883]

Imagine a course with this level of production.

[@jiro4559]

you're very good at graphic design, mate

[@tevor09]

i love motion canvas and astortion

[@stokedfool]

Subtle, quality content. I learned something, thank you. [07:10]

[@konkitoman]

Really good video, the video artifacts happens when you encode the video or when KZbin transcodes the video?

[@Mempler]

The fact that you edited this video with code is kinda insane ngl

[@GoldenBeholden]

This is a really nice reflection.

[@zactron1997]

Would love to see your opinions on Bevy as one of its contributors! Regardless, excellent video as usual!

[@TinyLittleEnormous]

Having assets instead of code allows you to make changes faster because you don’t have to recompile everything when a simple change is made. When non programmers are present in the team, it helps them understand and modify the assets easily. I think the advantages of engines like unity are more visible when the team is bigger.

[@cristinocanga]

Video quality is crazy!🔥🔥

[@9darkspells]

I can't quite figure out how to articulate the idea fully, but this makes me think a lot about the tradeoff that exists between strongly typed and compiled languages like rust, and interpreted languages, or data. In game development I think my decision on where between the two I want my logic to reside is dependent on how often I expect to iterate on them. Changes to compiled code cannot be done while actively in the middle of running your game, which might be a desirable property if you want to quickly iterate through testing a slew of different mechanical tweaks or balance changes. In that case committing everything to strongly typed code is less desirable than the flexibility that would come from a more dynamic system.

[@qussaigamer553]

such amazing content, keep up the good work.

[@JinKee]

Wouter van Oortmerssen made his 2001 first person shooter Cube fit into 500kb by doing most things procedurally, including textures

[@mkwpaul]

Maybe this is different in gamedev, but my experience in non-game dev is that most often people hard-code behavior that would be much more easily expressed as some form of data. And by that I don't even necessarily mean a separate file format where assets are loaded at runtime, but also just normal structs that contain contain all the data to describe a certain thing and an "interpreter" that "dynamically" changes behavior depending on what the struct it is given contains. I often find this so much more flexible and easier to understand than big code structures that attempt to implement everything through hard coded behavior, especially when it heavily involves subtype polymorphism.

[@pedroth3]

Great animations! Motion canvas could be the new manim...