The article describes middle games as "'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."
Am I understanding that right?
A reasonably competent developer could make at least twice that in salary, with far less risk. So that's not really profitable, once you remember opportunity cost (and especially if you risk-adjust it).
The ones that take a few days can be a weekend project. The longer projects you'd be hoping become huge, and very profitable.
True for some cases, but not everyone embarking in those Gamedev journeys are competent developers able to land those jobs. If you see testimonials, they're often people coming from different walks of life, doing a micro-game (often following a tutorial) and then deciding to stop everything for a few months or even years.
Doing those mid-level games is arguably equivalent to taking a low-paid internship.
Yes, building and releasing a game that turns a profit is, in reality, a success.
As a programmer, you can absolutely make more money more reliably by getting a job or working freelance.
The problem the article is addressing (I think) is that this reality does not seem to inform the popularly held beliefs and expectations of (inexperienced?) indie game developers, and the effects of that.
>The problem the article is addressing (I think) is that this reality does not seem to inform the popularly held beliefs and expectations of (inexperienced?) indie game developers, and the effects of that.
Reality doesn't inform a lot of creative endeavors. Writing some tech book (or really books more broadly) is almost certainly some way below minimum wage task from a financial perspective unless it makes your company notice you more, it brings you clients, etc.
As mentioned in the article though, a middle game would be a stepping stone that provides hands on experience of creating and selling such a game.
You'd most likely be working on a small portion of a bigger game at a salaried job, without really being able to accumulate the needed skillset to jump into a larger game developed on your own terms.
In video games it would be very hard to make that kind of money(in vast majority of the world anyway) if you're just starting out. I myself was only paid £18k/pa as a junior programmer at a big studio, programming in C++ with two CS degrees. Industry pays crap to those starting out. So compared to that yeah, if you manage to make some games that make enough money to pay the bills and which give you game Dev experience......completely worth it. Or you could leave the industry, get a normal software job and be paid well - the choice is yours.
> I myself was only paid £18k/pa as a junior programmer at a big studio, programming in C++ with two CS degrees
How long ago was that though? I started professionally in games in 2004 getting paid £16k/pa living in Dundee making J2ME games then moved over to another company making a UE3 title after six months going up to 19k/pa. I also had an offer for 21k/pa working for EA Chertsey but didn't fancy moving there!
I hope base salary has gone up by quite a bit in the UK since then!
I think that's very regional? Salary surveys usually list Europeans much lower after currency conversion.
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.
I don't know if it'd really be hard (you could list them, or have various limits on users or total revenue among all related companies). You could broadly include all subsidiaries, contractors working for Amazon, companies effectively under their control, etc. (Ultimately it'll be interpreted by a judge, not an algorithm, that probably makes it harder to get around.) There is nothing illegal about offering a license to everyone except Amazon, Microsoft, and Google.
But none of those licenses would be open source licenses. That's the problem with doing it — you can't do that in an open source license.
The no discrimination clauses are a requirement of the open source definition, not the law. (The law of course does have some non-discrimination requirements, not sure how many of those apply to copyright licenses. But none of the normal ones would prohibit "everyone but Amazon may use this".)
Some unarchivers (especially ones which aren't Unix natives, like say rar) seem to love to do it. They're just buggy, of course.
Beyond that, before the mid-2000s, it was common to use non-UTF-8 locales on Linux. So I'm sure I still have ISO-8859-1/—15 encoded file names somewhere, especially in archived data. They're not always trivial to rename either, because there might be references to them by name. (Or, in odd cases, you can't convert the name to UTF-8 because you hit a filename length limit, since UTF-8 is more bytes).
I believe wanting to access data from 20 years ago is a perfectly reasonable use case.
It's not so bad if a program can't display the file name right, as long as it doesn't crash with an exception or refuse to open the file. Unix file names have been defined as arbitrary sequences of octects except / and NUL for 30+ years.
Because then you have to transport the wood to the site, transport the ash (etc.) off the site, and build something useful to do with the produced energy. Most of that would be trucks or ships if it's on a navigable waterway.
Oil and pipeline companies are building pipes to move gases because it is the cheapest way to do it.
I would still think that eBPF is a better suited approach. With fanotify, you would need to manage the mount points for which notifications need to be received. This works semi-OK for a static use case, but not for dynamically-created mounts and, worse, mount namespaces. In other words, fanotify is not suitable at all, without a lot of glue, for monitoring events happening in containers. And, for example, clamonacc (on-access file checking for ClamAV) does not work with removable storage, temporary network mounts, and containers for this very reason.
A lot of email clients support multiple email accounts, or at least sending addresses. Not just desktop ones like Thunderbird, but web ones like Gmail too.
You can additionally set up email to be forwarded (or retrieved). So, for example, you can easily have your me@example.com account forwarded in to Gmail and Gmail set up to send from that address.
That works fine if the site sends a confirmation email, it'll get to Gmail where the user expects to read it. But the other way around will give the user errors about having the wrong email (even if tj user picks the right outgoing address, because you won't be able to verify it), and ultimately cause the user to give up or you're going to have to spend a lot of time supporting all kinds of weird email configs.
I think airplane mode is intended to comply with the rules for using the device on an airplane. That used to be no radios whatsoever (and device turned off during takeoff and landing).
The rules on aircraft changed, so the feature was updated.
I suspect they wanted the feature changed because it gives them better data when tracking you and other nearby devices and that once the rules for airlines changed they figured they could get away with giving users a false sense of security, which is why the feature is still called "airplane mode" which the public understands to mean everything is disconnected even though that's no longer the case.
I think of it more as cynicism. I don't assume corporations act with our best interests in mind. I assume they will do whatever makes them the most money. Companies make a lot of money using the radios in our devices to track us.
I’m pretty sure “the public” knows that the giant blue (not gray) wifi icon and bluetooth icon in control center means wifi and bluetooth are still working when you press the airplane icon.
Unfortunately, high beams also risk blinding oncoming traffic, potentially causing a collision.
In addition, I wonder if the blinking would be distracting, calling attention away from the problem (at least when the horn is being used as intended, not just by someone complaining about slow traffic).
Can you describe such a situation? As far as my thought process goes, the horn is meant to attract attention, and lights only help that purpose.
If you are driving on a dark road with traffic coming on the opposite lane (the only situation I can conceive where high beam blinding is a problem), why would you sit on the horn for more than 1/2 a second?
Am I understanding that right?
A reasonably competent developer could make at least twice that in salary, with far less risk. So that's not really profitable, once you remember opportunity cost (and especially if you risk-adjust it).
The ones that take a few days can be a weekend project. The longer projects you'd be hoping become huge, and very profitable.