configuration file

[laurentperrinet]

the game should be controllable by a configuration file which allows to tune the different aspects of the game, from the window size, speed of ball angle, predictability etc...

there are different ways of doing that, see https://martin-thoma.com/configuration-files-in-python/

• there is https://docs.python.org/3/library/configparser.html - yet it is python3 only

• I personally like JSON or INI files

[Syht]

I chose JSON and I'm currently writing the configuration file. EDIT: I changed my mind and chose .INI file instead because it is faster, easier to use and is enough for what we want to do.

Is it really necessary to control the window size through the config.json file ? I'm asking because the parameters which determine the window size are many. They are not correlated with each others and thus it might be hard to control the window size with few values. I'm not sure how to link them together correctly, but if controlling the window size really is important I'll try my best.

[laurentperrinet]

ok, sounds right.

I would guess the window size (in pixels) is that from which you deduce the size of all elements in the game (from the paddle to the ball), am I wrong? (I am thinking of having to run the same game on 2 computers with 2 different screen resolutions)

[Syht]

The sizes of the ball and the paddle are not related with the screen size.

What I meant was: If you wanna change the screen size, you'll need to act on the following parameters:

• height and width of the window (currently 720 and 960 respectively)
• height and width of the PLAYABLE window (cf. class Arena). The parameters are tileside (the size of the side of the background element), numxtiles (the number of tiles on the abscissa axis) and numytles (idem for the ordinate axis). Those 3 parameters will determine the playable area.
• the aesthetic: there are matrices which pick the borders sprites on the spritesheet. The number of elements of these matrices will determine the length of the borders. And so, if you change the playable screen size, you'll need to adapt the number of elements of the matrices in order to avoid weird-looking borders.

I think I can correlate the screen size and the playable screen size relatively easily, but I don't know if I can for the borders.

[laurentperrinet]

indeed I understand that there is a hierarchy of boxes and objects to construct the game.

one solution is to use an interpolation method to resize the size (say at your original pixel size) to any other size. maybe this is available directly though pygame?

[Syht]

I didn't quite understand what you meant but I managed to link the window size and the playable size together. You can play with this parameter in config.ini As I said yesterday, the remaining problem is aesthetic: the borders aren't affected by the resizing of the window and thus it gives you visual problems as follow.

With a smaller screen

With a wider screen

A solution would be to simply eliminate the borders, since they are only aesthetic. What do you think?

[laurentperrinet]

what I meant was to use the resizing feature of pygame:

https://duckduckgo.com/?q=pygame+resize+window&t=ffab&ia=qa

see for instance: http://pygame.org/wiki/WindowResizing?parent=

I have implemented it in https://github.com/Syht/StochPong/commit/68bc94a7f2b29afbc936402c2c084b07a0f3344d

once you set up a correct window size, you can close the issue :-)

[Syht]

If I do get it, it means that we place a "support" picture in the folder and the resizing function will set the window size to the picture size? I'm still quite confused about the usefulness of it. I think I misunderstand something.

Off topic: Thanks for the Try: eyetracker=true Except: eyetracker=false I didn't know how to do that, you save me some time!

[laurentperrinet]

with resize, you create once a for ever a window with given pixel sizes and draw it - when resizing you adapt the pixels on this (virtual) screen to adapt to the window size on your (physical) screen - then one (virtual) pixel is not necessary one (physical) pixel

in computer vision we most often use internally interpolation (like https://en.wikipedia.org/wiki/Bilinear_interpolation) to do that

[laurentperrinet]

The main code has a lot of space devoted to variables describing the different levels of the game: could you just enter that in the configuration file? this would make the code more readable and .. more fun as you could imagine new levels (and even code to produce these levels...)

[Syht]

I moved the levels definition into the config.ini file. It is indeed much clearer than before. When you say code to produce new levels, you mean with a graphical interface and some leftclick/rightclick to add/remove bricks at the selected location? Or do you mean something else? I saw in others breakout.py games that it is possible but I'm not sure that it would be really useful to the study? The levels are already quite easy to create whith our matrix representation.

[laurentperrinet]

On 29 mai 2017, at 15:18, Thys Giaccone notifications@github.com wrote:

I moved the levels definition into the config.ini file. It is indeed much clearer than before. When you say code to produce new levels, you mean with a graphical interface and some leftclick/rightclick to add/remove bricks at the selected location? Or do you mean something else? I saw in others breakout.py games that it is possible but I'm not sure that it would be really useful to the study? The levels are already quite easy to create white our matrix representation.

at this stage, doing it by hand is reasonable. I was thinking in fact to have a python script to generate them and notably to balance the number and position of "bad" vs "good" blocks

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Syht/StochPong/issues/2#issuecomment-304659223, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXTcBMkl68KFZ3aeMMlqRcpBItg8Ipdks5r-sWWgaJpZM4NQpAd.