Experiences with GameBase (Amiga), other frontends and MAGE feature requests

[eLowar]

I am creating this thread in an effort to get some feedback about GameBase Amiga and some idea about what actual users of it and/or other frontends/databases are thinking and/or would like to see in the future.

About MAGE: As already said in a different thread, MAGE will replace the GameBase in GameBase Amiga in the not too far future. As a little bit of extra information: it will be a multi-platform frontend like GameBase.

To give some discussion points:

• What do you think about frontends in general?
• What frontend(s) do you use, if any?
• What do you like about it/them? What do you dislike?
• What would you really like to see in future frontends/versions?
• ...

This is, here, mostly about Amiga (and especially WinUAE) frontends, but feel free to also comment about other platforms.

[Retro-Nerd]

I use the Gamebase frontend since 5 years and i like it for his scriptbased settings. As example it allows me to make "per game" settings, a very comfortable feature.

A new frontend should have all gamebase features as well. But the "Game Details" were made for the C-64. There is no use for "Gamelength" or "Sid" entries when you want to setup a database for a console. An internal textviewer for manuals, walkthroughs ..., maybe like in mame for the history.dat & mameinfo.dat would be nice. And a better pictureviewer for the boxscans & other extras should be there.

GameEX looks very nice, but is a bit to slow.

http://tomspeirs.com/gameex/Includes/..%5CImages/9.jpg

http://tomspeirs.com/gameex/Includes/..%5CImages/16.jpg

[Marcuz]

i use gamebase for atari st only, so far, as i do not like to have to rename or rebuild a dat collection with the gamebase used name format, one way it nullify your preesistent game' configurations, or disturbs your tosec collection, the other way you need GBs of hard disk eaten away by dupes with a different name. but that's the way gamebase works alas!
(however, to how many GBs amount the current complete gamebase amiga dat?)
i use Lemonade for quick amiga game.
Lemonade pros:
1) scan of the actual tosec directory, no different dats needed
2) compact GUI
3) built-in update
4) nice colourful GUI
Lemonade cons:
1) crappy search function; for instance if you want to see all the 2 players games, you first need to find one of them, then select the hypertext function. if there's another way, it is not apparent.
also if you want to use the built-in wildcards, like "genre" you have actually to type the genre in the field, and i'm not sure how many there are the same goes for "publisher" etc.
2) crappy configuration system: you cannot for instance choose a custom screen resolution for fullscreen if you don't go text edit the configuration database (at least i think you can there, still haven't tryied)
the same goes if you want to batch configure or group configure the games. heck you cannot do any group. also i do not have edited much but i guess that when the database gets updated, the personal settings get overwritten.

i may be unprecise, but it's of little consequence, i point these things as stuff that should be considered in Mage if you want, and not as a betatesting of Lemonade. this take me to another point, the more open the community supporting a program, the better it gets.

[edit]i was pointed to GameLauncher (http://www.dribin.org/dave/game_launcher/) from Gameex site (cool looking that too but i think it's sluggish on my pc): sorry for the kinda OT but is it any good? i think it is far from what's the goal here, but who knows? if you come up with a nice idea for the GUI, i would not mind to see something like that: no apparent search functions or settings, that may be recalled from menu, cool looking fonts, graphic intensive. however, just an idea.
you see, what's i think it's a good thing of lemonade, the only one relly that pushes me to use it instead of the quicklunh of winuae, is that it's a fire and forget kind of solution: like when i had the amiga there, forget about the workbench, grabbed a nice disk from a colourful box, inserted and fired up and voilà! it was like the consoles only better. winuae, as good as it is, it is (to me) too slow to give me the kind of enthusiasm i had in that simple thing. and i use it since 1997 in one form or the other! just my 2 cents.

[eLowar]

Nothing emulator frontend/game database related is really off-topic here and all ideas/thoughts are welcome and will be taken into consideration (as far as possible of course). Keep 'em coming.

[Marcuz]

Originally Posted by eLowar

Nothing emulator frontend/game database related is really off-topic here and all ideas/thoughts are welcome and will be taken into consideration (as far as possible of course). Keep 'em coming.

hey mate, sure i know you guys are open minded, i wasn't forcing that point up there, just saying that as a general tought, but you know that... i love this community

[Belgarath]

Marco, GBST wouldn't work with the tosec ST collection either, so if you had a tosec st collection it would be useless.

And although I don't think HD space is much of a problem these days, once you scan using the dats (making sure you don't remove rebuilt files so as to leave your tosec directory intact), you can then quite happily burn the lot to DVD, GameBase will quite happily load all the games/pics/music/extras from a DVD as long as you specify the paths.

[Marcuz]

Belgarath, about the ST, of course you are right, i was just lucky enough to find me a whole set already renamed to download some month ago.

