Timeline for How do patches in games work?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 21, 2013 at 21:15 | vote | accept | MulletDevil | ||
| Feb 21, 2013 at 21:15 | vote | accept | MulletDevil | ||
| Feb 21, 2013 at 21:15 | |||||
| Oct 15, 2012 at 19:27 | comment | added | Sean Middleditch | @JonathanDickinson: please do. :) | |
| Oct 15, 2012 at 18:41 | vote | accept | MulletDevil | ||
| Oct 18, 2012 at 7:39 | |||||
| Oct 15, 2012 at 16:39 | comment | added | Jonathan Dickinson | @SeanMiddleditch I am going to do it just to prove it's possible :). | |
| Oct 15, 2012 at 15:53 | comment | added | Sean Middleditch | @JonathanDickinson: It's still nowhere close to "dirt easy" with .NET or Java, because again, even relatively simple fixes or new features can and often do change up whole sets of code and interfaces; you can rarely just replace a function or two except for the simplest of bug fixes. You will be replacing function calls, callers of functions, etc. And then with those languages, you can't just update functions, but also class metadata and the like. Oh, and possibly resign and recompress the binary. Again, cool idea, but a lot harder to pull off for real than it looks on paper. :) | |
| Oct 15, 2012 at 15:46 | history | edited | Jonathan Dickinson | CC BY-SA 3.0 | Added a disclaimer about EXE patching. Added emphasis to the final sentence. |
| Oct 15, 2012 at 15:44 | comment | added | Jonathan Dickinson | @SeanMiddleditch I will add a disclaimer about how impractical it is - it is still in the realm of possible though and does constitute a 'complete' answer. Also consider that this would be DIRT easy with something like a .Net Assembly or Java .class file - not all executable code is the same. | |
| Oct 15, 2012 at 1:04 | comment | added | Sean Middleditch | It is not that feasible to patch in individual methods in most games. The compiler can have rather drastically different output with even simple code changes. Automatic inlining decisions can change, symbol table layout can change, etc. Code changes also often change internal API structure. Optimizations already blur the line between function boundaries compared to what you see in your code editor. DRM systems also muddy the water greatly. Patch systems use wholesale replacement or binary diffs, and compress them. Anything like you suggest is simply too fragile to ship in the real world, imo. | |
| Oct 14, 2012 at 19:36 | comment | added | AturSams | That is very interesting. I suppose with bandwidth being what it is today, minimizing game patch size is not a major issue. +1 an interesting well thought out answer. | |
| Oct 14, 2012 at 19:30 | comment | added | Jonathan Dickinson | @ArthurWulfWhite yes. For an indie house probably not worth the time as it would take an extreme amount of time and effort (you essentially need to write your own linker) - as a company dealing with 'patching technology' exclusively it would be well worth the effort. It all depends on how large the executable code is - I took a quick look at Sacred 2 and it was 26mb (8mb for the main EXE). A binary diff might be able to get close to it though - still it's an idea worth putting out there (I know that CABs get good compression on EXEs because they take advantage of the structure). | |
| Oct 14, 2012 at 19:27 | comment | added | AturSams | What do you mean by package each method in an exe individually. Is that practical? | |
| Oct 14, 2012 at 19:25 | history | answered | Jonathan Dickinson | CC BY-SA 3.0 |