I remember being away from home on business, bored stupid, and absolutely desperate for something to do. I had worked out already that day and could do no more good for my body. I ran out of work to do for the rest of the evening as well. I was doing my best to remain disciplined enough to stay on my lifter's diet so going to get food was out of the question. What I really wanted to do was sit back, chill out in my room, and play some 'Punch-Out!!'. Alas, my Nintendo stopped working roughly ten years prior to this particular business trip.
I was overcome by a wave of nostalgia, so I googled it and happened to run across a site that had the rom files. It took a while to piece together the critical information I needed to understand the relationship between Emulators and Roms; but when I got it, everything changed. I remember actually feeling rushed to grab all the old game files I used to have, as if their presence on the Internet was somehow a temporary thing. I remember also being f*ing pissed when I found out that the games I used to pay fifty to sixty dollars for each, would now fit five per on a single floppy disk...
More study revealed that virtually every system each had their own unique emulator and rom file type so there was virtually no way to change platforms without closing the program you were currently running. The bridge to this issue was solved through use of a frontend which was a program that could database your roms and capable of executing their respective emulators from a single interface. Sounds great I thought, but soon discovered it wasn't that simple.
I discovered that not all frontends are created equal. Some frontends only cover a specific field of consoles, others just arcade games, still others only laserdisks, etc. Some could launch games across a multi-platformed archive of emulators, but required complicated scripting lines be plugged into their programming lines in order to do so. I was and am still completely unqualified to do this. I attempted to correct this shortcoming by learning a couple programming languages. As it turns out, learning how to do this is much more complex then I had estimated at the time. There's been alot of money throw away on teach-yourself-how-to-program books in my household over the years, and I am ashamed at both the money wasted and my inability to pick the terminal learning objectives up naturally. After giving up for a couple years, I returned to my search for the perfect frontend again and found two new candidates. Sometimes you just gotta wait for technology to catch up with demand. Those two frontends were GameBase and Mala.
When I found Gamebase I thought for certain I had realized the answer to my needs. It supported multiple emulators with a manageable scripting language (at least the couple at the time I was planning for). It could support image files for game art and would display them whenever you settled the title selection bar over a game. It could launch .txt and .pdf files from its browser which could be useful if you wanted to keep files associated with the games instruction manual, walk-through, or code/password lists. It even could cue a music file when you selected a game which would be super annoying after a while, but still kicks-ass from a geeky gamer perspective. I was pretty happy with it altogether, until I discovered that it could not be skinned. The grey buttons and interface were too clunky and ugly for me to get past.
Eventually I found Mala, which I am currently using to build my database with. It also supports multiple emulation platforms through use of a simply defined list of presets which saves many of us non-programmers much anxiety in coding. It supports audio files I believe. I couldn't tell you for certain because I haven't fully explored that lane. I was sidetracked by the fact that Mala supports video files. I find this to be specifically awesome because I can tie in gameplay videos which will run a few moments after hovering over a title. Exactly like the old arcade games do when you let them idle. As far as I know it can't run .txt or .pdf files from the browser, but may not need to if I can figure out how to write my own .dat files which can be accessed by hitting the Alt key. It also can be skinned to appear however the user wishes which adds a level of professional packaging that solidifies its use for me.
So now that I've described what Mala can do, I guess I should describe how I intend on using it. Firstly, as I said before it supports multiple emulators. As far as I've tested the only emulator that it has had trouble executing and loading romsets is my Turbo Grafx 16 emulator 'Magic Engine'. That includes PC and MAME games as well. When opened Mala immediately returns the user to the last browsed Emulator game list opened with the cursor set on the last executed game title. From this point I can navigate between genres via directional keys and emulators via keybindings. Making this intuitive is all about managing the information available to the user at all times. Old Neo Geo cabinets plugged this information into their marquee art. I will do it with my frontend's browser. Luckily I can skin it...
Besides providing critical instructions to users on the browser, I'm obliged to also make it pretty and interesting with game art, box covers, screenshots, and original marquees and fliers. This part is deceptively difficult given the magnitude of the project.
For example:
My estimated number for total, complete, working publicly available MAME titles (not including the XX console emulators {each with hundreds of titles} and PC games {maybe a hundred titles} being plugged into the cabinet) is somewhere in the vicinity of four thousand. I do not want to play all of those titles so I have to determine which ones I want to include. Aside the different world-released versions I typically have to go through this list one at a time (the resources I found to do this task will be available in the link section).
For efficiency sake, while I'm determining which titles I want to include in my database, I'm also downloading and consolidating each games individual associated media. In the case of MAME games, this is almost simple because all the marquees, title screenshots, and fliers are co-located on a single page and are already pre-named identical conventions for the frontend to build relationships to. However, I will still have to generate a video for each of these games using either YouTube or some type of screen recording software for each game and ensure it is named exactly the same thing as its partner rom's media so it can be recognized.
Other consoles are more difficult in this regard, because all their media is spread out (if available at all) across multiple sites. When I'm working on these databases its not uncommon for me to be multi-tasking downloads across six separate browser tabs trying to find it all. By the way, my multi-tasking skills are no greater than an infant's. I can not explain this, but am sorely jealous of those people who excel at this remarkable talent.

For the MAME games there are .dat files available in consolidated zip archives containing hundreds of games each that contain game history and information. I have to download these archives, and remove the excess files I don't need (these files just clutter up hard drives, removing them is a unnecessary but wanted step considering I don't have a clear idea how much room this entire project will cost me). I will also have to write new .dat files for the consoles which will likely consist of a consolidation of data from a wiki game search, a pre-written open-source FAQ or walkthrough, and a strategy/cheat/code/password document. All of that data will be located on separate sites.
I discovered early on, that I would need to catalog these titles in a logical fashion, in order to simple be able to tell whether or not I had a complete roster of the games I wanted to play and their associated media. I needed to find complete game lists for game platform so I could know what to look for, and I needed to track what media I had already consolidated, produced or otherwise passed on for later work. Stopping what I was doing during my downloading efforts, to create unsupported artwork was counterproductive to time management during after-duty hours. So I created a excel document to track all these titles and media files. This file is somewhat of a digital logbook to carry on my efforts across work-periods and allows me to annotate a alphabetical location restart my efforts once time becomes available again.
That example I hope gives you a better understanding of the insanity of this database project. In a way, I'm developing a library of information on these games; only the library will consist of books that were re-assembled from torn apart, non-matching copies of original releases. That's probably not the best use of literary imagery, but I hope it at least illustrates part of my meaning.