1,283 karma · joined January 25, 2010
Very cool, thanks for sharing!
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.
Revamped my blog to have a funky 3d background and animated cursor after years of minimalism: https://bdickason.com
A little screensaver inspired by After Dark: https://bdickason.com/static/experiments/flying-stuff/
A little toy using (mobile) screen tilt: https://qwertle.bdickason.com
A funky RTS designed for mobile: https://chasm-nine.vercel.app/
A start of a little 3D RPG: https://misty-woods.vercel.app/
Note: all experiences in varying states of completion ¯\_(ツ)_/¯
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.
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.
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).
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.
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).
(I don’t work for artblocks)
I don’t think it’s as simple as ‘eth or solana.’ I suspect that multiple chains will be useful for different applications.
For example, games which want super low latency will want a solution like solana. Even polygon slows down today and their usage numbers aren’t huge.
Solana has the fastest and cheapest transactions. That makes it my choice when it comes to defi apps.
I’m holding all 3 but I do think Solana has a great community and strong developer support.
I'll try to describe this in a bit more detail: Zero-to-one is a type of product which is created from scratch. At many companies, there are existing products and you add features or improve them to grow them. There are other products where you start something completely new. Think Dropbox launching 'Paper' which is a tool to make documents.
Deeply Understanding People means spending time to interview users or run user research, derive problem statements from those discussions, and then turn those into hypotheses. This is different from some PM's who like to focus on metrics and look for patterns in data.
So I'm saying: My strengths are product strategy (of the zero-to-one variety) and understanding people (vs metrics).
As for the style of writing, I aim to write simply and clearly. I'm obviously not hitting the bar here :) Do you have suggestions for equally good alternatives to this sentence? I'd be happy to update it.
I'd argue the latter, but it could be a question of framing?
Thanks everyone for sharing really awesome examples in the comments here - from Games to Receipt Printers to Apps, it's clear that speed is valued.
Or... that there's a big opportunity to bring back lightning fast products :)
When I built my blog, I tried to find every opportunity to reduce cruft (even stripping out extra CSS classes) so reading it would feel as close to a native app as possible.
You could argue that HN succeeded because it's focused on speed above all else.
(Also - fellow former Q1/Q3 player here, I competed in CPL, Quakecon, and a few other events).
Thanks for sharing this, it's crazy how much super fast experiences still surprise us.