I just spent the last couple of days writing this Ogg/Theora decoder. It wasn't difficult, but it would have been even less difficult had I been able to find a tutorial somewhere on the Internet. Hopefully someone will find this useful. If you have any questions or any suggestions for further improvements let me know.

The use of video in place of conventional sprites has obvious benefits. In particular, the amount of space required to store a given number of frames is substantially less. Video codecs achieve this space-efficiency by using a range of techniques. In the case of Theora:

I just stumbled upon this old game of Reversi I made about four years ago, and thought I'd display it here on my website. The CPU player makes its moves based on a really simple heuristic that turns out to be quite effective. As you can see it beats Iagno on easy mode.

[Click 'Read more' to see image]

Iagno on medium takes so long to make its move I got fed up of waiting, so I couldn't test it against that sadly.

It can beat KReversi on medium too. This was after several attempts (this time playing as black).

[Click 'Read more' to see image]

[Click 'Read more' to see image]

Latest version: 1.1.0, released April 9th 2013.

Windows installer: link

Linux x86 binary: link

Thirteen days ago I mentioned participating in One Game a Month. Well here is January's effort. There are still a number of things to do before it's ready to make available to people. It needs optimising a bit, and porting to platforms other than Linux, but aside from that it's basically done.

It's not particularly exciting or creative I know.

[Click 'Read more' to see video]

I'm quite proud of the menus though; I probably spent as much time working on them as on the game itself.

I've decided to participate in the One Game a Month event. You can track my progress here on this blog, or for more frequent updates see my Twitter feed.

For January's game, I'm thinking of doing some kind of Minesweeper variant. That's all I'll say about it for now. As a starting point I'll be adapting this generic boilerplate code:

A key aspect of any game engine is the ability to load and unload resources (textures, sounds, etc.) as and when they are required by the game. The component responsible for this task usually goes by the name of Resource Manager or Asset Manager. In my engine, the AssetManager class is just a dumb container. It's implemented as a monostate class, which means there is effectively just one global instance of it. The MapLoader class (also monostate) is the one responsible for loading and unloading assets into and out of the asset manager as the player moves through the world.

My primary goal in the design of this component (as with the entire project) was simplicity. So with simplicity foremost in mind, I decided on this initial design:

This is basically a summary of what I remember from the book Security Analysis by Benjamin Graham and David Dodd. I don't think I finished the whole book (it's huge!), and whilst it's been a long time since I read it I can still recall the basic principles.

Recently on YouTube I stumbled across the trailer for a TV series I watched several years ago called Million Dollar Traders. Back then I was reading a lot about value investing, and had developed some strong opinions on the world of trading, the people who participate in it, and the effect it has on the economy.

The purpose of the stock market is to provide a means for companies to raise capital to fuel their expansion; once a company has reached a size where it's difficult to attract wealthy investors privately, it may choose to "go public" and its stock is floated on the stock market where it's available for the average person to buy.

The general public, rather than buy stocks directly, will tend to buy into some sort of investment vehicle—such as a mutual fund, or unit trust—which will invest their money of their behalf ...

Segmentation is the process of partitioning an image into separate regions, each relating to some class—such as trees, sky, or grass, for example. This involves assigning a class label to each pixel of the image, and is therefore fundamentally a classification problem.

Many problems relating to image processing can be stated in terms of recovering some 'true' image, or representation, from an observed image. This usually requires knowledge either of the original representation itself, or of the way in which it's been degraded, sampled, or transformed to produce the observed image. The problem of segmentation may be considered similarly. In fact, many techniques for solving other kinds of problems, such as noise reduction, can be applied to an image segmentation problem ...

This post details how I'm implementing general message passing in my engine. There's nothing particularly clever about how I'm doing it, but it seemed like a nice self-contained thing to write about.

Just one example of where such a thing is useful is when an entity's position changes; the grid, which is the data structure I'm using to partition the game world, must be updated with the entity's new position. I didn't want the Entity class to have to know about the Grid class because an entity is clearly a lower-level construct. Also, other classes/modules might be interested in 'entityMoved' events (or any other kind of event). This of course is the usual reason for such a message passing system -- to minimise dependencies between modules, and to eradicate "spaghetti code".

Shit Game (working title) now uses the engine's physics functionality to provide a combination of platforming and Boulderdash-style gameplay -- something I'd been thinking about for ages.

Initially I tried implementing the platforming mechanics using animations/transformations, with the player permanently aligned to the grid. This is because I expected it to be far more difficult to seamlessly combine the grid-aligned tunnelling mechanics of a Boulderdash clone with a physics engine that allows complete freedom of movement. Actually, it turned out to be quite easy.

[Click 'Read more' to see video]

I've also spent a lot of time improving the quality of the code because some of it's quite old and I used to be shit at programming.

I haven't got as much done as I'd expected by this point, and there are no visible differences to show off -- just some work behind the scenes.

[Click 'Read more' to see image]

Here is the code that produced the above screenshot. This doesn't include the several thousands of lines of engine code!

Btw, please feel free to leave a critical comment. I'm always happy to receive constructive advice.

This website now conforms to the HTML5 Polyglot Markup specification, as described here. This means that it's both valid HTML5 and well formed XML -- in addition to complying with a few other constraints.

You might think that polyglot markup is the HTML5 equivalent of XHTML1.0, but actually it's slightly less strict as it doesn't require that the document conform to any DTD. However, these web pages do almost validate as XHTML1.0 Strict.

Unfortunately, HTML5 Polyglot markup does not permit the use of Javascript method document.write() -- and as I'm serving these pages as XHTML it wouldn't work anyway. This causes problems when trying to integrate Adsense or ReCaptcha.

The solutions are as follows.

I've decided to spend the next week or two making a small 2D game using the Dodge Engine, which I started working on a while ago but never quite finished. If all goes well I may publish it on an app store.

In my opinion the best approach to developing a game engine -- or any large and complex piece of reusable code -- is to create a series of projects (probably demos initially), each of which demands the addition of some new functionality; any reusable code is factored out and recycled into the next project, thus forming the "engine".

With the Dodge Engine I got up to demo 4, which demonstrated widgets. Shit Game (working title) will effectively constitute demo 5. I'll be using demo 1 as a base to work from.

When the engine is done it should enable me to produce shit games very quickly.

This may sound like a boring topic to write about, but I've been spending a lot of time recently watching videos of Peter Schiff and Milton Friedman on YouTube, and also reading their books, plus Friedrich Hayek's famous book titled 'The Road To Serfdom'. They seem to have had an influence on me.

Prices, to an investor or business person, are like an engineer's dials; they convey vital information that informs his course of action—specifically, information about supply and demand. A business owner, for instance, will maintain a close eye on all his costs in an effort to predict where the prices might go in the future, and this affects what he does in the present.

Of all prices though, there is one that is more important than any other: the rate of interest—the price of borrowing money.

Imagine that you're an aspiring entrepreneur with a promising business plan, and you need some cash to cover your initial expenses. If you're lucky enough to live in a society in which a good number of people have spare money lying around (which we'll refer to as savings), then it shouldn't be too difficult to find someone from whom you can rent a sum of money at a good price ...