commit 5c38967ff1ecd75943143cc495d5168a233c47f1
parent bd76dcc88bfa060f836bc5ab48909b56509d208d
Author: Erik Letson <hmagellan@hmagellan.com>
Date: Sat, 31 Oct 2020 15:20:01 -0500
Basic form of turn manager object
Diffstat:
3 files changed, 66 insertions(+), 1 deletion(-)
diff --git a/src/constants.py b/src/constants.py
@@ -26,7 +26,7 @@ COLORKEY = (255, 0, 255)
# Other constants
PIECE_MOVE_SPEED = 2
PIECE_MOVE_DELAY = PIECE_MOVE_SPEED * 4
-SCROLL_SPEED = 3
+SCROLL_SPEED = 4
# File paths
DATA_PATH = os.path.join(os.getcwd(), "data")
diff --git a/src/turn.py b/src/turn.py
@@ -0,0 +1,51 @@
+import pygame
+from . import manager, vgo
+from .constants import *
+
+###########
+# turn.py #
+###########
+
+# This file contains the following:
+# 1. The TurnManager class, which handles turn order and displaying turn info in the GUI
+# 2. The TurnTray Entity subclass, which represents the
+
+#################################
+# Section 1 - TurnManager class #
+#################################
+
+class TurnManager(manager.Manager):
+ """
+ TurnManager handles organizing turn order, deciding
+ who's turn it is, and displaying upcoming turns and
+ info about the current turn in the UI.
+ """
+
+ def __init__(self, game):
+
+ # Parent initialization
+ super().__init__(game)
+
+ # Important values
+ self.current_turn = 1
+ self.current_active_piece = None
+ self.turn_order = []
+ self.turn_tray = None
+
+##############################
+# Section 2 - TurnTray class #
+##############################
+
+class TurnTray(vgo.Entity):
+ """
+ The TurnTray is the on-screen object where icons
+ and names representing the next Pieces to take
+ their turns are drawn to. It is a seperate class
+ mostly because it must write specific text.
+ """
+
+ def __init__(self, name, ent_id, sheet, sprite = (0, 0), animation = None, animated = False):
+
+ # Parent initialization
+ super().__init__(sheet, sprite, animation, animated)
+
diff --git a/src/vgo.py b/src/vgo.py
@@ -26,6 +26,20 @@ from .constants import *
# 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.
+# 2. An alternative to the above: Reimagine EntityManager as PieceManager,
+# Meaning it is only responsible for board Piece entities. The BoardCursor
+# could be handled by a seperate manager of its own, which could manage
+# the cursor across multiple modes. This would mean splitting the EntityManager
+# and Piece classes off into their own source file (a good option would
+# be to combine them with Unit, remove UnitManager, and just make units
+# be something PieceManager handles). All of this would be in line with
+# the natural path that the code has been taking, whereby there is not
+# one single management object for ALL entities, but rather entities and
+# other VGOs are drawn and updated by the managers that logically are
+# already associated with them. Drawing entities is a pan-Manager thing,
+# and one of the important distinctions between managers and subsystems.
+# The codebase should probably reflect this by doing away with EntityManager
+# entirely and refactoring it into PieceManager.
# This file contains:
# 1. The VisibleGameObject class that defines the abstract parent of all entities and other visible sprites