Category Archives: Widgets

It has been so long since the last post, I am at a loss for words!  So I’ll just show a picture instead.

The math and 3D object manipulation to get this working took way too long, but I eventually got it.  Spending half hour chunks here and there among other things didn’t lend itself well to solving the puzzle.  I should have treated it like I treated the dynamic wall-generating algorithm: PAPER.  Sometimes when faced with a coding problem I go back to paper and scribble out my thoughts, and work through the logic of it all.  I should have done that here, but it does not matter … the results are what they should be.

With that part off of the “To Do” list, I only have one thing left before sending out another updated demo: smarten up the AI.  Right now, they fall off cliffs like lemmings, and are generally stupid.   There is also a couple bugs with it where they will run away from the player if approached from different angles, while in different states.  I may also make an “auto shutdown” type flag that if one enemy is touching another it will stop moving for a miniscule amount of time.  I hope this will prevent the physics from getting bogged down when 100 spheres are all pushing toward the same corner (to get to the player).  If I can fix those few things I will be happy.

So at the request of fellow forum-goers, who were sick of going back to the beginning of a level after the marble fell, I hurried up and added restart zones. So far they work out quite well. At first I just had restart “points” and when the marble fell, whatever point it was closest to on the X/Z axis would be the spot to go in. But I starting playing with it and saw an inherent problem: the player could end up restarting where they haven’t been yet (?). That doesn’t seem right.

I have since changed the concept to a zoned restart point which means once you enter the zone of a restart point (approximately 5×5 tile area) it is available for you to restart in. Restarts are widgets and widgets can have zones, so this easily fit into the current system.

The speed arrow is another widget which can be used to help or hinder the player (like all widgets in the game). If the marble touches the square the arrow is on, it will be pushed in the direction of the arrow. Like all widgets it can only be placed on flat tiles (no slopes).

This is probably the simplest of widgets, but one which has many uses. It can be used to push the marble off a narrow walkway, or to help it gather enough speed before rocketing off a slope.

Hopefully, this serves to drive home the point that, for the most part, widgets are neither good nor bad. They just are. It is up to the creator of the level to decide how they are used. Hopefully this freedom will yield interesting results from both official levels and user-made levels.

Of course there are widgets such as triggered lasers which are pure obstacles to be dealt with. It will be interesting to see if someone finds a way to make these lasers helpful to the player. 🙂

The catapult was one of the first widgets I made and it was done so early mainly as a proof of concept.  I considered it one of the more complicated moveable widgets in the game and wanted to make sure it worked!

While utilizing the Hinge Joint in the Newton physics engine, it also had to have a compound collision object in the form of the cup and arm of the catapult.  Something for the marble to nestle itself into before being vaulted to its destination.

The catapult is activated by the marble touching the cup/arm of the widget.  Once this is done there is a 4 second delay before the catapult goes off, with or without the marble in the cup.

There are plans for having 3 strengths of catapults.  One will vault you over 15 or so tiles, another will go 30 tiles, and the final will go 45 tiles, which is basically across the entire map!  I think each catapult will be color-coded, or at least textured differently, so that players can recognize them immediately.