I finally got the shadow effect working correctly.
Wait! I haven’t written for a while. Let’s rewind five weeks…
~
I had just finished the final part of my platformer prototype, getting player contact forces working (when the player stands on something, it goes down). I said I had 11 and a half weeks left in the competition and was planning on spending the next three or four of those on “technology”.
The next two weeks were indeed spent on technology - specifically a level editor. I got a simple polygon and vertex editor working, with all the nice things like load/save, undo/redo, and so on.
The third week was mostly spent away from my keyboard. When I got back I started by copying in the shadow effect that I had prepared earlier.
While it worked just fine for simple polygons,
it had big problems with small polygons,
and also concave polygons,
and a few more not-so-edge-cases besides.
So the last two weeks have been spent recreating the shadow effect from scratch.
~
The “Fundamental Failure-Mode Theorem” states that every complex system is operating in an error mode - even if it appears to work. As it turned out, my prototype shadow effect was riddled with bugs that were (mostly) being masked by other bugs. Getting rotation functions reversed - but then always rotating things in the wrong direction. Only handling half of the possible illumination conditions - but using a testing shape that didn’t exercise the other half. And so on.
This wasn’t really surprising, given that this was a prototype. In cases like this, the “correct” solution is to throw the prototype away and start again with a more careful approach. (Admittedly it took a couple of days of “hammering” to reach this conclusion.)
First I redesigned the algorithm on paper. I then wrote a “visual unit test” system in C#, using line-drawing, that visualised the operation every little function. This helped ensure that both the algorithm and implementation were correct. It took a couple of iterations of this (rework on paper, update implementation, test) before it was finally working satisfactorily.
After that it was a simple matter of copying it into HLSL (a programming language used to create effects that run on graphics cards) and then a few days to squeeze it into the size (instruction) limit of my target graphics card architecture.
Here is a screenshot of the completed shadow effect, with some of the visual testing lines overlayed.
~
There are now six and a half weeks left in the competition. My next task is to bring in the physics and user interaction from the platformer prototype. I am hoping that it won’t be as problematic as the shadow effect was, so I can move onto actual gameplay as soon as possible.
Thanks to the help of Dmytry over at GameDev.net I have a working solution to the contact force problem I described last time.
Dmytry supplied me with the formula for the force an object applies to an object it is in contact with. Reproduced here:
force = mass ∙ ( gravity - acceleration )
Of course, I don’t actually know the acceleration, but I can approximate it each time-step as:
force = mass ∙ ( gravity - (∆ velocity / ∆ time) )
In the simulation, here’s what happens when a player lands on an object:
In the first frame, the player contacts the object and the ground snapping takes effect. This sets the player velocity to zero (if the object it landed on was at rest), from a large downwards velocity. The sudden deceleration, or upwards acceleration, results in a downwards force much larger than just the object’s weight on its own (Mass ∙ Gravity).
The problem I experienced here is that this downwards force, when applied, creates a downward acceleration in the next frame. This downward acceleration, when big enough, generates an upward force. The upwards force gives an upwards acceleration and a downward force in the following frame. And so on, in an oscillation that would often grow out of control.
The solution to this problem is to never apply an upwards force. Upwards forces are instead stored by the player object. Downwards forces first have to cancel out the balance of upwards forces accumulated, before being applied to the world. The result is that the force applied to the world, considered over frames, is physically correct, but doesn’t send the simulation haywire.
(I also cap and dampen the downwards force, but it turns out that this doesn’t yield any useful effect.)
You can download the new prototype here. (As usual, it requires .NET 2.0 and XNA 3.0, the easiest way to get these is to install Sketchable Game 1.)
New in this prototype are the arrows at the top (velocity across two frames), left (∆ velocity), and right (blue: cap on downwards force applied, yellow: stored force, orange: force being applied) of the player. Also new: F4 will hide debugging information (which can be distracting), including shape outlines that (due to the way they are drawn) tend to show “jitter” more than the underlying shape.
~
This prototype completes the platformer-on-a-physics-engine experiment, at least sufficiently to begin building it into a proper game. In the next phase of development of I will be taking this, and my 2D lighting prototype, and building an engine (and making it work on the Xbox) and an associated editor. I don’t know a proper name for this phase, so I will just call it the “technology phase”.
There are around 11 and a half weeks left in the Dream Build Play competition. Prototyping took about a week longer than I would have liked. I’m now going to aim to spend three, maybe four weeks on the technology phase, leaving about 8 weeks to dedicate to the content.
The final feature I want to implement, before moving onto the next phase of development of my Dream Build Play entry, is dynamic platforms. In a traditional platformer, the player (controlled object) reacts to a moving platform by moving along with it. With the addition of a physics engine, it makes sense to also have platforms that react to the player standing on them.
The following screenshots demonstrate a simple application of the effect:
You can download the latest prototype here (as usual, it requires .NET 2.0 and XNA 3.0, the easiest way to get these is to install Sketchable Game 1). There is a list of controls in my previous post about the platformer prototype.
In this prototype, platforms that move the player work nicely (use the number pad to move the selected platform), but the player moving the platforms is not quite finished - I’m posting this now because I’m going to ask for some help (both here and in this thread on the GameDev.net Maths and Physics forum).
First I should explain what is happening in the prototype. To get good walking mechanics within the physics engine, I have disabled bits of it and replaced the missing functionality with my own. Specifically: when the player is on the ground I disable gravity, fix the vertical velocity at zero, and ignore collisions with the “feet”. Then, to keep the player on the ground, I “snap” the player’s position each frame to a point exactly on the surface. The snapping occurs at the intersection of the edge of the ground polygon with a line extending from the center of the player to a point just below the player’s feet.
(You can visualise this in the prototype, especially when zoomed in: The red outline is the pre-snap position of the player, the pink line shows how far the snapping line extends below the player’s feet.)
The Farseer Physics Engine works by separating object penetrations. When the player is snapped to the surface there are no penetrations to separate and the player has no effect on the objects it stands on. This is the behaviour of the previous platformer prototype (this behaviour can be toggled in this prototype with F7).
In this prototype I added a simple but incorrect downward force at the player’s feet to simulate the player’s weight on the object the player is standing on (the force is the player’s mass, multiplied by gravity). This provides an unconvincing approximation of the correct movement.
The see-saw-test level included in this prototype download (and seen in the screenshots above) is useful for demonstrating the main failure cases (Ctrl-O to open levels). When the player jumps onto the raised end of the see-saw, it seems to “stop” when it lands - as if its momentum is not transferred into the see-saw. Then, the see-saw seems to tilt back-and-forth for longer than it should - again I suspect this is something to do with momentum not being transferred from the see-saw back into the player.
To demonstrate the correct behaviour, in this prototype, the ground-snapping behaviour can be turned off (with F8) and the player acts as a normal physics object. In this case it is easier to use the debug-movement keys (the arrow keys) instead of the gameplay keys (W, D, space) to drop the player onto the see-saw and see the more realistic result.
So my question is - how can I simulate the correct behaviour, ideally in terms of applying force to the object the player is standing on?
Here we go again with another 2D lighting experiment. This time the soft shadows are generated using only geometry, no need for fancy full-screen post-process pixel shaders. As you can see from these screenshots, I also have multiple light sources working.
You can download the prototype here. As usual, it requires .NET 2.0 and XNA 3.0, the easiest way to get these is to install Sketchable Game 1.
Use the left mouse button to add lights to the scene. Press space to reset.
The prototype from yesterday was suffering from some aliasing and banding artifacts. I mentioned yesterday that I could fix them, but it would be expensive in terms of system resources.
For sake of exercise I went ahead and made the improvements. The improved prototype can be downloaded here. (As usual, it requires .NET 2.0 and XNA 3.0, the easiest way to get these is to install Sketchable Game 1.)
The previous method used a single full-screen post-process effect per-light. This one uses three per-light. Either way it becomes expensive when considering that I want to use lights for gameplay, and I will want to have a lot of them.
I have some ideas sketched out for a purely geometric solution that should be much faster, if it works.
This is a first attempt at 2D soft shadowing, getting some penumbras going.
You can download the prototype here. (As usual, it requires .NET 2.0 and XNA 3.0, the easiest way to get these is to install Sketchable Game 1.)
What I am doing here is drawing the shadow geometry (see yesterday’s prototype) to an off-screen buffer. Along with the shadow shape I encode, per-pixel, the distance away from the geometry that is actually casting the shadow.
To get the soft shadows, apply a rotational (tangent) blur to that buffer, centered on the light source. The amount of blurring at each pixel depends on the distance value I encoded earlier. The upshot is a nice sharp shadow directly behind an object, that softens out further away.
Unfortunately the method is kind of expensive, if I were to have multiple lights. It also suffers from quite noticeable aliasing and banding artifacts that, if fixed, would make the method even more expensive.
Then again, it might look fine with some textures behind it, in-game. Also I’m thinking of using light and shadow as a gameplay element, for which hard shadows might work better anyway.
Here is some initial work on 2D shadowing. Download the prototype (as usual, it requires .NET 2.0 and XNA 3.0, the easiest way to get these is to install Sketchable Game 1).
This is just a simple vertex shader for generating shadow geometry on the GPU. Move the mouse around to move the shadow.
Continuing on from my previous prototype: Walking physics is now considerably more reliable, physics debug view is improved, dynamic geometry is now available, and it’s now possible to create and save “levels” (send me yours!). You can download the new prototype here. (As usual, it requires .NET 2.0 and XNA 3.0, the easiest way to get these is to install Sketchable Game 1.)
I will give you a complete list of controls. First player movement:
- A, D: Move left/right
- Space: Jump
- Arrow keys: Free movement (for debugging)
- R: Reset position (do this when loading a level)
You can also use an Xbox 360 controller: Left analog stick to move left/right, A-button to jump. The Jump button selects whether you want to use the keyboard or the Xbox 360 controller.
For level editing:
- Left click: Select geometry
- Left click and drag: Move geometry
- Right click and drag: Create geometry
- Mouse wheel: Rotate selected geometry
- Number pad 4, 5, 6 and 8: Move geometry
- Number pad 7 and 9: Rotate geometry
- Ctrl key: Hold for slower movement and rotation
- Delete key: Delete geometry
- Enter key: Convert geometry between static and dynamic
- Ctrl-S: Save level
- Ctrl-O: Open level
And finally there are some debugging keys:
- F1: Show Farseer Physics’ debug view
- F9: Zoom in/out
- F10: Pause simulation (toggle)
- F11: Jump forward by a single frame
- F12: Hold to pause / hold to play (when paused)
~
Dynamic geometry still has some issues when the player is walking on it (when pushing it around, it seems to be fine). Specifically a walking player doesn’t affect the geometry that is being walked on, or vice-versa. This means (for example) that the player’s weight won’t make a piece of geometry topple over an edge. It also means that the player won’t move horizontally along with some geometry that also is moving.
It is also possible for the player to get stuck if there’s a hole on the level where the sides of the player can stop on, but the feet don’t touch a walkable surface (which means the player cannot jump or move effectively side-to-side).
I might try to fix these issues later. For now, I think, I will look at prototyping something else. At the moment I’m particularly interested in 2D-occlusion based effects - for example falling water, rain and light. These have the potential to be very pretty and to introduce some entertaining gameplay.
Things are going smoothly again, which is good. Yesterday and today I rolled the physics engine stuff and the platformer movement stuff into a single prototype that you can download here. (As usual, it requires .NET 2.0 and XNA 3.0, the easiest way to get these is to install Sketchable Game 1.)
The “player controls” are: A and D to move left and right, space to jump. Or you can use an Xbox 360 game pad: left analogue stick to move and the A-button to jump. Pressing jump will switch input method.
Additionally there are some debugging controls. Arrow keys will let you fly around; holding number-pad-zero allows ground-snapping while doing this. F1 to see the physics debug view. F2 to see the ground-snap range. F12 to pause and, while holding that down, F11 to jump forwards by a frame.
The ability to pause the simulation and to jump forward one frame at a time was particularly useful when developing this prototype. Especially in concert with the visual debugging aids - you can see these as dots and circles that flitter about when things happen. These give some real-time feedback about what is happening “under the hood”, in a way that a debugger simply cannot match.
A quick word about the shape of the player: You will notice that it is a diamond. This has the benefit of having some width, while possessing an unambiguous point of contact with the ground (unlike the oft-advocated “capsule” shape). In the previous prototype, I used a rectangle for visualisation, but the actual mechanics were based around a single point. Those same mechanics are used here.
My next step with this prototype will be to add some more and more varied geometry, as well as some non-static geometry to see what happens when the player pushes things about and is pushed about.
