Second the comment about code quality. Many decades ago (at least three, but at most four), during the era of terminal-style full-screen applications, I read a book about software development.
The author was a consultant, and to make this point he told the following anecdote:
He had a client who was in the automobile business of some kind (Parts? Service? Sales? Resales? I can't recall the specifics...). The client had written an app to automate an important part of the business, and taught themselves BASIC to do so.
After the client got it working for themselves, they decided to sell it to others in the industry, and it had grown into a cottage business.
The problem the client wanted solved was that certain things were taking too long for his larger customers. Could the consultant take a look at the code?
The consultant did, and saw that the client had rolled their own sorting, and was using a literal Bubble Sort, a "Schlemiel the Painter's Algorithm" (https://www.joelonsoftware.com/2001/12/11/back-to-basics/).
There were other things just like this throughout the app, and the consultant was able to make the client very happy in a short period of time.
The moral of the story as told by the consultant is this: The client's domain knowledge was far, far, FAR more important to the success of the product than the quality of the code. And until it became cripplingly slow, the client's customers put up with its slowness because it was still so very valuable to their businesses.
And so it is with games. What matters first and foremost is whether people like playing it!
Good luck to the OP!