Pathing

I've now built up a way to implement simple pathing to anything I choose to spawn from the editor. For now, it's just a series of points that the object will follow in order. They'll either follow it to the end, then start over from the beginning, or follow to the end, and then reverse their course along the points. I plan on expanding on this in the future to allow pauses at specific points, maybe choosing which direction the object should face once paused or a variety of other actions that may take place at those points. In addition, I think I'll add a way to have just general roam areas that the object will wander around in randomly rather than a strict point to point type movement.

Retention

The game now supports the ability to store and recall what was in the previous area. This is obviously very important and basic, but yea. I've got it set up and functioning swimmingly. This stored data could also be used in the future for save files. I think the system is robust enough that if I want, I could go ahead and use it for saving at any point the player wishes. . . I doubt I'd allow that, but the option is there. In any case, all objects will now store and restore correctly. In addition to this, I've implemented a way for those objects to know how long a period of time the player was absent for. What can be done with such information you ask? Well, for starters, I can change their alert status from active to inactive so that if the player was gone for a long enough time, they'll just go back to doing what they were doing prior to chasing the player around. I'm also toying with the idea of having mobs be able to follow the player from one area to the next. It's not hard to do. . . at least, it's not too complicated, but I'm not sure just yet it's something I want. We'll see.

Grouped AI

Another thing I threw in is that enemies will now react to other enemies in their direct vicinity attacking the player. So you can't say hit one, and have only that one know what's up with joe blow right next to him is oblivious. Right now, it's super simple so they'll just also join in on attacking the player but I can flesh it out further once I get down to the nitty gritty.

Loading

It took some doing, but I put in a loading screen. On the PC which is where I'm capturing this stuff, it doesn't seem to take any time at all to load, but on the 360, I'd say in between those two levels, the load is around 4 or 5 seconds. I'm figuring with more art, sounds, and full sized areas, it'll be considerably more. I figured out how to break off a thread so that the loading screen can have stuff going on (animations and whatnot) to show that something is still happening to the player as the bulk of the system is loading up the next area. I also added a fade to black and fade back in between level loads to keep it from being too jarring. Again, this is all place holder and I plan on making something a little more interesting later on, but the foundations are now there so hurray for that.

What Else?

Aside from those, I've made a lot of smaller changes here and there to various systems so that everything works together nicely. A lot of clean up and optimization. I put a little more time into the way the camera handles as well. . . There was a crazy bug with the camera that I tracked down over an hour. The fix took literally 5 seconds. . . But oh man, finding it was sweet.

Huge Improvements to Level Editor

The biggest thing I've done since the last update is in an area that you can't really see which is the level editor. I've completely revamped it from the ground up. It's more robust and helps me build levels, make edits and whatnot way faster than before. Pretty much what would have taken me an hour will now take me only around 20 minutes or so. I'm guessing this'll be an even bigger help when I start constructing larger areas. Of all the things I've changed, the one I needed the most was a way for the editor to break up my larger sprite sheets into the individual pieces without me having to input the information every time. Now I can make an XML file with the info, and the editor will grab it and load up the pieces as individual selectable "tiles". They're not exactly tiles, but you know what I mean. I've also added a bunch of new types of world collision rectangles and the ability to spawn enemies in the locations I want them to be in.

Changes to the Game Engine

I've gone a bit deeper into the whole, segments turning see through. Now I can have multiple sets of objects become visible and invisible at the same time and I can also control when they become visible separate from each other. All for what I THINK is a low cost. In addition, I've further added to the functionality of switching levels. I show it here by running to the right, and appearing on the left of a different area, then running back left to once again appear on the right side of the original level. This can be toggled to happen automatically or be player controlled with a button press. I haven't gotten around to resetting the objects that are in the level yet, but I've got a good idea of how I can do it. Which should also work nicely with the save system I have planned.

Shadows. I have Them

Another thing I added is a system to determine whether or not objects should be shadowed or not. By shadowed, basically I just mean darkened as I don't think doing normal maps and whatnot on 2D sprites is something I'd want to invest my time in. . . yet. Anyway, I've got it set so that you can go in and out of shadows to varying degrees. It shouldn't be an issue applying this to everything in the game and as far as I can tell, I don't think it's a resource hog. Anyway, I think it's pretty.

Ceilings

A long long time ago, I had the whole tunnel thing implemented, but I've gone and updated it to work a bit better. Instead of just checking against your height, it'll check against the height that an object's head (or top most point) is at when deciding whether or not you're hitting the ceiling. I think I'll make it so that baddies take damage if slammed up against something. Anyway, it's back and I'm glad to see that it still works.

That's about it for now. A lot of visible progress. It seems like a lot in a short time but really, the speed that I could do it was only made possible by the week and half of straight cleaning and coding I did previously. Anyhow, I've got a couple other things planned. I really need to work on making the transitions between areas a bit smoother. . . Also, I need some new art if I want to build out levels to test, but before that. . . I need to finalize at least some of the areas the player will be going through. Mmmm. . . . also have to clean up my targeting code some. Plenty to do, not much time to do it in.

The Vid

I've haven't been updating recently

But that doesn't mean I haven't been coding furiously, because I have. Once again, I've gone through and cleaned up a ton of code. In the process, I've totally revamped the process my game uses to generate levels received from my level editor. I've also made a lot of improvements to the way the level editor itself works. The largest amounts of rewrites and code changes were in the environmental collision section of my code. Everything has been separated and compartmentalized so that I can easily modify specific types of collisions and have it applied to every portion of my game. Once again, I love object based programming.

The new stuff

One of the biggest environmental collision based updates I've put in, is the ability to have diagonal collision rectangles. Previously, I'd have to staircase multiple collision rectangles over and over to simulate a diagonal while now, I can just have the damn thing check against angles. This took a little bit of math wizardry but now that it's in, it's marvelous =) I've made the collision rectangles on the first platform layer visible so you can see what I'm talking about. Not only will this save an immense amount of time in level creation, it should mean fewer collision checks every update.

In addition to that, I've added the ability (not shown in vid) to change maps based on either the player moving to a specific location, or activating something. I've also put in a very rudimentary load screen. Eventually I'll make it so the transition is sexy, but for now it's just super basic and functional.

I've also added shadows to the aiming cursor to give the player a better idea of where the item they are throwing will go. The height that the item is thrown is also now player controlled dependent on how far the trigger is depressed.

The last thing demonstrated in this video is transparent background objects. I've managed to figure out a way to use my level editor with my environmental collision stuff to have sections of the level become transparent when the player is at specific locations. This'll be useful later on when I'm building maps.

Things I've been working on

I've still been hard at work building up the dialog system that I need for my game. I've got all the basics down, but what I really need to do is nail down how it's going to look, and in what way the player will be able to manipulate their choices. Hopefully I'll have a bit to show on this section soon. I'm also still working on the story. . . which is something I really need to get together soon as I think I'm nearing the completion of the engine. I've still got plenty of HUD work to do so while I have a lot of wiggle room, I'd like to have it nailed down before I actually NEED it to progress.

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.

Basic Physics

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 Formulas

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.

Conclusion

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 -_-;;

UPDATE

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.

What's New

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 -_-;;

Steam Effects

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.

JetPacks?

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.

EDIT Added stuffs

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.

What's New

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.

Time investment

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 -_-;;