rocket-league-replay-analysis
rocket-league-replay-analysis copied to clipboard
enzanki-ars
Moving to an Electron app UI
DO NOT MERGE THIS. This should not be merged to master (not now at least) and should instead be merged into a new branch.
Just wanted to show you what an Electron App would look like! I included the bare minimum in there. To run it:
cd electronapp
npm install
npm start
For the minimap, I added a comment in src/Minimap.js explaining the possible options:
- Using a canvas
- Using three.js to render a small 3D scene
- Using D3.js to easily and efficiently render an svg from the live replay data.
Something else to figure out is how to run the python scripts and retrieve their output data. My current idea is to spawn python processes through Node.js but there might be a better solution.
Love the layout! I think using D3.js would be the best, mostly because I am more familiar with SVGs, and as a result, I should be able to help more there. Looks great so far!
In terms of the runing of the python scripts, I have an idea:
Electron is OK is some respects, and for what you have created so far, I think it is a good way to prototype, but in terms of an actual program, I don't think Electron is the way to go. Interfacing between Node and Python is probably a pain.
It would probably be easier to run a webserver directly from Python, something I have a decent amount of experience with. This would allow for some neater code in terms of interacting with the parsed output, plus would allow for some cooler things down the road, such as creating a local server for coaching and allowing team members to join in and watch the replay at the same time. (VPNs like Hamachi or ZeroTier would be perfect for that, if they don't already have a LAN setup.)
In the next couple of days, I might contact the collegiate Rocket League team I know (They may or may not have come in second at the last Collegiate Rocket League National Championship...), plus some of the RLCS casters to see what they would love to see in a program like this, and how they may use it.
Just realized a bit of what you mentioned, D3.js would be a great start, but three.js might be a cool later addition...
To be clear, I am not hating on Electron at all, I am just worried about ease of use, distribution, and maintenance with both a Node.js side and a Python side.
Using something like Bottle or Flask (I have used Bottle before, and it is really nice and pretty easy to use) would serve the same purpose and should be easier to distribute and/or maintain.
I totally get what you are saying and do agree that having a python backend would probably be the best solution. However I think you are forgetting 2 things:
- You will still need a web client to see the page. This can either be a browser or Electron in the case of a web application.
- Flask and Bottle are frameworks for the backend. They are great for generating html pages but in the end you will still need javascript in order to get interactivity in your application.
The solution I propose is to use either Flask or Bottle (whichever you are most comfortable with) in combination with Electron as a web client. In the start script of Electron, we simply spin up a python server on some port on localhost and then let Electron display that URL (something like http://localhost:8000). I also propose to use React to generate the HTML markup (just as I showed in this PR) as this is much more convenient from a frontend development perspective!
This way we have clear separation of concerns, the front-end being used to display the data and making it interactive and the backend being used to generate that data from the replay files! This would also work through a VPN and has the added bonus that it could be ported to a website in the future!
If there is one thing that would really help with figuring all these things out would be to have some input from players and casters, as you mentionned. I highly encourage you to contact these people as soon as possible!
Before I comment here, I want to apologize in advance in case this message comes off in a ruder tone than I intended. As a result, while I will post the message below, I feel that it may be better to demonstrate what I mean. In the next couple of days, I may do that.
Also, I may complain a bit too much about Electron here. I do use Atom every so once in a while, plus I use the desktop Discord app and have used the desktop Slack app in the past, all of which use Electron.
First, I want to be clear that I respect your experience, but I must disagree with you in terms of the usage of Electron/React/etc.
There is a program I have been working on for the past year that is a python project that displays many freely available live streams from their official sources. I wish I could open source this project, but do to some legal concerns with hosting their videos outside of their website and accessing it via tools such as youtube-dl and streamlink, I am hesitant to release it at the moment.
The reason I bring this up is that this program has a backend to find all of the stream's links and auto update titles, links, and previews, plus a frontend where users can select a stream or multiple streams and to view them right in the browser. Every part of that is programed on in Python, Bottle, HTML, CSS, and JavaScript (I do cheat with the interface, as I am not a graphics designer, and use Bootstrap). Python can automatically launch the browser with the right URL, plus make it available on the local network. Without any modifications, the program can be hosted on a server and made available to the public.
Looking at the requirements for this project, the exact same set of tools can be used.
As stated above, even with the possibility of hosting the application in the future, I must say that Electron/React/etc. is not needed at all, and is very overkill for a project of this nature.
I will address your concerns backwards from your post, as I feel that it may make a bit more sense.
React: While React is a cool project, the programming style and design choices of React do not fit this program. React is designed as a front-end templating language. This is something that can very easily be done in the back end, and also is much faster. In terms of Bottle, this comes from the templating system built in, that can interact with python objects directly. These templates work in a similar way to
Interactivity: Again, React is a bit overkill for this task. All that is needed are a couple of buttons with onClick listeners. This can be done in 100% native javascript. Even things like three.js or D3.js are not even needed, but I am fine with using them as it would make some things a lot easier. React as a level of complexity that is not needed.
Electron: All Electron does is create a Chrome window without the top navigation. While it does have a couple of APIs allowing for direct interaction with the computer that Chrome can't do, and the only one this project might need is a way to access the filesystem to allow users to add replays. This can still be added in the browser without Electron using an upload button, which can allow users to even upload folders.
Separation: Using a template language like Bottle would make it very easy for anyone to update and is completely separate from any Python code, though it may interact with Python if requested very easily.
Finally, I want to address the performance of Electron. I have a pretty powerful computer here. Even then, from pushing enter after typing npm start to seeing the Electron page loaded with your design took about 6 seconds retesting right now, even longer the first time. I compared this to the program that loads up my live tv application, and from pushing enter on python -m livetvserver.server to seeing the entire page loaded in Chrome took about 2 seconds at maximum.
Additionally, in terms of packaging, without electron, this program only took ~10 MB on my hard drive. With electron, it now uses ~315 MB. Seems a bit overkill when I already have Chrome installed and can launch this program in Chrome just by typing in http://localhost:3000 and see the exact same thing.
Again, I do apologize if this message seems rude, but I do not intend it to be that way. I just feel that that this could just as easily be done in Python without the need of Node.js and Electron at all. Plus, hosting this online could just be as easy as running python -m rocketleaguereplayanalysis.main --server, or maybe even python -m rocketleaguereplayanalysis.server, or just double clicking on rocketleaguereplayanalysis-server.exe and having it auto open the user's prefered browser. OBS users could even use the interface directly in OBS's browser source without any trouble.
I understand your points and I think in the end it mostly boils down to what we individually consider easier: I have more experience with Electron + React and thus find that more convenient for myself as a developer (React especially has turned from being an additional complexity to almost being a necessity for javascript projects).
I am thus not against not using Electron. I think running this app in the user's browser is very acceptable as we would save on storage and RAM usage, but at the cost of some user experience points.
The one thing I have difficulty to wrap my head around is how the backend will manage to automatically refresh the frontend data (and at a rate high enough for this application which will update data possibly for every frame in the replay files), all that without refreshing the client's web page. Are you using some kind of framework/library which takes care of these updates for you through some WebSocket? I have never used any technology of the sort, but would love to learn more about it! I had imagined that this constant refreshing would be done in Javascript, hence we had quite a different understanding of how much Javascript was going to be required for this project.
Thank you for taking the time to voice your opinion in such details! It really helped me understand your concerns and don't worry, you were not rude at all (and I hope I didn't sound like that either 😄)