Yesterday I went out and bought a small whiteboard. I miss the wall-sized whiteboards we had a former company I worked at, where whiteboards covered every wall in every room. Mine were constantly filled with math and class diagrams. I like drawing out ideas and working them through visually. I really like UML as a tool for code design. It helps me to think through my code architecture and see things I might have otherwise missed.

So, like I said, yesterday I went out and bought a whiteboard. It’s only 18″ x 24″ and I had filled it within 15 minutes. But that’s alright, it got me started planning. Today I started doing some UML diagramming on my computer. I spent much of this morning trying to find a half-way decent, free UML tool for Mac OS X. This turned out to be a difficult challenge. I’ve fallen back on a tool I’ve used on Windows before called BOUML (which is available for Windows, Mac, and *nix). It’s free and it’s pretty fast and it supports the features I need. The UI is a little clunky, but it’s alright. At any rate, it should be enough to get me through this planning stage.

The reason I’m doing all of this is that through the process of building the prototype, I’ve realised that the way I initially implemented my data structures for the prototype drastically limited my ability to modify the game later on. With that in mind I needed to sit out and redesign the data structures and underlying class hierarchy in such a way that it will allow me to build the game out properly, expand it, and add other game modes easily to it. I know a lot of programmers don’t like planning stuff out, they just like to get in and start coding, but I really enjoy this stuff. Plus, if it makes my life easier 3 weeks from now, it’s time well spent.

At this point the big issue I’m trying to resolve is keeping the underlying logic that represents the state of the play area (which I’ll refer to as “the board” from now on) separate from the data that renders the “pieces” on the board. In my prototype the two were directly coupled, in fact the drawing code just called the board directly to determine what to draw. The problem with this approach is that it didn’t allow me to animate between state changes in the board. For example, let’s say I want to animate a piece falling from row 2 to row 3. If the board is stored as a 2D array of values, the piece is either in row 2 or row 3 and can’t be in both, or even between the two. So what I’m doing now is decoupling the data that represents where the piece should be rendered from where the logical board thinks it should end up. This should allow me to update the board, then animate the visual representation between it’s current position and it’s destination.

At least, that’s the theory anyway…

Owen

This entry was posted on Friday, October 24th, 2008 at 8:36 am and is filed under Technical. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.