Roadmap Idea: Reverse engineer and add support for LegoTower + TinyTower Vegas

[leonitousconforti]

Tinyburg is supposed to be a place where "Towers come together" so why limit this to only TinyTower? I think (really haven't looked to much into this) that support for LegoTower and TinyTower Vegas could be quite simple to implement with a few minor adjustments some of the packages. I don't think that it would require adding more packages, as the scope of each is already pretty well defined but could be expanded upon to include the other games. Here is what I think would need to change:

@tinyburg/apks

• Currently we only store apks for TinyTower from multiple sources. All that needs to change is adding the option to choose which game when loading the apks. No changes should need to be made to the way we store apks or the way we retrieve them.

@tinyburg/bots

• MITM network requests when making new accounts to get burn bots from each game.

@tinyburg/core
Most changes will need to be made here. I don't want to create a 'core' library for each game as I believe that the endpoints will be structured the exact same for each game, so we should be able to re-use them. I think the approach I want to take is changing the 'nimblebitHost' field on TTConfig to just point to the host for the individual game. This means that when you create a tinyburg client, you are creating game specific client and can only query information from that game. I am against the idea of expanding the config to include a TTPlayer field (TinyTower), LTPlayer field (LegoTower), and TVPlayer field (TinyTowerVegas) and then adding an option to all endpoints to select which game to use because I think it could introduce problems easily where someone passes a TTConfig with a LTPlayer supplied but then tries to make requests for TinyTowerVegas. Another reason I think that each config someone creates should be game specific but the library endpoints should be game agnostic is because each client should just represent one game.

For example, say a user wants to send an item from their TinyTower account to their LegoTower account. In the first scenario, the user makes one TTConfig with the TTPlayer and LTPlayer fields supplied. Then they make the necessary requests to download their TT save, parse it, modify it to remove the item, ensure it has been updated so the server will accept it, pack it, and upload it - making sure they specify TinyTower as the game whenever they call an endpoint or parser. Then they have to do a similar process expect they have to make sure they specify LegoTower whenever they call an endpoint of parser. I feel like this could lead to a lot of confusion and lost data. In the second scenario, the user creates two TTConfigs, one for their TinyTower account and one for their LegoTower account. Next they create tinyburg clients from each config, so they have two clients now. They no longer have to worry about providing the right game identifier to every endpoint or parser function because the client instance handles all of that for them as long as they use the correct client in the right places. I think that keeping track of which client to use is much easier than remembering to provide the right game identifier to each endpoint and parser function.

This, however, comes with the added complexity that each client will need to know which game it is for in order to have the right types when dealing with save data. Right now, there is only one save data type which is for TinyTower, and while I do foresee the structure and data from the endpoints being the same, I think that there will be some variance in the save data. There should be some overlap, but I think there might be some differences too. In order to deal with that, each game will need its own save data type and each client will need to know what game it is for to use the right type. I think this can be achieved using generics and instead of a string for the 'nimblebitHost' field using a discriminated union of the three different game endpoints so that we can type match on them using generics. So that should solve the problem of each client using the right types for parsed save data and such, but what about the save parser?

The save parser itself shouldn't need to change (that is the recursive functions that actually do the parsing), however, we will need to add new parsing blocks for each game. As stated above, I believe that there will be some overlap in the save game data from game to game. Which means that we should be able to re-use some of the parser blocks in all the games. I am thinking that we have some generic blocks that work for all three games, and then for the game specific data we have game specific parsing blocks. Similar to the way that the client needs to know which game it is for, the save parser needs to know what game it is for so that it can choose the right blocks. As of right now, the save parser and related helpers (like adding an item to save data, modifying save data, and ensuring the server will accept this save over a different one) are not tied to configs - i.e you do not need to supply a config when you call them. They are still exposed to through the client so when the client calls them it could pass the game identifier as a parameter. But at that point, why not just pass the entire config? I think in this case I don't want to pass the entire config because it only really needs to know what game it is for and doesn't need to know anything about the player/proxy settings/burn bot/anything else. Instead, this sounds like I could be solved with some smart typing. All save data related functions would become accept either TinyTower save data, LegoTower save data, or TinyTowerVegas save data and then output the same type. Inside the function, I think we could use something like "instance of" to build the game identifier.

A problem I see that might come up is what about the functions that accept any piece of save data? I'm not sure yet how that will be handled but I think it could be as simple as adding a fourth save data type for something like base nimblebit save.

@tinyburg/doorman
Instead of making a custom version of doorman targeted at each game, I think it would be easier to make doorman abstract enough to handle each game on its own. I don't want to make things too abstract - but my idea is that there could be another decorator called "requiresGame" which is applied to any upgrades that require a specific game. The handlers (elevator, bitbook, mission, and stocking) shouldn't really need to change much. I don't think there will be any game specific handlers either, as handlers shouldn't include any big decision making they just play tedious parts/mechanics of the game - which I believe the base mechanics will be similar enough that there shouldn't need to be game specific handlers.

@tinyburg/bitprints
Just because I don't think there will be game specific mechanics/game changing mechanics doesn't mean you won't want to play the games in different ways. For example, and I have no idea if this is true or not, say in TinyTower Vegas you can't rebuild for some reason. You wouldn't want to create a FSM with a state of waiting to rebuild because that state will never occur. For that reason, I think there should be game specific bitprints. I think there could be game agnostic building blocks to get you started but then the user has to decided how that want to play each specific game. I think all this can be captured simply by the type of the state for the FSM which has the added benefit that nothing about the FSM implementation has to change and nothing in the building blocks has to change. Typescript should be able to catch if you add a building block to your FSM that isn't support for this game because it would try to access part of that state that isn't there and throw a type error.

@tinyburg/insight
The agents will need to be ported to each game (shouldn't be too different though), and new agents will need to be written for the game specific data.

@tinyburg/integrations
Add integration example for each game.

@tinyburg/architect, @tinyburg/cli, and @tinyburg/explorer
No changes