Return to repo list

heart-of-gold

Tactical RPG written in python, using pygame.
Return to HMagellan.com

commit 1246f52201a78677f16e7e7ac87ae9e940bb2c41
parent 69c68b14de1a78b2c1056d2c9c173f9a1d56aed8
Author: Erik Letson <hmagellan@hmagellan.com>
Date:   Thu, 22 Oct 2020 18:01:51 -0500

Planning and preparing

Diffstat:
Mmain.py | 1+
Msrc/board.py | 6++++++
Msrc/manager.py | 59+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Msrc/unit.py | 3+++
Msrc/vgo.py | 21+++++++++++++++++++++
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