There's a lot of new stuff brewing under the hood, a lot of which was hinted at in the last post. Let the excitement begin: We've added lots of new moves for the characters.
As seen in our video last time, the characters can currently punch, kick, jump, jump kick, jump punch, do sliding kicks, block, double jump, pick up people, throw people, and run around and interact with the level geometry which is made entirely of meshes whose vertices exist in 3D space. Stephen has kindly put in some late hours whipping up some nice "demo sprites" to get this stuff going, but we're going to transition fully into a system of customizable characters built out of different components.
This selection GUI is seen prototyped in last week's video as well. The moves each have their own subtleties (well, no kidding), which are being worked out as we play-test, but its all in there and working. Implementing the moves and having the animations run and so forth is technically straightforward, but the real meat will be making this stuff different and interesting for the actual gameplay, and balancing things out so everything works together nicely for a reasonably strategic game that doesn't degrade into just button mashing; this will be the next goal, although we've got some ideas to make this fun and interesting, which we'll preview in future updates when we work the system out satisfactorily.
As a little side note, it was interesting getting the successive punch working; if the punch button is pressed a single time, the bruiser will punch once, but subsequent rapid presses of the punch button put the bruiser into a continuous punch cycle that will end when the rapid button presses stop. We can't really queue each "DoPunch" command as it comes in, since a player can very easily press the button more quickly than the animation executes, but we have to detect and do something with the DoPunch command that comes in while another punch is currently executing; the obvious solution is to just always queue up to one additional punch than the one that is executing and throw away any additional commands that come in. As long as there is at least one additional punch queued, the character will punch in a fluid, continuous animation.
Single punch animation
Continuous punch animation
Contrast this with the kick and other moves: if you press kick twice in rapid succession, the bruiser will only kick once; kick attempts made while currently kicking are ignored and not queued, typical of most beat ‘em up style games.
Another thing that made the punch interesting is that we actually have two animations in place for it: a single punch will always animation the four frame "initial" punch animation. If the button is hit successively, the character will start on the initial punch animation and transition into the second starting on frame 1. The second set will be looped continuously for the duration of the continuous punch cycle.
Next up, the collision system is in place. Bruisers collide with each other and walk on meshes. The bruiser-bruiser collision is performed mostly in two dimensions with 2D bounding boxes (yep; these are flat sprites, pretty much some Paper Mario style magic going on in there). If a bounding-box collision is detected between the two sprites, they check the difference in depth position and report a collision if it all falls within some threshold. No problem. A fun little note here is what happens after the collision; when the collision has occurred, we actually calculate a "collision line" which is just a directional vector + magnitude to represent the force of the collision.
The stage geometry is now in-place. Gravity works. Bruisers can hop from mesh to mesh, fall off meshes and so forth. This would have been a million times easier to do if it was just tile based with discrete heights or something, but the current system is a lot more flexible since we've chosen to go with hand-paint (uh, pixeled?) backgrounds. Not really a lot more to say than that about meshes. The math is simplified greatly when the mesh is axis-aligned, so I have special detection cases in place for meshes that happen to be so. Going forward, it makes things easier if meshes are generally axis-aligned, but slopes and hills and complex shapes will definitely make their way in as we craft out the levels. Furthermore, meshes have characteristics - they slow people down, have "liquid" you sink into (see last week's vid!), spin off animations when sprites land on them or jump from them, and so forth.
Meshes or something
Almost done- In addition to standard game entities (game objects like bruisers, weapons, random stuff strewn about in levels and such), I've added some static "effects". I don't know what to call anything since I'm just making stuff up as we go along with this, but they're basically animations that pop up in some place, animate one or X times (or loop indefinitely), and then disappear. There are four types of these right now; they're either static (appear in one place, animate, then die), linked to an entity (their location is an offset from an entity for the duration of their existence), panning (most useful for animating backgrounds), or free (they move about according to an effect AI).
Splashes and name boxes are good examples of these
Finally, we built a simple sound engine using XAudio2. It could use some work; but for now, we can spin off music and sound effects whenever we want, as well as pause and stop them. Pretty straightforward. Woohah for progress.
Next on the list:
- Reworking the component sprite system for more flexibility and some added graphical effects
- world camera for scrolling about following the main player’s character
- working out some kinks in the input system
Take care, paisanos.
-Matt
