khalladay

I'd be careful about painting the developers at Rockstar as "not curious," that feels like an incredibly unfair conclusion to draw from this. Those developers have other pressures, and deadlines to hit. There are a million reasons why this bug wasn't solved by the team there. When a user complains about a bug in software you wrote, is it because you just "weren't curious" enough? Or is the situation more complicated?

Lots of incredibly talented people worked on GTA Online, it's worth trying to think through why a team of smart developers might not have prioritized this, rather than assuming something negative about them.

It's a little more possible now that iq has spent years teaching us all how to do it though

Don't data breakpoints help with both of these things?

I think my favourite open source project to poke around in recently is [Reshade](https://github.com/crosire/reshade). The code is pretty readable and is doing a lot of interesting stuff. Every time I've taken a look at it I've learned something new. Definitely super light on boilerplate, given that it's solving a bit of a unique problem.

In terms of tips and tricks, I often start looking at new code by trying to write out in plain english prose, a bit of a story of how the code works. Almost like I'm writing a blog post explaining how things work to someone else. Often this process uncovers rabbit holes that I need to go down to understand isolated bits of logic before I can return to building this big picture view, which is sort of the point.

> I wonder if a lot of gamedevs just get tired of playing their own game and thus don't care about it anymore as a result?

FWIW, if you work on large enough projects, you probably aren't playing the game that much at all unless you're a gameplay programmer (and even then, you might only play the small fraction of the game that your feature touches). I do graphics/engine programming for games and the closest I get to playing the game is "load into level, teleport to position X, use a cheat code to give me item Y, use Y, see rendering bug"

I've joked on some projects that I'm excited for the game to ship so I can learn how to play.

I could be misremembering, but this seems like an idea that's been tried (and failed before). I have a memory of a service whose pitch was that you'd load funds into an account (a 1 time large transaction to get past the CC fees), and then individual sites could request micropayments from that account balance. No crypto then of course, but I'm not sure adding crypto makes this idea functionally different from how it looks without it.

I could be totally off my rocker, but I'm pretty sure I remember this from sometime around the early 2010's ?

hell yeah, making a game just for fun or to learn new stuff is the best. Good luck!

I'm not the person you're replying to, but I have a bit of insight here. I've been happily employed in the games industry for the past 10 years and don't have any plans to leave it, but while I have absolutely recommended programming/software dev as a career field to people before, I would hesitate to _suggest_ the games industry to someone who wasn't already excited about it.

To your comment, making games is great and fun and I think it's great you want to do it. Working in the games industry is different from making your own games though.

For one - you pretty much will never have creative input on the game you're making as a programmer (unless you're on a really small team).

Probably the biggest reason to avoid the games industry is salary. Game developers make less than their peers in other areas of software development. Lots of people blame this on there being a huge supply of fresh grads to hire cheaply, but that explanation feels like a myopic/simplified view from people on the outside looking in to me. My opinions aside, the fact is that if I left my job today and got a job programming something that wasn't games, I'd almost certainly make more money. I'm paid well enough to live a very comfortable life, but if your goal is just to maximize how much money you make, game dev is a bad choice.

Next thing to point to is crunch. Game development is notorious for "crunch" (aka - long periods of 70-80 hour weeks). Some studios do this more than others. It always sucks. It's also a fact of life in games. Even teams that "don't crunch" will usually wind up doing something like it at some point. I honestly have no idea if other programming fields do this too, it's just a common criticism that I've seen levelled at games industry jobs.

Being a game developer also means that you're not working with the kinds of tech stacks that the larger software industry as a whole is using, which feels like it would make switching fields more difficult (not that I've tried). For example: I haven't had to build a real database since college, have written maybe two unit tests in my life and don't think I've ever worked anywhere that's used the C++ standard library, despite working in C++ for most of my career.

It's also super unstable. It feels like most game studios will close (or transition to not making games) within ~10 years of starting up. Layoffs and studio closures are also a really common occurrence. Every time a meeting gets randomly added to my calendar at the last minute, my first thought is that a layoff is going to be announced (even though this has literally never happened at my current job). This is less of a concern at large studios (although definitely still a thing), it's a huge deal if your dream is to work at indie studios though.

There are lots of great things about working in games, but the above wall of text are some of the reasons why I'd hesitate to encourage folks who aren't already interested in the field to choose game development as a career.

I think I probably sleep poorly (based on my criteria above) about once every other week or so. I definitely wake up sometimes before it's time to wake up and lie there for awhile, but I can't remember a time when it's taken longer than 30 minutes for me to get back to sleep in any of those cases.

If it's less than an hour before I'd normally get up, and I'm awake and feel like I want to get out of bed, I just get up early that day and am a little more tired when I go to bed that night.

For the most part I consider myself super lucky in the sleep department. I go to bed roughly the same time every night, fall asleep within about 15 minutes of turning out the lights, and usually get about 7-8 hours of sleep.

Sometimes I'll wake up to use the bathroom, and lately I've been waking up for a few minutes at 3 am every morning, which is weird, but I always get back to sleep easily after the odd wakeup. Waking up is harder in the winter when sunrise is later and I need to get up in the dark, but it's not a major issue.

