This demo shows off a proposed feature, objects displacing each other. This is my first attempt, and it’s a little wonky when you try to squish the character. He usually phases upwards. In the game, he would have died when crushed. It’s a work in progress, but I believe this is a decent start.
Try out the demo here!
Edit: Demo taken down.
Dev-Blog for the Puzzle Platformer Game, Filament!
Saturday, October 30, 2010
Thursday, October 28, 2010
Boolean is working! Demo #2
Click here to download
The character can now interact with white spaces formed by overlapping dark sections! Collision is a work in progress, but this will have to do for now.
(Edit): The jumping bug was fixed! Also, the character is now grey!
The character can now interact with white spaces formed by overlapping dark sections! Collision is a work in progress, but this will have to do for now.
(Edit): The jumping bug was fixed! Also, the character is now grey!
Concept Art: Round 2!
Click each thumbnail for some glorious vector eye-candy! Don’t rush, soak in the detail!
Project Status: Working Demo, and More!
The renderer support classes and the basic physics engine are up and running! Check it out!
Current Demo <-Download now!
Move the little block around with the arrow keys. It can hop around and run up and down slopes.
The larger block follows your mouse. This was just a proof-of-concept to test the inversion. The little block can’t phase through the big one yet, but he can climb on it.
As a side note here’s an early draft of the level editor. It still needs a bit of fleshing out, but so far it’s the design that I’m going to be aiming for.
So anyway, let’s talk a little about how the engine currently works:
First, the level contains chunks of data called Masses, which contain a list of points that form a polygon. These polygons represent the simplest form of objects in the level. Mostly, they just form walls and floors, but all that changes with the use of Actions. Actions are operations that can be performed on a Mass, things like rotating, translating, etc. These Actions are spawned by triggers that you attach to different inputs. For example, when the DOWN_KEY is pressed, the translate action is invoked on the polygon that represents the player character (the little one, in this case). It moves, and life goes on. Once the timeline is completed, Actions will be able to spawn based on time triggers.
The majority of movement is smoothed out by looping through large movements using little ones. This way, if I translate 70 pixels in one direction, the Action will use a series of small translations, and if it hits a wall at say, 20 pixels in that direction, the remaining translations are cancelled. This prevents the player from clipping through things, and it results in a smooth look if you repaint after every couple sub movements.
The inversion works by rendering every poly with an alpha of 99%. When two surfaces overlap, they form a color darker than the default surface. Our eyes really can’t see the difference, but when the pixels are scanned, the extra dark ones are replaced with white pixels. The process of scanning for pixels to invert is sped up by keeping a list of regions that are likely to feature overlapping Masses. The rest of the level is left alone as those regions are scanned. I’m currently scouting for a simpler/faster algorithm to handle this, as it is too slow to be used with larger screen regions.
The next feature to be implemented is per-pixel collisions (rather than the current polygon-bounds collision). This will allow the player to walk through inverted sections of screen. Arguably the most essential of all the features!
Current Demo <-Download now!
Move the little block around with the arrow keys. It can hop around and run up and down slopes.
The larger block follows your mouse. This was just a proof-of-concept to test the inversion. The little block can’t phase through the big one yet, but he can climb on it.
As a side note here’s an early draft of the level editor. It still needs a bit of fleshing out, but so far it’s the design that I’m going to be aiming for.
So anyway, let’s talk a little about how the engine currently works:
First, the level contains chunks of data called Masses, which contain a list of points that form a polygon. These polygons represent the simplest form of objects in the level. Mostly, they just form walls and floors, but all that changes with the use of Actions. Actions are operations that can be performed on a Mass, things like rotating, translating, etc. These Actions are spawned by triggers that you attach to different inputs. For example, when the DOWN_KEY is pressed, the translate action is invoked on the polygon that represents the player character (the little one, in this case). It moves, and life goes on. Once the timeline is completed, Actions will be able to spawn based on time triggers.
The majority of movement is smoothed out by looping through large movements using little ones. This way, if I translate 70 pixels in one direction, the Action will use a series of small translations, and if it hits a wall at say, 20 pixels in that direction, the remaining translations are cancelled. This prevents the player from clipping through things, and it results in a smooth look if you repaint after every couple sub movements.
The inversion works by rendering every poly with an alpha of 99%. When two surfaces overlap, they form a color darker than the default surface. Our eyes really can’t see the difference, but when the pixels are scanned, the extra dark ones are replaced with white pixels. The process of scanning for pixels to invert is sped up by keeping a list of regions that are likely to feature overlapping Masses. The rest of the level is left alone as those regions are scanned. I’m currently scouting for a simpler/faster algorithm to handle this, as it is too slow to be used with larger screen regions.
The next feature to be implemented is per-pixel collisions (rather than the current polygon-bounds collision). This will allow the player to walk through inverted sections of screen. Arguably the most essential of all the features!
Wednesday, October 27, 2010
First Round of Concept Art!
Every project has to start somewhere! This is the first batch of art- made completely in MSPaint.
Yes, yes, over 9000 hours, etc.
This first image is a basic explanation of the gameplay mechanic that Filament hinges on:
You can walk on the black stuff, but not on the white. When a black zone intersects with a black zone (see the middle panel), it forms a white zone that you can walk through. In the above picture, the player steps on a switch, which moves the large block into the center wall, forming a white path for the player to walk through.
In this picture you can see a NPC phasing through the solid black areas. If that creature were to gobble it up, you could walk freely through the white portion its body occupies. Although not everything about this interaction is planned out yet, you can see how the mechanic of white/black can be used for more than just sliding block puzzles.
This one shows off a bit of the decay that has occurred within the deeper levels of the game’s environment (you’ll just have to wait to find out why). All of the automatons in the game resemble a real creature in some form or fashion, and those relationships will often give you clues about what you can expect from some of the stranger looking foes, like the anteater above.
This final picture is an early scene from the current story, dealing with the last remaining bit of color in the entire world! More on that subject is coming soon.
Subscribe to:
Posts (Atom)