So the algorithm decided once more I might be interested in some videos. Examples
Older but related and worth knowing about for the upcoming stuff.
Speedrunning is not my thing, nor is game breaking per se. I can appreciate them well enough, and the technical side of tool assisted speedruns (TAS) speaks to something within me but the end results I am similarly indifferent to.
I watched a whole bunch of them though.
Watching a few of the speedrun history things a lot of things here appear to be done almost by accident, and the sonic one while not a presentation style I much care for had some interesting things to note. I am however a ROM hacker of some reasonable skills -- I was predicting what certain explanations would be from what I saw there, and nothing was new in concept to me. Beyond that fixing games is something I do (I tend not to involve myself in translations as much as bug fixes and improvements) and while I will seek to break a system when reviewing it I am not as good as there (the game breaking thing above was for an as yet unreleased game), and even if I never played dungeons and dragons if you give me some kind of stat system (even one with a ridiculous number of variables) I will attempt to min-max it. While there is doubtless an element of "everything is obvious once you know how" I am not going to write it off entirely as that. Most of what I have is based on memory.
Not especially related here but the sorts of things I also routinely read and contemplate, and will likely have some effect on things here at some level.
https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true
http://hciweb.usask.ca/uploads/332-aim-assist-cameraReady-v8-final.pdf
https://magic.wizards.com/en/articles/archive/duels-planeswalkers-all-about-ai-2014-02-13
https://www.dragonflycave.com/mechanics/gen-i-capturing
https://towardsdatascience.com/predicting-hit-video-games-with-ml-1341bd9b86b0 (completely unrelated but big data type methods do play a role in some things here, even more so as running thousands of simulations is essentially free where doing it in real life tends to make you one of history's greatest villains or people groups/empires).
3kliksphilip's series on counterstrike go bots and their navigation/behaviours
To that end I want to learn to think like some of those above, and probably take a more engineering/science approach to things -- coding in general already recognises a systematic approach to things, and indeed occasionally enshrines preventative measures to them as "safe" coding practices, languages and such. Some random stuff will still happen but I reckon more can be done here, be it in games or in a debugger, and a general approach formulated.
The aim of this then being to make maybe some kind of checklist or simple workflow one can use to break a game like those above do.
From the videos above (and those from the same channels -- for the history of speedruns the history of mario kart 64 has some good stuff) then much of that revolves around hitboxes, edges, odd behaviours with said edges, non standard animations changing effects (often again on said edges), technicalities with mechanics (the mario 64 speed variable being a good example), combinations of unique stat boosters, some kind of min-maxing (usually non obvious or against standard modes of play/human decency if it were real life), some kind of duplication glitch, some kind of hardcoded variable done to try to sort a problem but works to be exploited for another, can any created items be generated effectively infinitely from vendor items. Going further there was once a study done for Civilisation (can't find a link) where the first city is founded either in the first turn or the second (or maybe third) one after a scout does their bit... turns out in thousands of simulations that you really do want to found a town wherever you can that is best on the first turn. The vendor thing before also speaks to a further thing where a variable has a disproportionately large effect that you might be able to exploit by what looks like a minor tweak.
Some of this might take some unlearning -- one of the main tricks I do when it comes to ROM hacking is ask myself what I would do if I were the original dev in general, or based on what I already know, and then what approaches I might use to confirm or disprove that and otherwise learn what I want to know. I do however know many of the failings above and will try to mitigate them where, clearly, many devs do not.
Older but related and worth knowing about for the upcoming stuff.
Speedrunning is not my thing, nor is game breaking per se. I can appreciate them well enough, and the technical side of tool assisted speedruns (TAS) speaks to something within me but the end results I am similarly indifferent to.
I watched a whole bunch of them though.
Watching a few of the speedrun history things a lot of things here appear to be done almost by accident, and the sonic one while not a presentation style I much care for had some interesting things to note. I am however a ROM hacker of some reasonable skills -- I was predicting what certain explanations would be from what I saw there, and nothing was new in concept to me. Beyond that fixing games is something I do (I tend not to involve myself in translations as much as bug fixes and improvements) and while I will seek to break a system when reviewing it I am not as good as there (the game breaking thing above was for an as yet unreleased game), and even if I never played dungeons and dragons if you give me some kind of stat system (even one with a ridiculous number of variables) I will attempt to min-max it. While there is doubtless an element of "everything is obvious once you know how" I am not going to write it off entirely as that. Most of what I have is based on memory.
Not especially related here but the sorts of things I also routinely read and contemplate, and will likely have some effect on things here at some level.
https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true
http://hciweb.usask.ca/uploads/332-aim-assist-cameraReady-v8-final.pdf
https://magic.wizards.com/en/articles/archive/duels-planeswalkers-all-about-ai-2014-02-13
https://www.dragonflycave.com/mechanics/gen-i-capturing
https://towardsdatascience.com/predicting-hit-video-games-with-ml-1341bd9b86b0 (completely unrelated but big data type methods do play a role in some things here, even more so as running thousands of simulations is essentially free where doing it in real life tends to make you one of history's greatest villains or people groups/empires).
3kliksphilip's series on counterstrike go bots and their navigation/behaviours
To that end I want to learn to think like some of those above, and probably take a more engineering/science approach to things -- coding in general already recognises a systematic approach to things, and indeed occasionally enshrines preventative measures to them as "safe" coding practices, languages and such. Some random stuff will still happen but I reckon more can be done here, be it in games or in a debugger, and a general approach formulated.
The aim of this then being to make maybe some kind of checklist or simple workflow one can use to break a game like those above do.
From the videos above (and those from the same channels -- for the history of speedruns the history of mario kart 64 has some good stuff) then much of that revolves around hitboxes, edges, odd behaviours with said edges, non standard animations changing effects (often again on said edges), technicalities with mechanics (the mario 64 speed variable being a good example), combinations of unique stat boosters, some kind of min-maxing (usually non obvious or against standard modes of play/human decency if it were real life), some kind of duplication glitch, some kind of hardcoded variable done to try to sort a problem but works to be exploited for another, can any created items be generated effectively infinitely from vendor items. Going further there was once a study done for Civilisation (can't find a link) where the first city is founded either in the first turn or the second (or maybe third) one after a scout does their bit... turns out in thousands of simulations that you really do want to found a town wherever you can that is best on the first turn. The vendor thing before also speaks to a further thing where a variable has a disproportionately large effect that you might be able to exploit by what looks like a minor tweak.
Some of this might take some unlearning -- one of the main tricks I do when it comes to ROM hacking is ask myself what I would do if I were the original dev in general, or based on what I already know, and then what approaches I might use to confirm or disprove that and otherwise learn what I want to know. I do however know many of the failings above and will try to mitigate them where, clearly, many devs do not.
