We have fire, we have buckets of water, we can get the buckets to the fire… now what? Throw ’em, of course! So if a peep in state PASSING sees that its destination cell is not manned, but rather flammable, it will throw the water onto the fire. (It will also do this if there is no fire. I played with the thought of keeping houses wet to prevent them from catching fire, but didn’t get round to implementing this.)
This weekend was the third instalment of the Alakajam! game jam. I was really happy about the shortlist of potential themes, so I knew this was going to be a fun one. The winning theme, “Always growing”, was my second choice.
It’s been over two months since my last post, in which I announced that I was abandoning JavaScript for the development of Turtle Paint, and switched to Ruby instead. So far, it has been a great learning experience, and I’m loving this language more every day. There are a number of interesting technical posts that I want to write about the new internals of the game, but those are for another day.
As announced, I made a large sprint this week to bring the artwork closer to completion. I think it’s about halfway done now, but I’m getting more and more experience with this, so the second half should go a lot faster.
Like I announced, lots of work on graphics. In-game graphics are beginning to come together, but are only halfway done, so the overall result still doesn’t look too good.
In Android, generally speaking, each different screen presented to the user is called an ‘activity’. Until recently, the only activity in the game has been the game itself. I’d already added a few menu screens this week, like you saw before, and have now been working on putting it all together.
Like last week’s, this post is a day behind schedule as well. Since I’m working on my part-time side job on Tuesdays and Wednesdays, it was a silly schedule anyway – changing to Thursdays to accommodate.
It’s difficult to do a screen-cast of an Android game. You have to root the device to even take a screenshot, and with the game taking up most of the CPU, a live video is out of the question. The emulator that ships with the SDK is too slow to make the game run smoothly, and multitouch cannot be used on an emulated device. It would be possible to record a game session, then play it back at a slower speed while recording, but it would be hard to get sound, and it’s a lot of work anyway. It seems that the only viable option is to point a camera at the phone and live with the bad video quality. Oh well. Here it is.
After deciding in which direction to take the game, the last few days have been a matter of implementing this. Due to various circumstances I haven’t been able to get as much done as I would’ve liked to, which is why this post is relatively short and fragmented.
In the days of MS-DOS, things were simple. If you developed a game, you usually wrote it for one specific VGA or SVGA
resolution, such as 320x200 or 640x480. If someone’s video card did not support this resolution: tough luck.