New gamebase engine under development

[Jimbo]

Hi

Just a note to say I've started a new GameBase engine in .net.

Initially I am starting out by writing a library that will convert existing gamebase databases into, and interact with, a new database format in SQLite.

There will be 2 database files, a "master" db, and a "user" db. User data will be kept in the user db (such as personal prefs for each game, favourite, difficulty, rating, highscore, etc). This way new master databases can be released to everyone far easier (just replace a single file in your GB folder).

The plan is to also replace Gemus with a recognised scripting language (e.g. javascript, lua or something) with bindings to the functions that set ini values, run emulators etc.

Also the new database format is open-ended, so you can create all the tables and fields you want for your specific gamebase.

I'll keep you posted here... I expect it to take a few months!

Once it's at a decent enough point, I'll release on github for those that want to play (to potentially write a frontend/interface with it). If you're interested, let me know. I already have one friend who will write a frontend for it.

James

[Retroplay]

So, Linux users will be able to run this in Mono ?

If that's the case, Yippie, no more jGameBase for me.

[.mad.]

WOW!
i can't wait to see the first beta.
try and keep GEMUS replacement very simple.
That's the reason why we love and use GameBase.

i would like to see a few new features.

editable bitmap fixed font 8x8 would be cool.

then any c64 /nes / msx system font could be used in the frontend looking pixel sharp.

D64 images with heavily edited directories.
The runnable file can not be selected for a few demos.
if a name in the DIR is "" (double quote)
which on a pc would be just '.prg' (extension only)
not sure if it possible though.

[Jimbo]

So, Linux users will be able to run this in Mono ?

If that's the case, Yippie, no more jGameBase for me.

That's the plan.

[Jimbo]

WOW!
i can't wait to see the first beta.
try and keep GEMUS replacement very simple.
That's the reason why we love and use GameBase.

i would like to see a few new features.

editable bitmap fixed font 8x8 would be cool.

then any c64 /nes / msx system font could be used in the frontend looking pixel sharp.

D64 images with heavily edited directories.
The runnable file can not be selected for a few demos.
if a name in the DIR is "" (double quote)
which on a pc would be just '.prg' (extension only)
not sure if it possible though.

Gemus replacement will remain simple. And any existing scripts will be converted to the new format.

Any "frontend" stuff like fonts etc will not be part of this library but part of the/a frontend that uses it.

To be clear, I am writing a library... I do not have existing plans to write a frontend myself that uses it, however a friend of mine has committed to writing one... but it needn't be the only one.

Cheers

[Retroplay]

That's the plan.

Thank you, thank you & thank you.

[Jimbo]

Update #1: -

So I've been working a bit the last few weeks on the new GameBase engine library in .NET (c#). It's coming along well so I thought I'd give a status update on here.

First, here's a bit more information on what this library is going to do, that the current GameBase doesn't (or does, but not very well).

Database will be SQLite, not MS Access MDB...
This is mainly for cross-platform accessibility. Yes, I'm writing a C# library to interface to it, but there's nothing stopping someone else writing another one in c++, java, ios, whatever. SQLite has its plus points in that it's very easy to use, but it does have its drawbacks too (very limited ALTER TABLE syntax, for example). However... SQLite does give one really nice feature, which means...

The Database will be split into 2 files...
The "master" and the "user" databases (e.g. gb64.master.db and gb64.user.gb). The "master" database will contain all the game info etc that will be distributed with an update. The "user" database will contain all your personal preferences (highscores, peronal ratings, favourites, personal comments etc). This means when a new database is released (e.g. GB64 v 50) all you'll have to do is replace your gb64.master.db with the new one. There are other benefits to this, for example (in the future) you could send your user database to the master db maintainer, and they could import data from it.

