« Newer 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Older »
Last time, I wrote:
My brother probably expected the cart to make a turn if it was pushed on one side. Instead, it would spin around its axis, but keep moving in more or less the same direction! […] I will need to consider carefully whether this is going to be a real problem, though.
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.
My mind is always full of ideas that I’ll never have time for. But occasionally, one of them does get executed. This is one of those times.
Beavers live on wood, bark and aquatic plants. I would have guessed that they ate fish, but they don’t.
Beavers can hold their breath for up to 15 minutes.
No truism is always true, not even this one. I recently clashed with two common conceptions in software engineering:
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: