Archive for October, 2008
UML Diagrams and Code Design
Friday, October 24th, 2008
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
Publisher Deals
Thursday, October 23rd, 2008
Gamasutra is running a great feature today on deal negotiation with game publishers:
- Game Law: So, What’s the Dealio? (www.gamasutra.com) – “In his latest Game Law column for Gamasutra, veteran lawyer Buscaglia discusses how developers should work with publishers on a contract for your game – urging active, intelligent negotiation at all times.”
The article is intresting because it’s written for game developers. He looks at the commonly held beliefs about why developers get bad deals and breaks down each one into how the developer should handle it. It’s a neat read, and hopefully one that will help me someday when I’ve got a game to sell.
Owen
My Data is Safe(r)
Wednesday, October 22nd, 2008
It’s been a busy few days here at Streaming Colour.
This morning I finally got my source control repository backed up off-site. This is good news because now if my server goes up in smoke (including both redundant disks), my source tree still exists somewhere else. This should stop me from losing all of my work to date [knocks on wood].
Let me tell you what a pain this was to set up. It would have been much easier if I hadn’t cared about making sure the connection between the two servers was secure and that all the data was encrypted when being sent between the two…you know…little things. Luckily a friend of mine is a bit of a security/unix wiz and was able to help me get everything set up. He also gave me some space on his server to actually load my backup on to, so thanks!
When I haven’t been worrying about ssh tunnels I’ve been continuing to make improvement to the prototype. I’ve got two special items into the game now, which really helps with fun and playability at later levels. So, once again, I’m convinced that my end condition will work because the special items lend a lot more strategy to the game. The user feels like they have more control over the outcome of the game. I know I keep coming back to this same point, but it’s very important to the feel of the game. If there’s no challenge, why bother playing at all. If there’s no way to improve and get further in the game, why bother playing at all. It’s a tricky balance.
With regard to the business side of things, I’ve spent a lot of time over the last week dealing with PST issues. I’m not selling any products yet, but I will, and I need to figure out which provinces I need to charge PST on products vs HST vs no PST (Alberta, I’m looking at you). This has meant spending a lot of time on phone calls with various provinces’ tax departments trying to verify that what I produce is, indeed, taxable. Don’t get me started on whether or not doing contract programming work is a taxable service. Each province seems to have a different answer. Good times.
Owen
FingerGaming
Monday, October 20th, 2008
I discovered a new site (via Gamasutra) this morning called FingerGaming:
- FingerGaming (fingergaming.com) – Reviews and news for current and up-coming iPhone/iPod Touch games.
I’ve been having trouble finding a good site with reviews and gameplay videos of iPhone games, so this was a great find.
Owen
The Serious Art of Designing Fun
Monday, October 20th, 2008
Welcome to Monday, everybody! Ugh…
In other news, my friend and former collegue, Chris Khoo, has just started a blog on game design. Chris has worked in the games industry for over 11 years and wants to start sharing some of his thoughts on the processes of designing and creating games. Check out his blog if you get a chance:
- The Serious Art of Designing Fun (khoolworks.homedns.org) – A development blog by Chris Khoo
In prototype news, I’m making progress. Last week I put in some new interface elements that should help new players get into the game faster by showing them, up-front, what the effect of their move is. My wife and I had some friends over for dinner on Saturday night and I showed them my prototype. I could see that the UI changes I made were helping them get into the game faster, but something about it still seemed to be inhibiting them at the start. Maybe it was just me watching them? Or maybe I need to think more about how I can help players learn faster.
Right now I have a hint system in the game. After 10 seconds, if you haven’t made a move, the game will show you a tile that will make a valid move. However, right now the animation is not at all obvious and new players usually don’t see it. This is fair, since I mainly put the hint into the prototype so that I could verify that there were indeed valid moves left even though I might not have been able to see one. I’m thinking I need to do two things:
- On the first few levels, make the hints appear sooner
- Make the hint animation persistent and obvious once it shows up
I’ll probably work on that early this week.
The other thing I did late last week was to start adding support for special items. I got one special item entirely implemented, and it definitely helps the game feel more fun. I think it should also help with the difficulty at later levels. However, in putting the special item in, I introduced a rather serious bug into my searching algorithm. The search algorithm is used at the heart of all the gameplay. It’s what’s used to determine: when the player has made a valid move; where to show a hint to the player; and whether or not there are any valid moves left to the player. Something I changed broke this, which is bad.
Herein lies the real problem: my prototype’s code is getting extremely messy. That’s to be expected, as the whole goal of prototyping is to implement quickly without worrying too much about code structure and reusability. However, at this point, it’s making things really difficult to change. I’m quickly approaching the point where making major functionality changes is going to be more difficult in the prototype than just re-implenting things properly.
At this point I’m pretty sure I’ve nailed down what the technical requirements are going to be. For example, I know what I need from my animation system, I know how I want to separate my logic from my visual representation. So I’m not sure how much I’m benefiting from continuing to work within the confines of the prototype code-base.
My plan is now this: fix the bug I introduced on Friday, implement the 2nd special item I wanted to try, archive the prototype code in my repo, start building the game properly.
Owen