commit 1246f52201a78677f16e7e7ac87ae9e940bb2c41
parent 69c68b14de1a78b2c1056d2c9c173f9a1d56aed8
Author: Erik Letson <hmagellan@hmagellan.com>
Date: Thu, 22 Oct 2020 18:01:51 -0500
Planning and preparing
Diffstat:
5 files changed, 90 insertions(+), 0 deletions(-)
diff --git a/main.py b/main.py
@@ -18,6 +18,7 @@ from src import game
# manager objects could access the exposed values by talking to the bus. Additionally, the bus could enumerate all the managers that have been given
# bus access, and could expose these managers to other managers as part of a public list/dict. These features would eliminate the ugly "so-and-so.game"
# calls that are popping up all over the code here.
+# 6. Implement the pre-rendered cutscene playing methodology using Pyglet as described here: http://www.sbirch.net/tidbits/pygame_video.html
# Initialization of pygame and submodules
pygame.mixer.pre_init(44100, -16, 4, 1024)
diff --git a/src/board.py b/src/board.py
@@ -6,6 +6,12 @@ from .constants import BOARD_PATH
# board.py #
############
+# TODO:
+# 1. BoardManager should do the things GameInterface does with regards
+# to frame-by-frame board interaction. This file should not require
+# so much refactoring as vgo.py to bring the new implementation of
+# managers into compliance here.
+
# This file contains:
# 1. The BoardManager class, which manages boards and swaps between them
# 2. The Board class, which represents a grid of Tile objects and is the play area
diff --git a/src/manager.py b/src/manager.py
@@ -1,5 +1,43 @@
import pygame
+##############
+# manager.py #
+##############
+
+# TODO:
+# 1. A "ManagerBus()" object should be defined in this file.
+# 2. Possibly rename "Manager" to "Subsystem"? idk, maybe a bad idea...
+# 3. As opposed to 2, it is possible that Subsystem should be reimplemented, and that Manager should source from it. GameInterface and ManagerBus
+# are both sufficiently different from what the abstract concept of a Manager is that they should probably be something else entirely. A generic
+# Subsystem object would be the simplest possible Game-component object, and would likely simply have a reference to its game and nothing else.
+# Possible extensions:
+# 1. An "update_managed(self, surface = None)" method prototype to be overridden in child objects. This method would handle all logic that involves
+# updating the objects that a manager manages, and thus would have to be tailored to the specific manager. Implementation advantage would be that
+# managers could be called together as a group to update in game, and could possibly be stored in a dict rather than have individual attributes
+# they are associated with (would be very useful if implementing the ManagerBus() object).
+# 2. An "activated" bool value and associated setgets that would be used to determine whether or not a manager should update during an update pass.
+# 3. Support for a ManagerBus() object (details pending, refer to main.py)
+# 4. A generic "trigger_effects(self, effect_list)" method. This would implement a regularized form of the methods already present in SceneManager
+# and MenuManager. It would rely on a regular style of effect-encoding in JSONs, but that already exists in the codebase and so far seems general
+# enough for all possible extensions in this game. The "trigger_effects" could be extended by calling super() and then extending as needed in the
+# new object. One detail that would have to ironed out is that all effects would have to have a unified unique naming structure across all JSONs
+# and managers (nearly there already, minor detail not really a problem). Perhaps there should be an enum for the effects that should be common
+# across all managers? Additional single-manager-specific effects could be added as an attribute enum of the given manager at init and the extended
+# version of "trigger_effects()" could search this other enum instead of the universal one defined in constants.py. Also, a manager should have a
+# "effectual" bool value and associated setgets that determines whether or not it even checks for effects under any circumstances (this should
+# be subordinate to "activated" and dependent on the latter to function). This means that effect-checking should probably be a regular part of the
+# update loop rather that specifically called for by objects themselves (this is ambiguous right now).
+# 5. Perhaps a generic "load_json" function that could be extended? The base function could store the JSON in a dict in the manager object, keyed by
+# file name. Extensions could be added for specific JSON fields/local values. This may not be possible, however, need to investigate...
+
+# This file contains:
+# 1. The Manager object, which is the parent of other managers that perform functions directly subordinate to the Game object.
+# 2. The ManagerBus object, which handles inter-manager communication and exposes manager/game object attributes
+
+##################################
+# Section 1 - The Manager Object #
+##################################
+
class Manager(object):
"""
Extremely simple parent type for the various
@@ -10,3 +48,24 @@ class Manager(object):
def __init__(self, game):
self.game = game
+
+#####################################
+# Section 2 - The ManagerBus Object #
+#####################################
+
+class ManagerBus(object):
+ """
+ Shared communication object that ALL interaction
+ between manager objects should go through.
+ """
+ # What SHOULD go through ManagerBus:
+ # * Manager-to-Manager communication
+ # * Manager-to-external-object communication
+ # * ANY object talking to a manager BESIDES Game
+ # What SHOULD NOT go through ManagerBus:
+ # * Direct communication from Game to a manager
+ # * A Manager talking to an object it manages
+ # * An object talking to its own manager
+ def __init__(self, game):
+
+ self.game = game
diff --git a/src/unit.py b/src/unit.py
@@ -6,6 +6,9 @@ from .constants import STATUS_JSON_PATH
# unit.py #
###########
+# TODO:
+# 1. The utility/appropriateness of this entire file is suspect. Especially seems like Unit does not need its own manager.
+
# This file contains
# 1. The UnitManager class, which loads Unit JSONs and keeps track of them (like SheetManager)
# 2. The Unit class, which represents the statistics of a charachter unit
diff --git a/src/vgo.py b/src/vgo.py
@@ -6,6 +6,27 @@ from .constants import *
# vgo.py #
##########
+# TODO:
+# 1. Some serious refactoring needs to happen here. EntityManager needs to
+# be brought in line with how managers in general are imagined to work
+# now, especially if the generic manager is going to be significantly
+# extended and the bus is going to be implemented. The differences
+# between a VGO and an Entity are blurred right now. Hypothetically
+# speaking, an Entity should be an extended VGO that has features that
+# go beyond what a generally-extended pygame Sprite object should have.
+# A VGO is a just a sprite that can be drawn and animated by any other
+# object, but an Entity should be created and managed ONLY by the
+# EntityManager object, because of its extensions. Positioning and
+# animating can be VGO functions, but objects you interact with should
+# be Entities. This means the EntityManager should be active and working
+# in any mode that has on-screen object interaction (e.g. in Menu mode).
+# This is NOT how EntityManager currently works and refactoring of the
+# EntityManager, Entity, and VGO objects will be required to bring the
+# imagined function of this system of objects to realization. One way to
+# accomplish some of this would be to try to encapsulate more of what
+# EntityManager does each frame into its own update method, and make
+# the behavoir therein game_mode-conditional.
+
# This file contains:
# 1. The VisibleGameObject class that defines the abstract parent of all entities and other visible sprites
# 2. The Entity class that defines the objects that represent non-UI-element game objects
