Object Management

This is the first episode in the series that revolved around inventory manipulation and required a lot of consideration on how to best proceed with the implementation of the game. As is always the case, there are a lot of ways to design the game that allows the player to accomplish all the inventory goals in the game. The key factor when I make a decision is the time to implement. As I work on the site in my spare time and am trying to release new material every week, time to do something is always my priority.

From a programmer's perspective, the best way of dealing with game objects would be to have each game object be it's own actual object. These objects would be able to send and receive messages from each other. The messages would then change the state of the object and could communicate with the main game object to change the game's state. This is the way that things will work when I do Flex based episodes as Flex is much more programmer oriented than Flash is.

While Flash does support external objects, I personally find it easier to keep the code within the .flash file even though I come to flash from a programming background. For this type of programming, a more traditional style of adventure game programming (before object oriented programming was popular) of having the game state dictate what happens.

This is actually fairly similar method to the object oriented method. The big difference is that all the actions are within one main chunk of code that has all of the button handlers in it. When a button is clicked, the state of the game is checked and the appropriate action takes place. The advantage of using such a system is that it is fairly easy to assemble the game without requiring lots of external files that the Flash program (at least Flash 8) is very poor at handling. If you were using Flex, as later episodes do, then you are likely using anIDE that makes working with lots of separate text files very easy.