Grimmys / rpg_tactical_fantasy_game

A tactical turn-based game project in pygame, open to support
GNU General Public License v3.0
394 stars 85 forks source link

Unintuitive Elements #24

Closed UmbralReaper closed 3 years ago

UmbralReaper commented 3 years ago

Unintuitive to Players

Unintuitive in the Codebase (to me, anyway)

None of these (especially those under code style) are intended to be offensive - I'm simply curious.

Grimmys commented 3 years ago

First of all, I think it's important to keep in mind that this is a WIP and not such a serious project : many things are wrong only because I don't spend too much time thinking.

About your remarks concerning the gameplay :

Many of these remarks are true, and are really interesting. Yes, the game is not perfect since it is not finished, I was already planning to add some of these features, but you are right to point the fact that this should be a priority. So thank you, I will definitively add new cards to my Trello!

I will just discuss more about some of them :

"You have to open the menu to start."

I know it might not be that intuitive, but this design is inspired by games like the original Fire Emblem series, or FF Tactics, where you have to prepare for the fight, before opening a menu to start the game. But indeed, it's could be improved. Maybe I can add a keyboard shortcut (press S to start for example) or add a button " Start " to the main UI.

" Once you've used a potion from the inventory, you must wait - but the game does not auto-wait you. "

For this one, it's intented: I chose to let the player do something else after using an item. Like attacking a foe, or make a trade with another player etc. It's more of a test, it's probably too cheated (you could use multiple items during the same turn, just before a duel...).

About your remarks concerning my code base

" Why do you use from x import * when you could use from x import y, z "

It should be a simple mistake. I generally let Pycharm manage the imports for me, but maybe I took a little shortcut somewhere... Also, a lot of my files only contain two elements, so in this case, it could be more logic to import the whole content if both elements are needed.

" Why do you use auto() for enums? "

Because I don't want to manually assign values, since I generally don't need them. What would you advice me to do?

" Why do you not use type hints? "

Didn't know of this feature (I'm not really up to date with Python), I will consider using it, thanks.

" Why raise SystemExit instead of sys.exit() "

No specific reason, it's basically the same. Anyway, I'm even not really sure about the need of this statement in my code.

" Why are src.gui.constantSprites and src.gui.fonts built using an initialisation function rather than being a dict literal? "

Because the content of these files depends on the initialization of pygame ( pygame.init() ), but I could probably do something else.

" _Why is showfps in main.py a function? "

I'm constantly refactoring my code, and I'm currently planning to refactor this function. I may move it to tools.py .

PS : Sorry for my bad english, I'm not a native and I'm too lazy for correcting a so long message.

UmbralReaper commented 3 years ago

this design is inspired by games like the original Fire Emblem series [...]

I don't typically play many games like this, so if it's a staple in this kind of game, then it's completely fine.

For this one, it's intented: I chose to let the player do something else after using an item.

So you can do something after using an item! In that case, it's completely fine. I was under the mistaken impression that you couldn't, probably because I used the item while standing next to only empty space.

Most of these questions are simple curiosity on my part. I am a fairly (~1 year of experience) new python developer, so I am interested in the choices people make when writing their code. For example, it doesn't matter whether you manually assign enums or use auto(). I was simply curious about your motive behind using one or the other.

Because the content of these files depends on the initialization of pygame ( pygame.init() )

It does not. Try a simple script:

import pygame
image1 = pygame.image.load("image1.png")
image2 = pygame.image.load("image2.png")
image1.blit(image2, (0, 0))
pygame.image.save(image1, "test.png")

Thank you for replying so quickly. I appreciate it.

Grimmys commented 3 years ago

OK I understand better, no problem.

I was curious to know if you had a better solution to auto assign value to enums because I don't like this way, I would prefere a light syntax like in C, but it doesn't seem to be possible in Python.

Because the content of these files depends on the initialization of pygame ( pygame.init() )

It does not. Try a simple script:

import pygame
image1 = pygame.image.load("image1.png")
image2 = pygame.image.load("image2.png")
image1.blit(image2, (0, 0))
pygame.image.save(image1, "test.png")

The load or blit statements are not the problem, it's the convert methods and the font loader that require pygame to have been initialized. Moreover, transformation ( pygame.transform.scale ) can't be done without a video mode that was set beforehand ( pygame.display.set_mode ). You can try to move the order of the calls in the main.py file and you will see that the game is not running anymore. :D

UmbralReaper commented 3 years ago

I was curious to know if you had a better solution to auto assign value to enums because I don't like this way, I would prefere a light syntax like in C, but it doesn't seem to be possible in Python.

Have you seen the functional API? You can declare enums like this:

Animal = Enum("Animal", "ANT BEE CAT DOG")
Numbers = IntEnum("Numbers!", "one, two, three, four, five, six, seven")

it's the convert methods and the font loader that require pygame to have been initialized.

Hmmm. That's an interesting problem. You could use a different image library, but that is over the top for just a refactoring change. I'm not sure how that could be done better.

Grimmys commented 3 years ago

I will check this API, this seems interesting, thanks!