fix: proper integration with database and following of architecture

[LordTlasT]

Description[^1]

The theme of this pull request is making sure the location.py and travel commands work as designed.

Modifications[^2]

location.py:

• added a new Coordinate class to use for Player and Location and do calculations on positions. Later on Location and Player might have a Coordinate attribute. This was needed because Location was functioning like a Coordinate which it is not.
  • has a distance_to() function for calculating distance between two positions
  • has a is_location() function for knowing if there is a location at the coordinate
  • added a classmethod to create a location from a coordinate

travel_cog.py:

• moved the is_planet() to is_location() in coordinate, I think this makes more sense because this means we can use Coordinates to look up locations and we do not use planets yet / every location is a planet.
• use coordinates for traveling

player.py:

• scan(): remofed the use of a location

database.py:

• I added comments to organize the functions by categories, this will make it easier to redesign the database module later on. And will keep everything organized for searching.
• I added getresult() which gets the first result, useful for the new init() logic which I want to use everywhere else for initializing new objects from the database instead of getting each attribute one by one.
• added location_init() to read a location from database
• added planet_id_by_pos() to get a planet_id with a position if it's needed to know if a location is indeed a planet

travel_cog.py:

• Use the new Location/Coordinate logic instead

Additional remarks[^4]

The random image part has to be rewritten, I made sure it will be by hardocding "../assets/space0.jpg", this is because I think the code should know how much images we have and pull from there instead of using randrange(1, 9)...
It is not possible to create a location object with a coordinate when the location with said position is not in the database. This will throw an error.

[^1]: Description of the pull request. [^2]: Modifications, commands modified and explanation. [^3]: Files added, commands added and explanation. [^4]: Additional remarks (e. a. documentation needs to be updated)

[IGLADI]

floating in space picture has been discussed and we be done afterwards in the corresponding branch by calculating per zone (so zone1 =x0y0-x100y100 and have their specific picture and so on for every 100units)

[LordTlasT]

I think the choosing of images is a seperate matter of this pull request I propose following algorithms:

1. Have a max map_size and segment our map by the number of pictures MAP_SIZE = 500 x = pos.x/MAP_SIZE*len(pictures) y = pos.y/MAP_SIZE*len(pictures) picture = pictures[x][y]
   • This needs to have an array of x*x pictures.
   • This relies on calculating the map border, which at this point is the maximum value of an int
2. A new picture every x units. units = 50 x // units y // units picture = pictures[x][y]
   • We need to have enough pictures for this, so might use modulo instead for now.

PS: if none of this are good let's open a seperate issue for this