Closed stgraveyard closed 6 years ago
Hi,
As a general remark, what I did is definitely not the final solution. It's just a stepping stone for the next chunk. I'm trying to "fix" the DB schema and put it in the right shape before making improvements, while still keeping the site working so that we can release it in chunks. Hopefully that will clarify my approach a bit...
I see you have added the continent_id to the game_release table.
Yes, it was just a way to "fix" the database schema for now, without going all in with the locations. In fact thinking about it, I'm starting to wonder if the locations will work because they may be too fine-grained. We probably need to think about what the location table would contain (countries? continents? regions?). That's still a bit unclear to me so I preferred keeping continent for now and migrate the existing data. We can easily refine that later.
Game developers are linked to the continent table
I haven't changed that I think, that's the way it is in the current database. See for example in prod:
That felt weird to me too, but it's something we can change later.
You add the pub_dev_id to the game_release table, but in our analysis it is called publisher_id
I thought pub_dev_id
would be clearer because the table is still called pub_dev
. But I don't mind if you want to change it.
The game_publisher table should not be used anymore as this is replaced by the publisher_id in the game_release table.
Correct, but for that to happen we need the users to merge the remaining publishers (the new screen I made in the video). If we delete the table before that we will loose a lot of data.
What I did is keep the data, but modify the game editing screen so that you can't add publishers to a game anymore. The only thing you can do is merge the publisher with a release, or delete it (when you merge it in a release it gets deleted too). I suspect we will need to keep that for a while until the users have merged everything.
I do have some trouble understanding what the game_release_distributor table was for?
Not sure at this point, but I guess we'll cross that bridge when we come to it. I'd rather fix the existing DB schema first, and then make improvements and add tables for new features, if that makes sense?
The AKA table is deprecated
Yes we need to thing about this. Initially I thought the "release name" would replace that, but I don't think that will work. For example Captain Blood was called "L'Arche du Capitaine Blood" in French, "Die Arche des Captain Blood" in German. But both are probably from the same release from Ere Informatique... So perhaps AKA needs to stay where it is, or moved to a release?
we do not stick to our analyses
2 things on this:
I'm not sure where to go from there... Probably:
Once we have that going I would consider that a "v1" that already brings major improvements to the site and contributors. After that we can discuss what will be the next priorities in terms of improvements? Let me know what you think...
Thanks!
Ah, I should have searched for .xslx
:wink: Got it now. I think an issue is that it's either not precise enough, or outdated. For example it says "no action" on game_developer
, but in fact we do need to remove the continent_id...
Hello Nico,
Let's keep this issue open until we release the version 1.0 like you mention above. I think it could help to have this for now. I do prefer your 'chunks' document, I started updating this last month but I think it is outdated for now. Maybe for version 2 we can make a new document with an analysis of what we will be doing and keep it up to date. These things really help me not lose my mind.
Regarding the big excel file. This file I made to keep track of ALL the tables we have, we will need and what needs to be changed. It contains everything from your online excel, everything from the technical doc that is needed and everythign from our super big discussion thread. No, the excel is not outdated, the reason the game table is not changed, is because I probably was not sure what to do with that or not aware. I have uploaded an updated version adding the 'type' field to the game release table. I am very sure there are other things which need to be changed as we come along, but this excel is, for me, pure gold. (And the reason I did not make an online version is because I used it a lot on the train and I have very bad connection there :-1: - But we can make an online version of it) I think you should give it a chance, these are the important tabs which really help for now : 1) Table overview : Every single table currently in the DB and all tables we discussed that need to be added. 2) Checklist : Again a list of all tables and their action and which action have been already completed 3) Game structure : This is the part from the game thread in GIT and your excel, all in 1 page. Very handy when you forgot how it worked again (which happens A LOT with ME :-) )
I would really like to add perhaps the tabs of this excel to your online excel, to have everything in one place.
I'm still struggling with the XLS because I don't know where to find it, nor how to make sure I'm looking at the latest version (Can you give me a link? I'm running a search for XLS files on my AL folder but it doesn't yield anything). I don't think I have reviewed it thoroughly either. I'm mostly working with the initial spreadsheet we made
I see you have found it. The excel is in the master branch only for now. I hope this changes when this release branch is merged.
I consider this to be more "guidelines", than specifics we need to apply to the letter. I think things will change as we implement them and realize that we have made slight mistakes (see above about continent/region, and AKA), so I'm in favor of keeping an open mind on this.
I'm also in favor of keeping an open mind, I do think we need to document our changes properly because we will lose track. Also because more people are working on this. I think the most work regarding the documentation is done, we just need to keep it up to date.
The AKA table is deprecated
Yes we need to thing about this. Initially I thought the "release name" would replace that, but I don't think that will work. For example Captain Blood was called "L'Arche du Capitaine Blood" in French, "Die Arche des Captain Blood" in German. But both are probably from the same release from Ere Informatique... So perhaps AKA needs to stay where it is, or moved to a release?
@stefanjl was talking about this yesterday and I do think we need to have the AKA for these kind of cases on some level. Maybe this needs indeed to be linked to the release level, please @stefanjl @Brume-AL @MugUK , let us know what you think.
I'm not sure where to go from there... Probably:
- Fix up the release regions / locations
I would definitely like to have this one solved indeed, but it will require a conversion process. We will need to investigate a little deeper.
- Cleanup the developers (remove continent and game extra info?).
I don't think we will need to remove the extra info? Continent I think, but maybe @Brume-AL @stefanjl can answer this better? In the current structure, a DEVELOPER is linked to a region (see prod cpanel). Why? The game extra info seems usefull to me, we have the same for the publisher (but not anymore in the new screen - is the extra info stuff for publisher not needed anymore? I guess so, please clarify team) - Or is all this stuff solved because we create a new release. I think this is a bit of a mess and needs to be cleared up.
- Improve the release editor (tabs)
This seems like the easiest task
- Fixup various parts of the main site that needs to be changed from "game" to "release". For example searching for games incompatible with Falcon needs to be converted into a search for releases. Searching from a publisher needs to return releases and not games, etc.
Very good point, I have not tested the search thouroughly yet but this will definitely need to be checked.
Will we be adding the AKA part to version 1.0 as well?
Thanks for this overview, let's try and stick to these points, solve them and have everything tested, tested and tested. Than release this version and continue on the next.
I will do some work this evening. Maybe add some tabs if you can agree on the currect way of working (see the TAB issue you created).
Maarten
I have no idea when to use "extra info" or "continent" in the first place... is there any good examples you can show me in the DB?
Nico... about captain blood example you mention with the name in different languages so do all three become different releases.
The best way is probably to have AKA to release... but does this mean when searching for a game then a long list will appear... i mean if a game has 3 releases and it has a AKA then 6 releases will be listed?
@stefanjl and other : We have less than 25 games where a developer is linked to a region, examples :
There are 175+ games which have a developer with 'extra info'. Examples :
Man, this is complex to me ... I have this extra info table flagged as 'to be deleted' with a comment 'This will be replaced by the release structure'. But honestly, I don't think it should be removed. This last example seems a good one, no?
That "extra info" is it not like what we talked about yesterday when i tried to add "The Sales Curve" as producer? i mean "producer" could be added to "extra info" maybe?
Yes, that is what I saying. So in your case, there are 2 developers and one of them has the task 'producer' which would be selectable from the extra info field. No? Seems like a clea solution to me.
I do think we need to document our changes properly because we will lose track
I'm hoping the comment in the tables + columns, and comments in the code will be enough... Perhaps it's wishful thinking! But I personally have rarely used the DB schema diagram or any other doc past our discussions. It's definitely useful to discuss, but I'm not too sure after that... It's probably just that we have different ways of working!
I don't think we will need to remove the extra info I have no idea when to use "extra info" or "continent" in the first place
So currently the extra info at the publisher level, has been converted into a release type: Budget, Re-release, Budget re-rerelease.
The extra info at the developer level is:
We need to decide what to keep (and if we need to add values). So perhaps:
I would also probably rename that to developer_role
to clarify, rather than game_extra_info
?
In terms of continent I don't think it makes sense at the developer level. We can probably remove?
For the AKA I'll comment on the forum since the discussion has made some progress there already.
That is no problem, Nico. I will not bother you anymore with the documentation. It is indeed a way of working and I really want a 'as complete' as possible document when this project is 'finished' on some level. I can't imagine, after a hiatus of a few months or more, having to look through countless of forum posts or what not. I will continue updating the doc as good as I can, even if it is just for me. To give you a good example, just to continue the discussion of all the different ways we are now using the extra info (an extra table, in the release table ...) I find it easy to have a look in the diagram how it is all set up :-)
But anyway, this is indeed very important.
game_extra_info is linked to following tables :
So yes, we can rename the table and the id field in the game_developer table quite easily, I guess.
Regarding 'Arcade' : normally there is no 'arcade' flag in the game table, as we had decided on a portid linked to a port table which had all systems including 'arcade' in it, but it can also be a C64 port, an Amiga port ... (It is this kind of discrepancy in info that makes it hard for me to follow sometimes - I am just trying to add what we all together decided on as the 'best' solution)_
Regarding the location in combination with the developer. At first it doesn't seem to make sense, but did you see my last example? http://localhost/games/games_detail.php?game_id=1522 What if we have multiple development teams in different countries? Could it be a nice to have or am I stretching it here?
Regarding 'Arcade' : normally there is no 'arcade' flag in the game table, as we had decided on a port_id
Correct. I was omitting this to keep the discussion simple, but the upshot is that we can remove "Arcade" from game_extra_info
I think?
What if we have multiple development teams in different countries? Could it be a nice to have or am I stretching it here?
I think the location is an attribute of the developer, not of the release? So a developer is located in a specific country, regardless which game they are working on? For example ERE Informatique will always be a "French" developer, regardless of which game they are working on. So for me it doesn't make sense to store this under game_developer
. At best it's just a country
column on developer
?
I tested and added a couple of Outrun releases at dev.stonish to try out the new release system and adding releases was very easy... excellent :)
Good to hear! Thanks! :) I checked the Outrun page on dev.stonish.net and you've been busy indeed!!
Thanks for doing this Stefan. If you have suggestions, make sure to tell...
I'm playing with the new cpanel and it's a brilliant work! Congratulation, guys 👍
Have a suggestion, but let's take an example first. Bob Winner: the first version that comes in a wallet (not in a crystal box) works only with TOS 1.0. Of course it's incompatible with STE and Falcon machines, but also with STFM that uses 1.02 or 1.04 TOS. Another example could be Tetris (by Mirrorsoft). The French first edition works only with TOS 1.0, too.
Also, there's another case: some editions don't support some TOS languages. The edition of Captain Blood by Metal Hurlant / Infogrames UK doesn't work with French TOS. Same goes for Manhattan Dealers (the English version): it requires a UK or a US TOS version and won't work with a French version.
So, would it be possible to add a 'TOS' option in the 'Compatiblity' tab? Or is it planed to add it to the Download section?
Thanks guys.
Hello Bruno,
When looking at our analysis and our game diagram I see a game_release_tos_version_incompatability table (I guess the table with the longest name ;-). So yes, this is all covered but will be for a future game release update. If you want to have an idea how game release version 1.0 will look like, check the projects tab here on Github.
Cheers, Maartren
Thanks, happy that the new cpanel works for you!
I think we accounted for TOS incompatibility in the new design, but I'm not sure we did for TOS languages...
i have been testing some more but should probably stop as (like you said) not everything is linked yet.
Also i don't know if it is in this thread i should post this... but "author" need to be linked to "releases"... a good example is Outrun wich has different musicians for different releases.
Yes! It's part of the new design to have individuals associated for releases for additional contributions. We want to finish a v1.0 though with the existing data structure, before adding more tables.
Hello @nguillaumin,
I'm now checking all your changes in more detail, and I will start with a complete storm of questions and remarks before I do anything. Also, I don't know how to add this stuff to an existing branch so I created an ISSUE. If you have hints on how to do this better, let me know.
Nico, I love what you are doing, the only thing I find a bit worrying is that we do not stick to our analyses. Shouldn't we use the naming convention and structure we agreed on?