I remember thinking those ACiD and iCE artists were godlike. The illustrations in those packs still look amazing today, even if you forget how many limitations they were operating under.
Indeed. When all I knew was text mode I envied graphics, but the reality was that true artists were making amazing art just with text and colors (and even just text and no colors!).
The C64 PETSCII scene is also amazing. It still exists!
I recently spun up a project in Rust (a small game using Bevy) and the main issues I ran into were around smart defaults for the compiler. I was surprised how many lines I had to add to my cargo.toml to just complete a simple game example.
Some examples:
It defaulted to the fully backwards compatible version (vs 2021) which threw errors as I went through some recent example code.
(I think) I had to add a few lines to my cargo.toml so the compiler would not rebuild bevy every time I recompiled (when I only changed 1 line in my program).
Either you accidentally installed a version of cargo from before the 2021 edition was stabilized, or you ran "cargo new --edition <something>", or you started by cloning an out of date project of some sort, in which case it's not really an issue with "defaults".
> smart defaults for the compiler. I was surprised how many lines I had to add to my cargo.toml
Normally this would be a pointlessly pedantic point, but cargo is not the compiler. This thread, the linked title blog post, they are about the rust compiler, not cargo. There's a close relationship, but cargo's defaults aren't necessarily related to what the "next rust compiler" might do.
I started my project without cargo at first and tried to start writing code without a cargo.toml. I was surprised that cairo didn't default to 2021 until I specified it in the .toml file. Good point that cargo init/new would have solved this!
I guess my point about the compiler was that it seems to rely on cargo.toml for many 'optimizations' that I would expect to be defaults. (Examples include the two i mentioned above).
But I'm new to the language and understand that most people will just use `cargo init` and google a few other common cargo.toml settings to improve compile times.
Ah, yeah, hand-writing a Cargo.toml like that does run into that issue.
However, I don't think the solution is a better default, but rather the solution is time-travel.
Defaulting to the latest edition would mean that any rust library that predates editions would likely break when you imported it (since it would default to an edition that didn't exist when it was written, and editions are allowed to make breaking changes of that sort).
The thing that would fix your issue would be time-traveling back in time to when cargo was created, and making edition a required field of all cargo.toml files that results in an error until you add one. That would have saved you from any trouble.
Rust could also do a python2 -> python3 like transition, where crates from the old "edition not required" world can't be imported anymore at all, but that seems like a very small thing to cause so much ecosystem pain over.
I've been using Godot off and on for the past month prototyping a mobile game. The editor loads/refreshes very quickly on a macbook air m1 (which hasn't been the case w/ Unity of late). The workflow is intuitive and for reasonably scoped games, it's a great fit.
I was surprised to not feel limited by gdscript (having no python background and doing most work in JS for the past decade). I picked it up quickly and it's well documented and integrated into vscode.
Not sure if it would be my choice for a large game with millions of entities (e.g. an online RPG that needs an ECS system) but for small 2d games it is a delight to work with.
I may be the minority here, but I hope Godot doesn't try to cater to AA/AAA devs and keeps small indies front and center as the focus.
At least in Kentucky both Kroger and Target have them randomly in the imports section of the cookie aisle if you look for them. (Depending on supply chain presumably.) In Kroger it's often the hard to see/hard to find top shelf. They rarely get the fun or the especially good flavors, but they often have the originals.
I don't think Kentucky has an especially large Australian influence, so I assume that they distribute Tim Tams somewhat broadly nationally, but I don't know.
This is very cool. I love the focus on builders and do think there's a gap in easy to use 2d web-friendly game engines currently.
Phaser still requires a ton of boilerplate code compared to the example games here.
Both Godot and Unity are very similar to each other and aren't great for say.. hacking together a quick js prototype and sharing it with your friends on the web (or with a lil' device).
Thanks! I've been really strongly influenced by great constructionists like Brian Silverman (who worked on Scratch and early Lego Mindstorms). He also helped consult on Sprig actually. We wanted to have a nice composable construct kit of ideas which would make getting started easy but which would still be fun for experts.
I've been really impressed with how well people can build out really engaging games with simple graphics but interesting game mechanics. The community already has pushed it beyond what we originally expected when designing the engine.
For all the faults with Flash (security primarily) it gave so many people an easy way into games development.
We’re missing this today.
Just getting the environment setup for a lot of game engines today is beyond today’s teenagers (and to be fair, me - both in terms of required knowledge and attention span), whereas 40 years ago, you just turned your computer on and boom - a flashing cursor. You had to type things to even load games.
As someone who previously found art very inaccessible, I loved diving in with p5 and feeling like I finally found a medium (gen art) that I can freely create and experiment within.
This was a really popular project. For those who haven’t poked around generative art recently, check out artblocks.io. You buy a piece of art (limited edition) and it creates a unique (randomized) piece for you on the spot. Pretty rad.
You didn't answer any of the questions, especially regarding decentralization. If there's going too be only a handful of validators, then it's as good as a centralized app hosted on AWS. Then how is it facilitating "DeFi", when there's no "De"?
I’ve read a lot about Solana and have considered trying to get a Validator up on their testnet.
I think the concern about centralization of the Solana chain is a real one. I don’t know what to say about the coin distribution in general and frankly that is my biggest concern with Sol. But in regards to validator centralization, I wonder how many validators would be required to assuage these concerns. Thousands? Tens of thousands? Currently there are 632 validators on mainnet Solana with the largest stake holding I see close to 5% (1). Compare that to the ETH mining pools where the top two pools almost have a majority of mining hashrate (2). I’m not trying to make a “whatabout” argument, just pointing out the relative decentralization in comparison to current Eth network.
With regards to the eth2 network, the comparison is a bit more straightforward. If we do a calc of the market cap / #ofvalidators, Sol has about 16M$ market cap per validator. I see 172,920 Eth2 validator deposits (3) so if the Merge happened right now, each validator would represent about 1.7M$ (=300B / 172920). So in this highly oversimplified model, Eth2 has about 10x as many validators as Sol.
This of course means nothing about real world outcomes as you could imagine large staking pools forming and the situation looking more like the BTC or ETH PoW chains with a few large groups dominating either Sol or Eth2
Anyway, for me, that’s actually kind of reassuring. Solana wants to push out more validators but block times are so fast that growing the network has some real technical challenges. If they can overcome those challenges, they’ll be reasonably decentralized with regards to the number of validators, at least compared to ETH.
This is a pretty rad credential. ACiD and iCE were hugely influential in my early career and I looked up to the early and late members. Very cool.