Also brings an interesting question for #16: should debug mode handle this extra space or should the games do it?

Nose is, AFAIK, unmaintained plus there's some mysterious behavior in Travis CI that I hope will be remedied by this.

Give PointShape a Surface property so that it can be drawn as a sprite.

See the approach in the word search solver of programming praxis repo.

Make use of Python's logging module. 'Nuff said.

Instead of having additional window space when debug mode is active, just make use of what window space the game is already using. Just use the bottom/upper n pixel rows of the window to display debug logs. Throw an exception if window size is too small. The text should, of course, overlay on the game.

This makes #16 pointless unless I add in more config values for this.

Right now, we explicitly require GameConfig attributes to be made settable and gettable through decorators. Look into using class descriptors for them so that we no longer need to state it explicitly.

Remove unnecessary hash bang lines. Only runnable files should have them (But what if we use it to indicate the expected Python version for the file?)

Fix hash bang lines declaration (#! usr/bin/env python to #! /usr/bin/env python).

Change tabs to spaces.

So users can just instantiate this class instead of creating a dictionary.

Also, throw an error if the provisions of event and handler parameters are not met.

Right now, Publisher.notify_subscribers and Subscriber.notify expect a dictionary for arg_bundle. I think it is more Pythonic to use **kwargs instead.

Because in the Docker image, the default user is pygame, which, odds are, different from the uid of the native user which owns the source directory we are mounting.

And make the color vary depending on the log severity.

Also, maybe use nose2, since nose is an abandoned project.

So you can't, for instance, have a button alongside a clickable QuadraticGrid.

Might want to try checking how debug mode affects the Color Blocks game since that game actually uses QuadraticGrid (AFAIK, in contrast to Snake which only uses the algorithms of QuadraticGrid and not the grid model itself).

Would've used SemVer but it feels too formal and constrained for something that is under heavy development.

Also, as of this time of writing (and earlier, by a few weeks), the code/demos in release "Milestone1" is no longer compatible with the framework.

It already takes in a GameScreen which, in turn, already takes a GameConfig. The original purpose of taking in the GameConfig can be filled from there.

Furthermore, this opens up to confusing behavior if GameScreen and GameLoopEvents are given different GameConfig instances.

Building from branch logging-dockerenv-fix:

cestioco@nb-hwygy33:PyGame-Objects$ ./duckrunner demo.snake.game
2020-08-28 09:45:06,633 WARNING Can't open a file handler. Logs won't be written to file.
No protocol specified
No protocol specified
No protocol specified
Fatal Python error: (pygame parachute) Segmentation Fault
pygame init
Aborted (core dumped)

Maybe we have to update base image. Or Python/Pygame.

Enabling debug mode should automatically cordon off the area set for debug logs. See short self-contained example of this at algorithms/grids/main.py of skytreader/pydagogical@fada85a.

Checkout skytreader/pydagogical@10caf39 and run algorithm.grids.main for a minimal, self-contained example.

This is confusing!

Like buttons or about modals.

Basically create a mini-Kivy. Haha.

For this, should probably specify a fixed-width font as well.

Might tie in with #6 but, instead of explicitly invoking notify_subscribers everytime a config changes, why not just provide a decorator for it?

For UI/UX!

Keep making games and improve documentation as it goes. Not gonna close until I'm satisfied!

Check out Factory Pattern --- might be usable for instantiating Views.

This does not affect the current development code as much while the only UI element available is a button (whose only event is a click). But take, for instance, a UI element that responds to keyboard events.

Where to put handler functions?

Most sensible place seems to be in GameLoopEvents. However, handler functions are actually attached inside GameLoop.

Either way, this requires users to interface method calls in Sprites, Images, Models, etc. to handle events. That is tedious.

And while you're at it, define proper endgame conditions too. Collisions determine a defeat conditions but what determines a victory condition?

Distro: Ubuntu 20.04.1 LTS

Sample log:

$ ./duckrunner demo.snake.game
2020-08-31 12:44:56,413 WARNING Can't open a file handler. Logs won't be written to file.
No protocol specified
No protocol specified
No protocol specified
No protocol specified
Traceback (most recent call last):
  File "/app/components/core.py", line 166, in go
    self.loop_events.loop_setup()
  File "/app/components/core.py", line 517, in loop_setup
    self.configurable_setup()
  File "/app/components/core.py", line 501, in configurable_setup
    window = self.invoke_window(self.game_screen.screen_dimensions)
  File "/app/components/core.py", line 473, in invoke_window
    self.__window = pygame.display.set_mode(window_size)
pygame.error: No available video device
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
pygame init

In general, running via GUIs via Docker seems different now.

See: https://github.com/skytreader/PyGame-Objects/wiki/Standards-and-Conventions

Make it so that all tuples describing positions describe them as (row, col). draw_offset currently uses (width, height) and is confusing.

Make Image observable since it is just an encapsulation of the common functionalities of images in a game.

From here, we can make Sprite classes observe Image instances.

Drawable objects should be able to know how big the allotted screen is. In fact, I think all objects should be able to do just that. So that they can scale their actions depending on the size of the screen.