Development of an engine and demo can be found here:

https://github.com/efruchter/Filament

This blog is pretty dead, but once development gets moving, I'll resume posting.

:)

-Eric

Still Alive

I found some older docs, from back when I first started thinking about Filament. The original plot, subtle as  it is, and the new color mechanics solve a lot of the plot and mechanic issues that stopped me from working on the game, and I think I'm finally ready to start devoting time to the engine and the tools. It feels more possible than ever, and it's time that I stopped worrying so much about getting it right the first time, and simply do it.

My plan is to start off by coupling Java2D's XOR functionality with the collision detection, so the colliding world will actually be drawn twice, once to an invisible collision image, and again to the screen, but the latter being much more detailed. This keeps a nice separation between entity model and entity view (a complex looking entity need not collide complexly), while still being faster than anything else I can think of. If I ever find a fast, stable way to boolean out shapes mathematically, then I'll just swap it out when that comes up.

That is all!

Fixing The Flaws

Take a look at the picture below:

This is a common scene in the old Filament design: a room with some objects strewn about, in this case a table with a block on it. There are two core issues that jump out at me when I look at this: First, there is no way to tell where one object begins and one object ends, other than pure intuition. The second problem is a physics one: what’s to keep all of these objects from just falling through each other (the core game mechanic)? Nothing.
These two issues have made level design very difficult, almost impossible, even.
Luckily, a better mechanic is available! See the image below:

By introducing a color mechanic, we fix these two issues completely. Our scene is now stable, objects will not phase through each other the moment the level opens. Instead, we’ve tweaked the phasing mechanic so that only objects of the same color may overlap. This opens up a bunch of puzzle possibilities that just weren’t there before, and that’s never a bad thing!

The player gains the ability to change to certain colors at will, which lets the player phase through matching entities. Certain colors, like black, may remain impenetrable to the player, but only to enforce some sort of level boundary. The main idea is that this opens up a vast ocean of enemy and puzzle mechanics. Image a boss fighting you, shooting fire balls or some other manner of projectile. You simply change colors to match it, and it goes right through you. This can be spun into all manner of fun and challenge, and I look forward to designing around it.

New art style

Hey, Harris again

So we were thinking of adding some color, just to add to the setting. In this 1st concept, we have a heavily desaturated yellow to allow the idea of being outside. This place is the nuclear stage, but we'll talk about that when the game is closer to being complete,

More concept art (New Character Design)

hi, this is Harris, concept artist for filament, I will probably be taking over posting these images from now on, so they will be a little faster getting here. Im kinda bogged down in other projects, but expect a lot more starting January next year. The dragon image uses the old character design, the monkey uses the new one.

Demo #4 Breaks ALL THE RULES

Demo 4 brings a host of changes to the core packages, including improvements in the rendering pipeline and a basic implementation of a physics system.

Try out this EXTREME DEMO
Edit: Demo restored!

If you move the inversion block too fast, or crush the gray block, it will automatically move to a nearby safe position. In the actual game, the player would have been killed when the gray block turns red.

So anyway, the graphics are still the same, but now the background (collection of all non-moving masses) is pre-rendered at creation time. The game then uses the pre-rendered background as the canvas to paste the potentially moving objects on. When the backgrounds get more diverse and complex, this will definitely save some valuable render time. It also allows for a neat and simple environmental destruction mechanic, where applying a blank color to the pre-rendered background would permanently erase the black, interactive segments. One way to utilize this could be an enemy firing a laser through the world and leaving a hole that the user could walk through, or that objects could fall through.

The physics system is quite simple. Every mass has a velocity vector, and the arena has a known acceleration vector. When you press a key, such as <LEFT> or <RIGHT>, the gray mass is given a certain velocity in the positive or negative direction perpendicular to the direction of acceleration. It’s simple, fast, and allows me to tweak the way gravity works at any given moment ("gravity wells" WILL be a game play mechanic).

You can switch the gravitational direction by pressing <UP> and <DOWN>. <SPACE> jumps.


Also, the movable block now locks to a 5 x 5 grid!

Demo #3: Primitive Displacement

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.