The GoG connector for mybacklog is broken again - now they have a recaptcha for signing in. Ugh. If I want to keep that functionality I will have to implement a browser module to allow the user to sign in when the cookie lapses. I wish they would just make an api already.
I also did some light planning scoping out one of the erik quests - one about breaking into someones basement.
Working on some small mybacklog bugs. Hoping to get back to erik this weekend.
I added some sniffing for mybacklog to set up it's attachment to the user's steam account automatically - as long as they have steam installed first and to the default directory. I also realized that I can just reuse my web api key rather than end users having to get one. You can still set your own web api key, but if you leave it blank it will default to mine. Should make it a lot easier for eventual end users to get it set up and try it out.
Some optimization of downloading the extra info from steam games: caching, threading, and some indication of progress.
Had a friend over the other day and we weren't sure what to play. Steam has no way to filter your installed games by whether or not they have local co-op. You can certainly search the store for things to buy... but you get a very long list, and surely I have some games that have that feature already. I am compulsively buying games all the time.
Sounds like a good time to add more data to the steam api component of MyBacklog. Now it will also include whether or not a game has co-op when importing games from steam. Once in mybacklog, it is easy to search for. Next time I'm in a similar situation I will be able to choose a good game much faster.
Fixed some bugs editing emulators and adding emulator games.
Fixed a couple bugs in MyBacklog.
Same download as before: https://bitbucket.org/saluk/mybacklog/downloads/mybacklog_setup_0.25.exe
Had a concert to go to last night so broke the streak. Oh well. I've been thinking about Erik a lot, and playing a game called Deadly Premonition which has given me a few ideas for it. Later today I am going to design a third "situation" module, or whatever I am going to call them. They are like a combination of puzzles, ai routines, events, and conversations. They are the core gameplay I believe. On their own they won't be terribly interesting, but when there are several going off at different times in any given scene, that's where the game should get interesting!
Also, I added two editors to MyBacklog that kind of complete the package in my mind. The emulator path editor where you can choose an emulator for each type of system, and the source editor where you can add emulator systems or storefronts you want to track. Every bit of functionality that I envisioned for a release version is now there. You can download the updated setup (though still tagged as version 0.25) at the same place:
https://bitbucket.org/saluk/mybacklog/downloads/mybacklog_setup_0.25.exe
After I get some feedback from you guys and a few other testers, I'll move on to the polishing/documentation phase. Documentation... probably just a youtube video showing how I use it will be what the kids want these days :P But I really think this program may have value for some people. The GoG sale is today, and I saw comments on multiple forums about "well, this is nice, but I don't buy games outside of steam because I like to have all my games in one place." Ugh. People are so quick to sell their freedom for convenience.
Found out how to make the threads work better in my QT application, and actually tested it on an empty games database this time. I should probably post a tutorial for how to get the information to sync up your steam account, but I'm too tired to do it tonight :P
@nico found a bug in the program and I've been tracking it down. It turns out I am using threads very wily nily, and things are not very safe. I didn't really solve anything but I'm on the case :)
Also, new version uploaded. There is a little bit more obvious help for steam information, and slightly better logging while importing games.
https://bitbucket.org/saluk/mybacklog/downloads/mybacklog_setup_0.25.exe
Ah, my awesome perfect little application has no flaws and does everything I want it to. And if it doesn't quite get there, well, I can either tweak it, or I know how to work around it. The joys of working on a project where you are the only user.
Things change when other people start poking at it!
So just to make things interesting, here is the first alpha of my game launcher/management program, MyBacklog. The windows version only so far. Hopefully someone in here has a windows machine and would be interested in testing it. Just run the installer, and launch the app. A lot of things should be self explanitory. I'd love to know what is confusing, and have elected not to provide much of a readme to see how learnable the interface is.
About:
Missing:
Woo, since the site was down I was unable to submit. I made really good progress yesterday too!
After waaaay more work than it should have been, I am now encrypting the accounts file. Your steam password is a lot harder to sniff if someone is running a scan of your hard drive and runs into mybacklog's user files.
One minor flaw in mybacklog, is that I am not making any effort to detect when you have stopped playing a particular game. With all of the ways exe's are run, and the hoops that are sometimes jumped through with shortcuts and things, this is error prone. Even the big boys get this wrong sometimes (I've had issues occasionally with steam tracking my game time). Instead, I've opted to let the user record the stop game event. There have been a few occasions in the past year where I have forgotten to tell it that I stopped playing, and I had quickly implemented a notification that would ask you if you were still playing every so often. If you forget, you will get a reminder. But this is error prone too, and with some games (if they are running in a window for instance) the notification pops up over the game. Yuck!
I knew that was really just a stop gap anyway. I've implemented a few subtle, and less subtle, style changes when you play a game that should make it clear that you should click to stop playing before doing anything else, after your time of fun has concluded.
Barring further discovered issues, all that's left for an alpha release is to make a final decision on the app name and design/borrow a decent icon that fits. (The app name is littered throughout the code and I only want to change it once).
Some deliverables tonight...
Have a running exe version of the app, and also managed to figure out how to make an installer (using inno setup). The only issue is users are going to install to a protected folder such as "program files", and storing the data in there is no bueno. I will need to move my data files to appropriate directories.
Changelog:
I'm pretty confident to have a releaseable candidate in a week or less. There are only a few remaining important tasks:
I've reimplemented the source information in mybacklog using a dictionary for most of the data. Each item points to the class that is used for dealing with special cases with that item. It looks something like this:
{
"gog":{
"class":"GogSource"
},
"steam":{
"class":"SteamSource"
},
"offline":{
"class":"OfflineSource",
},
"none":{
"class":"ExeSource"
},
"humble":{
"class":"ExeSource"
}
}Note that both humble and none (none is a standin for "I don't remember/care where I bought/downloaded this game but it's on my hard drive") point to the same class. To the user they DO look different, and in fact the client knows how to import humble games, however from a data perspective they both act the same. If the user wants to record a source which I hadn't thought of (for instance, I've only created snes, gba, and n64 emulator support, so what if someone wants to add a playstation game and emulator?) they will just choose the closest "base" source to base it on and add the new name. I probably wont make a real interface for this in the first version...
Additional. These sources can make use of some data stored in the local storage. (The local storage is unique to every computer mybacklog is installed to, while the game database is intended to be shared across devices). In the case of EmulatorSource, they look in the local storage to find the command line to run in order to launch a rom for that specific source. So "snes" is going to look for local["snes"]["command"]. This way you can configure your emulators on a device once, but share information about playing a particular rom.
More mybacklog work. Feel very close to a finish line. Game id hashes seem to work correctly, and every weird thing I try to do seems to act about how it should be expected to act. You can edit games, add games, and import games, and they update existing entries where possible, and create new entries where mergine the entries would be too dangerous/weird. The hash was definitely the way to go. Only thing I'm not thrilled by, is when the hash changes and all of the references have to be forcible updated. The algorithm there is quite inefficient. But who cares. It works fast enough on my 1300 entry database. If someone has enough games in their database to make it take a couple extra seconds to update an item every once in a while when a hash changes...... they have a bigger game addiction than I do!
But my time was cut short by my copy of Witcher 3 in the GoG galaxy client activating. Galaxy is still a bit new, and I can't launch games inside it from mybacklog yet. So I just ran it the old fashioned way.
I'm still obsessed with mybacklog and stuck with erik. Sorry to the people who miss my rpg work. But I'm nearing some form of end goal for my game manager, and once I hit that I won't be able to work on it anymore and it will force me back to the game :P
Today I fixed a few more bugs (it's amazing how many there still are) and revamped the gog api to work with their new better system. Rather than scraping html and doing regexes, I'm not able to query their server and parse json. Much easier. This means all of the gog games in my library finally got their proper titles - but I had to double check that nothing got screwed up in the process.
Humble is also working again. The changed package/bundle support had some issues there.
I've thought of a really simple method to handle syncing the game database. It's called dropbox :P Since the local information and the syncable game information are in separate files from the refactoring of the data I've been doing, it's as simple as configuring mybacklog to store the db in a shared location. I'll have to test out how well this works in practice, but it's a lot easier than coding some complicated method to handle syncing. With only a little bit of extra effort, I could even add a per-game config for where the save files are located, and have it copy those files to the dropbox folder when you click to stop playing a game. Boom. universal cloud saves. Minimal coding.
That leaves:
As the remaining features for MVP (minimum viable product.
What makes this project more fun than Erik: I have a clear understanding of what the MVP looks like. When I return to that in force I want to strip it down even more and figure out what that mvp should be.
MyBacklog - the march forward continues!
I'm nearly done with data conversions now. I've created a separate json file that stores the information about your game library that only makes sense to have local, rather than synced to the server. Currently, the only information here, is a list of files associated with the game. And to be even more specific, there is only one file in the list, which is either the exe to launch the game, or the rom file in the case of emulated games.
I've also done a little bit of refactoring, and fixed numerous bugs (yes, there were still some bugs that sent me into nervous fits about whether my data was safe or not).
Almost everything left that I would want to do to the data could be handled by adding fields, which is a much less dangerous operation. I could add a tags system, or do other interesting things, but I think I'm going to call the current data format final. Baring any bugs I find.
Remaining tasks lie in user interface (editing games is pretty off, and there are big features missing), networking (syncing the game information across devices is pretty important), and integrations (humble isn't quite there, I'd like to add itch.io and desura, and being able to upload to other tools like backloggery or howlongtobeat would be cool to at least get started).
The data format SUPPORTS having one entry of a game that shows what stores it was purchased from, over the current layout of each store purchase being a separate copy of the game. I am not sure if I want to actually create code that handles and creates these unified entries however. It's definitely cleaner from a user perspective (do I have this game? oh yes I do, and look I bought it from gog and steam) - but I'm not sure if it's enough of a convenience to bend over backwards to make it happen. I think this is something I'm going to put in the future bucket :P
I leave y'all with a gif showing real time search of my library, and a frivolous but fun total time played counter, which sums up the time for the games in the search. You can see I am a big Assassin's Creed fan, playing the series collectively for roughly 11 days! This is not including the first 2 games, that I played previously outside of time tracking systems (steam or otherwise). Creed III is the longest so far, and I'm almost done with Unity - it's 42 hours is never going to hit 3's 72. III is actually my favorite of the series... despite some of it's problems. I think I am pretty alone there! Titles in green I have marked as "finished".
mybacklog
Two data format changes, one not so significant another quite significant. And a bugfix.
Firstly, I added a field to each game showing the last change that was made to it's data. Then I allow the client to sort by change date. This isn't really meant for end users, more as a way for me to more easily audit when I mess up my own data and how to possibly fix it.
Second, and more important, I changed how bundling was stored. Sometimes when you buy a "game" from a store, you will get more than 1 game along with that bundle. GoG has many games that are bundled (although they are moving away from this system as they update for GoG Galaxy). For instance, you can buy a game called Alone in the Dark 1 - but it actually comes with Alone in the Dark 2 and 3 as bonus downloads. The humble store (and humble bundles obviously) also has this notion where one "purchase" is tied to a collection of games. My previous implementation of this concept was very fiddly, done totally different for GoG and humble, and would not scale well (fetching the list of games inside a bundle would have to look at the entire game list).
I've unified the 2 current systems, and of course it will work for other stores as well.
In fact - it is possible if you so wish to make your own "bundle" of games in the list. For instance, you could collect all of the Geneforge/Avernum games as your own "Avernum Collection". The options for displaying this information on the game list aren't great, as the game list is flat and you will see the bundles along with the items inside the bundle just laid out side by side. So currently there is no real reason to do this. However maybe somewhere down the line I make it show bundles as their own single item that you then drill down into, or something.
More importantly, I'm a little more confident in other people building collections with the more clear data format, rather than the confusing custom fields I used to have.
And the bugfix: Also realized my matching algorithm to see if a game you are adding is already in the database had a huge typo error that may have been preventing it from working properly. So my local database may be royally messed up without my knowledge. And with 1200 games in the list it is really hard to check that they are all correct. Possible errors would be duplicate entries for a game, which is BAD. I have enough games to try and manage without duplicates! It's possible that the error did not actually apply to my data set and the test operations I was running last night, and I caught it in time.
Next up: Take another look at tasks and how the game .exe location is stored. I realize that currently, if I just switch over from my pc to the mac and sync the database over there, all of my games with hardcoded exe paths are going to crash when I try to launch them. I need to be careful of where I am storing local platform information that shouldn't be synced and needs to be recreated.
