Jump to content

  • Log In with Google      Sign In   
  • Create Account






Siege Weaponry, Redoing the UI Backend

Posted by JTippetts, 31 January 2013 · 601 views

Goblinson Crusoe isometric rpg hex based turn based
Posted Image

Been fleshing out the combat some more. I added a new damage type, Siege Damage, in anticipation of adding siege weaponry such as the above catapult. Catapults (or whatever types of siege machinery I eventually end up with) will be craftable minions that can be summoned onto the battlefield using Kits that you can craft from found materials. They will be useful in later stages of the game, when the rival wizards that you must defeat to obtain materials and magic will be entrenched in fortified bases.

Siege Damage is effective against walls and barricades, but less effective against monsters/NPCs/etc... Of course, there are other types of turrets and magical machines that will be good for mowing down hordes of enemies.

In other news, I've stripped out the old UI system. I've retained the graphics, but I am reworking how the UI works from the ground up. As the UIs got more and more complicated they were getting slower and slower. Most of the underlying code was pretty quick proto stuff, so I've stripped it and am working on a batching system that collects all UI elements into render batches.

I am also in the process of re-thinking shadows. Currently, I have just been using a soft blended fuzzy black disk for shadows, but I am kind of toying with the idea of rendering shadow layers for each sprite. So if the above shot looks odd without the shadows, I've got them disabled right now. I'm still not entirely sure I want to re-render the sprites with shadows, though, especially since it complicates the pipeline a little bit.




Very awesome. Your modelling skills are improving alot! Not that I can comment - mine are nonexistant.

I am also in the process of re-thinking shadows. Currently, I have just
been using a soft blended fuzzy black disk for shadows, but I am kind of
toying with the idea of rendering shadow layers for each sprite. So if
the above shot looks odd without the shadows, I've got them disabled
right now. I'm still not entirely sure I want to re-render the sprites
with shadows, though, especially since it complicates the pipeline a
little bit.

When you render all your sprites with blender, then you should consider rendering the depth map too and use a kind of deferred shading approach to do shadow mapping and later lighting too. An idea:

1. render your sprites and depth map with an orthographic camera.

2. use a single directional, global, lightsource, render the shadows from an according orthographic camera

rendering:

3. write the depth map to a buffer (encoded depth).

4. after 1st pass, render all sprite shadow maps onto the buffer to determine the shadow.

 

I don't know what API you use (pure 2d, or maybe opengl), when using some shaders, you should include shadows quite easily.

Recent Comments

July 2014 »

S M T W T F S
  12345
67891011 12
13141516171819
20212223242526
2728293031  
PARTNERS