A poor night of sleep for me is either one where I wake up more than a couple times (usually because I overdid it at the gym and I'm crampy/sore, or because my apartment is unusually cold), or any time I get less than 6.5 hours of sleep.

I don't do anything special, just follow all the usual boring sleep advice: I don't lay on my bed unless I'm going to sleep (mostly), I go to bed and wake up at the same time most days, and have a set routine when I wake up. I exercise daily for 30-60 minutes, don't drink coffee after noon, and if I'm drinking alcohol, stop drinking a few hours before I'm going to sleep.

[Edit: I should add that when I was younger, I could drink coffee or alcohol at any time of night and still sleep well. That has changed as I've gotten older]

This is a weird stance to take. Software development is not sports. There is no "game day," and the best teams I've worked on have managed to treat folks with respect while still maintaining a high degree of quality.

You can treat people kindly without having to agree with their opinions, or taking their PRs. If you are already going to reply or interact with them, it costs the same to be kind as it does to be a jerk.

I'm super out of the loop on all things blockchain... why is it cool that pixel art is stored on the blockchain as opposed to anywhere else? What benefit does that provide?

Disabling javascript (via the dev console) and reloading the page did the trick for me.

I really like the beers from the Athletic Brewing Company (https://athleticbrewing.com/). Aside from being slightly less carbonated than alcoholic beer, it's hard to tell the difference between them. And more importantly: everything I've tried from them tastes good.

No... they wouldn't. Unless the only thing keeping unqualified people from doing safety critical work is the job title they give themselves.

I've been in games for about 9 years. In my experience, virtually everyone uses Perforce. Studios that use Subversion seem to be the outlier.

You're dead on with the rest though. I'll add that UE4 is a large, hulking behemoth that generates a metric crap ton of intermediate files during builds and general development, which makes managing what to check in a bit of bear. Additionally, a lot of teams try to avoid having artists need to re-compile their editor when they pull changes from P4, so some amount of compiled binaries get checked in as well (usually from an automated build system like Jenkins or Team City that runs after every source file commit).

There are also some parts of the engine that need to exist in order for other parts to run properly, but that don't get compiled when you're making changes to the engine itself (like helper programs, or platform specific DLLs, which you need to specifically compile when you want them). Sometimes, these binaries are checked into p4 for one reason or another, which leads to fun things like needing to remember that if you're checking in the DotNet binaries folder, to explicitly NOT check in a couple iOS related DLLs, since the engine's build tool will try to recompile them every time you build a game for any platform, and will fail if those files aren't writeable. The engine is so massive at this point that there several other things like this that need to be kept in mind when setting up version control on a project.

[edit: I originally said there were "at least 20" things like this and realized I couldn't think of that many, so I've revised]

The engine is very capable (there's a reason that AAA studios without an in-house engine default to it), but it's also got 20 years of legacy systems in it and a lot of pain points to deal with for projects of any real size.

Capstone is a real treat to work with. It has a lot of quality of life features that really sped up development when I was putting together a function hooking system (like tagging instructions with RIP-relative operands).

If you're looking for more computer security / hacking related books, I can recommend "Sandworm" (by Andy Greenberg) and "The Cuckoo's Egg" (by Cliff Stoll). Both appear to have audible versions.

This is true a lot in games - often the "debug" version of a game is literally too slow to reproduce issues, so you have to work with the optimized builds.

...even if the actual debugging would be much easier with a debug build.

It's possible that this was done entirely through chat. Ie/ Rumor types " Snatches Hat " in chat. As long as both players agree that what's typed in chat is what happened, it doesn't matter if the game actually has an animation to support it.

What parts of the article drove this comment? I admittedly skimmed it, but the whole thing seemed to be about why millenials aren't just "doing it with money," and that reason wasn't that they wanted life to be like school.

Author here - cool to see this posted to HN!

As I touched on at the end of the article, I really don't have a clue what I'm doing in Vulkan, so any feedback from folks who know even a little bit of what they're doing is very, very welcome.

I'm just trying to slowly work through the complete ignorance stage of learning something new.

Sounds like I have some more to figure out :) I haven't touched alpha blending on the GBA at all yet, but that sounds excellent.

I'm especially interested to see what the performance cost of blending is on the GBA, given how expensive it is on present day phones.

Got a source for the Cold War stuff?

You are definitely right. Tonc has some interesting data (here: http://www.coranac.com/tonc/text/text.htm#tbl-txt-se2) about performance of operations with 16 bit vs 32 bit variables, but none of that information applies to memcpy, and I think I jumped the gun on making as much as possible 32 bit types.

Thanks for catching that! I'll remedy that line later this evening.

Although, evidently ARM chips have an optimized code path for 4 byte aligned data: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... , I'm not sure if that would apply in this case or not?

Thanks! I think the feedback that I got last week on here was very good. Despite my initial desire to stick with the bitmap modes and try some 3Dish stuff, it really didn't make sense to try to learn new hardware by ignoring the most common use case.

Hey, author of blog post here :)

I know about the sprite system in abstract, but I haven't tinkered with it yet (nor do I know enough to start tinkering with it yet). I'm still trying to decide whether I want to go down that route or build a ray casting engine / do some 3D stuff, since most of my other work is 3D related.

Regardless, this post was meant more to cater to the "I know nothing and want to feel like I'm making progress in 15 minutes" crowd.

Although it might last a long time in it's own niche. Perforce is definitely still alive and kicking in the games industry. Git might eventually return to just being the VCS of choice for the linux kernel.

At least with the real time applications that I have experience with, this is often mitigated with custom memory allocators which pre-allocate large contiguous blocks before performance critical sections and then parcels out segments of those blocks at runtime.

github gists are an ok solution for this if you don't really mind not having total control over color scheme.