Totally agree with this. Blizzard nowadays is a giant, but nobody would have blamed them if they remained a small studio, trying to protect what they've worked hard for to create. Just because they have a lot of money now, doesn't legally change a thing. It sucks because Blizzard has become a shitty company, and I'd like these types of devs from Turtle WoW to be able to continue their work, but you have to draw the line somewhere.
Out of curiosity, as a fellow dev I'm interested in how you go about reverse engineering these types of things. I assume for networking, you keep track of what goes in and out of the live game. How do you go about pathing? How do you reverse engineer spells, how they scale over levels, and how bosses work, when they spawn, and how they spawn (based on non time based factors) ?
In WoW specifically, I'll chime in with some things I know about:
- the WoW client contains a lot of stuff in their DBC (DataBase Client) files (for example spells and their effects, talents, achievements, etc), which you can extract (the file formats used are basically unchanged and well known since first WoW came out)
- the client also uses WDB Cache files which contain things the player has encountered (creatures, items, quests), and volunteer players then send these files to projects like TrinityCore (probably the best known server emulator), which use them to build databases
- for dungeon/boss scripting specifically, there's a lot of guilds competing for "world firsts" on official servers who collect a ton of information about boss behaviour, they then use that to develop addons, which help their players when actually doing the boss. then, when you want to implement the boss scripting in TrinityCore (or other emulator), these addons provide a decent starting point for things like abilities and their times, boss phases, etc. afterwards, volunteers report differences they encounter on official servers vs emulators in boss behavior
Yes kind of.
You have to differentiate between all the different kinds of data. A lot of data was already included in the client files, but for the rest you had to sniff packages, analyse combat logs, watch 360p videos of boss fights and try to figure out exactly how mechanics are working.
It got very ugly after a new expansion has been released, because it was not possible anymore to sniff for the older expansion.
It was always a “best effort”, but also very rewarding if you got a specific fight “somewhat” close how it was on the official servers.
Networking was the most straightforward part actually. You run the real client and then point it at your server, and use a packet sniffer to capture everything.
I think this comment deserves some nuance. Every company has to comply to local laws. Unless you want to run something illegal, at which point it's not a very reliable alternative for all your mail and more.
Proton in some cases was forced to turn over whatever they knew of a few accounts, according to Swiss law. They try to obfuscate as much as possible, so they can't turn over complete e-mail conversations. But some info is in there, and they have to turn that over. But (correct me if I'm wrong) they have to only comply to Swiss law, when there's a court order.
I have uBlock installed, and it blocks these kinds of requests. However every request returns an error and they enter a constant request loop, causing the LinkedIn tab to slow down as the errors pile up after few minutes. Attached a screenshot [0] from DevTools.
Hand drawn pixel graphics heavily relied on the hardware's color palette (and monitor properties) for dithering and 'lighting' tricks, and especially the C64 color palette is quite 'exotic' and didn't have overlap with other home computers of the time. You need to consider that essentially each pixel was carefully placed by hand to 'enhance' the limitations of the builtin palette through color bleeding with the neighoring pixels on CRT monitors.
Automatic conversion of images between different hardware platforms usually stood out as looking quite poor and a sign of a 'sloppy port'.
You see that the C64 palette has a much more muted, pastel look and does not map one to one to the CGA/default EGA palette. C64 has a lot less vivid colors, but it also has much better luminosity ramps which can make dithering look a lot better.
In addition, the C64 has restrictions on the number of colors you can use in the same 8x8 block which I don't think EGA had.
It takes an artist to turn a CGA/EGA image into a C64 image.
I think the C64 palette you linked has been "tweaked" by the artist who uploaded it, this is probably closer to the original: https://www.c64-wiki.com/wiki/Color
But your point is still valid: while IBM PCs and other machines of the time had a propensity for "pure" colors (cyan, magenta etc. - so 100% for one or two of the basic colors and 0 for the others), the C64 designers opted for more muted colors.
On my screen that doesn't match videos of actual C64's on actual CRT's. (It also doesn't match my memory of them, but that's a whole lot less reliable)
Videos of actual C64's on actual CRT's are pretty consistent other than brightness, though, so if it doesn't at least somewhat match those, the model is broken.
I won't go over the details, but if you look at the website mentioned in the other thread from 2021, you'll see I'm not being hyperbolic.
EGA Loom is a work of art. VGA Loom misread the style and completely obliterated it, in its eagerness to deploy that early VGA "pillow shadow" style so typical of games of that era. (I love the term "pillow shadow", so apt now that I've learned it!).
Every nightly blue gone, light sources broken, every shadow gone, ominous deep-black tree shadows converted into gray/brownish things, etc.
To be clear, I think this is less a limitation of VGA and more a case of the conversion done lazily and/or by an inferior artist.
Hi, I’m the author of the article. Thanks for the feedback.
I cleaned up the shader code to make it easier to read/follow. If anything’s still unclear, feel free to comment on the post and I’ll try to clarify.
Would have been awesome if there was step by step visualization where simple color transforms slowly upgraded until you get final result for easier understanding of what each thing is doing.
Otherwise quite hard to visualize changes in you head.
Hi, I’m the author of the article. Thanks for the feedback.
I’ve pushed an update to the post with more implementation details, and I also cleaned up the shader code to make it easier to read/follow. If anything’s still unclear, feel free to comment on the post and I’ll try to clarify.
reply