GEMUS will be replaced with a javascript engine.
This makes it much easier to write scripts and introduce more functionality as time goes on (and I don't have to write my own parser ). Existing gemus scripts will be converted to the new format.

You will be able to choose your own database structure...
With the current GameBase, you can rename tables and fields, but you're limited to a specific set/number of them. With the new engine, you can create tables and fields however you want. You want a genres table? Create one. You want 3 levels of heirarchy in the genres table... add them. You want to link many separate programmers to a game instead of just one? Configure it that way. You want a games collection, a music collection and a demos collection in the same database? Create them.

You'll be able to link many files to each "game"...
Game files, music files, screenshots, videos, covers, scans, docs, etc. There are no limits in the new engine, you decide what you want to have linked to each "item" in your collection when you set your database up, and what to call them. Also, more info can be stored per file, such as a title, description, comment etc.

So that's a little overview of some of things being worked on. Here's where I'm currently at: -

I've got the API written to create and manipulate the "list" tables (those like publishers, genres, programmers, years, etc)... the stuff that games link to. I've got this to a point where I can use this API to import all the current list tables from the existing gamebase mdb database to the new sqlite format. So I'm currently writing an MDB database converter tool that serves as a great testbed for the API, and it's working well so far. You can create plain lists (e.g. publishers) or heirarchical ones (e.g. Genres with sub-genres). You can also modify these tables, add rows, edit rows, delete rows, same with fields. Basically the API is there now to completely configure the List tables that you want in your database.

I've also written a basic "ViewMaker" as part of the API which will return a "view" (i.e. a list of records from 1 or more tables, with one or more filters on them) to display in a frontend.

Bear in mind this is just an API at the moment, but any .NET developer should EASILY be able to write a nice frontend for this (once it's done!) by just doing the UI stuff, and calling functions in the API. There is already a friend of mine who has promised to write a frontend but if anyone else is interested in making one as I continue to write the library, PM me and we'll talk. The library will be going up on github at some point during it's development.

That's it for now. Stay tuned...

[.mad.]

I'm currently writing an MDB database converter tool that serves as a great testbed for the API, and it's working well so far.

This is an absolute must for me.
I use MS Access to paste all my Gamebase entries in one hit.

Good to know i can still make a NEW Gamebase in the same OLD way and convert it. If i can not get my head around SQL.

[Jimbo]

You won't need to get your head around SQL

At the very worst case, you'll be able to use http://sqlitebrowser.org/

[K.C.]

Good to hear James, looking forward to a Gamebase replacement!

I'm currently writing an MDB database converter tool that serves as a great testbed for the API, and it's working well so far.

This is an absolute must for me.
I use MS Access to paste all my Gamebase entries in one hit.

Good to know i can still make a NEW Gamebase in the same OLD way and convert it. If i can not get my head around SQL.

I understand your concerns. For Introbase, I have a master Excel spreadsheet that I use to generate the Gamebase database (import Excel sheet from Access).
If there will be a conversion tool, you can still develop MDB-based collections and convert them to the new format.
At the other side, new features cannot be used (like a custom number of nested genres), as the current Gamebase frontend will not be updated (I assume).

Jimbo, I'm not sure if this is a Frontend- or Library-thing, but this should be a nice feature for the new frontend:
In the current frontend, you can specify one or more folders for games, screenshots, music files and extras.
If you also can select an ISO file, and the frontend is capable of mounting and using it (without using drive letters), for a lot of Gamebase collections, you don't have to copy hundreds of thousands of files to your file system.
Eventually you can add a 'real' folder (mandatory or optional) for supporting addition of new games/screenshots/extras.

[freenit]

Hi Jimbo , I am very happy that finally someone is working on a new frontend... but my question is if it will have support for video, meaning that when you select a game a video is displayed automatically , and can choose more than one video for each game ...
Have you seen other frontends like HyperSpin?
I think to have videos is awesome.
Thanks for your work.
Greetings.

[Seiya]

maybe support animated gif or small animation for default "no_picture" (animated gif, quicktime)

[Jimbo]

Update #2: -

It's been a bit slow since the birth of my 3rd child but things *have* progressed a little...

The main thing being it's been re-factored so there is no longer only a "master" and a "user" database. Instead there is a "master", and then as many "add on" databases as you want (one will be the "user" database with your personal data). This makes it more flexible for people to easily add their own data to an existing gamebase without actually modifying the distributed master version. It also means these add-on databases will be dead easy to share amongst other gamebase users.

Also, (and you will either love or hate this), but the name for the library is now...

[slug]base

Reasoning being it's not just for games, but really the library could cope with any arbitrary data (demos, apps, utils, movies, etc.). I also like the word 'slug' Of course, the actual frontend can be called differently, and your databases can still be called gamebases, demobases, appbases, etc. It's a more generic library for these kind of databases, so I think the name fits.

Thats all for now!

James

p.s. oh, and I'll look into the ISO thing, K.C.. The other requests are all frontend based, but there's no reason why they can't be built in. Video is a staple requirement these days!

[taulore]

Just spotted this one and had a good read through.

Jimbo, I'm glad to see you are back at it and creating another frontend for our beloved Gamebases etc.

I like the fact that you are moving on from Access based databases. Access doesn't handle databases over 1GB very well and what with the ever expanding uses that Gamebase has been used for, this may become an issue in the future.

I find it exciting that you will be able to add databases to the system and that you have the ability to change the structure of said databases by linking multiple fields.

My fear though, is that the frontend will become less user friendly. There are other frontends out there and I have used most. But GB has always been my frontend of choice as everything that I require is there in front of me. I don't have to open another window to view graphics or read rom information. It may not have all the features that others have but it is the most accessible.

[Jimbo]

Thanks, I'll be trying to keep that accessibility in the new version, as much as possible!