167 karma · joined July 29, 2012
I agree it should be prevented. It seems so absurd and is clearly not necessary. Android should have an option to let it see an empty/phony address book, so it can't tell that you've blocked it.
A half decade before you, I also started at a big studio writing C++ (but with one degree) and was paid more twice that but in Canadian dollars (65k CAD). You're right that it pays lower than other programming jobs: Silicon Valley starting salaries were around 80k USD.
Studios still use Flash (now called Adobe Animate) to create great looking art very quickly. I think Massive Monster used Flash for Cult of the Lamb. Klei still uses this process:
https://youtu.be/8_KBjd0iaCU?si=J1jL6fXVkvkXjWy_
But it definitely requires skill and drawing many frames: just not as many as flipbook animation.
The point of the article is to find success at smaller levels before aiming higher.
However, you're right that good-looking screenshots sell, but that's just good art and not exclusively AAA art.
> A “middle game” should only take 1 to 9 months to create and can be profitable (or at least not a money sink) because it is expected to earn in the range of $10,000 to $40,000.
$53k/year isn't a great salary, but $120k/year is common outside of big tech and especially in games.
It's also a lot better than working unpaid for 4 years on a game that fails to capture any attention (or sales).
The point is releasing games as a stepping stone from new studio to large projects. How much would a founder earn at a self-funded startup in the first year anyway? $0?
However, very true that it would be foolish to live in the Bay area when not earning a Bay salary.
I found ahk python module [2] but combining it with the keyboard module doesn't work as well as autohotkey as a hotkey listener.
[1]: https://github.com/idbrii/daveconfig/blob/main/win/autohotke... [2]: https://pypi.org/project/ahk/
Why make this runtime instead of a prepublish script (even a git commit hook or CI action)? Doesn't seem like your images would ever change so it introduces a point of failure, but I guess relieves you of ever thinking about images again?
The author converted it to a vim plugin with the same name, but I use a different vim plugin implementation [mergetool].
[dc]: https://github.com/whiteinge/dotfiles/blob/master/bin/diffco... [mergetool]: https://github.com/idbrii/vim-mergetool
Credit Bill Joy for the modal editing paradigm, but vim is so much more than that. Most editors have a vi mode, but they don't compare to vim because they are awkward to script and don't have powerful regular expressions so readily available (both introduced in vim).
We could thank Ken Thompson and Dennis Ritchie for enabling vi, but I thank Bram for keeping vi viable, portable, and well-supported across languages.
Navigating quickfix and location lists is global, so a single common command wouldn't make sense (you can use `:cn` from any window -- even if the quickfix is not visible). However, you could use a `<buffer>` map to use the same key to navigate within loclist/quickfire windows.
> The only explanation for this ridiculous state of affairs must be that it was too difficult to extend quickfix lists to do the things that location lists do.
Their entire concept is to be what quickfix isn't: instead of a global list, it's a list that's tied to a window. I can't think of features that a loclists have but quickfix doesn't unrelated to their nonglobal nature.
I can't claim vim's code is easy to understand, but this is not a fair complaint.
But git users are more familiar with porcelain so I wouldn't be surprised if they parsed that for an initial implementation.
It sounds like plumbing shouldn't break as often as you imply:
> The interface (input, output, set of options and the semantics) to these low-level commands are meant to be a lot more stable than Porcelain level commands, because these commands are primarily for scripted use.
https://schacon.github.io/git/git.html#_low_level_commands_p...
However, doesn't seem like they're nearly as rigorous as you hope.
Neovim migrated to a more modern style of C and more tightly integrated Lua as its scripting language (instead of conscript). Those are two large potential stumbling blocks for contributors.
From loosely following development over the years, I see names like chrisbra and justinmk who contribute to both projects, but there seem to be many who contribute to neovim but never contributed to vim.
Neovim also seems to have influenced the development of vim: channels, jobs, terminal mode, and issues/PRs on github (instead of mailinglists) felt like shifts in response to neovim.
I think it's also to Bram, justinmk, and other maintainers credit that the two projects contribute back and forth: many vim fixes are merged to neovim and I see big changes get brought back to vim too.
Better job offers because you have high rep?
I've found using hererocks[1] makes setting up lua and luarocks on Windows very easy. Running it in visual studio's command prompt has let me install pure Lua and C rocks.
However, I've noticed many rocks aren't updated on luarocks and the best way to install them is to point luarocks to the rockspec file in their git repo. Instead of `luarocks install testy` you do something like `luarocks install https://raw.githubusercontent.com/siffiejoe/lua-testy/master...` I don't use Lua for desktop development, so I only use rocks for dev tools to help write Lua for my embedded target, so I'm not sure how popular luarocks is these days.
Types can certainly help prevent something from going wrong, but they're not a zero programmer time cost safety feature.
OP worded it aggressively, but if someone can't see how others benefit from lower overhead, they should look closer.
I assumed it was this shorter lines effect that Pocket, Instapaper, etc put wide margins around your articles and large text.
Disable (Uncheck) automatic updates from [Settings] > [System] > [Automatic Downloads]
You'll have to uninstall the game and reinstall it from your hard copy to get the original version of the game you remember.
However, if you'd bought the digital version, you'd be out of luck.
The technique I use looks like this: https://youtu.be/_aAeI7p-Tkc?t=11
Most of my code review comments are along the lines of "what does this do" -- the primary question I'm asking in an in-person review. My goal for a review is to pre-emptively answer the questions I'd ask if I had to fix bugs in the code. This frequently exposes bugs because it requires the author to consider their code from a different perspective.
Maybe it's the code under review: I work in games and was reviewing a lot of code from juniors, so I'd often be asking questions intended to get them thinking about their technical design and we had very little rigor.
In my eyes, the biggest upside of in-person is how it reduces mental drain from back-and-forth. A conversation is comfortable instead of the digital equivalent of repeated red ink all over your work.
> Over a decade of experience with merging enthusiastically approved, hopelessly broken code
Or maybe you're commenting on the code reviewers you've worked with rather than your own experience as a reviewer?
My first full-time job had an unexplained email expiry policy. After being frustrated several times at losing some explanation on how/why, I started forwarding all my emails to gmail. In retrospect, that's probably a worse result to whoever imposed the expiration.
Fortunately, these days people are better about consolidating knowledge on wikis or some kind of shared docs instead of only email.
Your effort estimates line up with mine, but I'm not sure about the ROI (but it's been a few years and I was pre-fortnite).
We made limited changes to Unreal source, but I think we made more changes than we had to. We had our middleware, we fixed bugs (none upstreamed via github due to company policy), but we also introduced new features varying from necessary for the project (instanced mesh rendering) to unnecessary (fancy logging). Every upgrade, I regretted most of the changes we made.
But also, it seems like every upgrade our data assets and blueprint script would get less stable and cause weird infrequent crashes in the blueprint/uscript interpreter.
Do you use bleeding edge features? I recall being wary of anything that hadn't been around for a few updates.
This part lost me because I can't see how you can use std::transform (which is in <algorithm>) without hitting this flaw. Unless you edit the headers? I guess you mean the algorithm isn't flawed.
I also didn't understand the title because I don't use clang-format and I skimmed past the single mention of it (my fault).
Regardless, interesting post.
So devs of two year old games will need an old macOS install that can export their game to 64-bit, but also a new enough macOS install that can notarize their app (maybe these can both be Mojave -- but many indies don't own their own macs).
Also, Unity 5 is no longer available for purchase. If they're already using their license on another machine, they'll have to migrate it to these macOS installs.
Devs could upgrade to a more recent Unity and fix all the bugs, but to what benefit and at what cost?
[1]: https://forum.unity.com/threads/installing-unity-on-macos-ca...
Also, fixes seem to be flowing from vim to neovim.
But I like your idea. Something like Vittle as a whittled-down version of vim.