Best means to go about structuring data when making a hacking utility?

Discussion in 'Technical Discussion' started by Travelsonic, Feb 1, 2019.

  1. Travelsonic


    For a while I have been reverse engineering (or rather, trying to anyways) Konami's DDR series. I feel like I have enough information where I can make a multipurpose utility (think equivalent to what GerbilSoft's Sonic Hacking Wiz Pro, or Esrael's ESE/ESEII was for Sonic games in the early-mid 2000s ... *nostalgic sigh* ... only for the Playstation2 DDR mixes).

    One thing that I am struggling with is the best way to handle/manage the data for different games, as this utility will support multiple games starting with support for Playstation2 games. My problem comes specifically with managing the different places where the editor will look for data to edit within different parts of the program (coordinates for object positioning, color palettes for songwheel slot text on the music select screen, etc), Playstation2 games pre-SuperNOVA using largely the same engine only with data in different addresses (and features being added and / or removed in different mixes - beginner mode added to the U.S version of MAX2, Marvelous timing added in EXTREME, etc), SuperNOVA seeming to use a newer version of the engine. Also, EVENTUALLY (as my research continues) I would like to add support for Playstation1 mixes, and older arcade mixes (bemani system573 games)

    I feel overwhelmed, and I probably shouldn't be. ~_~
  2. van0014


    The first thought that comes to mind is using an array of addresses for each game. The array index would be used to select an address, independently of the data type. That means having one array per game, and choosing between arrays when the game is changed. A 2D array could be used for keeping information on the expected data length, or for other handy reasons.

    What IDE will you use?
  3. Billy


    RIP Oderus Urungus Member
    Colorado, USA
    Indie games
    Assuming you're writing this in an object oriented language, I would suggest using a bridge design pattern, so as to swap out implementation for each game you support.
  4. Travelsonic



    For something like a filedata table extractor that I have made, I did exactly this, and as solutions go, for those cases, it works fine.

    Problem for me is that I feel like there will be a lot of data being categorized (addresses for positioning for various elements, addresses for data loads, addresses for SFX indexes, and categories for various addresses in each group (attract screen related, menu related, in game / song related, etc) , not sure if I want to turn my program into a proverbial DBMS (Database Management System) (especially if there are routes to keep the data external to the program (and just collected/managed by the program), which would allow for users to customize the program in so far as adding support for games I may have not added out of the box support for). (Even though database design/architecture seems to be a strong suit of mine :P )

    I am using Visual Studio 2017, and am coding this in C#.

    I am definitely looking into this.