definition = g_resourceManager.getResource< UIDialogDefinition >( "yesno.odlg" );
YesNoDialog pYesNoDialog = new YesNoDialog;
pYesNoDialog->createFromDefinition( *pUIElementCreator, definition );
pRootDialog->addChild( pYesNoDialog );
g_resourceManager.releaseResource< UIDialogDefinition >( definition );

(Note: I omitted the asserts to improve readability.)
No magic going on here:
Load the definition (resource) from a file.
Create the dialog object.
Tell the dialog to use the definition.
Add the dialog to the tree.
Cleanup.

That’s all.

Bad news first:
- Steffen, who is along time friend and was one of our candidates, decided to pursue his own targets, in his own way and time. We still stay in contact and are more than happy to consider his feedback, but for the time being he will not be joining us.
- “Mr.X”, one of our silent funders, has also left us due to some personal circumstances. While this is a serious blow in budget and business expertise, we fully understand his reasons.
- The acquisition of office space failed. We had some good candidates, but in the end we decided that none of them was really a perfect fit, so we are still looking. (Maybe the Gamespaces.de initiative will help us.)

Good news:
- A lot of development took place behind the scenes.
- V0.8 of CrazyAir has been finished, just slightly behind schedule.
- Looks like we have new project and with it a new developer. (More on that later…)

And we will renew our demoscene roots and sponsor them again,
as we did the last three years…

While looking for the correct wording for one of the lines I stumbled across this:
Getting rid of virtual method calls

Since my explanation wasn’t much better,
I’ll just leave you with the link to Floh’s article
and a snippet of our rendering engine.

[renderer.hpp]
 
#if defined( OM_PLATFORM_IPHONE )
	#include "iphone/renderer_iph.hpp"
	namespace OM
	{
		#define Renderer OM::Renderer_Iph
	}
#elif defined( OM_PLATFORM_OSX )
	#include "osx/renderer_osx.hpp"
	namespace OM
	{
		#define Renderer OM::Renderer_Osx
	}
[...]
[renderer_osx.hpp]
namespace OM
{
	class Renderer_Osx : public RendererBase
	{
		public:
[...]

Just one more thing to say:
This works perfectly for us on the 9 supported platforms.

Check out:
GianasReturn-v0.997.dmg
And let us know what you think.

Since Kojote is away, there is no artwork (.dmg background, .app icon),
but I’m sure we’ll add that to the next version.

There are some commandline parameters that you can use (scaling, fullscreen, etc),
but for this version you are on your own to find out how

Update:
Due to a little uncaught typo the last .DMG still had a wrong library reference in it.
Try this version instead:
GianasReturn-v0.997b.dmg

We don’t have a dedicated QA at the moment, but rest ensured: All our games will be thouroughly tested before shipping.

Update 2:
Yet another version:
GianasReturn-v0.997c.dmg

Sorry for the confusion, but SDL is a little bit … erm … complicated…

I cannot tell you why … yet, but here are some hints:
- A new/old developer has (re)appeared and is more than happy to work with us again.
- Gameplay of “CrazyAir” is 95% finished. Just a little bit of polishing and we might let some testers onto the first-playable version.
- Negotiations for “Project: Drunken” have started and do look really good.
- It looks like we will have real offices soon, which will really help us with our WiiWare developer license/registration.

So full steam ahead. The future is now.

Last week we suspended our development to relax a litte bit and start into the new year with full steam.

Well, that was the plan,
but after two days we got bored and things started to happen.

Kojote gave us the chance to do the Gianas Return port for Mac OSX.
Starting from 0.997 we will provide the Mac builds.
It’s not cleanly packaged into an .app yet, but Kojote is travelling during January and we will fix it when he is back.
Enjoy the game!

And let us know if you need your game ported!

Last wednesday Anno Wii received the award for
“Beste deutsche Konsolenspiel 2009″ (Best german Console Game 2009).
Since this was my first lead role in the game industry im pretty proud on what we achieved.

And I’m more than super motivated to get another one

Didn’t have a lot of time during november, but created some.
The only thing that seems to be limitless is time.
There are always ways to find more.

Here is a randomly sorted list of stuff that I managed to squeeze in:

• Window resizing for OSX and Linux with fixed aspect ratio. It feels so much better to play in a bigger window.
• Added score and cash handling. Game logic is almost complete with this.
• Implemented pools for game objects. Constantly newing and deleting was just fragmenting the memory.
• Added various helpers for easier creation of dialogs.
• Added animation converter and loader. Dialog animations are much easier to tweak this way. No editor yet.
• Added Level 4. Also added some extra features needed for this level.
• Added graphs to our subversion statistics. This is a huge motivational help.

Overall the game (and the framework) got a huge push forward.
It will still be hard to make the alpha deadline in december, but we are trying.

I also got a quick update from our artist, but didn’t actually see the new graphics yet.

Our windows developer is still missing…

The good news:
In the first 2 hours I managed to:
a) Get the Mac Version working again (the dreaded Carbon to Cocoa translation).
(And yes, I will give you the promised sample code, but first I have to fix some minor things … and that is pretty low on my list right now.)
b) Created a bunch of tests for the platform/window/context code. This should make it a lot easier to port to a new platform in the future.
c) Cleaned up the platform code … using the said tests.

In the other 2 hours I managed to work on “Crazy Air” [Codename] again.
This included the following:
a) Level converter, kevel loader, in-game level selection and 3 sample levels are done.
b) Game over and level completed handling are done. (About 99%.)
c) The build utilities have been extracted from “Crazy Air” and can now be shared with the other projects.
d) The asset-build has been automated.
e) The font system is fixed. Before the alpha was broken and only one font could be used.
f) “Speed” controls have been added to the game. (Including pause…)

That might not seem like a lot, but the game (prototype) is about 90% finished now.
Soon there will be some gameplay tests, before I go and fix all the small glitches.
There is simply no need to make the graphics perfect if I don’t know if the game will be entertaining.
(It is for me, but I want some extra players…)