/** * Kamefu DESIGN document. * By Michaël Larouche * * Version 0.1 * -Initial rought draft. */ This document present the basic design of Kamefu (KDE All-Machine Emulator Frontend for UNIX) and his dependencies (kfile_plugins). Content ------- 1. Application design 2. Architecture 1. Application design -------------- The main idea behind Kamefu is to manage a collections of ROMS from various systems. Also to serve as a frontend to differents systems which use differents emulators. Think amaroK but for your ROM collection :) Which means that Kamefu will be able to: -Build a collection manager based on ROM kfile_plugins you have installed on your system. -Display the collection mostly like amaroK does, allow to filter by various criteria like "Editor", "Year", "System" and "Genre". -Configure system and his emulator directory into Kamefu. -Handle list of your favorities (so called playlist in a audio/video application) -A little application like "kfmclient" that take a rom path in input and launch the required emulator for the system. GUI ideas: ---------- Display of a item: -Show a title screenshot and a game screenshot -Show information like the Editorm the Year, Genre and System. -Able to retrive Wikipedia Entry. -Has action button like "Launch Game", "Show Meta Information" (using KFileMetaInfoWidget) Front page: -Has item like "Select system", "Browse Collection", "Configure Kamefu", "Configure system." -Could be used to display "Play game from CDROM", "Play game from ISO image." for Playstation systems. Collection treeview: -Ripped(errr based ;) on amaroK Collection sidebar view. Statictic view: -Most played item -Recent additions. Generic Plugins ideas: ---------------------- -Plugin that advert in Kopete the current game played. 2. Architecture ------------ The architecture is loosely based on Kopete architecture. Services overview: ------------------ -Core library that create singleton manager classes and host the various base classes used in "plugins". -KFile plugins that retrive metadata from ROM images. -Collection builder that scan folders and build the collection database. -Collection access that update the listview based on specific filters like "Editor", "Year", "System", etc... -GameLauncher is a factory that creat the correct game launcher based on the system. Design problem I have to solve: How to handle differents emulators by system not hardcoded, I don't want to make emulator configuration in C++ neither hardcode the list of emulators by system. Factory(Manager) classes: -------- -GameLauncherManager -RomMetaDataFactory -PluginManager Base classes: ------------------- -GameLauncher -RomMetaData -System -Plugin Data class: ----------- -RomMetaInformation (for exchaging data between Collection Builder and Collection access) Game Launcher service: ---------------------- GameLauncherManager is a singleton class that handle emulator launching. The input is the full path of the ROM image to launch. Then the game launcher determine the mime type of the ROM Launcher and get the right derived GameLauncher for the system. The derived GameLauncher must handle User emulation configuration arguments that he setted in a GUI. Collection Builder service: ------------------- Collection Builder is the service that list a list of directories defined in a configuration file. After retriving the metadata, it adds the info to the database. During listing of all the files, if a file is a zip file, the collection builder uncompress the zip file to see if the zip file contains a ROM image. Using the temp file (unzipped), the Collection Builder will be able to retrive metadata from the file. For each file, Collection Builder should use a class obtained from RomMetaDataFactory. If no specific class is required, the RomMetaDataFactory will return the DefaultRomMetaData that read the metadata from KFileMetaInfo. This will be useful for exemple for the MAME system to use MAME database to retrive meta information. When it has retrived the meta information, it push the meta information to database using Collection Access service. Why RomMetaDataFactory ? ------------------------- Think first of all at MAME. MAME identify his game from zip files that contain Game data. For exemple windjammers.zip represent the game "WindJammmers" by Data East in 1994 on NeoGeo. MAME use a internal database to get that information. The derived RomMetaData class will retrive in MAME system plugin the meta information from MAME database then push it to the collection builder. Collection Access service: -------------------------- Collection Access handle creation, updating and query of the database used by Kamefu. For now I'm thiking using the KexiDB library for database access. The data class use to push and pull rom information is RomMetaInformation. System plugins -------------- System plugins represents a game system like a NES, SNES. System plugins mostly offert classes that will be used by core factory classes depending on the context. Context are like collection build and game launching. The system plugins handle what it's specific for each system. Each system plugin will register for mimetypes that the system support. (ex: application/x-rom-snes for SNES system.) Why retriving the MD5 hash ? ---------------------------- MD5 hash will be used later to identify good ROMS from a XML database. This will rename ROM image to their good name, get addition information like year, editor, genre.