Jump to content

  • Log In with Google      Sign In   
  • Create Account

Crawling with ideas


Posted by , in cardboard, silly, Uncategorized, Electronics, Programming, swift, arduino 28 November 2014 - - - - - - · 583 views
electronics, programming, swift and 3 more...
Welcome back!

Last time I have created a software for communicating with my Arduino using HC-05 bluetooth module. Now that I have had that prepared, it was time to do some serious work. It was time to create the robotic arm itself!

Now, I have never done any robots before, so I didn't knew where to start. I've looked at some instructables and saw simple, 3D printed robotic arms. They seemed sensible, but I haven't used CAD software in ages, and I didn't have access to 3D printer anyways, as I currently am staying couple hundred kilometers away from my hackerspace (and haven't yet decided to buy my own 3D printer). I could have done some blind design and just print it out when I would be in Warsaw, but I wanted the robot NOW. So, after looking at the room for scavengable materials, I have decided to take some old box that was lying under table and make robot out of cardboard Posted Image

First I needed a base on which the whole arm would be rotating. I've cut out a small square of cardboard, and in it made a small hole that would hold the base servo:

Posted Image

Now that the first step has been made, it was easier to follow it up. I took a second servo - the one that would be used for angling the main arm, wrapped it in cardboard, and prepared it to put on top of the previous servo via liberal application of scotch tape Posted Image

Posted Image

I have repeated the process twice for main and secondary arm, and it was ready, the CARDBOARD BOT OF DOOM appeared before me:

Posted Image

Now all that was left was testing it. I've tried using it, but the SG92R servos have insane torque for something so small, and the whole robot was flailing around whenever I tried rotating the arm. Again I scanned my surroundings for something to help me, and I found stack of CD-Rs and some small plastic box. I've applied scotch tape yet again, and here is the result:

Next I'll be working in some CAD, probably solvespace or openscad, and try to create something looking bit more professional, hopefully also bit more durable.

Till then, bye!


Posted by , in Programming, gamification, iphone 09 February 2014 - - - - - - · 1,014 views
iphone, iOS, programming, fun and 2 more...
Quick break from World making. Normal service will resume shortly.

So, as I looked at my life and noticed that I'm not getting ridiculously rich fast enough, I decided that I need to do something with it. I am going to gym, I study new things a lot (lately bioinformatics, astronomy, and cryptography, MOOCs are fun!), I help my friend with his project. But I wanted to do something to keep me motivated.

Enter gamification.

If you're not sure what that is, quick disclaimer, in my own words: It's using game stuff to make otherwise boring tasks fun. As you clean your dishes, you get experience points, when you get enough xp you level up! You may hate doing dishes, but being Level 41 Dirt Obliterator feels just cool, so you'll want to work just a bit more.

I decided to write a generic iOS/Android app that I could run on my phone, and level up in it. I took level up mechanics from Dungeons and Dragons, as they worked to get them solid way better than I ever could. This started as a really simple application just for myself with one screen, done in 30 minutes, but ended up as a bigger project. One that I'll upload to AppStore/Android Market even (for free), as soon as I'll make it pretty and robust enough (my girl is helping with art still, woo). So, without further ado, the mechanics:

1. Encounters

Each monster/group of monsters of strength equal roughly to yours that you meet while traveling is an encounter worth
300 * level
experience points. I chose to assume each week counts as an encounter of your current level. At first you set your goals, say you want:
  • 3 gym sessions
  • 1 studying session
  • 1 working on project session
each week. You add those, and then the experience points is divided equally between each session. If you get all or more of those, you get points assigned, for each one in each session type you miss, you get penalised. Each session type may have following kind:
  • Sport
  • Education
  • Work/projects
  • Food
  • Art
  • Entertainment
  • Social
2. Levels

Levels in D&D (and thus in my app) are calculated with the following formula:
XPrequired = 1000 * (level + Combinatorial(level, 2));
So the required XP for levels are 0 for level 1, 1000 for level 2, 3000 for level 3, 6000 for level 4, etc. You look at your current XP and let the math figure out which level are you.

And the overview screen looks something like this:

Posted Image
It's not very pretty, but I need it done for tomorrow, when I'm at gym, so that I can start levelling up Posted Image. According to my guesstimate (too lazy to calculate), it should be more than one year of training to reach level 20, which is when you're Epic Character in D&D standards, and after more than one year of sticking to the work, in mine as well.
Here's a quick video of the application working:

Obviously the app needs some work done before I can release it to people (because even free apps should be of SOME standard), but I really hope that you like the idea. Will be back this week with more World In 7 Days, because I've added that to my Gamificator, so now there's no escape ;).

See you then!

World in 7 days, Day 1: Galaxies

