My friend in his youth created an entire storyline and comics based on some batman like characters. One was BatChao (his last name being Chao) which was I guess, for all intents and purposes, Batman. He was then killed, and became BatChaos. A new BatChao rose to take up the mantle of the now deceased and ghostly BatChaos. In this universe, Batman exists as a comic character. . . I didn't go too far into the nitty gritty details of how things work seeing as how this was a middle school creation.
Anyway, I'm currently deep in Arkham City (Which is fantastic) and got the urge to draw the Batman, but didn't really want to devote the time to doing it. . . And in some kind of perfect storm of coming up with a flimsy excuse to do some batman fanart, I went ahead and did a fan art drawing of my friend's characters (who are basically batman anyway). He also works at Disney Interactive, so that should explain the BG. Oh, and it's the size it is just in case he wanted to use it as the art for a custom iPhone case online.
I sorta skimped out at the end because it was getting late so the cape isn't all that it should be, but overall, I'm fairly happy with the results. Here's some pics I took while I was drawing the thing.
BatChao is the one in the front as well as the one in the initial super sketch -_-;; Apparently, he's got like, a baklava type deal on underneath the mask that covers his entire face. Anyway, just thought I'd share cuz. . . . well, just because.
In the meanwhile, I'm still working on my game. I've redone the targeting system and I personally think it works better now. I'm also in the midst of trying to figure out how I want dialog to work, so I've been making, dismantling, and recreating my dialog system. I've got some specific things going on that I think are unique so I can't really share it at the moment as I don't want to give it away. . . you know. As if anyone would really steal my ideas, but on the off chance, I'd rather keep it to myself until I'm ready to really show it off =P I'll post some other updates sometime soon.
This is a short vid, with a long post about how I dealt with the gravity situation. I love physics. I love math. But they can be a real pain in the ass when you don't understand them -_-;;
The Math Behind Gravity
So, I've had a pretty basic way to do targeting before with the balls that show the trajectory and whatnot, but it was janky and a sort of slamshod put together business and was pretty restrictive in the types of aiming I could use. The hardest restriction being that the height of the throw couldn't be altered on the fly =\ This had to be changed so I delved into the math behind gravity and how I could use that to determine arcs and such. The following is basically a math class for anyone interested. To some it'll be sort of hard math, to most it's basic physics with some intermediate algebra. All I know is, I remember when I was learning this stuff in school thinking "when the hell am I ever gonna need this crap? Quadratic formula? psshhhhhhh" but lo and behold, this shit's everywhere.
Physics wise, you can pretty much completely separate directional movement and the force of gravity. At least, in this game you can as I'm not going to calculate anything like wind resistance and whatnot. . . at least not yet. Getting the direction that an object should travel is easy. You just normalize the difference between the target and the object tossing the item. The problem is determining how fast this object should travel at a given launch velocity. This gets even more complicated (at least for me) when you start to factor in varying heights for the target and the tosser.
The base of applying gravity is simple. The speed an object is moving vertically is just increased by the amount of gravity over and over. This is simplifying things greatly if you're looking at the real world, but again, I'm working without any frictional drag. And also as of yet, haven't found the need to apply any sort of cap on fall speed. So, if I want to figure out the Y value of an object given a launch speed and an elapsed amount of time,
Y = launch speed * elapsed time - gravity * elapsed time ^ 2 * 0.5.
That right there is how I determine how high the targeting balls are to represent the arc the thrown object will take.
Now, if I'm talking just plain old flat ground, the speed that the object will travel is easy to find out. Basically, using the previous formulas, you can determine how long an object will be in the air assuming it was thrown from the ground, and will land on the ground. You can use an easy
time of flight = 2 * launch speed / gravity
Knowing how long something is in the air, you simply divide the distance between the two points and you know how fast you need to travel to reach the destination as the object is hitting the ground.
The real difficulty I ran into was figuring out the arc to hit the target when the target was above or below the tossing point. To get this bit of information, I ended up using the quadratic formula. First, I had to figure out if the target is above or below me using both their heights and getting the difference. If I always place the tosser at (0,0), I could use the QF, plugging in the difference in height as the Y value to figure out how much time, with a set launch velocity, would have to expire before the tossed object hit that height.
Time In Air Till Impact = launch velocity / gravity + sqrRoot ( launch velocity ^ 2 / gravity ^ 2 - 2 * target height / gravity)
With the knowledge of when in time, an object launched at a specific velocity would hit the ground at the specified height, I can now divide the distance that I need to cross by that amount of time and get the speed that the object needs to be throw in. And BAM.
I've got the core of all my gravity based targeting in place. It's set up in a way in which I can vary the height and if I wanted to, the speed of thrown objects. This'll go a long way in terms of enemy attacks in the future as well as giving the player more options. I'll still have to figure out a nice way to give the player control over their item throws, while balancing the complexity of the action. Progress.
Another really short vid just for my private record keeping.
I reviewed my item toss code, and didn't like it. So I rewrote it. It works a lot smoother now, and is much cheaper as far as the amount of lines it has to go through to get it done. As an added bonus, the code is really freaking clean which I like.
While I wanted to work on it again just because it was messy, the real reason behind it was to implement player controlled angled projectiles. Now, depending on how far the trigger is depressed, the player can control how high or low they throw the item. Next thing I have to do is add in the necessary code to have it work properly with the various platforms. I think I'm going to have to whip up a testing area again so that I can make sure everything I'm doing will work properly with all the old platforming code. Anyway, that's it for now.
This is almost a non update, but I threw together a quick text menu and the ability to spend the points you earn. Not a big deal appearance wise but I did a bunch of code changes to the way damage and items are handled to support upgrading.
Also, I had to rejigger a lot of the point counter stuff. It turned out subtracting wasn't as easy an operation as I originally thought it was. Though, it was easy enough once I figured out where the problem was. Everything seems to be gravy now so yea. . .
In this vid, player pretty much gathers up some coins, then spends it to unlock the double jump and the sustained jet pack. Everything is in flux as usual -_-;;
Here's another vid of iterating on this effect. Unfortunately, the audio has been disabled due to copyright stuffs. There's not much to say that's not covered in the annotations.
I only had a few hours tonight to continue working out how the steam would work and look. I thought I'd try something different and show off the iterative process that I'm using to get to where I want to get to. . . which I haven't gotten to yet -_-;;
I'm Not There Yet
but I'm on my way. While I'm not positive as of yet, I think this will be the general "look" of what I'm aiming to get to. I've still got a lot of refinement and also, artwork till I get to where it'll look how I want it to look, but I hope you can sort of see what I'm going for. Also, this vid should give you a better idea of the type of process I'm using to develop this particle engine, and so far, may of my other ones. I'll write some code, test it, see how it looks, determine what needs to change, change the code, test again, rinse repeat.
Open to suggestions
As usual, I'm open to any suggestions or comments. If you have any opinion at all on how this is currently looking and the direction I'm heading in, I'd love to hear it =) I'm considering animating the individual particle (steam clumps) to give it a better look, but first I need to get the core of how it'll look down. And then I'll get into refinements and final artwork.
I've done a few things since the last update including as usual, code cleanup. Smaller things that don't have to do with the main topic at hand include modifying the way the point counter on the bottom right works. Now it'll slide out and readjust when more number spots are needed. This is to sort of declutter the HUD a bit more and also because I think it looks snazzy and will look even more so once I get in some real artwork there. Also, I've finally updated the counter to count up points quicker because it was a bit ridiculous how long it used to take. I also increased the amount of multiplier gauge buildup you get from the regular lookin potato by 6x so that I could quickly build up the multiplier -_-;;
As for the steam effects, the actual sprites being used are temporary. I pretty much just needed some placeholder stuff so that I could get the coding started. Once I'm comfortable with the code, I'll put in some artwork that fits the overall style of the game better and I've already got a few ideas in that area. The spots where the steam comes out on the HUD right now, are not final but I just wanted to see if I could make the amount variable depending on what multiplier level is active and also, whether or not it's EXP, points, or both. The steam I've got set up right now, can be angled in any direction and will adjust the steam exit direction accordingly. In addition, the color changes from a brighter to a darker based on where the steam particle is at and the direction it's moving. The color changing is all done by the actual particle engine rather than being defined by me. . . well. I guess in a way it's defined by me because I wrote the code but I think you know what I mean.
I knew from the offset that I wanted the player to have a double jump, and I wanted to explain it as a blast of steam. The jetpack type thing is pretty much a result of me needing to test the particle engine and varying the strength of it and such. . . I'm not positive at this point whether or not I'm going to keep it but it would work with the story and setting I've got planned so it's a definite maybe.
This was a somewhat small update since I don't have much time during the work week to work on it but I'm happy with the progress. Open to suggestions, comments and criticisms.
A small update not worth creating a new blog post, but something I'm still happy with and going to post. I've added functionality to the experience counter so it works now as well as the gathered points counter. Exp on top, Points on bot. Also, I added a flipping number animation so that numbers don't just change instantly lookin all. . . instant. Now I've got both points and Exp pooling. Right right! =D
Here's a look at something I just finished putting together.
I've finally put together an actual spot on the hud that'll show the player how much he/she has gathered up in points prior to banking. The bottom set is for points, and the set above is for experience which I haven't added to the individual enemies yet. Or rather, they have exp values, it's just I don't have it set to pool yet -_-;; But I'll get around to it.
The Break Down
Here like before is the sprites as they appear on the spriteSheet prior to being cut up and put into the game proper like. I'm nowhere near done with the detailing on the housing and while the numbers themselves are complete, I'm going to add an animation that'll play for when the number is changing from one to another. The look I'm going for in these is like, those flipping numbers that work like a roladex calendar. The housing itself will also have labeling to point out which is the exp, and which is the points. Pretty much, it's barren at the moment. Still, I'd like to show my progress in stages which is why I'm putting this up now.
This weekend, I feel like I've spent the bulk of it making the art rather than coding. Which I'm cool with since both need to get done and as long as I'm working on something, I'm making progress. Also, while I love coding, I also love seeing the things I'm drawing appear on the screen looking how I want them to look. It's still a bit rough, but I feel like I'm starting to get a better feel for how the game will eventually look. The HUD is going to be a very important element of the game. I've got some pretty big plans for it and I need things working before I can start expanding and implementing those plans. I hope when I start to show it, you guys/gals will agree with me that it's prolly the best path for me to take.
Anyway, till next time =)
EDIT: Btw, the position of the hud elements are not set as of yet. I plan on pushing it further down and away from the middle of the screen to provide more game space. Also, it'll retract when not in combat. That's later tho -_-;;
This is a somewhat smaller update to my previous post but the work that went into it was no small task -_-;; Here's the vid, and following I'll do a slightly more in depth look at the process behind creating something that seems so simple.
Here's a screen of the actual multiplier light thing up close.
The parts that make the whole
And here's a breakdown of all the parts as it is in the spritesheet.
I apologize for the ridiculous watermark, but I'd rather be safe than have my stuff appear elsewhere -_-;;
The order that it's drawn and put together is the second row, right hand side glow is drawn first in the very back followed by the unlit number panel on the top right, then the number glow (bot row), the lit numbers in the row above the bot then the glass casing+mesh in the second row.
What I wanted the damn thing to do
The way I have the actual coding set up, is a lot more complicated than it has any right to be -_-;; To break down how it was put together, I first need to explain the things I wanted to happen. Here's a list!
Slow pulsating regardless of anything else
When a number changes, old number slowly cools away
As multiplayer gauge increases, glow intensifies
For such a short list of demands, it took a lot of doing.
Simplified explanation of the code
Here's where the boring stuff comes in. Some of this stuff is going to require a bit more explanation than I'm really willing to write down, but I'll try to make it simple enough for anyone interested to get the jist of it. EDIT: So, I wrote it down and I'm comin back up here to say, it's a dirty read. It's not very well written and may be more confusing than it's worth to read, but it's there -_-;; I'll answer any questions anyone might have about it if they'd like.
First thing I did was create source rectangles for each and every number and it's corresponding glow that contained the location of the individual numbers on the spritesheet. I also made three source rectangle containers that would be used to draw the number glowing, the current active number, and the currently deactivated number.
Two bools (true or false). one for whether or not the glow was increasing (isTubeGlowUp) and one for whether or not the old number was currently cooling down (isTubeCoolingDown).
Two floats (decimal number). One for the pulsing alpha amount on the glows, and one for the alpha amount of the cooling down number.
The main glow and pulsating
For the base amount that the currently active number would be glowing, I used the percentage that the multiplier gauge was full (number between 1~0.0) and lerp it between the minimum amount of alpha I want (0.4) and the maximum (0.8) based on that percentage. This causes the active number and the glows to increase when the gauge is getting to its max, and decreasing when it starts to fall down.
For the pulsating glow that is happening apart from the main glow amount, I use that float and bool I created earlier. If isTubeGlowUp is true, I add 0.005 to the float every update until it reaches 0.2. When it hits 0.2, I change isTubeGlowUp to false and when it updates and that bool reads false, it will subtract 0.005 from the glow amount every update until it reaches 0. At which point it's set up to change the isTubeGlowUp back to true. This repeats and that float amount is added to the main glow amount. This is also why the main glow is set to max out at 0.8 because if that's at max, and the pulse glow is at max, that equals the full amount.
That takes care of the pulsating, and the glow increasing with the gauge.
The number cooling away
When the number in the tube changes from one to another, I run a method that determines which number should currently be drawn. When this happens, the two containers that hold the number and corresponding number glow is filled with the proper source rectangle. After this happens, the third container is filled with what was the previous number so that it can be drawn cooling down. The isTubeCoolingDown is also switched from false to true. When this is read true, the alpha float for the cooling down is subtracted from every update till it hits a predetermined threshold at which point, it changes the bool to false, and resets that alpha to full so that it's ready for the next draw.
That's it for now
Yup, that's it for now. I also demonstrate the screen safe mode and how it effects the hud because I forgot to show it in the last vid. I'll post more eventually.
It feels like it's been forever since I've actually uploaded a video. That's not to say I haven't been busy =)
So, what's most obvious is going to be that gauge on the bottom left corner. It's far from being done as there needs to be multiple other components to it including a proper counter for the amount that is currently stored and more importantly, the number that the multiplier has reached itself. For now, it's just showing the bar that you're growing to get up to the next multiplier. Also, I've added a sort of super rough draft of a roll evasion the player can use to get out of a tight spot. It goes through mobs and objects but I don't plan on allowing it to get through world objects. Walls and such still stop the player properly and you still function up and down ledges.
How the Gauge Works
The gauge will fill up from combat. As I mentioned before in my blog about how I want to sort of handle experience, the point is to have a risk reward system that the player will be using. I haven't implemented any sort of losses just yet, but that'll come in due time. For now, it's only the gain portion that the player is worrying about, and also only with the money and not as of yet experience points. As the player attacks enemies, the damage they take gets transfarred to the gauge. Like I mentioned before, and is demonstrated right off the bat, if you use the same attack on an enemy multiple times, the amount that it adds to the gauge decreases. This will promote use of a variety of moves as opposed to just using what's most effective but only when it comes to building up the gauge. If you're just out to kill something, by all means, use what you feel most comfortable using. In addition to just repeat moves, the amount the gauge increases also depends on the level multiplier you're trying to achieve, the enemies themselves will have a variable that will change from enemy to enemy, your current combo count and I plan on adding a few other things to help with the gameplay.
How do you use your multiplier?
it's a button. At any time, you can hit the button, and it'll take your current multiplier, and add it to your stored points then transfer it to your actual points. The goal would be to build up your points and multiplier at the same time and bank it at the ideal time. Again, I haven't implemented the negatives of holding off banking immediately just yet, but that'll come soon enough. I hope =P
There's a bunch of changes in the code. While I'm making this thing, I'm still studying and boning up on my C# and any time I learn something new, I'll go back through my existing code and put them in where it makes sense to do so. This takes time, but it also helps me remember things I've learned and cleans up my code so that it's easier to know exactly what's going on. Also, in most cases, these changes make the code run more efficiently. While I haven't even begun to reach a point where optimization will be an issue, I think it's best just to do it when I can so that it'll make things easier on me later on. A few of the things I can think of that I've touched on since my last update are. .. I'm still tweaking and fiddling with the proper way to do air combat. I've split up a lot of my combat into separate chains so that they're easier to manage and expand. I've futzed with the items a whole bunch including allowing the player to put their usage into regular combos. You can also use them in the air now. I updated the heck out of the screen safe mode so it works with all current hud elements. Obviously a lot of that exp/multiplier stuff going on in the background. I've made some touch ups on the HUD elements. I've separated (for the player at least) the shadow from all animations. (this took remaking all my sprite sheets but it's worth it). I've got a few other things as well but I can't seem to recall. I've also put some amount of time and thought into some new enemies and the story of the game but those I'm a little less inclined to share at the moment. Maybe at all -_-;;
You can prolly tell the vid quality is still a bit shakey. The game runs at a fluid 60fps on pc and 360 but for some crazy reason, I can't seem to record it properly. It looks pretty damn janky, but I promise it doesn't look like that. I plan on putting more work into this thing over the weekend. As always, comments and suggestions are more than welcome. I'll answer what I can and listen to anything anyone has to offer about the game, mechanics, etc.
I was reading some replies and whatnot about the PS3 thing, and someone mentioned that they haven't been online in a while. Then I realized, my PS3 isn't even plugged in. It's set up to my speakers and television, but the AC isn't plugged in. I pulled it out a few weeks back to plug in this little device that emits sound to scare away bugs. When I rented Resistance 3, I unplugged the device, booted up the PS3, ran updates, beat the game, unplugged it then plugged the bug thing back in.