No updates last weekend, because I’ve been busy with the Rails Rumble: an annual contest to build a Ruby on Rails web application in 48 hours. Three friends and I built ChordWise, an online ear training and score reading practice application for musicians. Although there are some bugs to be ironed out (sound doesn’t work in Chrome, probably nothing works in IE), I’m very satisfied with the what we’ve accomplished in just two days. It’s a promising start, and we might continue to develop this into a full-fledged product and try to make some money out of it, if there turns out to be enough demand for something like this.
Although I’d previously determined that the controls of the cart worked nicely on a touch screen, they were nowhere near perfect yet. This is one of these aspects that can make or break a game, so it’s important to address it as early as possible.
After the model compiler comes the texture compiler. Decompressing a PNG file on Android is possible, but the loading code is simpler if the texture is already available in a format that we can feed directly to OpenGL. So I devised the GLT (GL Texture) format, and wrote a program called gltc to convert PNG files to GLT.
Having a level editor is a good start, but it’s not all. We need some kind of workflow to create models and textures and eventually get these to show up in the game. I started with the models.
Does a carpenter create his own hammers? Does a painter make his own brushes? Usually not, but a game developer often needs to build his own tools to get a particular job done. One of the most important tools to have is a level editor – you really don’t want to put all objects into a level by typing long lists of coordinates. Building the editor has kept me busy for the past few days.
I’ve decided to change course. Drastically. The fluid engine works nicely, and although it’s fun to play with, it’s not exactly a game just yet. I had this idea, which I alluded to in my previous post, of making it into a creative construction game. You’d be a beaver, and you’d have to use twigs and branches, floating in the water, to build a dam.
No truism is always true, not even this one. I recently clashed with two common conceptions in software engineering:
“All problems in computer science can be solved by another level of indirection.” – David Wheeler
“Some people, when confronted with a problem, think ‘I know, I’ll use regular expressions.’ Now they have two problems.” – Jamie Zawinski
The problem, in this case, is the heart of my little content management system, Utterson. As I discussed previously, I want all content to live in a Git repository, which is read and interpreted (later, also written) by the CMS. For example, I would create a blog using magic file extensions like this:
I’ve been doing more experimenting with the engine, trying to come up with a workable puzzle concept. Below are some videos and reasonings.
First off, the game objective. Assuming that it’ll have something to do with the fluid, one possibility is that the player has to make the fluid flow in a particular way or direction. We could represent this as having to “paint” particular objects with colours that are injected into the fluid. For example, in the video below, the player would have to paint the top box red and the bottom box green. (The opposite would make for a rather more difficult puzzle!) The boxes don’t yet react to paint in any way.