June 2025 Progress Report

 June was actually a decent month for productivity.  It's rarely as much as I hope for, but I am grateful to have finally implemented some things I'd been considering and get a start on the big, important things to come.

A ghost!

Accomplishments

• Ghosts are in the house!  They don't do anything yet, but ghosts exist!
• The ghost controller has been started...barely.  It is not yet functional.
• I implemented steering forces to influence player character movement.  It's still not perfectly streamlined, but noticeably improved.

Known Issues

• The tile map subsystem has been improved slightly, but is still a little bit of a mess.
• Though it has been improved, there is still some poor cohesion in the application structure that should eventually be addressed.
• There are still likely performance issues in tile map actor collision checking.  I'm going to hold off on addressing this until I see if/how it affects the game's performance.

Next Steps

• Finish implementing ghost movement.
• Refactor engine's tile map system
• Implement dialogs and text areas
• Choose and create a game font for normal text
• Create container objects
• Cabinets, chests, etc.
• Continue to improve the game's runtime architecture
• Consolidate game's input functionality
• Decompose game screen code to MVC pattern
• Consider cohesion issues vs. class explosion risks

April-May 2025 Progress Report

I skipped the progress report in April because there was very, very little progress to report.  My sole "accomplishment" for that month was to analyze the physics and AI code from MHFramework 3 and refresh my memory on its features, interfaces, strengths, and weaknesses.  That was all.

May was a bit more productive.  Not nearly enough to catch up with the project plan, but it began a long and complex path toward the implementation of some core functional requirements for Operation SCARE.

Accomplishments

• Through a lot of trial and error, I ported my old Java code to C#, and then refactored it into a more modular and dynamically customizable set of behaviors.  Testing is currently in progress.

Known Issues

• The tile map subsystem is spaghetti.  Before I go any further with the ghost AI, I need to clean it up.
• Though it has been improved, there is still some poor cohesion that should eventually be addressed.
• Potential (likely) performance issues in tile map actor collision checking
• Need to improve player movement and wall collisions through steering forces.

Next Steps

• Refactor engine's tile map system
• Implement dialogs and text areas
• Choose and create a game font for normal text
• Create container objects
• Cabinets, chests, etc.
• Continue to improve the game's runtime architecture
• Consolidate game's input functionality
• Decompose game screen code to MVC pattern
• Consider cohesion issues vs. class explosion risks
• Experiment with better wall geometry
• Implement ghost controller

March 2025 Progress Report

March didn't see quite as much progress as I had hoped, but a few important things happened, and steps were taken to harden work that had already been done while smoothing the way for work yet to come.

Accomplishments

• Implemented the candy visibility feature so that it is invisible until the player character is near it.
• Began cleanup of the general architecture surrounding the game state.  More needs to be done, but good steps have been taken to optimize and simplify the model-view-controller nature of it.
• Located AI code from MHFramework 3 in preparation to update and incorporate it into MHFramework 4 to support the ghost behaviors.

Known Issues

• Though it has been improved, there is still some poor cohesion that should eventually be addressed.
• Potential (likely) performance issues in tile map actor collision checking
• Need to improve player movement and wall collisions through steering forces.

Next Steps

• Implement dialogs and text areas
• Choose and create a game font for normal text
• Create container objects
• Cabinets, chests, etc.
• Continue to improve the game's runtime architecture
• Consolidate game's input functionality
• Decompose game screen code to MVC pattern
• Consider cohesion issues vs. class explosion risks
• Refactor engine's tile map system
• Experiment with better wall geometry
• Implement ghost controller

February 2025 Progress Report

In anticipation of an extremely busy month, I didn't plan too many tasks on this project for February.  The month did indeed end up being full and challenging.  Nevertheless, I got a few important things done.

Accomplishments