Posted by , in Programming, worldin7days 27 January 2014 - - - - - - · 928 views
programming, worldin7days and 4 more...
The thing that drew me to programming was simple: ability to create. I always loved travels, adventures and discovering the undiscovered. I used to watch this old 60s cartoon called Jonny Quest, about boy having adventures, but when I looked out the window, I only saw blocks of flats in my city, and couldn't imagine that this was possible any more, so I spent time playing with my computer. When I was bit older Cartoon Network ran a reimagining of those stories - The Real Adventures of Jonny Quest. And they had adventures IN COMPUTER!

Posted Image

Now, this later on was looked down upon as not being able to stand the test of time, but for me it was always amazing. After I saw the first episode I bought 'C++ in 24 hours' and started writing an OS/AI/VR system (do keep in mind that I was young ;) ). Obviously it didn't do much except for saying 'hello, mantis!', but it set me on a road to where I am now.

Later on I've picked up the subject of creating worlds couple times, with changes in complexity and scope. I have done some basic ROAMing planets and atmospheric scattering, but I've never put it together into a coherent project. When I was finishing my last project though, I've bumped yet another time to blog of a guy who created the most amazing planets that I ever saw - Journal of Ysaneya. Now, these days his screenshots are down, which is a real shame, because they were AMAZING. Just reading the names of the entries gave me idea, why not do what I always wanted to do? Well, the complete world is a complex piece of engineering, and seeing how Ysaneya worked on his projects for couple years and I'll be wanting to finish mine in 7 days, there will have to be some compromises. Nevertheless, I set out on a journey, and am awaiting with curiosity where it will take me.

The scope is following:

1) I want to generate at least one galaxy
2) That galaxy needs to have proper amount of stars (I'm talking billions here)
3) Each star needs to be blue, white, yellow, orange, red or brown dwarf
4) Each star may have planets around it
5) Planets may have atmosphere/water (the M-class planet, to use Star Trek terminology. I'm not a big ST buff, but I like their naming convention)
6) Planets with atmosphere/water may have plants


How would I divide the work:

Day 1) Shaping of galaxy, preparing density maps
Day 2) Dividing galaxy into octree, allowing for tens (or hundreds?) of billions of stars
Day 3) Go to planetary system mode, create orbits for planets, display planet/sun
Day 4) Create proper terrain on the planets
Day 5) Create atmospheric effects
Day 6) Create L-system plants
Day 7) Polish (rest?)

Yeah, I don't get any smarter or less optimistic in my estimates. But I decline to give in Posted Image

Without further ado,

DAY 1:

Posted Image

I've started by playing around with Unity and figuring out a way to most efficiently represent thousands of stars. After short deliberation I chose the new ParticleSystem. I could access all the particles as an array, and tweak their parameters. I've looked up the wikipedia article on star types, and noticed something which surprised me: most of the stars aren't in fact white, but white are just that much more visible. Which meant that Ysaneya's approach to generating galaxies (using octree to look up stars depending on their colour) made sense. Well, that much I didn't doubt.

To generate correct shape I have combined a bell curve with the equation of:
float a = 2;
float b = 2;
float c = 0.7f;
float d = 0;
float e = 2.71828f;
probability = Mathf.Pow (a * e, -((dist * b)*(dist * b)) / (2 * c * c) + d);
and a picture that I have drawn in GIMP

Posted Image

To get the following result:

Posted Image

You can also see 'record' 'stop' and 'play' buttons there. What do they do? Well, your voice is your key: I take the recording sample, get its hash value, and pass it as a Random's seed value. That means that each person will have his own personal universe, unique to himself (or as close to unique as the hash function allows).

Basically, this means you can create universe by saying 'BE!' ;)

That's it for tonight! See you soon!

Story so far:

Days 2, 3 and 4: Stars and Planetary Systems
Day 1: Galaxies

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

Posted by , in Programming, 7days1game 26 January 2014 - - - - - - · 2,290 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 - - - - - - · 963 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:

Posted Image

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.

Posted Image

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,149 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,165 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:

Posted Image

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

Game in 7 Days, Day 1: Still alive!

Posted by , in Uncategorized, Programming 12 December 2013 - - - - - - · 1,631 views
programming, ludumdare, ld48, fun and 1 more...
Game in 7 Days, Day 1: Still alive! Holy shit, was it really half a year since I last posted here? Time flew fast.

My son was born (woo!), and I've had no time for absolutely anything at all, no sleep, no rest. Go figure. I have, as always, hanged out on #gamedev on afternet, but didn't code anything at home. These days, I'm finally setting into the role of parent and finally have time to resume programming for fun. I put a hold on my previous project, as it is bit big, but I was looking for some inspiration. I looked for it where I usually look - Ludum Dare website. I was lucky enough to find that it's happening this weekend. Time to warm-up then, right?

