Well. I managed to finish some stuff after all.

More soon.

Things are moving. Here is that screenshot i mentioned.

iPhone screenshots coming soon. I managed to wrangle some of the issues left on iPhone , not many more till its showing me the game. Luckily with the view system i can run the game at the 'correct' resolution (in this case 960 x 600) and the iphone will render it at the native resolution ( 480x320 on iPhone 3GS and 960x640 on iPhone 4).

Today, the 30th of December, is my birthday.
Lucky for me I gave myself some really cool progress over the last day. More platforms!

Laboratory is currently on 0.9 beta 1.8.

What did all the .somethings add in beta 1? Well, bunches. I have a really meaty changelist that will be going up soon with the docs. That's right, docs were in that beta too.

What do the versions mean?

It may seem strange how I am labeling the numbers but it makes it far easier to track. Each minor revision of the beta fixes bugs found but more importantly, adds necessary features and implementations. I am taking this approach to suit rapid looping and iteration. The alpha of a revision is usually massive changes and underlying systems being brought in and as soon as that is done, the first beta is the first pass of fixes and changes to the alpha. 
This continues until beta 2, feature complete revision with a pretty solid basis. Beta 2 will then include docs, and examples - always examples - of what is new and added. Usability issues are definitely NOT found by testing, they are found by using.

That means beta 2 has one main goal - user experience and polish. Once satisfied that all the issues are ready for use, the final beta or release candidate is labeled and released. All fixes and changes here are focused on stability and nothing else. And finally, the most stable version - the actual release - can be used in production as expected. This includes change-lists and patches for api changes, functional changes and structural changes.

Mac and iPhone builds

Anyway. I wanted to bring up the platforms for a moment. From day 1 I have coded with portability in mind. I chose libraries very carefully, as I knew my targets well. Along the journey I have stopped to l the roses and see if the tech runs on other platforms and I was pretty satisfied that when it came to porting the rest it would be a breeze.

With that in mind you will be happy to know the Mac OSX builds are done. Full support for the engine in it's current state is done, and ready for use.
Having worked on iPhone some might realize how close it is to mac. With a few compiler options and some rebuilds of code - you might also be as excited as I am that I have the engine running on iPhone.

There are some minor file access issues and a few more tweaks before I can say it is done, but I am confident it is right there. iPhone and iPad support are a handful of code away.

Now, that leaves Linux. No, I didn't leave Linux till last in fact, my most recent tests were done in my virtual box not all that long ago. I chose porting over the last few days by risk factor. Some of the Libs might have needed more wrangling on Mac and I was right, but a day later and we now have mac and iPhone leaving the todo list. Linux is next, and I have confidence it will be as simple too.

Ill upload some screenshots tomorrow.
This is really fun stuff to be done.

[posted from my phone : edited to make more sense.]

Merry Christmas!

As interesting as the challenge is on its own accord, just by title, the most interesting aspect of this particular challenge is the highlight that it points right at you. Right at your development methods, your chosen tools, your skillset, your choices. It all comes down to you - and the post mortem.

 I have posted mine, you can see what I came up with and didn't over at this page.

Another really interesting thing to do is to record yourself working, using a nifty tool like chronolapse. It captures frames at given intervals, and stitches up a movie so you can see what your workflow is. If you see too much anime, movies and web pages you can adjust your workflow accordingly ;) I only captured one day of my working but it is still interesting for me to see. You can see it on youtube over here.

Now, my entry to the competition was supposed to be a few things. But one thing i chose up front was to design something i could cut and cull everything until the core prototype was left. And... that is basically what happened.

I had to decided to work on a platformer game, that mixes gameplay with a point and click adventure game. A Use/Look sort of interface, but with the constraints of reach. You can see a switch but can you reach it? If not can you jump up and reach it instead. I had prototyped the mechanics and i enjoyed them, some obvious oversights (using platformer AND mouse is commonly an awkward scheme) but i kept at it. I decided to draw some levels in a fixed viewport, and just cycle through them, for simplicity sake, and the levels came out something like this :

The first step in my usual workflow is to prototype, and then implement the required tech (like collision boxes in a level file definition, and triggers with callbacks) which i did end up doing. More notably, i was using my own engine that i have written over the last while which was extremely interesting to me.

Laboratory Gamelab and its current status

Using the engine first hand in a really huge rush was enlightening. There were a lot of interesting logic issues i had made without knowing, fixing them along the way, and carrying on with my goals. The 'fixing them along the way' part took my time away for finishing as much of the game as i wanted but the cost to me was way worth it.

I have a working basis for a lot of really cool flexible code. None of the code i have made during the competition i could use (it is real ugly) but it gave me so many ideas and actual test implementations. That means that the tech for actual game specific stuff is well on its way.

Short term goals

1) Particle type system.

This is going to be really fun. I have some pretty cool ideas for this, combining my multi threaded base layer and event queues, i think im gonna enjoy this one a lot.

2) Finalise the file system and resource manager.

The current filesystem can only store and index files in an sqlite database. That misses the entire point of what i wrote at first, where the actual filesystem stores files using lzma compression, and encrypts the files on their way to the database using GCM AES public/private key encryption. I have moved this code around so many times, and with more reading into file management efficiency from (see www.gameenginebook.com) i have decided to just finish it. This "finishing" will include the network based updates if i can manage to get the server side in JS.

3) Get the server side in JS. Current the server is in C++ and i have prototyped a node.js version of the server succesfully. While i would love to go ahead with it, it does require a linux server which until that changes - isn't all i need. Instead, the server will be a stripped down core engine with its main function handlers exposed to the scripts as the current game engine is. This will mean parity for coders and similar tools/syntaxes across the bpard.

Finishing the LD game

I have plans to finish the 12 levels and the boss battle. The level tech is implemented, and it's a matter of adding trigger callbacks and collision rects. I have also spent more time polishing the intro sequence and game story.

Some more laboratory news later. If you would like to see the engine and the game in action, you can download a version over here

My sister kindly gave me a holiday in the mountains here in our beautiful South Africa. Yesterday I was at home as normal and today i am on the top of a cliff face staring at the mountains.

This is the first holiday my wife and i have been on together, so we are making the most of it. Today we got here around mid day so we decided to take it easy and hike to the highest point of the surrounding cliffs and take some photos.

They also have some authentic bushman paintings, which are quite cool to see up close.

Tomorrow we are hoping to do some horse riding or quad biking or something just as awesome.

Keep in mind readers, this is very rough around the edges. Proper detailed documentation to all subsystems (with examples) are always sought after. Im going with the easy to read, and then deeper knowledge. Higher level makes understanding so much nicer for me. Any suggestions on this one? Its kinda tl;dr but the blocks separate it enough to pick out what you want to know.

A lot of people keep asking me what it is i keep telling them about. Instead, i picked up the really cool www.simplediagrams.com tool and i went to making some illustrations for you guys.

Click for fuller size.

What is it exactly?

How does it fit together? 

Hope this helps :)