Entry 21 or rotation and animation
Feb 26, 2011
Well, here’s an update.
Angular movementum
Let’s fix the movement with Xbox controller controls. First of all, the movement ”on screen” should match the movement of the thumbstick. So we get the angle between the thumbstick’s X and Y components of the thumbstick and convert it from world (blue) to screen (orange) coordinates (a shift of 45deg):
Now, concerning the actual character control. The Xbox controller thumbstick report a [-1..1] range in both X and Y axis. This means the thumbstick can be fully shifted, at rest in the middle, or in any position in between. So what I want is: little shift = slow walk; big shift = fast walk. This, of course, is only relevant to the controller and not on the keyboard, where the move speed will always be the maximum.
Three dee
Let’s make some awesome 3D! Well, not really 3D. Here is a quickly modeled character:
To make the fake 3D, what I do is render the same character from 32 different angles:
(You are free to use the above sprite/graphic for any purposes)
This is done in Maya with a camera attached to a circular path. All 32 pictures are individually rendered and then stitched together with an external app.
From practice, I found that 32 is the smallest viable number to make the sprite seem like the character is facing the actual direction it is told to face. Anything less made it look displaced. I am not too worried about texture memory, even if the png is over 1600px wide…
Anyway, some coding and math later, here is units facing different directions:
Now the units need to know how to rotate properly. So far I only used a right/left flag for direction. Now we have 32 different angles.
Now, I don’t want units to turn/rotate instantly. That both looks bad (very abrupt change) and feels wrong (you cannot rotate instantly in real life unless you are a ninja). Additionally, as Xbox thumbstick is released the angle jumps abruptly as the vector magnitude reaches 0. Since the vector angle (and not magnitude) is accounted for during the rotation direction calculation, the character always ends up turning a little bit just as the thumbstick is released. And that is really annoying.
So similar to before: slow movement means slow turning (rotation) and fast movement means fast rotation. I also don’t want the units to move whilst standing still, so the 0 value should also take care of that.
Now, the walking/turning principle I want is a modified version of dual joystick shooter. The player walks with the left thumbstick – magnitude and angle determine walk speed and direction. Now, if the right thumbstick is released (at rest), the character just turns towards the movement direction. However, when the player shifts the right thumbstick the character rotates in that direction, allowing the character to shoot and walk in different directions.
Animate me
Let’s make 2 more frames for animation — just a quick leg/arm postion/rotation change and two more sprite rows:
The animation is then just looping through 1st,2nd,1st, and 3rd frames. And this works nicely (not that I can shot in a screenshot):
The problem is not so much getting the animation match the walking speed or get the right frames at the right time. The issue is really the arbitrary turning, when the visual animation does not match the actual movement direction. This can be fixed by either having a gazillion of frames for each imaginable animation, or do it Alien Shooter style and rotate legs separately from the torso. The thing is the character could walk south and shoot north bot arms extended. And that is a bit ridiculous. As far as I’m concerned this is an indie project without resources (time or money) to do complex animation, and the amount I’ve done (should I ever finish the 3D model) is already more than I planned to do.
The final touch of “realism” is that the character attempting to look any other way will walk slower than looking the direction he’s walking towards. So basically, a penalty for looking/aiming/shooting away.
Yay, update!
Here is my terrible model in Maya:
I may need some Maya tutorials, especially character and rigging/animation ones. Don’t want to design something I will need to re-make later on (you know, like everything else so far).
I wrote today’s post in a little over 3 days. There wasn’t any proper info to post every day, since the above took a lot of fiddling.
(I waive the copyright of the above graphic under CC0 license and you may use it for whatever legally allowed purposes you wish (use/modify/distribute), but not in a way that suggests I endorse your work. Link-back appreciated.)
—-
Entry 22 or proper character model
Mar 2, 2011
I renamed my blog posts (note: this was before I transitioned into WordPress blog) into entries and added a real-world day counter… Holy cow; Day 47! That’s like… 1.28 months. 22 real entries is like 0.46 entries a day. That’s like 0.69 months I’ve done nothing. Hehe 69…
Vitruvian Model
First order of business, get rid of fugly square model character, and make a proper-er one:
Which would look like this in the game:
I must say, while it looks O.K. shrunk down to 104x52px; the actual close-up model is an awful mess that makes 3D modelers scrape their eyes out.
But don’t despair, for the magic of a few accessories and custom materials will save the day:
Which produces these sprites:
Which makes it look quite decent in-game:
Let’s go all out and add a few more items:
Almost great, discounting the totally cowboy look. Now I just need to do proper animation for this and hopefully set up my Maya scene to be easily editable without needing to change much for rendering.
—-
Entry 23 or walking… again
Mar 3, 2011
At what point in time did my game making shift from “coding” to “3D modeling”. Although I don’t consider myself bad at it, I am definitely not an artist, so my models end up lacking the crucial appeal factor. But, whatever, I made and I should be proud.
Rigorous
First order of business, rigging the main character. Technically, I have no idea if that’s what “rigging” means or not, but I’m adding rough joints/bones, attaching inverse kinematic controllers, and then moving them around and playing with settings. So here’s the rigged character:
I don’t really want to animate arms right now and I want to get “shooting” out of the way as soon as possible, so here’s a little crossbow I made (ignore ugly arm bend):
It looks half decent when zoomed out:
And in-game:
There are a couple of reason I did a crossbow. Firstly, it does not need (much) animation for firing. Swords, bows, and other fantasy theme stuff need a lot of animation — swing, aim, etc. Here, the character can just carry the crossbow aiming forward. Same principle applies to guns, but I did not want to make the game contemporary/futuristic; at least not with guns (at least yet, may be… I haven’t thought this through much).
Walk… yet again
Now that my Maya scene is properly set, I can change the kinematic controllers to easily setup the character’s appendices the way I want; for example, step:
Which also looks fine in-game:
Now, going all out (i.e. shitloads of Maya fiddling hours later), I got a full scene with basic 4-step (high point; contact; high point; contact) animation:
Which looks a bit “stretched” in-game, as the character throws his legs forward a lot. Reminds me of Jagged Alliance 2; I think that’s a good sign. May be.
Today, tomorrow, the future
Today has been mostly about animation. Tomorrow I may get some coding done — to get even. And who knows what the future holds.
—-
Entry 24 or pretty gifs
Mar 7, 2011
Ungh… this is going slow. I can’t make myself work. It just stopped being fun a while back and became tedious. The parts I need to do now are mundane coding parts. At least character animation is one thing that’s keeping me moderately focused.
So, anyway. To finish up the walking animation, I made a total of 6 frames and made the character “throw his legs around” a little less. So, here’s the full walking animation:
The beauty of this is that everything is key-frames and dynamically adjusted. So while it took a week to make this work, it took 15 min to move and shrink the crossbow:
Here’s some more accessories/details on the model:
So here are two in-game “stances” — “hold” and “aim”:
By default, the character carries the crossbow. Controller’s right shoulder trigger “shoots” and the characters goes into “aim” mode for a short period. I haven’t made an actual projectile though.
—-
Entry 25 or time for change
Mar 12, 2011
Let’s get realistic here. I will never finish an RPG. Contrary to most game marketing department’s selling points, RPG is not about combat system, tons of classes, video card shattering spells, and all that. It’s about narrative — you cannot have an RPG without a story. No matter how amazing the rest of your game is, if it has no story, it’s a failure. And even crappy visuals and clumsy combat can be easily saved by intriguing setting, excellent writing, and deep characters.
So what’s stopping me from doing exactly that? Well, time mostly. Setting, characters, dialogue, plot/story, quests, backstory all take time. They also require a thorough thought and beforehand planning about them before jumping into implementation. That’s not an ideal ground for agile development. I could finish all gameplay elements and still have nothing to show for a game, because there is no story. (Not to say other genres don’t need story.)
Now that I’m done convincing myself to do something “else”, let’s see what this entails. I will have to get rid of several irrelevant features. But at the same time, I have to salvage as much code and features as possible. I am not making the game anew. Thankfully, I hadn’t gone too far into RPG territory yet.
So the other genre alternative that I wanted to do and for which my engine is perfect, is — obviously — an RTS. I have a 2D map, isometric view, units, objects, path-finding, terrain, etc.
Trashcan
So what I’m trashing is:
* Walls — no point in keeping thin mid-tile walls that only hinder path-finding and collision detection.
* Inventory — I hadn’t made much, except a few graphics and some unit storage
object hierarchy
* RPG variables — level, experience, health calculations, and whatever misc. variables I had for future implementation
* Character model — :(
* Some of art
To be honest, not a very big loss.
Placeholder “art”
Enough screwing with Maya and Photoshop. I’ll do graphics when I really need them. I’ve now got enough of an idea on how to do modeling and animation. I now also realize just ”how” slow it is. So here’s an idea of what placeholders are:
A quick 5 minute mock-up produces enough material to spend a couple hours implementing various kinds of buildings and states/animations. That’s the ratio a programmer should have for his work. No graphics unless there’s nothing else to do (or just tired of coding).
So this is in-game implementation:
It’s now eye-bleedingly dull to look at (not that it was Sistine Chapel before), but it focuses my attention on things that matter. Getting a playable alpha, for examples.
I kept the whole “health-block” concept. The buildings themselves are just a hierarchical extension of object class, so that did not take much time.
Story
I have been very “focused on” story and that the game needs one. So let me borrow the best principles of RPGs and apply them to an RTS. After all, even the early ”Dune” and ”Command & Conquer” games had a decent story. I have a few ideas and from the screenshot and previous art one could possibly gather some of it.
—-
Entry 26 or selections, controls, and turrets
Mar 15, 2011
So today’s a basic RTS element day.
Selection
First, let’s make stuff selectable. So here are various buildings (small/large) and a unit (circle) selected:
I still remember Dune for being the most annoying RTS allowing you to select only one unit at a time. So here’s multiple unit selection (currently via Ctrl click):
Turrets
First of all, turrets (yes, that was a “turret”) need to rotate and face the direction they are shooting at. This basically means at every turn each turret chooses the closest target and then fires at them.
The spritesheet for the turret is below:
To improve this, turrets should have a “shoot” animation. Just a little flash:
Of course, 8 direction is not the limit and all depends on how many angles I do in Maya or wherever and much GPU memory I want to use. And most importantly, what looks good.
Controls
I will stick with Starcraft/Warcraft type of controls (as opposed to C&C) — left click: select, right click: issue command.
So here’s a basic move command and the accompanying target indicator:
And same for turret attacking:
Now, the viewport will be scrollable/pannable with the arrow keys, because the right mouse button is now busy issuing commands.
—-
Entry 27 or paths and lights
Mar 16, 2011
I’m really running out of intro lines for these entries.
Optimal path-following
My A* is fast. I also made a queue and limited the number of requests per frame. With smooth tiles/borders and unit animation, I sometimes forget this is all isometric. Now, the only remaining issue is “cutting” corners.
A typical path would look like this (blue line):
But what I actually want is this (purple line):
I don’t want the A* itself to do this, as this would involve checking every visible tile from each path point (as opposed to up to 8 surrounding tiles checked now). Instead, the unit itself should decide when to pathfind and when to move to the next cell.
So the basic algorithm of a unit that wants to move somewhere is this:
* If the path to the target if no yet decided, then find the A* path to the target; remember that the current location is the first tile in the path.
* If not currently moving, choose the next tile to move to. This is essentially the next tile in the path.
** If the tile is occupied, then try looking for a new path instead; and try from there
* If the next tile is chosen, try to “cut corner”. This means — see if the tile after the next can be chosen instead. Then try the one after that, and so on, until the tile is out of line of sight.
So, for example:
At each step the unit tries to choose a one tile further than currently chosen. The next location gets “furthered” 4 times. Then on the final iteration, the tile is behind a corner and no longer visible. This means the unit will ”have to” go around it — that is, follow the path “properly”.
Don’t block me, bro
The obvious (sort of) problem is what happens when other units/buildings/objects suddenly block the path? If the unit is not “skipping tiles” (cutting corners), then it can just find a new path; and the coding to see if there’s anything in the next tile is easy. This gets tricky for skipped tiles. Basically, I need to keep a list of tiles the unit is “skipping” through. So, if at any point, should the unit encounter something in it’s path, it will find a new path and follow that instead.
Let there be (more) light
As one could figure, one of the (crappy) buildings is a lamp post. It needs to produce light, like so:
Admittedly, this doesn’t really differ much from the fireplace area light. But this is done slightly differently. The algorithm is more optimal, the light depends on parameters, it also depends on building type and state.
Now let’s make each lightpost have a top rotary part (like turrets):
There nothing much to look at, but I am currently much less concerned with graphics and much more with the gameplay. As I’ve said before.
Now to “light up” the tile that the lightpost is pointing to. This can be assigned via a right click — issue command:
(I really need to fix the shaders though)
This is actually an essential feature for what I am “planning”. Basically the attacks on the “base” will require that the illumination is above a certain level. Otherwise it will be impossible to “see” and the turrets will keep missing their targets.
—-
Entry 28 or enough with the borders
Mar 18, 2011
The whole project is slightly messy, so I have to fix all the small problems and deficiencies, so that it not just works, but works well. That should get me more motivated to work with it, rather than being constantly reminded of small bugs.
Fin the borders
My borders are currently a mess, because playing with variations has left the Photoshop file a layered nightmare. So I am fixing that. First of all, a saner approach to border variations (i.e. same type of border, slightly different image) is only applying them to the straight bits. All the curves and weird shapes don’t need variations, they are “interesting” as they are. Besides, they rarely appear in sequence.
So here are the base border shapes:
Now, adding a little variation:
The tiles now have 3 different variations. (In principle, I could make sure the same variation never occurs twice in a row. So 1-2 or 1-3 but not 1-1.)
Now, let’s copy the layer and make it a dirt “undercoat”:
To add a little depth, shift it:
The do a little smudging of the grass layer:
Here’s a collage of the transformation. While each step may be small, the idea is rather powerful if I may say so myself.
Here is water fixed:
And 3 variations of water:
Dirt coast fixed:
And, of course, mixing (with minor bugs):
And deep water:
This is all still done with the same border sprites, which are now nicely done in Photoshop to be easily adjusted/changed:
For now, this is as far as I’m willing to go with border logic before more important things are done. At least, borders are fixed now and I can work ”with” them not around them.
—-
Entry 29 and more tweaks
Mar 19, 2011
Generic intro statement here.
De-collider
When units move, a typical scenario is this:
As my path-finding is per tile and not instant, units often get “bumped” by other units or skew from their path. And most importantly, since the player can send them to any coordinate, they rarely start off from the center of the tile. Thus, inevitably, units collide with other objects, even if following a valid path.
Now, it is not hard to detect/remove the collisions, since I am using the same base class for everything and all the coordinates are compatible/easily manipulated.
So, here’s a close-up of the issue:
(A) is unit on its way somewhere. (B) is where it collides with some object on it direct path. This means the unit has made a “step” in the current frame, but that move the unit “inside” another object. We do not want this, so we push the unit away. Typically, one would just not let the unit move, and “push it back” where it came from (C1). But that doesn’t really solve anything, as the unit will just try to move there again next frame. So, instead, we push the unit out of the object at a normal vector between their centers (C2).
This is particularly important for rectangular buildings (as oppose to circular).
The only problem is that units moving straight though the object would get trapped in an infinite loop. But that should never happen. In fact, with proper path-finding and unit movement logic even collisions should rarely occur with static objects. And it’s highly unlikely moving objects will go straight at each other, especially since A* would determine the path is blocked. So the units may brush against each other and continue their own paths.
Turret
I made a rudimentary Maya model for the turret to replace the placeholders:
Which makes this in-game:
The graphic is made of a single sprite of the static bottom part and 64 sprites for the top rotary part — 32 for idle and 32 for firing animation.
Now that I’ve actually learned something in Maya from character modeling, this one did not take much time at all. Even with a few primitives, the turret looks “decent”. Of course, a little more detail, some textures, a degree in design and it will look lovely.
—-
Entry 30 with zombies
Mar 20, 2011
What a pretty number today — day 64.
What’s green and hungry?
I made a little zombie sprite in Maya:
(looks like a watermelon)
As per before, 32 rotations (sprites):
Here are they in-game:
This is not the final version, unless I run out of time or patience. But it’s better than a placeholder.
Now I’m working on zombie AI. Then turrets killing them with some gore and decals. Everything a healthy game needs.
—-
« Previous entries (11-20) — Next entries (31-40) »