|
Hello and welcome to the first RF Generation Dev Log!
For a quick introduction, I'm Misto, one of the volunteers working on bringing RF Generation into the modern era of websites. If you are not aware, dev logs are commonly used to document and bring awareness to the efforts, struggles, plans, etc of all the work that we are doing behind the scenes throughout a project. I'm hoping that this will be a fairly regular type of blog post just so everyone can see that, yes work is being done - whether its visible or not. There has been a lot of discussion and mentions in the recent blogs about the site redesigns but I wanted to use this first post to outline all the steps that need to be done before anything can even move forward. Also this post will be long so get ready.
First and foremost, as many of you know and what's been mentioned in past blogs, RFG is pretty dated. Not that its a bad thing per se but it does limit us from expanding or building on top of what is in place. Right now, much of the site is running on outdated software and we really don't know if any upgrades or updates will break current functionality. Most of the original developers have since moved on as well, so we are stuck with a bunch of hacked together legacy code. What I've been working on currently, is creating a separate server that mimics the current site configuration but running on the latest and greatest (operating system, hardware, PHP/Perl versions, and database version). I did manage to get the OS and database migrated successfully but I'm still working on getting the actual site code moved over. The test server I'm running on is in AWS (Amazon Web Services) which has some free tiers which are perfect for this upgrade test. Unfortunately, we have too many images in the database and they don't fit on this tier (free tier only has 60 GB of hard drive space and we have about 25 GB of games images alone!).
This brings me to my next point - costs. The unfortunate reality is hosting a website outside of a basic blog isn't cheap. A lot of software and hardware needs to come together to make anything run and it all costs money. Just knowing that we can't run the server on a small server with a 60GB hard drive, means we need to pay for more space on the server. I mentioned before that I'm using AWS to host a test server. I ran through multiple configurations to determine costs based on the requirements I think we would need in a worst case. Requirements are the obvious like CPUs and hard drive space, but also the less obvious - how many visitors does the site get per day, will the server be running 24/7 (yes for us), how many requests do we get, are there spikes in traffic (for instance does most traffic come between 10-11PM on a Wednesday), how big are each request size. All of this needs to be taken into account. Most basic and cheap webhosting are going to run into limitations for anything beyond a simple wordpress site.
The good news is with AWS (or similar cloud provider), I think a lot of the costs I calculated so far are around the current server costs. But it gives us a few benefits to move. One is scalability - did your server go down unexpectedly? Just spin up a copy of it. Need to make changes? Just spin up a test server and make changes before pushing them out and hoping for the best. There is also another potential benefit, the possibility we can get away from cPanel. cPanel is great for a lot of things, but as we grow, its hard to use and difficult to manage with a team of programmers and other volunteers. I can't find a good way to give access to other people without giving them full server access. Its also a completely managed service (meaning the software, site, databases, and images) are all stored on one server (remember the 60GB limit above, cPanel takes up about 20 of that alone). It also limits you to specific programming languages and other supporting software you can use. Its also about $30 a month for a license. We have discussed in the Discord a full site rebuild, using a cloud service like AWS, we can utilize services that could allow us to make a more robust site while also potentially coming in a bit cheaper than what we currently pay.
Moving on from server configurations, lets talk data. RFG has a fantastic amount of game and hardware data but it can be organized in a better way. A lot of you have pitched in with ideas and we've come up with a schema (how the DB is organized) that we think will address some of those issues. First is the games - we've built in a sort of hierarchical structure to better organize them all. I'm going to use an example for this of my favorite series - Resident Evil. First you have a "Franchise" or the "Resident Evil" franchise, this will have any shared game info (like creator, first game release, etc). Most of this is more for fun than anything but it could also be used to see how many games in a series you are missing. Then we have the "game", this could be "Resident Evil (2002)" for instance. This will have all the shared info for a specific game (alternate titles, descriptions, etc).
Under that is what we mostly care about - the "variant". The Variant will be things like the original GameCube North American release or the Wii re-release in Japan, etc. These are the games that are all in our collections. Variants will now optionally support a lot more data than we currently have
- Credits
- Multiple developers/publishers/distributors
- Listing for bonus physical goods for collector editions
- Flags for homebrew, digital only, full game on media, online only, cross platform support
- Print run of the game
- Inclusion of download codes
- Required or supported controllers
- Hardware or OS requirements for PC games
- An appears in option - tie games to compilations
- Flag as a pack in games for consoles
- Standardization of genres and game modes
- Multiple images for each "type", as in multiple front box images or cartridge images
I think that about wraps things up for this post. As usual, let us know what features/improvements/bugs/etc that need addressed. It may be a long time before we can get to it but I wanted to show that progress is being made behind the scenes. I'm hoping soon we can have a better idea on what path forward we are taking (some of this is dependent on costs and how much we get in donations) but in the meantime I'm working on getting a git repository of the current code setup to give developers access as well as somewhere we can document and submit issues or requests in a more formal way.
|
|
|
|
