artq99/xeus-pygame-extensions

Framework aiming at making 2D games with @PyGame easier and faster.

xeus-pygame-extensions's Issues

Saving game utils

Scene manager supporting layers

For now, there is only one scene manager - SimpleSceneManager. It supports rendering a list of sprites contained in the instance of SimpleScene. Another scene manager should be created that would support grouping the sprites of a scene into layers.

UI system

Fields as properties (XPGESprite class)

Some fields of the class XPGESprite can be turn into attributes:

• scene_manager (read only)
• image
• rect (read only)
• active
• take_focus
• components (read only)
• focus (read only)
• name

The method set_pos can also be removed and its functionality moved to a new property position, that will be the shortcut for operating on the rect of the sprite.

All the new attributes should be well documented.

During the refactoring, the method load_image can be removed and its functionality, i.e. setting the rectangle of the sprite to the rectangle of the newly set image, can be moved to the setter of the attribute image. The property interacts_with_mouse is not being used as well and can be deleted.

Property 'icon' for the XPGEApplication class

A way to set the taskbar icon of an application should be implemented.

Current state

To set a taskbar icon now, we have to use an appropriate Pygame method before the application object is created:

pygame.display.set_icon(surface)
app = XPGEApplication(SimpleSceneManager(), (800, 600))

Use case
A programmer should be able to set the taskbar icon through an instance of XPGEApplication:

app = XPGEApplication(SimpleSceneManager(), (800, 600))
app.icon = surface

** To do:**

• The call of the method pygame.display.get_surface() should be moved to the method run_main_loop() of the XPGEApplication class
• Within the scope of this issue, the method run_main_loop() should be renamed to run()
• Implementation of a new property icon in the XPGEApplication class

Resources manager

Idea: A mechanism for the XPGEApplication class, that would scan a certain directory on startup, like resources/ for example, and load the resources into the memory depending on the resource manifest of the scene. Than it would be possible to get a resource using, e.g. res_manager.get("resource name").

Field sprite of the class SpriteBehaviour as a property

The field sprite in the class SpriteBehaviour should be turn into a read-only property. The script should never change the sprite to which it belongs.

Missing unit tests for XPGESprite class

Some functionality of the XPGESprite class is not tested. Additional test cases should be created.

The parent - child mechanism for sprites

Idea: A mechanism for sprites to contain other sprites - The children would not be directly governed by the scene manager, their position would be calculated according to their parent.

Property static in the SimpleSceneManager class

Currently there is no easy way to keep global variables, that would be independent from the scene currently loaded to the scene manager. To create such a possibility, a new property static should be added to SimpleSceneManager class. It would provide access to a dictionary, in which the user can keep the variables, that do not change on the scene switching.

Refactoring of the tests

The tests of the project are badly organised:

• They should be divided into unit tests and embedded tests.
• The method run_with_timeoug from the module test_utils is obsolete - the same effect can be achieved using simple setUp and tearDown mehtods of the TestCase class.

Renaming of the XPGApplication class

By mistake, the main application class has been incorrectly named: XPGApplication class should be renamed to XPGEApplication, to keep consistency in naming.

Method find_by_name in the class XPGESprite

The method find_by_name in the class XPGESprite is misleading and its structure and functionality should be redone. For now, the method returns a list containing the sprite, if the given name matches the name of the sprite. This way it works in XPGEGroup. This is not an ideal solution and should be restructured.

Unit tests for SimpleSceneManager class

The logic behind SimpleSceneManager is not tested. The unit tests for all the methods of this class should be created.

Moving examples into separate projects

Right now, there are three example projects within XPGE and more of them are to appear. Before ti happens, the existing ones should be moved to separate projects and documented, so we can keep this project clean.

Math utils

Fields as properties (XPGApplication class)

Some fields of the XPGApplication class can be represented as attributes:

• scene_manager (read only)
• frame_rate
• running (read only)

Documentation of the project

Removal of the class SceneManagerBase

The class SceneManagerBase was created to serve as an interface for all the scene managers, however the SimpleSceneManager class, which is the only implementation for now, would much better serve this purpose, since it delivers convenient defaults. This is why the SceneManagerBase should be deleted, and the documentation moved to the SimpleSceneManager.

Later on, it is worth considering to rename the SimpleSceneManager.

Methods on_spawn and on_kill of the SpriteBehaviour class

To extend the ability to control the behaviour of the sprites two new methods should be implemented:

• on_spawn - called after on_scene_loaded, so the things that require the scene to be fully initialised, can be done here, and when the sprite is spawned during the game.
• one_kill - called when the sprite is removed from the game.
  Along with the methods in the SpriteBehaviour class, corresponding functionality that will do the actual call should be implemented in the SimpleSceneManager. The functioning of the new methods should be thoroughly tested.

Methods spawn and kill in the scene manager

