> How would you design FPSs to remove this "bad game design?"
I think we just need to accept that bots will always be better at reaction based KPIs & abusing "knowing" too much game state, we should just remove those conditions.
1) Move most of the application logic to the server, the client should be a fairly dumb terminal that knows how to render and accept inputs, and only receives the state that it needs. No more spying issues.
2) Just give everybody auto aim & immediate/auto controlled firing, etc. No more aim bot issues.
3) Improve the quality of gameplay around the types of interactions which bots are bad at. Decision making, strategy, communication, execution, adaptation.
We can only minimize the amount of extra information given to the client, not eliminate it. And at high enough skill levels, even 1-2ms of extra information will always be actionable, even by humans (not just bots).
Literally the worst job you can find as a programmer today (if you lower you standards and particularly, stay away from cryptocurrency jobs) is 10x better than the non-programmer jobs you can find.
If you don't trust me, give a non-programming job a try for 1 year and then come back and tell me how much more comfy $JOB was :)
> Literally the worst job you can find as a programmer today (if you lower you standards and particularly, stay away from cryptocurrency jobs) is 10x better than the non-programmer jobs you can find.
This is a ridiculous statement. I know plenty of people (that are not developers) that make around the same as I do and enjoy their work as much as I do. Yes, software development is a great field to be in, but there's plenty of others that are just as good.
Huh? I'm not saying there isn't careers out there that are also good, I'm not sure what in my comment made it seem so? Of course there are many great fields out there, wasn't my intention to somehow seem to say software development is the only one.
>>Literally the worst job you can find as a programmer today (if you lower you standards and particularly, stay away from cryptocurrency jobs) is 10x better than the non-programmer jobs you can find.
A lot of non-programmer jobs have a kind of union protection, pension plans and other perks even with health care. That makes a crappy salary and work environment bearable.
There was this VP of HR, in a Indian outsourcing firm, and she something to the effect that Software jobs appear like would pay to the moon, have an employee generate tremendous value for the company and general appeal that only smart people work these jobs. None of this happens with the majority of the people. So after 10-15 years you actually kind of begin to see why some one might want to work a manufacturing job.
Life is long, job guarantee, pensions etc matter far more than 'move fast and break thing' glory as you age.
I was a lot happier in previous non-programming jobs, they just were much worse at paying the bills. If i could make my programming salary doing either of my previous jobs, i would go back in a heartbeat. Hell if i could make even 60% of my programming salary doing those jobs I'd go back.
I enjoy the practice of programming well enough but i do not at all love it as a career. I don't hate it by any means either but it's far from my first choice in terms of career.
All of them. The issue at hand is not limited to a specific language or tool or ecosystem, rather it is fundamental to using a package manager to install and update 3rd party libraries.
It was in the context of the argument. What's more real about Bitcoin than bonds, options, or stock?
It felt like "real" referred to the physical: gold, food, energy, minerals, real physical things that people have a constant demand for.
It was funny to spot the odd entry, where bitcoins are fully digital and have a very socially dependent agreement and entire digital infrastructure required to keep them functioning.
Gold has a bit of a social agreement as well, but it's social agreement dates thousands of years and even if it broke away still has value as a physical material.
It takes like two seconds to write a ticket and then tag your commits with it.
You get credit for fixing the issue, avoid giant fix-along-the-way PRs, and future credit for people (maybe even you) understanding why you those changes were made.
But then if you cannot work on a ticket because of prio, you cannot either work without a ticket, isn't it? I thought the point here was doing work with or without a ticket.
Without a ticket, the only people who see that you're working on that thing are the engineers reviewing your code. At many companies, this creates a lot less friction.
To put it a different way: it's better to ask forgiveness than permission. Creating a ticket is like asking permission (as the project managers will see the ticket and start asking questions about why time is being spent on low-priority things). Just going ahead and pushing code is asking forgiveness - sure, someone might notice after the fact that you did some work that you weren't assigned to do, but by that point it will be considered irrelevant, as long as your other responsibilities were handled on-time.
If you've never worked at a company where these political games are necessary - count your lucky stars!
> If you've never worked at a company where these political games are necessary - count your lucky stars!
I've worked at several places that use Jira, and none of this stuff ever happened. I've helped make sure that's the case, of course, but I don't think I've had anyone I've worked with question an individual ticket's priority.
