Yep, this is what I use as well. Works well! (In my case, I have it just running as a CDN in front of Wasabi, which actually stores the images - likely even cheaper if most of the images aren't viewed)
> (I don't know what to do if another change interrupts the first but it's a rare case and can probably be handled imperfectly.)
This kind of lerp trick, while imperfect, is useful in exactly these sort of situations. It allows you to smooth movement even if the target point is changing at at arbitrary intervals (note too that it works okay generalised to multiple dimensions). And the statelessness is very useful too - I don't think the feel is great and it's not very controllable, but being able to just add some damping to the movement without having to track animation states or anything like that is super useful.
Hi! Thank you. The exported games run as ordinary HTML pages, so hopefully they're hitting a minimum bar for this kind of accessibility already (tab will cycle through links, enter will work to select it). The actual output format is open source (https://github.com/downpourlimited/engine) so making games within Downpour, exporting them, and then adding in the AAC shim or any other technology should be pretty straightforward. I'm not sure what adding more support for this tech by default would look like, but I'd be happy to chat more about it - email me at v@downpour.limited ?
and yes, to be honest i agree with everything you're saying here. it's needed attention for a good while, i've just been busy with getting the app finished & trying to avoid the distraction pit of "fixing up my blog"
As the creator of Downpour, I have to say: yes! both of these tools are great. I'd also shout out Bitsy and Twine as two phenomenal simple game making tools.
Great job, I am partial to such tools!
We used both Bitsy and Twine at work for single-day game jams, as such experience teaches valuable skills.
I'll definitely want to use Downpour for the next one.
Hello, the creator here. It's a tricky subject, I agree - especially because as a trans person who likes lots of messy transgressive art, I don't want to shut down that kind of self-expression from the platform. But also it's on the app stores, which do have rules for what content can be served up within an app. But there's a few layers to this - first is that the Featured list is currently a hand selected list of users, which means that there's no algorithm to surface that kind of explicit content automatically. And there's also a reporting/moderation system for explicit content that is uploaded. And finally - the app works as a standalone tool even if you don't host the games on the platform - you can make explicit content and export it to host elsewhere. I'm always glad when people think about this side of stuff - honestly it's one of the things I've most been stressed about with launching this. You gotta!
Either you make an account and upload your game, getting a downpour.games link you can share. Or you can export the game as a self contained webpage to host elsewhere (it's a zip with an index.html, a JSON file & the required images)
Creator here - sorry about this! I've found a few people are running into this, and I'm not sure what the cause is - going to be looking into adding password auth as a workaround, but that will obviously take a hot second.
> Typically, the selection of a programming language is predetermined in brownfield projects, leaving little room for choosing the "ideal" programming language for migration unless it is absolutely necessary (go can be a suitable option for migrations).
Yep - or it's the standard for some tasks & the important thing is being able to use the ecosystem of external packages that everyone else uses. In this case, the author is working on AI & computer vision, for which everyone else uses Python. Python could be a much worse language than it is and using Python would still be the right choice in this scenario.
In computer vision, you use Python for prototyping and research. It of course gets rewritten if it's to be actually used, think for example of the guidance system in a car, plane, or weapon.
It's pretty much the same for AI, except that there is an increasing trend in AI of it being used by people that do not have the skills to do the productionization.
I agree that in most cases it should be rewritten for production, but in my experience that quite often doesn't happen, and AI stays in Python even for production usages.
