Some progress

I’ve got some progress loading ps2-era locations. Still a lot of research to be done until I’ll actually start implementing the converter. I’m going to implement locations convert tool instead of direct loading to support HD restoration.
ac5-clay

A little break

Recently, I’ve been spending all my free time on Open Horizon to get the demo out of the door. As a result, I now have a huge unread pile of ranobe that has been recommended to me. So I’m taking a break from development until I catch up on my reading.
SONY DSC

Some thoughts about code quality

Shocking truth, but significant part of Open Horizon’s code wouldn’t pass my own code review. It’s probably ok for pet-project, because if I will rewrite code every time I want, the project would be in development forever. The reason code isn’t perfect from the start is quite simple.

First of all, I don’t know how the original game worked before some research so I write first implementation, then, when problems occurs, I research again with updated information, making new assumptions. This is a continuous process, but other code is already depends on what I wrote previously so every time such problems appears I can’t just rewrite it all.

On the game mechanics side, I often choose ugly solutions right before the release, because I want it to be done already so I cut corners and struggle with my own architecture. While I’m complaining about architecture, the other aspects of the code quality, like checking ranges and pointers, are mostly fine, because it’s critical to the stability and sanity. Any unnoticed null pointer reduces game’s value to zero.

Open Horizon Mission Editor

editor_screenshot2It’s finished at some point. Of course it’s kinda useless right now, as you can’t see the result in game yet, but I wanted to release it anyway so people can make suggestions. Like, what else is required to remake AC5 missions?

You could find some documentation here. Don’t expect to have undo/redo and copy-paste in this release, it’s complicated.

Using QtQuick/QML for games.

In games with complex UI, creating a library that supports that UI and tools that allow designers quickly iterate changes could be a daunting and a time-consuming task. A task that you’d like to solve once and forever, and not write a new solution for each new project, or even for each new company you work at. Life, as it can be said, is too short to roll your own UI libraries!

So, in desperation, you begin to search for a third-party universal UI library. Once, this was the domain of CEGui and the like, but the current generation of game-specific UI frameworks is dominated by Scaleform and Coherent UI. Although, if HTML-based UI is what you want, you may simply choose Awesomium.

Unfortunately, this trio has some problems with performance, especially apparent on mobile devices. Just a few years ago, I’ve seen a nearly empty screen rendered with Scaleform take up 50% of frame time on iPhone4.

So, I always wondered why does no one use Qt for game UI – a library that is well known for being one of the less-fucked-up UI toolkits for desktop applications. This is not actually entirely true – a list on Qt Project Wiki has some games that do use it, but it’s mostly open source, small-time projects or ports of old games.

Of course, it’s obvious why you wouldn’t use Qt Desktop Widgets in a game. They are not at all suited for hardware-accelerated rendering, and while you may try to work around this problem, it’s far more troubles than its worth. However, for a long time, Qt had a different library, the one that allows drawing hardware-accelerated widgets: QtQuick.

Not only it is said to be specifically targeted at mobile devices, it also has a very nice text format for describing UI screens, which is well-suited for quick iteration.

Still, I have never yet heard of a professional game developer using QtQuick. As I could find no posts or articles that could give me the reason for this, I just had to check it out for myself.
Continue reading →