Jump to content

  • Log In with Google      Sign In   
  • Create Account

Crawling with ideas

Game in 7 Days, Day 7: DONE!...ish

Posted by , in Programming, 7days1game 26 January 2014 - - - - - - · 2,209 views
7days1game, fun, worms and 2 more...
Game in 7 Days, Day 7: DONE!...ish And it's over! Finally sat down to finish my game. Or, at least, do as much as I can. But let's not get ahead of ourselves. What has been done then?

First, the game. I've compiled it in Win/OS X/Linux versions, because the web version doesn't work yet and I didn't have time left in the 7th day to try and figure out why ;). Anyways, here are the builds.


Controls are: mouse, arrow keys, shift for jumping, space for shooting, tab for switching characters/girder mode, and numbers 1-5 for fuse length on grenades and dynamite. Also, direction of meteor storm depends on which direction the currently selected worm is facing.

So, what happened since day 6? First, I've added actual summary screen (though it's very simple, due to time constraints). Which means you can have matches till 1, 2 or 3 wins. The matches carry out on 3 different types of terrain: Stone field, sandy desert, and icy snow. The type is picked at random on level generation. My gf has found time to also create some properly magical weapon art:

-Fireball (bazooka)
-Exploding skull (grenade)
-Magic punch (shotgun)
-Deadly mixture (dynamite)
-Meteor storm (air strike)
-Force field (blowtorch)
-Summon wall (girder)
-Round skip

Posted Image

You'll also notice that beardlings aren't oozes from space any more. They are in fact wizards/gnomes. Actually, what I wanted the most from this little exercise in 7 days, was to learn how to use Unity's new sprite system. Since I was mostly bruteforcing it so far for everything else, this was the perfect opportunity to learn the new skills. My girl has drawn a little 'exploded' bearding like this:

Posted Image

And I have combined it into one game object, which I then animated using Unity's inbuilt animator/animation system. Sure, I've done only one animation, but I have done SOMETHING! ;). As for everything else, audio was added (just sfx), and some explosion animation. Suddenly the game feels much more alive, when the little buggers are shouting out their spells and dying in explosions and under water.

What did I not manage to do in time?

-Fix the web build bug (I started trying to compile to web last thing in the evening of seventh day. Bad idea apparently)
-Prettify all the GUI.
-Improve physics (seriously, this one's bad, I had to move on, and the physics is of such importance in a game like this)
-Work out death sequence so that little beardlings die like worms did, instead of just disappearing
-Add music
-Replaying match on same level
-Pretty much everything from configuration menu
-Hall of fame
-Proper list of teams to choose from (don't create lots of teams ;) )
-How some weapons work (blowtorch being the biggest offender)
-Special weapons would be nice
-Voices in one pitch. I've never done any voice acting, and so the voices of the beardlings vary in pitch and speed a lot - I've tried to mitigate it, but there is a lot of noticeable differences ( compare "fireball" to "exploding skull" for example)
-fix some random bugs (heh)

Huh, seems like quite a lot of things. But then again, the scope of this project was insane. I have pretty much set out to create a full blown Worms clone from grounds up in couple days. This was never going to happen, especially since I've spent plenty of the days away from the computer and with my kid and girl. Still, the project is done and the game is playable, so I am really really happy. I'm also really happy that my girlfriend has helped me out, and we're looking forward to our next project together. She says that she had a great time learning the tools and working on the art, which does bode well. Hopefully one day we'll release some awesome game together.

Posted Image

In the mean time, I already have idea for the next project. Remember how I said that scope of this project was insane? Well, next one is something that I always wanted to do but never got round to doing: Whole world, in 7 days. To quote mikeman: the last guy that did it got pretty famous ;). See you then!

Story so far:

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

Game in 7 Days, Day 4: Tracking back

Posted by , in Programming, 7days1game 26 December 2013 - - - - - - · 945 views
7days1game, programming, unity and 5 more...
Hey there people!

As usual, had to wait some time for next day of development. Kid's got runny nose, he's coughing, and his teeth are growing. Talk about bad combo for holidays. And I'm down with some flu as well. At least this meant that I don't have to be socially active and finally I get some time in front of the computer Posted Image (whenever the kid's asleep).

So, where were we? Looking at my chart it seems like I should be doing Day 4: Gameplay. But I didn't feel like it. I decided that I don't want stationary targets shooting with two types of weapon. So I tracked back a little. Firstly, I've added walking.

Walking while easy in polygon or tile world, is massive pain in the backside in the per-pixel collision world. Let's take a look at the algorithm:

1) First, check ground-level pixel in the direction you're moving. If it's empty, check one above it and so on till you've checked enough pixels for the character to pass through. If you managed to find enough space, allow movement.

2) Now, if one of those pixels was non-empty (that is, part of landscape), check how high above the ground is it. If it's less than allowedSlopeDifference variable, zero the free pixel counter and start counting from the pixel above it, returning to 1)

3) If you detect that there is not enough free space to move, well then, stop movement.

4) Check pixels underneath. If there's a fall, and that fall is less then maxFallDistance, step down. If it's more than that, 'physics' kicks in and free fall starts.

Well, that's it. Doesn't sound that complex, and really isn't (and should be replaced with something better later on), but it allows me for implementing movement based gameplay.

That is, WEAPONS!

Well, ok, not all of them needed movement to be used, but only when movement is used do they truly show their potential. Without further ado:

Posted Image

Shotgun, lightly damaging weapon that you can fire twice. Useful to put two opponents out of their misery or cut through small wall. Implementation was simple enough - hitscan that causes explosion the moment it hits something. A simple line algorithm that iterates through level and looks at each pixel on its way, testing for collision.

Posted Image

