And again…

…I postponed Carl Cube, because before global game jam started I wanted gamekit to be able to link blend-files or at least group-instances. That should make it possible for teams to work on different blender-file and link objects of the other one. That worked quite well on linux and actually also on windows, BUT during GGJ windows crashed all the time…

Great, just as I imagined… In the end it was just some stupid asserts that fired on windows but not on linux (where they seem to be ignored). Compiling windows in release-mode fixed it,…too bad that it took several hours to come to this simple conclusion (todo:still have to look at this asserts)

GGJ wasn’t perfect, and in the end it was like the last year. We were more or less ready to start creating some levels just before the deadline. Of course at this time we were already a bit stressed And therefore the actual game is a bit crappy.

The result is here(the title screen on the website is the best of the whole project :D):

Btw, the other two guys involved in this were Markus Oppermann and Burak Kahraman.

In the end I have to admit that I still wasn’t as confident with gamekit as I thought, so we actually ignored the physics-engine just because something wasn’t working right from the start. Keeping a cool head and first thinking before coding would have been a bit better for this…Not sure if that would have changed anything though

But in the end all about ggj was positive. Getting stuck with gamekit let me know better where and how to improve it… Btw the location in Mülheim(Ruhr) was great and well organized.

When I came back home I started thinking what went wrong and why, and since then I’m working hard to get gamekit more stable and to look more indepth to know what is really going on there. There is still much to discover

Works well, especially since I decided to not commit any new feature I built in the official gamekit-trunk (e.g. video-texture, gui-support in lua, linking of blend-files..), I can work much faster. No need to think about how to implement a feature so that it is bullet-proofed for gamekit-trunk or do it perfect before going on.(no that anything in gamekit would be bullet-proofed, except bullet-physics of course :P) Just do as you need,…great! Btw, I can’t point out the GIT is the best tool to work on such a project, keeping the own development branch with the official branch in synch,…GIT GIT GIT.

To finally get something done, I started (again ) a simple project and decided to go for a well known old game “SOKOBAN”. (Carl Cube have to wait…)

The mechanic is simple but works excellent. I already created most of the framework. Things done so far:

• simple creation of bricks (for now static and moveable)
• player controlled by keyboard (but decoupled over message-system, so any other input-device sould be integrated quite easy
• goal-points (for now just sending an internal message, that all points are mounted ==>level won)
• editor that let you create and modify the levels at runtime
• save, load, delete via ui

I want to keep it simple and want to go on with deployment for the different mobile devices. Now I have to create a new gamekit-android-runtime from scratch. That will be a hard fight not to think about iOS.

We’ll see how far I will come.

Actually, I wanted to show a small video, but was too stupid to create a screencast…

Keep on rocking,ToM