Published on January 24, 2010
I’ve put a lot of thought into best practices for exception handling. The guidelines described here are intended to maximize readability and maintainability of the code, as well as exposing failure information without looking up source code. In professional and personal projects, the experience with this method has been a very positive one.
Summary
- Centralize error message construction to ensure consistency
- Catch generic errors and throw specific errors in their place
- Include as much information as possible about the error in the message itself
- Exceptions are a tool to help solve problems, they are not problems themselves
- Always throw an exception the moment the application state becomes invalid, rather than waiting for it to become a problem
Fatal Exceptions in Actionscript 3.0 continued »
Published on January 15, 2010
Measuring all of my progress in small verses isn’t going to work as the project expands, although I will continue to use them to express my immediate goals. I also have some major milestones in mind, such that there is a complete game at each milestone that I can cut a version of and release. My current target will be called Rooms. Before I move onto to building a larger game world, I need to be able to pack some interesting things into a single room. The following are my high-level goals for Rooms and some details on room types in particular.
IllFate Long Term Goals continued »
Published on January 7, 2010
Now that the busy holiday season is over, the steady progression towards being an actual game continues. There is now a single obstacle to escaping The Room; you have to pick up the key from the floor in order to open the exit door. It doesn’t sound like much, but it required quite a bit behind the scenes to get it working. Saving and loading are also working now.
Verse 1:4
Door locked securely
First obstacle encountered
Where did that key go?
IllFate Verse 1:4 Completed continued »
Published on December 29, 2009
Saving and loading the game is potentially a rat’s nest of bugs for a complex game if it’s not done right. This is my approach to it in IllFate, complete with source code and some explanation. If you’ve had experience with similar systems or have any questions about the approach I’ve taken, I’d like to hear about it.
Saving and Loading in IllFate continued »
Published on December 26, 2009
What I expected to be easy turned out to be a rats nest, all because I didn’t maintain my diligence when completing verse 1:2. I had no tests for velocities higher than one. I knew it would be a problem when I did it, but it turned out much worse than I anticipated. I ended up scrapping the entire physics class in favour of something closer to real physics. I will be more diligent about not writing any code that isn’t satisfying a unit test, even if it means building out features a bit beyond what the current verse requires.
Verse 1:3
In quite a hurry,
but the ice is treacherous.
The walls are not soft.
IllFate Verse 1:3 Completed continued »
Published on December 21, 2009
I’ve completed development to satisfy my second requirements Haiku. When the player reaches the door, they win, and the game is reset to its original state.
Verse 1:2
Walk across the room.
That door looks awfully nice.
I just won the game.
IllFate Verse 2 Completed continued »
Published on December 16, 2009
A friend of mine wanted to get a look at the visual verification I’m using to unit test my rendering code, so I figured I might as well give it a spit-shine and share it with anyone that might find it useful. If you are working with pixel art a lot, especially if you are working on a tile-based game, this might be useful. It won’t work well in most other situations, since it expects pixel-perfect matches.
Visual Verification with FlexUnit continued »
Published on December 16, 2009
I am starting development of a Roguelike as a way of familiarizing myself with some development practices which I haven’t had a chance to use professionally yet. IllFate Project continued »
Published on May 24, 2009
TOJam will always be a special time of year for me, right up there with Christmas. It’s an amazing experience to sit down in a building filled to the brim with people who share your passion and are driving towards a common goal. TOJam 4 continued »
Published on June 10, 2008
I just ran into a frustrating issue with Flex Builder 3 that wasted my entire morning. I did manage to track it down, however, and thought I’d share it.
I was using Flash CS3 to create a SWC with an embedded image, and then creating an instance of that image from Flex Builder 3. Flex threw an “Internal Build Error” whenever I tried to touch this image’s class. According to the build failure log, the compiler was choking up when it was trying to get symbols from the SWC.
As it turns out, when you create an extension of the BitmapData class in Flash CS3, and set it to re-encode as JPEG, Flex can no longer convert that image to a format it understands. As soon as I changed the settings to export the image as Lossless, the compiler error disappeared, and everything worked. The image works fine in Flash CS3 either way, so there must be a bug somewhere in the Flex compiler in regards to JPEG imports.
Posts