The methods have been implemented along with #22.

Tutorials & Examples

SimpleSceneManager allows to overwrite a scene on registering

The method register_scene in SimpleSceneManager does not check if a scene under the given name has been already registered. It is possible to overwrite a scene and it is considered a bug.

Methods for obtaining components of the sprite

To allow components of a sprite to communicate with each other, four methods should be created in the XPGESprite class:

• get_component_by_type(component_type)
• get_component_by_type_name(component_type_name)
• find_components_by_type(component_type)
• find_components_by_type_name(component_type_name)

Property mouse_mode in the XPGApplication class

Since in many games the mouse cursor is not needed, the way to turn hide the cursor or hide it and bind the mouse position to the centre of the screen should be implemented.

Use case 1

A programmer should be able to hide the cursor in games that do not need it completely:

app.mouse_mode = MouseMode.HIDDEN

The same functionality should be available from the scene manager of the application for easy switching between the modes:

scene_manager.mouse_mode = MouseMode.HIDDEN

Use case 2

A programmer should be able to hide the cursor and bind the mouse position to the center of the screen. For example, to control a sprite with mouse movement and to be sure, that the cursor will not reach the screen edge:

scene_manager.mouse_mode = MouseMode.BOUND

To do:

• Implementation of an enum MouseMode in a new package commons
• Implementation of a new property mouse_mode in the XPGEApplication class
• Implementation of a new property mouse_mode in the SimpleSceneManager class
• Adjustments in the run_main_loop() method of the XPGEApplication class

New mechanism for sprite components

The way in which components of a sprite are managed should be redone.

Current state

Now the components of a sprite are contained in a list and there are methods in the XPGESprite class that allow to obtain a specific one:

get_component_by_type()
get_component_by_type_name()
find_components_by_type()
find_components_by_type_name()

A new class should be introduced that would be a wrapper for a list and would hold the functionality of the methods for finding components. The class should be placed in a new package components into which the SpriteBehaviour class should also be moved.

Use case 1

A programmer should be able to get components of a sprite:

comp_1 = sprite1.components.get_by_type(ComponentType1)
comp_2 = sprite1.components.get_by_type_name("ComponentType1")
comp_list_1 = sprite1.components.find_by_type(ComponentType1)
comp_list_2 = sprite1.components.find_by_type_name("ComponentType1")

Use case 2

A programmer should be able to call some of the basic list operations on the wrapper class:

sprite1.components.append(new_comp)
sprite1.components.remove(comp)
reversed_list = sprite1.components.reverse()
count = len(sprite1.components)

for comp in sprite1.components:
    ...

Other list methods should not be implemented.

To do:

• Implementation of the ComponentList wrapper class
• Moving the SpriteBehaviour class into the new components package
• Adjustment of the examples

Property 'caption' for the XPGApplication class

The XPGApplication class is missing a property that would allow to change the caption of the app window - a shortcut for pygame.display.set_caption(). Now the cleanest way to do that is to override the whole class and call the pygame method in the __init__() method, which makes no sense, when we don't need to do anything else.

Property 'is_active' for the 'SpriteBehaviour' class

A way to deactivate single component on a sprite should be implemented.

Use case 1

A programmer should be able to prevent event methods of the SpriteBehaviour class from being called:

sprite.components[1].is_active = False

After setting the value of the property to True again, the execution of the event methods should return to their normal state.

Use case 2

A programmer should be able to control the behaviour of the sprite, when a component is activated or deactivated, by overriding appropriate methods:

class Component1(SpriteBehaviour):

    ...

    def on_activate(self):
        print("Component 1 activated")

    def on_deactivate(self):
        print("Component 1 deactivated")

and then calling:

sprite1.components[0].is_active = False
sprite1.components[0].is_active = True

would produce the output:

Component 1 deactivated
Component 1 activated

To do:

• Property is_active in the SpriteBehaviour class
• Methods on_activate and on_deactivate in the SpriteBehaviour class
• Adjustments in the examples

Property scene_manager in the class SpriteBehaviour

Accessing the scene manager from the methods of the SpriteBehaviour class is a commonly used functionality. This is why an alias for sprite.scene_manager should be created, as a property scene_manager directly in the class.

Removal of the XPGEGroup class

The initial purpose of this class was to enable grouping the sprites that have been added to a scene manager. This is unnecessary complication, since the class for layer functionality is about to be created. It is possible in the future that such class will be restored, but its implementation will certainly differ. For now, this class should be removed.

Missing tests for XPGEGroup class

There are no unit tests for the class XPGEGroup. They should be created in the module sprite_test.py.

Property screen_rect of the SimpleSceneManager class

For the purposes like easy checking if a sprite should be rendered, a new read-only property screen_rect should be implemented in the class SimpleSceneManager. It should return the descendant of the pygame.Rect class, that will hold the size of the screen.