search

eikofee / nene-quest

Reproduction of Nene Sakura's game "Nene quest" from the japanese anime "New Game!!" with SFML
MIT License
79 stars 5 forks source link

Config header for easier const & path values management #6

Closed eikofee closed 6 years ago

eikofee commented 7 years ago

After a small discussion with @engboris , we thought about referencing every constant values and texture paths for easier edits without searching in all the project which could be a pain, especially for the file structure overhaul we're talking about lately.

Since we didn't really know about how to organize these values, I gave it a try by putting all the values in a header file config.hpp. It's currently not complete (only covering most of the const values in the .cpp files), but it just gives an idea about how it would look.

Maybe it needs to be more explicit on certains values (like weapon's sprite precise position in the player's hand) or some of its values aren't that pertinent enough to figure in this file, I don't really know.

What do you think about it ?

engboris commented 7 years ago

It seems to be a great idea, especially for the controls.

As for the paths, it seems fine as well. Considering the size of our project (amount of sprites) I don't see any problem. If we were in a larger project we would have to think about how to organize the paths in a smart way to not think too much about which path we should change.

Moreover, externalizing the damage values and such provide a great modularity which is indeed necessary.

👍 Validé par Boris.

MisterDA commented 7 years ago

IMO, the best idea would be to put these values into a text config file, loaded at runtime and not compiled with your program. You could use a simple key=value format and write a little parser or use a slightly more advanced format like INI. This would allow to change the configuration without recompilation.

eikofee commented 7 years ago

A single .ini file would a little too big for the amount of static values we are using, but would be nice for things like options or controls management and more end-user friendly. If we're using multiple files, the option one should be located at the root folder, and the other files in a config folder or something.

Given the structure of .ini files, a parser should be simple enough to code.

engboris commented 7 years ago

Considering the amount of static values we have a INI file seems fine to me. What about a file for paths and another one for options ?

I don't really know how these kind of things are handled in real games.