about the burning: yeah, that would be a solution but i'll have to update the pc tough; so far my 5 years old AthlonXP 1800 @1500Mhz, 512 MB ram, without dvd burner is more than enough even for working with photoshop! but if i can i'll update nevertheless this year.

[eLowar]

In the spirit of leaking information and to provide some peace of mind, while Belgarath raises some valid points, this problem has already been considered and there will be alternative solutions. A bunch of details are already worked out, but I shall say no more.

[Marcuz]

i expected to see much more input from people... so i give it a second run.
as mage is apt to be used (i know, LATER) as a more generic frontend, i think some study should be applied on the way paths of the frontend are used: Gamebase, for instance, sees the various dirs called arbitrarily by the particular emulation it's going to serve. so for the commodore 64 you have an EXTRAS dir whych contains subdirs that you'll have to explore with a menu on the EXTRAS button; it may contain images, other disks, music etc. gamebase amiga too it does, and in the extras you see SPS games. so pretty much disorganized. (but possibly you, eLowar, are already working on this)
i, for one, would prefer for instance to see all the accessory content added in the tabbed interface of gamebase, maybe with a more efficent structuration.
i would also like to have disabled by default the "sproing" sound that the compiler of the database adds to his favourite games.
more interaction with the emulators would be even better. for instance, c64 again: why not a button that forces the emulator to make an empty disk to be used as savedisk etc? some emulator has not the capability to do that (but i also don't know much of commodore emulation).
most of all what i feel it lacks is a better administration of input controllers and of remaps of keys. why should one do it painfully inside the emulator?

[eLowar]

Indeed, most of these issues have been discussed before. I'll have to rethink the general Extras thing. Here is how running games works, though:

Each game has a list of available versions. The user can set priorities for each version. So for example you could say "run HDF if available, if not, run cracked ADF, if that's not available/not set up, run SPS", that kind of thing. Likewise you can give priorities to emulators (if there are more than one) and you can choose what to give higher priority, the preferred emulator or the preferred version (in case of a conflict, like your preferred version is not available for your preferred emulator, etc.). You can also pick the version/emulator manually if you want to, of course.

Edit: Oh and, I've probably said this before, but no matter, yes, there will be better support for user settings.

[Marcuz]

ok then listen this one what if the databases were managed as modules? there is a master database that comes with the official releases and it is unmodifiable and then slaves/modular ones in wich you can store your additional games or else the master one is modyfiable but you cannot add games to it?
also you could release multiple masters this way for each additional official release, and each one has new games' configurations, so for instance, instead of download the 4 CD release of GBC64 (when it will be available) you would download only additional content (1/4 of the stuff)

[eLowar]

Originally Posted by marco pedrana

ok then listen this one what if the databases were managed as modules? there is a master database that comes with the official releases and it is unmodifiable and then slaves/modular ones in wich you can store your additional games or else the master one is modyfiable but you cannot add games to it?

Actually, the way I'm doing it right now, a copy of the official database is stored in the user's profile along with extra user data. That copy can be updated with a new official release. Would that cover about what you meant? In "database developer" mode you can also add/remove games, in normal "user" mode you can only edit user data (personal favorites and such).

Originally Posted by marco pedrana

also you could release multiple masters this way for each additional official release, and each one has new games' configurations, so for instance, instead of download the 4 CD release of GBC64 (when it will be available) you would download only additional content (1/4 of the stuff)

I'm not sure I see a point in that. The database itself is small (so no point in breaking it up really) and files that aren't available just won't run, so the files are modular anyways (are already with GameBase Amiga).

[Marcuz]

the first thing: yeah it works to me
the second: i guess it's more about how the pakcs of additional stuff are distributed than a gamebase problem, and yes gamebase amiga is already ok about it.

I am the author of GamebaseST, as Belgarath will know, and would like to take this oppuntinity to wish you all the best with MAGE!

When developing the ST version there was quite a few things that I wished where better:

The ability to add Programmers,Graphic Artists, and other individuals who had a hand in the making of a game. Gamebase is severely limited in this respect with GamebaseST only able to use Publisher and Developer fields.

Many games where also published by more than one publisher, for example Defender of the Crown was published by Cinemaware in the USA, UBI Soft in France, and Mirror Soft in the rest of the world. However, there is limited space to put this in the current Gamebase, and if you do manage the interface just looks cluttered.

I always thought it would be neat if Animated GIF's where supported, and an absolute needed feature is support for different size screenshots. This is urgently needed for the Amiga since many games where developed to use 320x256, or even highter if overscan is used, not to mention any high res games. Gamebase only supports 320x200 which is severly limiting even for the Atari ST!

The music section of Gamebase is the biggest hangover from Gamebase's C64 roots. It would be great to see this have some kind of overhaul with MAGE supporting MOD's, Mp3's, and dare I mention the Atari ST's own format, SNDH files. Maybe MAGE can extract the header information from these files and display it in the database.

A splash of colour wouldn't harm MAGE either but it should be user-defined if possible. I'm not really a fan of Walt Dinsey coloured interfaces but ever since Lemonade came out it is something that I have heard over and over again.

OK that about it for now! But before I get crucified for liking the ST I should mention I love the Amiga just as much. I spent a lot of my youth on both machines and even wrote demos and educational software on the Amiga!

[Marcuz]

hay, i take the chance to thank you for GamebaseST, as limited as you put it, it's the thing that made me go nearer the Atari machines, and i do not regret it; GamebaseST is a fantastic effort!

[eLowar]

Originally Posted by Goldrunner

I am the author of GamebaseST, as Belgarath will know, and would like to take this oppuntinity to wish you all the best with MAGE!

When developing the ST version there was quite a few things that I wished where better:

Thanks, we've actually been waiting for your feedback.

Originally Posted by Goldrunner

The ability to add Programmers,Graphic Artists, and other individuals who had a hand in the making of a game. Gamebase is severely limited in this respect with GamebaseST only able to use Publisher and Developer fields.

Many games where also published by more than one publisher, for example Defender of the Crown was published by Cinemaware in the USA, UBI Soft in France, and Mirror Soft in the rest of the world. However, there is limited space to put this in the current Gamebase, and if you do manage the interface just looks cluttered.

The database structure will be completely defined by the database and complex objects (like nested dictionaries and lists) will be allowed as values. I hope that will solve all the flexibility problems with GameBase.

Originally Posted by Goldrunner

I always thought it would be neat if Animated GIF's where supported, and an absolute needed feature is support for different size screenshots. This is urgently needed for the Amiga since many games where developed to use 320x256, or even highter if overscan is used, not to mention any high res games. Gamebase only supports 320x200 which is severly limiting even for the Atari ST!

I am glad to report that animated GIFs are already supported and of course different screenshot sizes are a must, for the Amiga just as well.

Originally Posted by Goldrunner

The music section of Gamebase is the biggest hangover from Gamebase's C64 roots. It would be great to see this have some kind of overhaul with MAGE supporting MOD's, Mp3's, and dare I mention the Atari ST's own format, SNDH files. Maybe MAGE can extract the header information from these files and display it in the database.

Well... There will be a plug-in system and I'm planning on adding a music player plug-in early on. For mod-support I'm currently looking into porting (as the first release of MAGE will be for Windows) and embedding (that is, actually, interfacing with) UADE. I'm not sure how much ST stuff that covers, I don't know too much about the internals. If you can suggest a library or available player that is easy to remote control, please by all means feel free to mention it.

Originally Posted by Goldrunner

A splash of colour wouldn't harm MAGE either but it should be user-defined if possible. I'm not really a fan of Walt Dinsey coloured interfaces but ever since Lemonade came out it is something that I have heard over and over again.

Theme support is built in (that is the shape, colors and fonts of buttons, etc. can be changed; shape changes can only be done through plug-ins, color changes can be configured easily by the end user). Skin support is planned, but I'm not entirely sure how far I want to take it yet. For now arbitrary window frames (probably with binary transparency, but not alpha transparency) are as far as I'll go.

Originally Posted by Goldrunner

OK that about it for now! But before I get crucified for liking the ST I should mention I love the Amiga just as much. I spent a lot of my youth on both machines and even wrote demos and educational software on the Amiga!

No crucification in this forum. It must be somewhere in the rules... hmm... doesn't look like it... strange, well... don't worry, we're all civilized and stuff.

GamebaseST as been in development now for over two year and the main reason for that is that it trys to prserve these games also.

For example, we scan everything from games, box, disks, manuals, etc. At this point we currently have the biggest collection of 16-bit PDF manuals ever assembled (over 500). I mention this mainly because about 3/4 of these manuals are exactly the same as the Amiga one, with the both machines mentioned in the manuals. GamebaseAmiga (or whatever it will be called) is welcome to use these for its database if needed.

Currently we have a cracked game listed in the database along with the original (in pasti fromat). This means two entries in the database for one game, one cracked and one original. It's works OK, but really there should be just one entry with the user easily able to see both are included. No idea how you intend to get around using mutiple images of the same game, but each of these entries should (maybe) have their own information in the database.

It would also be idea to have more note pages for showing such things as cheats, intersting factoids, walthroughs, etc. We got around this by using the extras section but it would be better if things like this (that are used over and over again) had there own pages.

Now comes one of the things I hate most about Gamebase, namely only being able to display two columms in the main database window. Two might have been OK for people with limited display areas but the option to show 3,4, or more fields as columns in the main scrollable window would be a massive improvement.

[eLowar]

Originally Posted by Goldrunner

GamebaseST as been in development now for over two year and the main reason for that is that it trys to prserve these games also.

For example, we scan everything from games, box, disks, manuals, etc. At this point we currently have the biggest collection of 16-bit PDF manuals ever assembled (over 500). I mention this mainly because about 3/4 of these manuals are exactly the same as the Amiga one, with the both machines mentioned in the manuals. GamebaseAmiga (or whatever it will be called) is welcome to use these for its database if needed.

Hmm, Belgarath is responsible for GameBase Amiga (the actual database), he's been busy with real life (or something) these days, but I'll let him know unless he already sees it here anyways. I doubt I'll be building in PDF viewing (although that could be done by means of GhostScript), more likely I'll suggest using a small standalone viewer like Foxit PDF Viewer (which I personally use a lot) to associate with PDF files in MAGE.

Originally Posted by Goldrunner

Currently we have a cracked game listed in the database along with the original (in pasti fromat). This means two entries in the database for one game, one cracked and one original. It's works OK, but really there should be just one entry with the user easily able to see both are included. No idea how you intend to get around using mutiple images of the same game, but each of these entries should (maybe) have their own information in the database.

Here's something I said about the subject before (see above):

Originally Posted by eLowar

Each game has a list of available versions. The user can set priorities for each version. So for example you could say "run HDF if available, if not, run cracked ADF, if that's not available/not set up, run SPS", that kind of thing. Likewise you can give priorities to emulators (if there are more than one) and you can choose what to give higher priority, the preferred emulator or the preferred version (in case of a conflict, like your preferred version is not available for your preferred emulator, etc.). You can also pick the version/emulator manually if you want to, of course.

Does that about cover what you meant there? Basically different versions won't be extras but, well, just different versions.

Originally Posted by Goldrunner

It would also be idea to have more note pages for showing such things as cheats, intersting factoids, walthroughs, etc. We got around this by using the extras section but it would be better if things like this (that are used over and over again) had there own pages.

Well, I was going to make a simple file manager and built-in text viewer. At this point I should probably explain something about the general design: the central item is the game list (in form of an actual list or a thumbnail view for example) of the current database, around that there are "inspectors" (working title), which let you view details about a game and can be positioned and resized freely (or floated, though I personally wouldn't use that) around the main list. E.g. there would be a Screenshot Inspector, a Doc Inspector (for cheats and docs), etc., I haven't completely worked out how flexible to keep this without compromising ease of use. I'm thinking maybe the database creator should be able to define inspectors, for example by using (available or new) plug-ins and generic file viewers which determine what kind of file they're dealing with by patterns in the filenames or directories they're in. Another option would be tags. For the first release I'll probably go for the pattern solution.

Originally Posted by Goldrunner

Now comes one of the things I hate most about Gamebase, namely only being able to display two columms in the main database window. Two might have been OK for people with limited display areas but the option to show 3,4, or more fields as columns in the main scrollable window would be a massive improvement.

There won't be any hardcoded limit for columns as there really is no reason to put one at all. I never quite got that in GameBase.

Hmm, this thread is turning into an information leak.

Edit: But, by now I'd like to know if planned and partially implemented solutions are any good.

[GameBase]

Hi, I'm the author of GameBase, and just want to say it's nice to see another project going strong! I'm looking forward to seeing MAGE - It sounds like it is addressing all the shortfalls of my now ageing frontend. Speaking of which, the reason for the 2 columns is because when I first coded it I was working with C64 database (GB64) with about 10000 games, and reading more than 2 columns into a listbox on my PC in Visual Basic was waaaay too slow at the time, so I decided to code and optimise for 2 columns. Well, hindsight is a wonderful thing...

I would have thought since releasing GB as open source, someone might have added some multi-column functionality, and fixed some of the other problems, but maybe my code is too bad for most people to bother The reason for the halt in GB's development (and the reason for going open source) was due to lack of time, part lack of interest, getting married and moving house (twice). With what little time I have now I'm developing another frontend called 'cabOS' (cabinet Operating System). It's like a GameBase for arcade cabinets. It will use a custom text file database, and will not suffer the same defects of the GameBase frontend.

I haven't downloaded your Amiga database yet, but I'll try to take a look very soon. Keep up the good work.

[Retro-Nerd]

Hello, James. Nice to see on the EAB. I'm using your frontend for years. There is not really an alternative at the moment for me using the computer & console emulators. But i'm looking forward to see Mage as well. Are you working on another multi-frontend, or is "cabOS" your single aim at the moment?