Day 7: The Saga of the Command Pattern

Today was a busy day at work, got nothing done.

Just kidding. I was fortuitous enough to be able to study while I was at my post, allowing me to dive in and study as much as I could today. I was concerned about my lack of skill with the Gang of Four's design pattern list, so I went over as thoroughly as I could to understand each pattern. So far I managed the Command, Strategy, Factory/Abstract Factory, Builder, Prototype, Singleton (the good, thread-safe kinds), Adapter, Bridge, Composite, Decorator, Facade, and Flyweight patterns. Implementing them properly and knowing when might need a bit of practice, but I managed the Command design pattern today. 

Luckily enough, AS3 allows functions as parameters (of class Function), and allows any function to be passed into a Command object (self-made) without any need for a receiver. Luckily enough, that's about as generic as it can get, allowing a single Command class to be used for any function I need to use for something like the Input Manager. Speaking of, I managed to switch between mouse and keyboard input for Penty in Lizard Rain (elegantly stuck in a static class turned enumeration) and had some difficulty with moving the character properly; it seems that the keyDown event is fired continuously but at long intervals, and movement needed to be smooth by using booleans (isMovingInDirectionSpecified, but that's just generic) and checking it. Thankfully enough, the command to execute managed despite that bug. I also cut the movement of Penty so that it doesn't move off the screen; that also led into another bug where the playScreen (player's parent; should share width and height with stage but) expanded during game. By saving initial values, the player managed just fine (shown below).

Before getting too tired and headed to bed, I looked into the next part of development, which involved actually using the timeline frames (gasp!) for a single frame for loading screens and another frame to load assets, which were placed into an AssetHolder.

This means that in order for the code to stop at frame 1 instead of violently switching between frames, one must use the stop(); command. This is usually done in the actions tab, but a little birdy told me addFrameScript ( 0, function(){stop();} ) did the trick, and now everything's loaded and stopped at frame 1. Except... wait. There was supposed to be an error involving mismatches, according to the tutorial I followed, but nothing's wrong. Strange; I'll have to look into that when I tackle the pre-loader tomorrow.