Changes to Storyboard and Over-pending Updates

The last visit to IIT entailed a complete reordering of targets, both short and long term. Our efforts prior to this somewhat paradigm shift was mainly directed toward achieving :

• Platform Independence for the executable product : Nitin had discovered a method for generating a .exe file that played out the Blender Game Engine sequence for our modelled contraptions. He had also managed to replace certain .dll's to run the executable on a Mac platform.


• Building the front-end : The predicament of selecting a language for coding the front end had not been resolved. So we decided to make sample GUI's in both Java and Python. After going through Prabhu Sir's tutorials for Python, I managed to create 2 GUI's in Python, while Kaeyur coded a GUI using Java applets. Neither was up to our satisfaction.

Enter Prabhu Sir. Deliberating with Prabhu Sir resolved many roadblocks; or rather put us onto a new road altogether. The consensus reached upon during the discussion was that since Blender is coded largely using Python, it would be easier to integrate meshes into a Python based front end, ergo we drop Java as a viable option for our front-end. Prabhu Sir then suggested that since the Blender Source Code is available, we could directly use the methods Blender emplys for its GUI. Brilliant. Now all we had to do is analyse the Blender code or use its API's for our UI.

So we set out to analyse the Blender Architecture and Code which comprises largely of C methods wrapped up in Python procedures. Meanwhile we were simultaneously sharpening our Python skills using the online tutorials.

At this point there was a near epochal discontinuity owing to a very hectic college schedule. While Nitin pursued Python a bit, Kaeyur and I were busy tackling college submissions and vivas which have just concluded. Luckily the interlude proved to be rather beneficial to the project. Through this interlude I had been exploring as many games as I could to garner some useful ideas for Contraptor. These are a few inspiring ones:

• Half Life 2_Episode 2 (Valve) : Incorporates Problem solving along with the action of an FPS.
• Bloxorz : A brilliantly simple concept with a thoroughly intriguing approach to problem solving. http://www.albinoblacksheep.com/games/bloxorz
• Portal (Valve) : One of my all time favourites. Uses the same Engine as Half Life 2, puts cognitive problem solving to the test.
  

Comparing these with the gameplay and storyboard we had in place for Contraptor, I developed this convincing and hugely unpleasant impression that I wouldn't want that product to be the outcome of our efforts. So I've modified the entire game to be a lot more challenging but simple to play.

Here's the plan along with the reasons behind the design changes:

The basic objective is to control the movements of a glass ball to assemble contraptions that trigger actions enabling it to escape the room it is trapped in. The game is divided into 10 tasks, each using 1 or more contraptions.This is the basic room layout I've designed which might be subjected to changes (No contraptions included as yet):

The objective is to unlock and exit through the door. The unlocking switch is at the foot of the bed inside a glass casing. The game starts with the ball placed near the cube at the lower left.

Task 1 - Climbing up the stairs : The staircase required a mechanism by which it can get converted into a smooth ramp to allow the ball to climb up. Nitin at this point came up with a smart mechanism. He suggested to have the stairs held in place by a load over a pully. The load rests on a see-saw at the base of the staircase. By some mechanism the load should be launched causing the steps to collapse into a ramp. This should explain better.

The railing at the outer end of the staircase has strings holding up the outer edge of each step. these are controlled by the load at the end of the strig going over the pulley. The simplest launching mechanism I 've come up with is dropping a load from the lid of a bin onto the see-saw. The ball has to simply step onto the pedal of the bin that opens the lid.The arrows below the non-supported edges of the steps show how the steps would collapse into a ramp.

Since I have not yet sketched the other tasks I will save myself the 1000 words and explain them in detail through images in subsequent posts. Ill mention them here though.

Task2- Procuring Magnets

Task3- Unlocking a metallic ball

Task4- Arranging the magnets: The magnets, a horse shoe and an L shaped one need to be placed in such a way that the metallic ball reaches the base of a hammer placed in front of the glass casing enclosing the switch.

Task5- Unlocking the door : An extension of Task 4, the metallic ball pushes the base of the vertical hammer pivoted at the centre of the handle. The head of the hammer on rotating down hits the metallic ball through the glass casing, throwing the switch that unlocks the door.

Task6-Climbing onto the Shelf : The ball now has to descend down. The path selected goes through the shelf on the far wall. The ball has assemble a contraption taking it to the top of the shelf on the far wall.

Task7- Resolving a Roadblock : The ball has to light a candle that burns the string attached to a block that is meant to well, block the path of the ball.

Task8-More Obstacles : The turn around the beam at the middle of the shelf actually is a piece of cloth between 2 rollers. Using what I call a 3 ball mechanism, our ball has to manouvre this turn. More on this later.

Task 9-Descending : The ball has to now descend along the shelfs on the right wall of the room (haven't been drawn) using another contraption.

Task10-Opening the Door and exiting : The door that is unlocked still needs to be opened using yet another contraption before the ball can finally exit and complete the game, or level if we decide to extend this game.

In addition to the much more structured gameplay this plan offers, it also solves some of the problems we were facing with the old plan:

• Storage of meshes in a 'vault' : The player would have to drag these meshes from the vault into the playing area. We haven't yet discovered a method to use mouse actions to control events using the Game Engine. This new plan establishes entire control using only the 4 arrow keys, which can be very easily implemented using the BGE.
• Play-Stop Gameplay : In the earlier plan, all the player had to do was place a few objects in a certain manner, hit 'play' and watch whether the arrangement is right or not. The new plan offers active player involvement compared to the passive gameplay in the earlier plan.

I do feel that we would have to design a game engine ourselves to implement this game, but before that a lot of work remains to be done. I shall post the details of the tasks after discussing these ideas with Nitin and incorporating his inputs.