Dynamite. Huge power, huge radius of explosion. Implementation was modified grenade script. Also has timed fuse (set to 5 seconds currently, will be changeable in game). Doesn't bounce though, and the throw strength is only at couple percent of the normal strength, so while it can be thrown off ledge, it's never going to fly far horizontally.

Posted Image

Airstrike. 7 small projectiles that are dropped from the air onto the enemies. They can arrive from left or right, creating different attack patterns. Implementation wise, this is still only prototype version. I take (+/-0.5, 1, 0) vector from target position, collide it with drop line, and then create couple bombs there, centred around the origin point, then drop them in the opposite direction. What I could however do is:

1) as Zao proposed, do a binary approximation, launch couple virtual (properly physics-based) shots, and align them left/right, till I'm within some margin of error, and then fire off real shot
2) calculate the time required for the shot to fall down from the sky to the target level, and then from that calculate the side movement it needs to do, and calculate the position properly.

Oh, and I probably should have the bombs actually face the direction they're falling to Posted Image

That's it for weapons for now (special weapons will be added with when/if the crate drops will be added, some more basic weapons could also be created - fire punch, suicide attack, mine, etc)

I've also added some navigation tools:


Shovel. To get to those unreachable places. Currently the problem is that, unlike Worms, it uses your movement speed to progress, so when you accidentally point your shovel down, you're going to do a free fall while digging your own route to hell. This definitely needs fixing.


Concrete slab. It can be used defensively - to protect your character from enemy shots, or to run away. It also can be used offensively, to create route to enemy or to guide weapons towards him. From coding perspective, this was a nightmare. Original Worms had girder rotating not only at 90 degrees, but at 45 deg increments. So, how would I solve it? First, find axis-aligned bounding box that contains whole concrete slab (or girder, as it was in the original), whatever its orientation is. Then, for each pixel on the map that overlaps with AABB, check if it's within tightly-packed oriented bounding box. If there is any, don't allow player to place the girder. If the map allows, place the block there by looking up each pixel from the girder based on coordinate and rotation. This is costly. Like, really costly. My solution for this is pre-drawing concrete slab in 4 positions (vertical, horizontal, and angled up-left to bottom-right and down-left to top-right), and use them as look up textures, to alleviate the calculations done on per-pixel basis. But for now, I've just used the horizontal and vertical positions, which don't need no calculations (also, their AABB is equal to their OBB, accelerating the collision checking process as well).

That's it for today. Haven't added Skip Turn and Concede, as they actually need gameplay implemented to be used, and, most importantly, haven't implemented Ninja Rope. This one will be a biggie, and I hope to implement it before the 7 days is up, but I don't want to do it before I'm sure I have everything else done. Going back to these steps cost me one day, which means that probably Audio and GFX day will have to be merged.

And as usual, all art is temporary, but concrete slab is really temporary, as it was done at 1am (when my usual sleep time now with kid around is around 9pm), and I wanted to just get it over with as fast as possible.

I hope I'll manage to squeeze in Day 5 before the weekend, but we'll see. See you then!

Story so far:

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

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

Posted by , in Programming, 7days1game 15 December 2013 - - - - - - · 1,129 views
programming, worms, artillery and 5 more...
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

Game in 7 Days, Day 2: Boom boom boom boom!

Posted by , in Programming, 7days1game 14 December 2013 - - - - - - · 1,138 views
artillery, programming, ludumdare and 2 more...
Day two is done!

Since I had a long day at work yesterday, the coding had to be moved to today. At first, my goal was to make full collision, physics and movement for the character. That proved bit too much to be done in one day. As always when faced by huge wall, I got bummed out and played around with graphics and effects Posted Image

Posted Image

Basically, this is a single octave Perlin noise generation. I've also added dirt tiles for underhangs (I think it looks really sweet now, even if graphics is temporary and put together in couple minutes) and slime/squid alien thingie as a player character. Because, as Shakespeare said, everybody loves slime/squid alien thingies Posted Image.

I've later added bit more complex and customisable level generation. Apart from possibility to go multiple octaves, for more jagged look, I've also added option for controlling amount of terrain appearing, changing between more vertical and more horizontal levels, and some other tiny knobs that you can twist for cool effects:

Posted Image

Then I returned to working on physics. Since there was no implementation of per-pixel collision for Unity anywhere online, I had to put together one on my own.

I've solved this by dividing problem into wide and narrow phases, for optimisation purpose. First, broad phase. I take AABB (axis aligned bounding box) of the object I'm moving in the Origin position, AABB of place where it will be, int the Target position, and wrap both of them in one AABB, like this:

Posted Image

Then I take this big boundaries AABB and iterate over every pixel within level geometry that is contained within this box, and check if it's solid (nonzero alpha). If so, I procede to narrow phase: for each solid pixel that could be encountered, I fire a ray in the direction that is opposite to movement direction, which means that only the pixels who are on direct route will fire a ray that will collide with origin box. If such points in the map are found that the rays for them hit the origin AABB, the one closest to the origin AABB is chosen as collision point, and the function returns.

That sounds complicated but is necessary for pixel perfect collision, and that is what I need if I'm going to make Artillery game. Again, like I said, since this took me quite a while and I needed to take care of baby, and now I need to sleep, for now the game will be oldschool Artillery, with no movement for the squids. Once I had the collision code I could quickly hack together a physics code and add some explosives to be thrown. No special effects yet, just canonball that has gravity, and when it detects collision with ground, explodes destroying everything around it. Here's the result:


You can see holes in the ground to the right of our brave alien hero. I understand that static images can't really show how awesome this is, so here's a tiny .MOV file (click) that shows level destruction. Now on to day 3!

Story so far:

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

October 2016 »

2324252627 28 29