• Implemented door functionality
• I haven't tested locking yet, but opening and closing work, along with correctly updating the collision map and generating audio events.
• Updated actor factory to recognize door identifiers and spawn doors
• Implemented candy collection
• The world loader now populates the house with candy, which the player character picks up upon colliding with it.  There was a bug with the candy spawning inside the walls, which then caused the player character to get stuck in the wall when picking up the candy. This was caused by the fact that the collision map had not yet been created by the time the candy was instantiated.  Now the tile world objects update the collision map immediately upon creating the actor list.

Known Issues

• Messy class structures with poor cohesion, especially surrounding the game's input handling and the engine's tile map system components
• Potential (likely) performance issues in tile map actor collision checking
• I'm still not completely satisfied with collision around wall edges. Not sure if the solution will be a visual improvement to the walls or a physics trick.  I want to try calculating the center point of the tile the player character is moving to and use a steering force to move him/her.

Next Steps

• Implement the candy visibility feature
• Candy should be invisible until the player character is near it
• Implement dialogs and text areas
• Choose and create a game font for normal text
• Create container objects
• Cabinets, chests, etc.
• Reconsider the game's runtime architecture
• Consolidate game's input functionality
• Decompose game screen code to MVC pattern
• Consider cohesion issues vs. class explosion risks
• Refactor engine's tile map system
• Experiment with better wall geometry
• Implement ghost controller

Getting Started on Operation S.C.A.R.E.

Welcome to the project journal for Operation S.C.A.R.E!

This is my first new game project in a decade. I won't retell the story of my absence here, but believe me when I say that I have missed this work more than you can imagine.

Operation S.C.A.R.E, in a nutshell, is intended to be a spooky, kid-friendly adventure of exploring a haunted house, dealing with greedy ghosts, and reclaiming the Halloween candy that the jealous ghosts stole from the neighborhood kids.  It contains the light survival-horror elements of limited resources, inventory management, and virtually invincible enemies inhabiting a creepy, atmospheric environment.

Last year (2024) saw the preproduction aspects come together, including the establishment of the concept, the creation of the game engine, several iterations of level design, acquiring candidate assets, and the ever-important game design document (GDD).

Now, at the end of January 2025, I find myself having made more progress in a month than I ever had before. The only game of mine that came together as quickly as this one has so far was CornShark, which went from concept to Alpha in just a few short months.  However, I was a student at the time and only working part-time at two jobs, so I had an unusual amount of time to dedicate to it.

My progress is about to slow, as the Spring 2025 semester is in full swing and a considerable workload is barreling toward me.  Therefore, it is extremely important that I remember my progress so that it can be resumed at the next opportunity.

Here is a quick list of what has been accomplished in January:

Accomplishments

Changes in the Engine

• Created, tested, and enhanced MHTileWorld class for coordinating elements of isometric tile worlds
• Map data file loader for tilemaps and actors
• Added overlays for floors and actors
• Added toggle for cell highlight in map views
• Added toggle for mouse pointer in MHScreen base class
• Enhanced MHTileMapActor for objects whose state as an obstacle is a toggle
• Created MHImage class to simplify image transformations
• Implemented messaging system -- tested with stairs and audio
• Implemented wall repulsion to improve navigation
• Collision map with real-time updates
• MHButton images
• Established asset pipeline for large isometric objects

Game Development Tasks

• Designed and implemented screen flow skeleton
• Game map loaded and displayed
• Game data model
• Character placeholders
• Whitebox level for main floor
• Whitebox level for upper floor
• Stairs
• Sneaking
• Started placeholder tile sets for all maps
• Implemented doors (incomplete at this point, but working)

Known Issues

• Messy class structures with poor cohesion, especially surrounding the game's input handling and the engine's tile map system components
• Potential (likely) performance issues in tile map actor collision checking

Next Steps

• Change actor factory to recognize and instantiate doors
• Implement dialogs and text areas
• Choose and create a game font for normal text
• Reconsider the game's runtime architecture

• Consolidate game's input functionality
• Decompose game screen code to MVC pattern
• Consider cohesion issues vs. class explosion risks
• Refactor engine's tile map system
• Create container objects
• Implement candy collection
• Experiment with better wall geometry
• Implement ghost controller