3 Replies - 11245 Views - Last Post: 03 December 2011 - 07:11 PM

#1 Recoil  Icon User is offline

  • D.I.C Regular

Reputation: 24
  • View blog
  • Posts: 292
  • Joined: 28-June 08

Game Front End efficiency ideas

Posted 20 October 2011 - 10:15 AM

Note: not asking for any help with this other than idea discussion for the most efficient way to go about this...coding not needed...

Main screen (not quite finished because only settings and games work)
Attached Image

System screen (for selecting the game system and seeing system commercial)
Attached Image

Rom screen (for selecting the rom for the selected system while viewing the preview movie)
Attached Image

Selected Rom screen (for selecting to view images/manual and see the preview movie for the game)
Attached Image

I have been working on my Game Front End for over a year now, dubbed GFE for short. This is a personal program I have made just for use by my autistic son. At one time I used GameEX, but ultimately needed something where I could control every aspect of the program in order to ensure what my son was/had the ability to mess with, while remaining functional for the adults to use without compromise when we have game time for rewards.

Going from the ground up has been a huge hurdle to overcome with the limited stuff that is in it right now because of my low level of programming experience, and the large list of stuff I want to do. But now I am getting into parts of it where I have either ran into problems with and could not figure out how to code it properly, or have tried to do something and re-written it 30 times for efficiency.

I am working on the access database. Initially I was wanting something like (and I don't know what else to call it other than a "module") that would hold all the content for each game:

gamename (box).jpg
gamename (back).jpg
gamename (cartridge).jpg
gamename (controls).jpg
gamename (snap).jpg
gamename (title).jpg
gamename (manual).pdf - to display in a manual viewer
gamename (video).avi
gamename.rom
gamename.text - to hold all the info (publisher/developer/release date/description/etc...) and display in a viewer

The problem I ran into was creating my own file type to hold all of this, and likewise creating my own file type for creating my own theme "module"...it's just too far over my head and everything I found for accomplishing this is confusing.

So then I just have 1 folder for the game, holding all the content. The problem is there is like 2000+ games I believe just for the NES, and coming up with a quick way to incorporate everything for each game has been daunting...something like a "ROM Module Editor". Due to the way everything is named, and the way the program reads the files in the game's folder, it would be much better to have something name these files properly and not rely on 1 person to input every character. I thought about having 1 access db file for each game...they would be approx 20mb each with everything in it, and I was able to display the images stored in it, but I was never able to pull the manual up in the viewer, nor use the rom from the access db file for the emulator.

Either way, the "module file" and the access db file would be more efficient to have, and I would be able to create an editor to speedup the process. Currently being in files they are taking longer to compile them for each and every game...and because this is not a commercial outfit (meaning just me doing this for myself), it is going to take me a while to re-size, edit, and compile everything. I do know that with each one what I am wanting to use them for can be done...and whatever way I go with would be worth the investment if I were to ever release this for public use.

I know, there really isn't a question anywhere in here. I wanted to get opinions of this though, as well as more efficient ideas about the game's files and possibly the theme files...other stuff that "could possibly" be added. Currently it works like it is supposed to for like 7 or 8 emulators...the others I seem to be having a bit of difficulty getting the command-line launch parameters correct. Works with a joy pad..."a" as in the only 1 type I have tested, but have 2 of them connected to the system (Logitech F310). Some of the controls are custom built for aesthetic reasons, some for functional reasons, and others aren't yet cause I am unable to figure out how to do certain things and can find no examples. This uses no Direct X...just straight drawing everything to the screen...and it shows poorly IMHO! All graphics for the theme are custom made by me, and this theme is dubbed "Gold" for obvious reasons.

I'd upload an example but I cannot figure out how to get VB 2010 to make the proper install files instead of just an exe that I am unable to get to work on anyone's system but my own due to the directories needing to be setup properly within the program.

Thanks for reading and offering ideas.

Is This A Good Question/Topic? 0
  • +

Replies To: Game Front End efficiency ideas

#2 xnn  Icon User is offline

  • D.I.C Head

Reputation: 36
  • View blog
  • Posts: 227
  • Joined: 10-February 10

Re: Game Front End efficiency ideas

Posted 20 October 2011 - 04:09 PM

I personally wouldn't use a database. You are suggesting storing files. If you do end up going with a database you will want to store filepaths in the db and use the filepaths in your program to load the images/avi/rom. Creating a different access db for each game would basically be misusing a db.

As an alternative, I'd create a couple classes that would encapsulate all the data you are trying to save.

for instance
Public Class GameDetails

Private _sBoxPath as String
Private _sBackPath as String
Private _sManualPDFPath as String
...
Private _tdExtraInfo as TitleDetails

...

   Public Class TitleDetails
   
   Private _sPublisher as string
   Private _sRelaseDate as DateTime
    ...
   End Class

End Class




You could XML Serialize the class. When you program starts and certain game information is requested, you would Deserialize the game details. I'd create a utility that would generate your original XML for each game to start (with file browsers and such). Unfortunately you will still need to organize your filesystem yourself and whatever convention you chose you have to stick to due to all the filepaths being saved. You can find more information on Serialization by searching on MSDN.

I'm sure others will have some other input for ya too.

Edit: I wasn't able to come up with any ideas for a type of automation for your file system/starting xml files. If you end up doing it manually, I'd probably do the top X amount of games for each system and add additional ones at your convenience. There are a lot of NES games that are just terrible and aren't worth your time to enter. I'm a collector/avid player, I recently trimmed my NES game collection down to about 50 games, because I knew I'd never play the rest again

This post has been edited by xnn: 20 October 2011 - 04:13 PM

Was This Post Helpful? 0
  • +
  • -

#3 Recoil  Icon User is offline

  • D.I.C Regular

Reputation: 24
  • View blog
  • Posts: 292
  • Joined: 28-June 08

Re: Game Front End efficiency ideas

Posted 20 October 2011 - 05:37 PM

Currently, the way I have it setup is mainly for use over a network that would be setup. I would be able to sit at my computer and drop each "game module" (folder with all the stuff in it) onto my son's computer. Everytime it goes to the Rom screen it adds the previews on the fly based off of what is in the selected directory...so if he selected a game, went to the Rom Selection screen, then I dropped in some files, when he went back into the Rom screen it automatically shows everything.

Another reason to set it up like this is so I can put a time limit (whenever I get to that stage) and he can play for however long, being notified like 5 minutes before his time runs out.

Currently it launches all the emulators in full screen, with settings already defined before hand, which was a ***** to setup for all the working ones. [Esc] normally launches an emulator's menu, but I have it hooking that key in order to keep him from messing with any settings and just shutting down the emulator. I plan on hooking all the keys soon in order to keep my hard drive from being bombarded with a bunch of save states and screenshots...LOL

As far as the filepaths go, I am creating a program that could possibly be useful for more people than just me...my directories being stored into the db file would be different from thiers, which is why I went with the naming conventions like I have for use with the directory option:

[Folder] NES
[Folder] + Castlevania
- Castlevania (box).jpg
- Castlevania (back).jpg
- Castlevania (cartridge).jpg
- Castlevania (controls).jpg
- Castlevania (snap).jpg
- Castlevania (title).jpg
- Castlevania (manual).pdf
- Castlevania (video).avi
- Castlevania.nes
- Castlevania.txt***

***has not been created yet as I have everything already in a DB file for most games, but not the other content. But if I were to create a custom file, the information would go in here in text instead of in the DB...I see no sense in retaining information in a Db for games someone doesn't have.

But since the custom file thing is a bit too much for me right now I am probably going to opt for a "ROM Module Editor" that does nothing more than have a user select the pictures in their proper spots, name them programmatically because the folder and files all need to start with the same name in order to be detected, and put them in the correct spot on the drive. That would pretty much leave it able to be streamlined with my current knowledge.

As far as serializing all the paths, the main directory for the program is saved in the settings...from there it selects the [System], [Rom], etc all by what is currently in the directory (i.e it lists all the folders in the [NES] directory when it is selected). Not only has this shown to be more efficient, it seems to be a lot quicker for me on my system, but I have yet to test it on another system. In essence there is only 1 configuration file, and the only other ones in the works are going to be the ones used strictly for the selected theme.
Was This Post Helpful? 0
  • +
  • -

#4 Recoil  Icon User is offline

  • D.I.C Regular

Reputation: 24
  • View blog
  • Posts: 292
  • Joined: 28-June 08

Re: Game Front End efficiency ideas

Posted 03 December 2011 - 07:11 PM

I'm not going to start a whole new thread for this issue, but would like to get the thoughts of someone about the interaction by using WPF controls instead of GDI+ for this operation. I have been going over several dozen articles, beginner projects, tutorials, ebooks, etc...and I still am unable to get a basic understanding of using VB.NET for the code-behind and WPF for the UI.

Currently this program contains everything for the theme in a defined folder on the hard drive, the "current" form pulls the information from a text file for the layout and what images to use and where. I thought this would be the best approach with my knowledge of VB.NET. It's simple and it works, and by creating an editor I can easily allow a user to move stuff around and change things without needing to edit the text files, as well as providing an easy method to create completely new themes.

It has been pointed out though that the level of interaction for a complete system front end I am after would be better sought by using WPF for the visual UI, because using GDI+ with custom drawn controls will be laggy on older machines...okay, so off I went in search for tutorials...but still feel people should upgrade for software they are using if they feel their system is laggy :/

Now from what I am understanding I can achieve a richer interface and easier effects out of the controls by going with WPF. The thing I do not understand is if I can "Populate()" with a sub the WPF control I am going to use with what I am wanting to display from the application...so if in WPF I were to create a different control to display all of the ROM images like in the 3rd image above, that will be possible, correct? I have run across tutorials using WPF controls in VB.NET, but have yet to see anything passed to the WPF control from within the VB code.

And since I am changing things pretty drastically with the UI, in theory because I know it can be done with regular controls, I should be able to display entire directories and all their contents from the code and onto the WPF controls? This would allow me to simplify the entire code by just feeding in the directory, and perform a select case on the type of item to define what the application will do with it: if its an image, display it; if its a video, play it; if its a rom, emulate it; etc...

Right now with the amount of content in my custom drawn controls and small fading in and out effects, the only lag I notice is when it comes to changing the selection with the joypad, which by tweaking the timer event for the joypad helps resolve this. I am trying to decide if I even need to worry with WPF...maybe there is some benefit that I am not picking up on? DirectX is no longer supported, so that isn't an option. Is there maybe some other new technology compatible with VB.NET that I have yet to come across that would work for adding a richer UI? I think I might need to display other themes or layouts, but working on this for now has been put off because I have been looking at using something I am not too sure that I need :/
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1