Having a client connect to a database directly is never a good idea for security reasons.
Keep in mind what audience you attract and in what mindset you put them when you create a hacking-themed game. They will try to find security vulnerabilities in your game. Some might even mistake it for the intended way of playing it. So you need to implement security-by-design from the get go.
The permission handling system of MySQL is not fine-grained enough to control what the client can and can't do on a field level. You don't want me to do a query like
UPDATE scores SET score = 99999999999 WHERE player = "Philipp". You will need to do a plausibility check first if I actually did something to deserve that score. Actually, you shouldn't allow me to tell the server my score at all. All I should be able to send to the server is what I intend to do. The server then calculates
- if I actually can do that right now
- what effects my action has on the game state
- which of these effects I should know about
and then tell me the result.
And you certainly don't want me to execute queries like
DELETE players WHERE player = "Corviuse".
And please don't believe that you can control what the player can and can't do and know about on the client. The player could simply develop their own client software, which does not sound particularly hard considering that you intend it to be "Text based game / console like ( minimum graphics )". There is no way for you to check if the player is actually running your software or a clone of it.
That being said, it is possible to implement all these checks I wrote above as stored procedures in MySQL and only give players the permission to interact with the database through these stored procedures. But stored procedures are an advanced feature of relational databases and the language is not vey suitable for writing complex game mechanics. So when you are a "total noob" as you say you will likely have enough on your plate with writing normal SQL queries.