My lord that was tedious

Maybe it’s a part of game development in general, or maybe it’s just something I do, but I can’t seem to stop myself chasing off down rabbit holes in a project like this. Like today, I got the new beam weapon hurting enemies and opening doors, then decided that it looked really crappy when the character runs, because the shot is always placed in the same position, not bobbing up and down like the character’s gun does when he runs. So then I spent the next many hours counting pixels and hard-coding manual offsets. I just couldn’t help myself — it makes an enormous difference in how the weapon feels. See for yourself: in the video below I have hard-coded offsets for the running animation, but not walking or jogging. Notice how it starts looking a lot better when the character hits full running speed.

The upside of this work is that (in my opinion) it’s the difference between a decent-looking game and a really hokey looking one, but the downside is that it’s tedious manual labor. It makes me want an intern.

Nonetheless, I finally got things looking pretty decent with standing, walking, jogging, and running animations.

More conversions to do tomorrow, but I got the really frustrating ones out of the way.

I’m not totally clear about how the damage from the gun works yet, but my current implementation is basically a damage per second model. If you shoot something with the beam continuously for one second, you do the same amount of damage you would have with 10 normal shots. Seems pretty generous, but it will need some tweaking as I create more enemies to kill with it.

4 thoughts on “My lord that was tedious

  1. It looks pretty nice. Just one question. Do you consider your character and weapon as a single bitmap? Or are they two bitmaps related through a hierarchy (e.g. the weapon being a child of the character and thus moving relatively to it)? I guess that in the second option it would be easier to implement the accurate shooting.

  2. Nice work. If you’d like more tedium, try manually rasterizing a font in The GIMP. Or multiple fonts. I’ve done three so far. I’m surprised to still have a semblance of sanity to be honest (and many of the character’s widths still need some alpha shaved off; nooo). Programming any game seriously IS a rabbit hole waiting to happen.

    When things work, however, it feels so good that it’s hard to stop working on the game. A good addiction, maybe.

    Perhaps you could reduce the number of animation textures to 16 for each type to reduce the number of manual offsets needed. A 16-frame animation cycle is smooth and still impressive, especially with multiple variations (walk, run, duck, slide, etc.). You could maybe keep the gun’s position static relative to each player animation type (one hard-coded offset pair per type) but add calculated offsets for each frame: OffsetX = Cos(Timer) / 4; OffsetY = Cos(Timer) / 1. You’d have to sync the weapon bob to the 16-frame animation cycle (tweak the numbers) but it would look cool and require little manual data entry.

    One last suggestion (ignore if you like) is to make extreme enemy deaths (tier 2 weapons) result in gibs flying around and corpses left behind. An excuse for some easy graphics work that could have a big impact on the perceived strength of weapon upgrades or alternates. Super Metroid with “realistic damage” but the same basic input/output mechanics.

    • If I could do it over again, I would definitely do fewer frames of animation. In fact, most of the animations have 16 frames and look fine — it’s just the running, jogging, and walking while aiming straight forward animations that have a ton of frames. Oh well.

      I’m totally considering making some new death animations, but trying to resist while I work on more core feature 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *