Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.






Game in 7 Days, Day 3: Guns! Lots of guns!

Posted by ManTis, in Programming, 7days1game 15 December 2013 · 843 views

programming worms artillery weapons physics collision fun 7d1g
So, day three was supposed to be... let's see... Weapons, Level Objects, and Tools. Seriously? Heh, I really am one optimistic dude.

Anyways. I've started the day by deciding what weapons do I want. I came up with the following list, that I feel encompasses spirit of Worms the most:

-Rockets (they can be thrown at varying levels of strength, wind has influence on their flight, they explode on impact, moderate damage).
-Grenades (can be thrown, they bounce around, have 5 seconds fuse, they explode after it finishes burning, moderate damage)
-Shotgun (hitscan weapon, fires twice for small damage)
-Airstrike (couple bombs drops from above, each for small damage, together they do high amount of damage)

If I'd add character movement, following weapons/tools:
-Dynamite (you put it where you stand and have couple seconds to run away, high damage)
-Ninja rope (for quick moving around, probably most fun way to move around in worms)
-Shovel (to dig in any direction, can cause small damage in close combat)
-Concrete slab (to build bridges/protection)

And the standard tools
-Turn skip
-Surrender (for wussies!)

I have thrown together some temporary art and menu that pops out after you press RMB that gives you possibility to switch between the weapons:

Posted Image

That was all fine and dandy, but really didn't bring me any closer to what I dreaded the most - grenade physics. I already had a plan on how to implement them (thanks Sirisian). But, before that could be done, I needed couple things prepared: shot/throw strength display, something to aim, and wind with varying direction. The throw strength display was quite easy - just a GUI.Texture drawn in rectangle that was scaled based on how long spacebar button was pressed down. The aiming thingamajig was just a sprite put at a certain distance from player character, and the location was governed by vector which was in turn rotated around the Z axis by using up/down buttons. Wind was virtually the same code as power bar, only instead of starting from left and going from 0 to 1 in scale, it started in the middle and went from -1 through 0 in the middle to 1 on the right.

Last thing I've added to 'prettify' the level was background. Basically, it is the same exact shape as foreground, only when I assign colour to it, I don't add grass/dirt, and make it at 0.75 brightness. And here are the results of those changes:

Posted Image

You'll also notice that the selected weapon display isn't a button any more, but regular image. Should've thought of that earlier.

Anyways, it was time to return to physics. Rocket physics was already done, wind was affecting it flight path properly, but since all of this was written using really temporary code, I had to rewrite it and properly encapsulate, separating collision detection from object physics, and then extending the behaviour for rockets and grenades separately. Rockets behaviour was simple - the moment it detects collision - KABOOM! The grenade was bit more complicated. First, it needed fuse - that was quickly implemented by adding accumulative variable in Update() that summed all the time deltas since moment of throw. When the timer hits 5 seconds (later on this will be customisable before throw) - KABOOM! Ok, easy part out. Now the bouncing.

See, bouncing is really easy: you take direction your object is coming from, you take surface that it's hitting normal, and you reflect the movement vector over the normal. Result: bouncing stuff. That is, if you're dealing with actual surfaces. Points however are just that, points. they don't have any normal. So how do you calculate which way to bounce? The way I do it is by using image gradient. If you ever implemented Canny edge detection, this is what you used. Basically, you take an array (matrix) of points around your collision point, and sum values of the vectors towards empty pixels, then you normalise that sum and presto - you've got yourself a normal of that given area. Obviously there are some caveats, like if you hit singular pixel in the middle of nowhere, you'll be trying to normalise a (0,0) vector, and that's a really bad idea (dividing by 0 yo). But if you cover your ass for edge cases, this is nice and robust algorithm that you can use for lots of cool stuff. Including, as was in my case, per-pixel normal detection. Here's a small gif to show you how it works in my project:

Posted Image

And if you want to, you can click HERE to see .mov version of that video.

That's it for today. Didn't have time to add other stuff, as I was taking care of the kid, but I really had fun while coding this, and will be continuing on Day 4. Which may or may not be tomorrow, as my boss has called me couple minutes ago and told me that we have release due end of day on tuesday, and as a lead coder I'll have to make sure that everything works fine by then. Sigh. Looks like another all-nighter. Luckily I'm on holidays starting 20th, so I'll have some well deserved rest.

See you around guys!

Story so far:

Day 7
Day 6
Day 5
Day 4
Day 3
Day 2
Day 1




November 2014 »

S M T W T F S
      1
2345678
9101112131415
16171819202122
232425262728 29
30      
PARTNERS