Specter is an action-platformer which borrows a lot of our favorite tried-yet-true mechanics from the genre and meshes them, all while adding some new concepts to the mix.
You play as king Harold who's castle has been overtaken by spirits. While otherwise reasonably pleasant neighbors, they decided to not longer tolerate the loud parties and drunken noblemen, puking on their sacred grounds.
Thus they raided the castle, possessing Harold's sweet skull decorations and stripping him of his abilities.
Now he must trudge through his haunted halls, feeling remorse, and reclaim his lost skills.
So much for the set up...
The game revolves around the king’s abilities. You’ll be receiving a new ability after the completion of just about every level (attacks/activations are inspired by the Kirby series), and you’ll be using your abilities during both battles and platforming sequences.
There you are going to encounter obstacles such as walkways that flip around when struck by your dashing attack, or platforms that only appear when struck by a charged projectile (a more literal approach to “action-platforming” if you will).
The theme of Specter’s gameplay is critical thinking. We want players to constantly be thinking about the most efficient attack to use on a group of enemies, or quickly assessing a simplistic puzzle, before leaping forward in narrow escape of rising lava.
This concept is encouraged in combat with elements like time limits during battle segments, and valuable rewards for speedy battle playthroughs (such as boosted max HP, secondary effects for your attacks, or even unlocking special attacks).
We want platforming in Specter to revolve a little less around precision, and more around thinking before you leap... ranging from quickly assessing a jump, to full-fledged puzzles.
We are three people working on this. I'm doing the programming and Blair the art/game design. The music is by Jonah Backfish
It might be interesting to mention that I live in Germany, while the other two guys are from the US. We do all of our communication via Skype, and share files via Dropbox (and git for the code). The 6 hour time difference was something to get used to, but it's working well now.
Currently I'm using XNA, but I really want to port it to MonoGame as a lot of my friends only run Linux and I want to support the Linux game dev community.
We are looking mainly for feedback on level design, but any criticism is welcome!
I'm currently working on a 2D platformer with a friend of mine. I do the programming, he does the art. He uses GraphicsGale for all his sprite animations and, as of now builds our sprite sheets in Photoshop manually.
As I had some down time yesterday I decided to see, if I can speed up his workflow in some way. I found GraphicsGale's exporter lacking in several respects. There is no plugin system to export to custom formats, just one format for frame information (csv, no xml or json) and no export from the command line.
Of course you can export single frames and use a tool like TexturePacker to build sprite sheets, but that's still hard to automate.
So I started to write my own exporter for .gal files (luckily they provide an API), It's not far along yet, but has already basically the same features as the internal GraphicsGale one.
I plan to add:
Custom exporter support via LUA or Python (will probably build some for the basic TexturePacker formats)
Easy integration into your build process
And more stuff as it is needed
I'll also share the code under an open source license.
I don't know how wide spread GraphicsGale actually is, but if you're interested in something like that let me know!
I am trying to implement a flexible solution for applying shaders to sprites in my XNA game. I have troubles coming
up with an efficient way to maintain back-to-front draw order (or any other way to draw translucent sprites correctly)
while having the possibility to draw each sprite with a different shader.
The only thing I can think of right now is sorting the sprites by depth and then starting a new SpriteBatch Begin/End block
everytime the current sprite has a different shader than the previous one, like that:
List sprites; //Depth-sorted List of sprites
Sprite prevSprite = sprites;
spriteBatch.Begin(..., sprites.shader); //begin with the parameters for the first sprite
foreach( sprite in sprites)
if(prevSprite.Shader != sprite.Shader) //if we have to switch the shader
spriteBatch.End(); //end old, begin new block
spriteBatch.Draw(sprite); //draw the sprite
This could potentially end in a lot of draw calls, though in a 2D game it might be probable for sprites with the same shader to be
drawn at the same depth. Has anyone a better idea on how to do this?
Hey all, I ran into a problem with my 2D Deferred Lighting implementation and I hope you can help me.
For the 2D game I'm currently programming I decided to go with Deferred Lighting, because it is supposed to be easy to implement and fast. I used this tutorial as a starting point and adapted it to my needs.
It's all working fine and looks amazing except that I get a sever drop in framerate as soon as I enable the lighting. From about 2500 FPS (CPU-Bound/ 80% GPU load) it falls down to 1000 FPS(GPU-Bound/70% CPU load). Of course 1000 FPS is still quite high, but considering my system (and the 2500 FPS without lighting) it's actually not that much.
I did some profiling and testing and it showed, that about 50% of processor time is spend in EndDraw(), this usually means, that the graphics card is overstrained and needs some time to catch up. I can't explain why that is, because after all I'm just rendering 9 lights to a 1280x720 texture and I've seen Deferred Rendering Engines with over 100 active lights.
This is how my code currently looks like:
private int RenderLights(List<Light> _lights, ref RenderTarget2D _lightingRT)
int lightsRendered = 0;
Device.BlendState = BlendState.Additive;
// For every light inside the current scene
foreach (Light light in _lights)
//simple early out condition (rough not in sight or not active)
if ((light.Position - (Graphics.Instance.MainCamera.Position + Graphics.Instance.Resolution / 2)).Length() >
(Graphics.Instance.Resolution / 2).Length() + light.Distance || !light.IsActive)
lightEffect.CurrentTechnique = lightEffect.Techniques["DeferredLight"];
//Set light parameters
if (light is Spotlight)
lightEffect.Parameters["angleCos"].SetValue((float)Math.Cos((light as Spotlight).Angle));
lightEffect.Parameters["lightNormal"].SetValue( Vector2.Transform(new Vector2(1, 0),
// Draw the full screen Quad
Device.DrawUserPrimitives(PrimitiveType.TriangleStrip, vertices, 0, 2);
// Deactivate alpha blending
Device.BlendState = BlendState.Opaque;
// Deactive the rander targets to resolve them
My first guess was, that the lighting shader is just too slow, so I made it to instantly return solld black. But that didn't change anything. The framerate stayed exactly the same.
I discovered that as soon as I don't apply the shader's pass (comment "lightEffect.CurrentTechnique.Passes.Apply();" out) it runs fine, but of course without the lighting.
I even did some profiling with PIX and looked at the time one light draw call takes. With my own shader, which just returns black it were about 200,000 ns, with the default one 130,000 ns. That difference could explain why the framerate drops, but I don't understand, why the default shader is so much faster than just returning black.
Does anyone have an idea of what might causing the heavy load for the graphics card?