Created: November 21 2011
What's happening recently... I added tutorial topics covering trajectory prediction and 'sticky projectiles', which also looks at a way to model an arrow in flight. And mayobutter's conveyor-belt idea made it into Box2D proper, so the conveyor belts topic has been made simpler. Next will probably be one-way walls/platforms.
I have been working on the boxing game a little here and there, at this rate it's not likely to be done until next February I'm guessing :) Here are some screenshots of the fight scene, this will give you an idea of how it will look. The big TV screen at the back is used before and after the fight as the menu screen. So while you are choosing your fighter character the 3D scene is already loaded and you are actually looking at the arena screen, but the camera is perfectly positioned so that you can't tell this until it pulls out and swoops down to the ring. Then after the fight the camera swoops back so that the arena screen once again perfectly fills the device screen. Quite neat if I say so myself... and I do.
Actually most of the work done since my last blog post is not related to the screenshots above.
If you were thinking that the heads of the fighters look too big, this is because you will be able to put photos onto
them, either from the device's photo album or by taking a photo with the camera. You can set up
three photos, normal face, ouch face and K.O. face for when you lose. Being able to beat on your
friends should be fun. So the menu screens for setting these up is where most of the work has
been going lately.
The fluid simulation has not been touched for a while. I came to realise that the loss of area that occurs in a collison needs to be corrected much more before continuing to the next time step. Currently I am first joining the drops together, then looking at the area that needs to be made up and pushing the surface outwards at places with high pressure, which is a good start but those new locations can still be intersecting so the area is not fully accounted for in just one iteration. I think something like Box2D's position iterations setting would be needed to do this say 10 times or until a stable point was reached.
The other thing I realised was that two colliding drops should not simply have their surfaces joined, because this discards information about the pressure in the overlapping portion. The overlapping portion should first be used to come up with a new border line between the two drops as if they were immiscible, and their area loss should be corrected individually before allowing them to become one drop. This has a couple of nice advantages: firstly the density of each liquid can be taken into account when defining the new border between them by allowing the denser one to take a larger portion of the overlapped region. Secondly, if you know where their border is, just don't merge them and you automatically can simulate for example oil and water.
The drawbacks are that the collision tests are more complex. Previously I had a linear time method which just ran around the edge of each drop looking for overlapping lines, and there was a simple algorithm to know how to cut them and which pieces to discard. If no surface sections can be discarded this won't work. There are other things to think about when rigid bodies come into the picture too... Since the new way of dealing with drop/drop collision is similar to how I was thinking to deal drop/rigid collisions. I still think there might be a way to keep everything handled in a 'unified' manner, but until I can figure it out I will probably not be coding any more just yet.
What I have been doing instead is checking out SFML and Angelscript. For some reason I had been thinking the ML in SFML stood for markup language so I had not bothered to even google it - silly me. Boy was I pleasantly surprised. With Angelscript too - how did I miss that one! I have used the Spidermonkey Javascript engine for a little scripting in the past and was thinking to use that again, but I never really found a way to fit it into the 'brains' of game entities satisfactorily, and I'm not a big fan of the un-typed nature of it (quietly letting you run something that will blow up in your face later), and being able to develop in Angelscript and then drop it (mostly) straight into C++ is a huge win too. I'm sold.
So I'm getting accustomed to these new (to me) tools lately. I was pleased to see how easily an SFML window fits into a Qt widget - this means that it could be used for the editor, and then detached to run on its own as a game using mostly the same code. Angelscript I am intending to use obviously as the 'brain' for AI, as well as probably for settings files to tweak values while running. Eventually it would be good if the editor had some scriptable features too.
Game progress
What's happening recently... I added tutorial topics covering trajectory prediction and 'sticky projectiles', which also looks at a way to model an arrow in flight. And mayobutter's conveyor-belt idea made it into Box2D proper, so the conveyor belts topic has been made simpler. Next will probably be one-way walls/platforms.
I have been working on the boxing game a little here and there, at this rate it's not likely to be done until next February I'm guessing :) Here are some screenshots of the fight scene, this will give you an idea of how it will look. The big TV screen at the back is used before and after the fight as the menu screen. So while you are choosing your fighter character the 3D scene is already loaded and you are actually looking at the arena screen, but the camera is perfectly positioned so that you can't tell this until it pulls out and swoops down to the ring. Then after the fight the camera swoops back so that the arena screen once again perfectly fills the device screen. Quite neat if I say so myself... and I do.
Actually most of the work done since my last blog post is not related to the screenshots above.
If you were thinking that the heads of the fighters look too big, this is because you will be able to put photos onto
them, either from the device's photo album or by taking a photo with the camera. You can set up
three photos, normal face, ouch face and K.O. face for when you lose. Being able to beat on your
friends should be fun. So the menu screens for setting these up is where most of the work has
been going lately.The fluid simulation has not been touched for a while. I came to realise that the loss of area that occurs in a collison needs to be corrected much more before continuing to the next time step. Currently I am first joining the drops together, then looking at the area that needs to be made up and pushing the surface outwards at places with high pressure, which is a good start but those new locations can still be intersecting so the area is not fully accounted for in just one iteration. I think something like Box2D's position iterations setting would be needed to do this say 10 times or until a stable point was reached.
The other thing I realised was that two colliding drops should not simply have their surfaces joined, because this discards information about the pressure in the overlapping portion. The overlapping portion should first be used to come up with a new border line between the two drops as if they were immiscible, and their area loss should be corrected individually before allowing them to become one drop. This has a couple of nice advantages: firstly the density of each liquid can be taken into account when defining the new border between them by allowing the denser one to take a larger portion of the overlapped region. Secondly, if you know where their border is, just don't merge them and you automatically can simulate for example oil and water.
The drawbacks are that the collision tests are more complex. Previously I had a linear time method which just ran around the edge of each drop looking for overlapping lines, and there was a simple algorithm to know how to cut them and which pieces to discard. If no surface sections can be discarded this won't work. There are other things to think about when rigid bodies come into the picture too... Since the new way of dealing with drop/drop collision is similar to how I was thinking to deal drop/rigid collisions. I still think there might be a way to keep everything handled in a 'unified' manner, but until I can figure it out I will probably not be coding any more just yet.
What I have been doing instead is checking out SFML and Angelscript. For some reason I had been thinking the ML in SFML stood for markup language so I had not bothered to even google it - silly me. Boy was I pleasantly surprised. With Angelscript too - how did I miss that one! I have used the Spidermonkey Javascript engine for a little scripting in the past and was thinking to use that again, but I never really found a way to fit it into the 'brains' of game entities satisfactorily, and I'm not a big fan of the un-typed nature of it (quietly letting you run something that will blow up in your face later), and being able to develop in Angelscript and then drop it (mostly) straight into C++ is a huge win too. I'm sold.
So I'm getting accustomed to these new (to me) tools lately. I was pleased to see how easily an SFML window fits into a Qt widget - this means that it could be used for the editor, and then detached to run on its own as a game using mostly the same code. Angelscript I am intending to use obviously as the 'brain' for AI, as well as probably for settings files to tweak values while running. Eventually it would be good if the editor had some scriptable features too.