The Battle City Database has several issues that need to be addressed.
SQLite: A new version is most likely available, so it should be assessed what is required to update.
Passwords: Passwords in the database need to be encrypted.
Structure: The database uses a flat structure with a single table which worked at first, but new fields were added that are problematic. For example, a separate table should be created for "tanks" that contains a player id and tank id making it possible for any player to own an unlimited number of tanks. This should also be done for rental cities and special items (which don't currently exists). These sorts of things can be sold to raise enough money for a dedicated server (we did this in the past when the game was popular and that's how we managed to keep a server running for so many years. The database wasn't really setup for it, so some players eager to donate maxed out on tanks, wanted others, but there was no way to add them without removing existing ones).
We also need to consider that Battle City was always a single dedicated server game. I think that hinders innovation from our creative community, that are not all developers. We want to encourage players to host their own unique servers. To build their own worlds. To add their own fun twists to the game. Of course, making that possible will require making more and more things configurable on the server, such as maps, available items, team size, etc...
... but I'm getting off-topic :)
We need to consider, how do we setup the database in a world where there might be multiple servers?
Should there be a central server for authentication, that passes the player name and ID to servers? Then each server can assign their own stats/ranks to that ID? Otherwise players will need to create a new account on every server and there is no guarantee their username won't be taken, etc...
Maybe the best approach would be to develop a "lobby" client. This "lobby" client would be where players create an account and login. They would then enter a chat-room which would also have a list of all Battle City servers. For each server you would see who is online, and the server settings. This lobby is what could be minimized to the system-tray. When you select a server, your username+id will be sent-over (not password) so you can play there with your account without risk. All this of course, has an impact on the database structure...!
@Deceth Great gems in this issue. I may create sub-issues to address the challenges for complicated issues. I think your ideas are great and just require some definition in order to set milestones in development.
The Battle City Database has several issues that need to be addressed.
We also need to consider that Battle City was always a single dedicated server game. I think that hinders innovation from our creative community, that are not all developers. We want to encourage players to host their own unique servers. To build their own worlds. To add their own fun twists to the game. Of course, making that possible will require making more and more things configurable on the server, such as maps, available items, team size, etc...
... but I'm getting off-topic :)
We need to consider, how do we setup the database in a world where there might be multiple servers?
Should there be a central server for authentication, that passes the player name and ID to servers? Then each server can assign their own stats/ranks to that ID? Otherwise players will need to create a new account on every server and there is no guarantee their username won't be taken, etc...
Maybe the best approach would be to develop a "lobby" client. This "lobby" client would be where players create an account and login. They would then enter a chat-room which would also have a list of all Battle City servers. For each server you would see who is online, and the server settings. This lobby is what could be minimized to the system-tray. When you select a server, your username+id will be sent-over (not password) so you can play there with your account without risk. All this of course, has an impact on the database structure...!
Just some ideas!