Last time I did 7 games in 7 days and it was a wild trip. I really enjoyed myself, but I don't think that I'll be repeating that when my kid is this young; I have some time, but not that much any more. So, new project would be 1 game in 7 days. I'm already way behind, with having only thursday and friday left for work, so it'll have to spill to next week, skipping for LD on the weekend (unless I feel like working on this game instead).

So, what's the warm-up theme? Take the first game you've ever created on your own (not by copy-pasting some tutorial) and remake it using the skills you learned along the way. First game? Woah, that takes me back.

First game I have ever created was Artillery (Scorched Earth for those of you that are bit younger, Worms for the ones that are even younger) clone written in BASIC. Funnily enough, I didn't realise back then that there was a QBASIC game that was exactly that: GORILLAS.BAS. I put it together in 45 minutes, during CS class in my primary school (I had a rich, for postcommunist Poland standards, school that could afford PCs in 1993), using a highschool physics book and throw equation for the shots. I didn't understand how parabolas were drawn, so I cheated: I calculated 'throw' distance (which was calculated using force of the throw minus the wind strength), max height of the throw, and drawn line from origin of the shot, to half the throw distance/max throw height, and then second one to max distance/ground level. It looked something like this:

Posted Image

Sweet game that, eh? ;)

Anyways, this meant that I'd be making artillery game again. Seven days gives me plenty of time to do very simple game. Let's see what's needed

1) Level generation
2) Character movement/physics
3) Weapons, Level Objects and Tools
4) Gameplay (as in, turn based stuff, killing, menus, GUI, etc)
5) Graphics
6) Audio
7) Polishing, cute stuff like crate drops with additional weapons
8) Multiplayer over net
9) AI

Seems like I've got my work cut out for me. I've written them in the order I'll be working on them. I want to make at least one point a day, so that I'll have functioning game by the end of the week (though it would be cool if I could fit in network play and AI). If nothing else pops out (I'm probably forgetting something), this should be doable. I'm trying to keep features/weapons/etc to bare minimum, to do the game on time.

Did I say that first dev day is done already? No? Well, it is Posted Image

I knew that I want something more than just straight line. For a while I was wondering about using 1D Perlin noise to just have wavy surface, but decided against it. I wanted overhangs, like in Worms series. So, 2D Perlin noise it was. But first, I had to choose technology. I picked Unity3D, because I like it, and wanted to do some 2D game development in it, to test the sweet Unity3D 4.3 features. First thing I did was creating a Sprite from a hand-crafted texture. Poking and peeking like it's 1982! After some problems, I've had first result - white noise that changed based on height:

Posted Image

Once I had the technology down, I could start working on level itself. It took a 2D Perlin noise, added value between 0 and 1 (depending on height of the pixel on screen), clamped it to 1, and then added it to texture depending on a threshold value I picked, here's the very simple and unoptimised code:
		spriteRenderer = (SpriteRenderer)transform.GetComponent<SpriteRenderer>();
		seedX = Random.Range(0,rangeMax);
		seedY = Random.Range(0,rangeMax);
		spriteTexture = new Texture2D(sizeX, sizeY);
		for (int x = 0; x < sizeX; x++)
			for (int y = 0; y < sizeY; y++)
				float color = Mathf.PerlinNoise((x+seedX)/resolution, (y+seedY)/resolution);
				color -= y/(float)sizeY;
				if (color < treshold)
					color = 0;
					color = 1;
				spriteTexture.SetPixel(x, y, new Color(color, color, color, color));
		spriteTexture.filterMode = FilterMode.Point;
		Sprite sprite = new Sprite();
		sprite = Sprite.Create(spriteTexture, new Rect(0, 0, sizeX, sizeY), new Vector2(0,0),1);
		spriteRenderer.sprite = sprite;
		transform.position = new Vector3(-sizeX/2.0f, -sizeY/2.0f, 0);
And here's the result I got:

Posted Image

Now that I had level with overhangs, islands and floaty bits (not shown on this screenshot, basically blobs of ground hanging in the air) generated, it was time to add some texture to it. I have iterated over every pixel, and did a modulo of its position vs ground tile and some random offset. Then I iterated over every pixel that didn't have anything above it (surface pixel), and added grass tile line underneath, based on modulo of pixel's x position vs grass tile. And here's the effect:

Posted Image

And that was it for first day of development. I'll add some bottom layer (something on overhangs, analogue to grass on top of ground), and some simple customisability, and I'll be off to physics and movement code. See you then!

Day 1 summary finished, mantis out.

Story so far:

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

January 2017 »

151617 18 192021