Funny how you can tell a project is vibe-coded just from a first glance at its website. All these websites seem to somehow have the same visual style. Anyone noticed this?
Yep, my fans started revving as soon as I loaded it. Animations are out of control on the normal web as it is, but genAI sites take it to another level.
Yeah it was. I've been hoping to get the time to write a userscript to identify and stop animations like that, but I haven't been able to understand the whole requestAnimationFrame thing enough yet.
I'd given up on that a while ago because I basically had to disable it everywhere. But yeah this was custom inline js so my ublock filters didn't get it
That is also my understanding. My personal theory is that many corporate compliance departments (or whoever is in charge of this at a particular place) just disallow any *GPL use in their company, regardless of whether it would actually cause problems, so this is an attempt to "unblock" the library for those. Instead of, you know, educating people about the nuances of different copyleft licenses.
Perhaps you are right. I work for a company right now that has a smarter than average legal4IT department and they ask sensible questions about every piece of FLOSS code you want to bring in:
- what is the license?
- is it a program or a library?
- do you plan to use it as-is or modify it?
- do you plan to include it in our products or is it for internal use only?
But I have also worked for a company that simply had "if MIT, BSD, Apache, ISC, MPL, zlib then OK else notOK" as a policy.
The indie gamedev scene is full of people for whom games are an art form. These people don't give two hoots about what "the industry" prioritizes, they just want to make their games their way.
Calling their creations slop and suggesting using AI to make them is honestly quite the insult.
I think the biggest mistake you can make is shifting your mindset from making a game to making a game engine. No, you still want to be dead set on making your game, you just don't have the ready-made building blocks from an off-the-shelf engine, so you have to make your own as you go, and only as needed. Personally, when I was working on my little game, I found it helpful to call the endeavour—just like Noel Berry in TFA—"making a game without an engine", rather than "making a custom game engine". I only really wrote the absolutely necessary plumbing that I needed for the game I was making, nothing more.
The same goes for software libraries in general, I think. Just make your program. Don't make an overly general library for something you won't need anyway. If the code proves useful for reuse, just factor it out after the fact and generalize as needed.
> shifting your mindset from making a game to making a game engine
This reminds me of when someone makes his own static site generator, write one blog post about how he started a blog with his own static site generator, and then post nothing afterwards.
I suspect the reason for this genre of behavior is there is just a tremendous amount of creativity required to come up with anything original enough to justify putting into a game, or a blog, but game engines and static site generators have relatively straightforward feature requirements that you can just implement like any software feature. Building your own game engine or static site generator is just a good way to procrastinate doing the hard part of game making or blogging while still keeping yourself in the game making or blogging zone so that you can tell yourself, yes, I am a game developer or blogger.
On the contrary, making the tool that makes the tool is what I live for! My personal tech stack has benefited incredibly from this practice and fuels my startup, though it did take me 20 years of slow iteration to get here.
Well I’m not anti ;) … I just mean if your goal is to make the thing and you’re sure you need a tool to do it, watch out for the temptation to make the tool that makes the tool, which is the LONG way around, as OP was saying
that's really dope, but i'm not sure if it'll work out the same way nowadays. i think we're in a weird stage where momentum REALLY matters in a way that it didn't 10 years ago or 5 years down the line (probably)
> What if something is costly, that you need to compute dynamically, but not often, makes it into the frame? Do you separately now create a state flag for that one render object?
The point of immediate mode UIs is not necessarily that there is no state specific to the UI, but rather that the state is owned by user code. You can (and, in these more complex cases, should) retain state between frames. The main difference is that the state is still managed by your code, rather than the UI system ("library", whatever).
I actually use a very similar paradigm successfully in a game [1] whose (immediate-mode) UI is fully responsive. I allow more operations than just cutting to do that, but the basic idea seems to be the same. The code may look like a bit of a mess at a first glance [2], but I still find it easier to work with and make it do what I actually want with some very basic vector maths, than with the layout-container rules of most UI frameworks.
>I would expect such a feature to use end-to-end encryption for the data
How would "end-to-end encryption" when such features by definition require the server to have access to the credentials to perform the required operations? If by "end to end" you actually mean it's encrypted all the way to the server, that's just "encryption in transit".
Use our new open source (modification and redistribution not permitted) app to exchange end-to-end encrypted (from your client to our server) messages with your friends! Having all your data on our service protects your data sovereignty (we do not provide for export or interop) by guaranteeing that you always have access to your full history! Usage also protects your privacy (we analyze your data for marketing purposes) by preventing unscrupulous third parties from analyzing your data for marketing purposes.
If we had competent regulators this sort of blatant willful negligence would constitute false advertising.
reply