Hey brad. Love your blog's layout. The neon sign headings are so catchy! And I'm going through some tough times in my life, and I can totally relate how cathartic the process of 'creation' is. Thanks for sharing!
I'm glad it was helpful! Sorry you're going through some tough times :( Hope you can find a way through and find the support you need from friends and family. Share your creations would love to have a look!!!
I just found your blog yesterday reading up on the stories of how Warcraft and Starcraft were made!! Have been hacking on small games and a tool to build 3d environments for a while and get very inspired by hearing stories from back in the day. Thanks for making everything public. I really enjoy your writing.
For me.. the most interesting part of the whole Warcraft saga would be more discussions around the arguments/design decisions of.. "we should include ___."
For example... War2 stuck with two races (and introduced alliances w/ other races like elves) instead of adding new races. How did you get to that decision? did you do any prototypes? Was it just a pure argument? What did you find in the process?
That kind of behind the scenes design discussion is rarely surfaced (and often messy) but is as interesting (to me) as the technical decisions.
One more idea.. You've worked across great companies and great games. If you were going back now to your former self striking out to ship your first commercial game, what are the 3-4 pieces of wisdom you wish you'd internalized back then?
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.
reply