News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Yu-gi-oh! World Championship 2011 Over The Nexus. Fixing all the bugs  (Read 2127 times)


  • Newbie
  • *
  • Posts: 1
    • View Profile
Hi guys, newcomer here!
With the start of the quarantine, I started to play yu gi oh on my old nds(r4) purely for nostalgia. I really like deckbuilding, and I was playtesting a vylon deck until I noticed one of the most important combos of the archetype can't be reproduced in-game.
Why? Because of a bug.
In-game it misses the timing. A thing that shouldn't happen normally.

Decided to enjoy the game to its fullest, I want to fix as many bugs as possible reported on the wiki of the game.

I know some basic C programming skills and programs needed for this task, but, once opened the code of the game, I don't know what parts do I have to modify.

There aren't videos on yt that explore the backbone of a world championship game as much as I do. How can I start to better know the datas of the game? Thank you in advance.  :)


  • Hero Member
  • *****
  • Posts: 2759
    • View Profile
Re: Yu-gi-oh! World Championship 2011 Over The Nexus. Fixing all the bugs
« Reply #1 on: April 03, 2020, 03:59:42 pm »
As ever I have to preface this sort of thing with a note that collectible card game AI is one of the harder problems in computing ( ) and as such messing with things too much will break it. This is also why you tend not to see many hacks for things.

This kind of bug fixing might also be jumping in somewhat at the deep end. If it was tweaking stats, basic stats handling, text, animations or colours of graphics then that is one thing but you are striking right at the heart of the game's logic. This means big boy assembly coding right from the start -- hardcoding a cheat can be learned reasonably quickly, as can basic stats manipulation, but this involves finding, understanding and ultimately changing program flow. I don't know if you learned some assembly as part of C (they often start there or soon go there to give the new coders some idea of what is going on underneath it all) but it is usually a lot of very simple steps to make up a complex function that you might be able to describe in maths and series of worded statements in a few seconds/lines (not for the DS but covers some for the PC, for the GBA which is similar enough to the DS I suggest ). If you want an example of how bitty it gets then where in C you might think nothing of sticking an int in memory the little ARM processors can't do a simple mov of a 32 bit value into a register (you need some bits to be the instruction after all) so it could be a several step affair involving putting part of it in, doing a shift and then adding a value to count for the bottom part of the number; if you are coding on a big boy assembler like the devs used then maybe it would have a simple macro to handle it for you but if you are looking at code as it appears from the end stage game, or doing it manually you might have to handle the lot.

Most CCGs will have a limited number of effects they use, and mix and match them and play cost to try to make a balanced game (at least before power creep but we will skip that one). However if something is truly unique it will typically handle it separately.

You then get to figure out how the game handles what you want, and then how to fix it which might be simple enough if it is something simple the dev missed (used greater than rather than less than sort of thing, or even greater than rather than greater than or equal to) or might involve expanding the code to add some new behaviours in which itself is its own problem*.

*for the DS I usually note that DS game binaries have lots of space given over to strings in various languages for all the weird and wonderful error codes that internet play might have had (assuming it is a game with internet functionality). You can jump to this space (which is likely always there in memory rather than loaded in as necessary).

Anyway step one is to get yourself a debugger. no$gba's one is almost certainly the best one going unless you are super hot on GDB and in that case desmume might get more done for you if you can get it to speak to it.
Get yourself to a point in a game where you will be able to observe the behaviour in question; if you have to cheat to put certain cards in your hand and give yourself infinite life and whatnot then do it to it, hopefully cheats already exist but if you can't make such a thing yourself then you are going to have a really hard time with this. I would be surprised if the game does some kind of branching prediction where it guesses behaviours beforehand and then runs through the animations (home console or PC I would not be but DS I would be) but that would just mean you go back further to plant your savestate.
Now you get to play debugger. If you had infinite time you would change the game to running instruction by instruction and step through all of them until you reach the end of what you want, and find as well as what you want you have an intimate understanding of how there is a little graphical flash, audio clip and maybe some nice animation. To that end you probably want to find something you can see changed or read (life, attack points, def points...) and latch onto that with a breakpoint (be it a bpw or break on write, bpr or break on read (say it reads the attack to know what it will do against something else), or maybe bpe or break on execute a bit further down the line).
The good stuff might have occurred before your breakpoint was hit but most times they have the 5 instructions or so before it and thus you can work backwards from there until you find what you want. If it occurs after whatever you find then back to stepping through each instruction one at time, or maybe allowing it to "run to here" where you reckon you know what is happening for the next few instructions (say it needs to count to 99 for some reason and you don't want to watch +1 and less than then +1 however many times that takes) and only need to come back in when it is past that point.
If you have to you can also start from a button press (buttons go directly to memory, and possibly then onto a debounce section for the game to use for the next frame lest the mechanical behaviours of buttons cause weirdness) and see what goes on from there, but again lots of probably redundant behaviour.

Hopefully you find what was coded wrongly, or where you can insert some code to do something else, and then do it. Such a thing might involve a lot of code and further understanding of the game engine (I see some of the effects on that link involve looking at the used card graveyard**), though probably nothing that is harder than more exotic cheat search.

**if you have to do a graphical selection of things there might be something else in the game that looks through the graveyard and provides the user a chance to look. See if you can use that before you code your own.

Have fun.