• ### Announcements

• entries
50
92
• views
65406

Putting the -ing back in developing.

## CARDBOARD ROBOTS OF DOOM!

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

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:

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

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

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!

## Ahh! What a fine day, for SCIENCE!

Hello there, journal, long time no see.

As always, I've been busy. Currently doing full time job, running four projects alongside, studying bioinformatics and raising a kid

After re-watching Dexter's Laboratory, I felt urge to go back to electronics for a bit. I may not have lab hidden behind bookshelf, but I could do SOMETHING, right? Obviously, after not touching electronics in ages, I barely recalled what's what. First job, as usual, was to make an LED light up. Then I've adde a button that would make the LED light up only when pressed. And then I went into the think tank.

Ever since I was a kid, growing up watching movies, shows and reading books about AI, malicious or otherwise, I was fascinated by it. One of my first projects ever was to write AI in BASIC. Obviously, I was just a kid, and had no idea what I was doing, but seeing 'HELLO, MANTIS' on my old, amber monitor made me really proud. I wanted to create a virtual buddy, a computer which would be my assistant as we discover things for SCIENCE!.

So, what is my project? I want to connect my virtual creations, with reality. The start will be creating camera on a remotely controlled arm. Camera shall be processing images and, depending on software I write, react to them in certain ways. Hell, maybe it'll just HELLO, . That would be nice evolution of what I started all those years ago.

How do I go on with this project? I'll be using Arduino UNO for prototyping, but later I'll probably just etch my own one. My awesome creation will look sort of like this (who needs CAD when you have Paint?):

There will be three to five servos: One to rotate the base, one to angle the base arm, one to angle second arm (second arm is optional), one to rotate camera so that it's level no matter the angle of base arm, and one to rotate the camera around the forward axis - its roll (optional as well). That's the positioning platform. There will be camera attached to the arm, that'll be connected to a processing computer (most likely some kind of rasPi). Computer will recognise the data, and send servo positions to the Arduino.

But how do I send the data? At first, I thought about using nLF24L01 wireless modules to connect between computer and the robot. But that required to create my own wireless dongle to connect to the PC. So I decided to go with WiFi. It would be good to have possibility to connect everything in the lab in a network. But first, I wanted to check out another way of controlling it - via bluetooth. First, I needed to learn how to communicate with bluetooth.

So, first subproject: turn an LED on and off remotely. I have connected HC-05 module to Arduino. The code on the remote side was simple:#include SoftwareSerial bluetoothSerial(10, 11);bool ledState = false;void setup() { // serials Serial.begin(9600); bluetoothSerial.begin(9600); // ledpin pinMode(13, OUTPUT); setLEDState();}void loop() { int c = bluetoothSerial.read(); if (c == 0) { ledState = !ledState; setLEDState(); }}void setLEDState() { if (ledState) { digitalWrite(13, HIGH); } else { digitalWrite(13, LOW); } Serial.println("State switched");}
However, code on the server side gave me troubles. At first, I had to choose the platform I'd be using to control my robot from. Since I was using Bluetooth, at first I thought about creating app for iOS, alas, even though my laptop was detecting the bluetooth module, the iPhone didn't. It turns out that HC-05 is SPP Bluetooth, and iPhone only connects to BLE bluetooth signals. Which means that I was going to need to write software for OS X.

I've decided that it was a good time to polish my Swift skills in a real world project. Using IOBluetooth framework, I've written a simple communications tool. Well, by 'simple', I mean 'it took me wayyy longer than I expected'. I have some problems with interoperability with Objective-C methods, especially with UnsafeMutablePointer<> area, but eventually I've figured it out. So, currently I'm sending an integer from my control project via bluetooth, and when the Arduino receives that integer, it switches the state of LED on pin 13.

Here's a picture of assembled, working circuit:

What's my next goal? Well, I want to have at least couple servos. At first I wanted just to send tuples of [servoID,servoPosition], but then I thought that I may want to add some other things (HD44780 LCD, maybe some LEDs to indicate resonses in real life) to the robot. That would require protocol that is bit more complex, if I want to keep it upgradeable. So, I'll be working on to Arduino that controls couple LEDs, data that controls how long each led should blink. That would basically be the tuple solution. If/when I'll get that working, I'll try sending more data alongside.

See you around!

## Rapid Game Prototyping

Journal stuff:

And back to coding again. As always, quick summary of what has happened recently: I've changed job, moved out from my city, and now I have the luxury of remote work from a house in a village. I'm coding, leaning back in a deck chair and listening to the trees (Ok, that's not necessarily true - right now I'm listening to Pink Floyd. But bear with me here), the kid is playing in the grass and I'm enjoying myself greatly.

I've done some work on the GAMIFICATOR. I've progressed it to what one would call early beta, and gave it to my friends to test out. I've received list of things they wanted to be improved upon, and lemme tell you - the list is big ;). Thirty features/change requests. Maybe it doesn't sound that much, but for a project I wanted to do over a weekend, it's a surprising amount of work. What I was happy about however was that they were positive about the app in general. So yay, go me I guess.

The galaxy generator was stuck on a back burner due to simple thing - I got annoyed at not being able to figure out easy frost line calculator for a solar system, and couldn't figure out where my planets with life would be. May not sound like much, but it got me annoyed and I paused the work on the project. Between that and moving/getting new job, I've halted my home development for three months or so. Time to get back in!

##################################################################

Project:

As the project progresses, the build HERE (click me) will be updating with more stuff. Click on button to start a mode, press Escape to exit back to main menu.

Ok, so what's this new awesome project? Back when I was working in games industry in Hamburg, I befriended a great designer, and we spent plenty days with couple beers, pens and notepads, jotting down ideas for games - especially games for iPhone which back then was a new and exciting platform. Utilising things like tilt sensor and touch screen seemed great for new games. Unfortunately, the company in which we were working crashed and we were separated, but the ideas stuck in my mind and from time to time I've pondered working on them.

One of those ideas we codenamed 'Klak', an onomatopoeia for piece of wood hitting another piece of wood. It was supposed to be a logic game based around the principles of Q*Bert:

Basically, the Q*bert is a really simple game. Change the colour of the blocks by jumping on them, till all of them are the colour you require. We thought about making it less of a direct clone, more a game inspired by this, Marble Madness, and maybe Sokoban. It was supposed to be a game in which you tilt the screen to move around a rotating tile to go through puzzle-levels. You'd start with really simple 'clean this area', and then switches, crumbling floor blocks, and other ways to make game interesting would appear.

Hope I didn't scare you off with this longish introduction. The idea I think really had chance (still has?), but I'm not sure if all of that is necessary for iOS game. Recently there has been trend for 'quick restart', as I call them, games: Flappy Bird, Timberman, Robot Unicorn Attack, Super Meat Boy and others. Games that you can turn on at any moment, play for couple seconds, and then put away. I totally see their appeal (having played them extensively. damn you, games!), and wondered if I could make a game like that.

So, how do I turn a puzzle game into rapid restarting arcade-y one? Long story short: No idea. I have however been religiously following Extra Credits. One of the things they said stuck: FAIL FASTER. Make a prototype as early on as you can, check what you see, ditch what sucks, keep what is good, iterate. And so I have. First up was the camera:

Original idea for the game for camera to be 3D, slightly from the side,but I also thought that maybe top-down view would be good. So I wrote a quick test of camera/controls in Unity, and what do you know - people liked top down view better.

Ok, easy part done. Now what?

How to translate the game to something quick and fun? I grabbed couple beers, sat down with my girlfriend, and as we sat and looked at the sunset, we wrote down what popped into our heads. So, we came down with ten possible ways the game idea could be translated into mechanics. So, here they are:

Terminology:

Tile: player controlled block. It's a 1x1x0.2 sized, rotates around one of its edges.
Block: basic building piece of a map
Dirty block: block that is not neutral colour, needs to be changed
Clean block: neutral block, you want all your block to be this colour.

Ideas:

1. Standard game: rectangular game area, all blocks start clean except for one. Then, every X seconds (getting smaller every time), a new 'dirty' block appears. You have to keep cleaning as fast as possible before all board is covered in dirt.
2. Exploding dirt: area, which you can fall off from. As with standard game, dirt appears, though after not being cleaned for some Y time, it explodes, leaving a hole into which you can fall. You have to survive on the board as long as possible.
3. Electric fences: One dirt at a time appears, every X time a row or column of blocks is 'electrified'. If you touch it, you lose. Amount and speed of appearing of electric fences increases as the game progresses.
4. Holes: Holes or trap doors appear, you have to stay on the board.
5. Snake: Normal board, but your speed increases, you can fall off the board.
6. Simon says: Dirt appears in certain colours, and you have to clear it in order given by game. The amount of dirt you have to clear increases every time.
7. Bejeweled: Moving over dirt doesn't clean it, but changes its colour to next one in cycle. connect 3 or more in the same colour to clean.
8. Sponge tile: Dirt blocks are in fact leaking water. You have to gather the water and move your tile to 'drain' area every time you're full
9. Rubbing the dirt: like standard game, but instead of tile you just use your fingers
10. Programmed levels: What we started with. Full puzzle mode. Maybe it's worth it.

Not all of them are great, hell, probably not all of them are playable, but they're supposed to give me something to play with and get a feeling for the game before final design.

Implementation and conclusions:

So far, yesterday I have implemented the first game mode:

I feel that it is not good at all, there's no real incentive to play, you can't lose fast, and when the tiles start appearing fast there's nothing really you can do. This however gave me plenty insight towards next builds. I have also realised that in the second game player can go forever just by bouncing between two tiles and preventing them from ever exploding. So already that's a good thing to know.

I have written the code so that I can reuse as much as possible, but since I still was just starting, I didn't know all the parts I would need. In second game I'll correct my library to be even more reusable.

Well, that's it for now. Maybe it doesn't sound great, but I'm really happy with where I am, especially with the fact that thanks to this approach I'm not digging myself into a hole with shitty game. Sure it hurts to realise that my ideas are crappy, but this helps me steer towards the awesome game at the end.

See you around!

## World in 7 days, Days 2, 3 and 4: Stars and planetary systems

I haven't updated in long time but this doesn't mean I haven't worked. In fact, I am splitting my work hours between this project and GAMIFICATOR(TM) ;) and I'm now on day 4 of making world.

Currently my galaxy can hold up to 5.4 * 10^13 stars (that's a lot). You can check out the most current version HERE (click me), the seed is set so no voice-created universes for you. The interface is clunky, sometimes it gets stuck (reload if that happens), and sometimes it generates gas giants next to the sun, with couple dozen earth sizes in diameter, and a fraction of its mass. But we're not here to nitpick, are we? We're here to generate UNIVERSES .

So, let's do a writeup of what has happened so far (with sprinkle of pretty pictures):

What I had previously was looking pretty, but ultimately doomed to fail, as it had no level of detail progression. Which means I was limited by the amount of stars in the galaxy. Bad thing. I've started working on it, and had some pretty funky results:

Finally I have created really nifty looking galaxy:

That's more like it, but still not good enough. I needed to walk away from prettyfying, and move back towards optimisation, to allow the amount of stars that I wanted (granted, this galaxy would be more than enough for what one person can experience). So I've started implementing octree. It took me majority of Day 2, and I was left with something that visualised to this:

Ooh, pretty colours. Still, it didn't feel right. On third day I sat with my good friend Theo, and implemented non-persistent node implementation, that created node ID based on its location and depth, and created seed out of that. This allowed for repeatable generation of data without the need to store the data structure. The seed code looks like this: void FillOutNode(int x, int y, int z, int depth) { ulong mask = 0xffffffffful << (nodeDepth - depth); float minX = (float)((ulong)x & mask); float minY = (float)((ulong)y & mask); float minZ = (float)((ulong)z & mask); float length = 1 << (nodeDepth - depth); ulong nodeID = FindNodeIDBin (x, y, z, depth); int currentSeed = nodeID.GetHashCode() + universeSeed.GetHashCode(); Random.seed = currentSeed; // STUFF HAPPENS HERE } ulong FindNodeIDBin(int x, int y, int z, int depth) { ulong mask = 0xffffffffful << (nodeDepth - depth); return ((ulong)depth << 36) | (((ulong)x & mask) << 24) | (((ulong)y & mask) << 12) | (((ulong)z & mask) << 0); }
Neat, eh? Well, this gave me neat spatial partitioning:

Rest of the day was spent on adding space navigation (ooh sexy starjump code) and starting to add proper star data generation, which continued into day four:

And on day four I've added planet generation:

Well, that's what I have so far, going into day 5, on which I'll focus on moving into planetary system mode. So far the problem is following: To allow for enough precision, I had to position the stars at pretty close locations. Going into planetary system will mean that the precision will need to be insanely higher (if we're to allow, say, visiting planets, which is the goal of this whole exercise). Smooth transitioning between different speeds will be interesting, but I think I can make it. That means also displaying of the planets and sun, which will also be fun ;).

I'll also want to do an update on GAMIFICATOR(C) some time before the end of the week, but don't know if I'll have time to do it. I reserved time on Sunday and Tuesday evenings for it, so that progression doesn't stop. So far so good . The GAMIFICATOR (patent pending) started as a tool to help me become productive, and I've spent more time polishing it and being productive on it than with any other recent projects. I guess it's serving its purpose even before it's finished ;).

So, again, I hope I'll find some time to develop some more.

See you then!

[color=rgb(40,40,40)][font=arial]===========================================================================================[/font][/color]
[color=rgb(40,40,40)][font=arial]Story so far:[/font][/color]

Days 2, 3 and 4: Stars and planetary systems
Day 1: Galaxies

## GAMIFICATOR

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 worth300 * 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:

It's not very pretty, but I need it done for tomorrow, when I'm at gym, so that I can start levelling up . 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

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!

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

Soooo.

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

DAY 1:

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

To get the following result:

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

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.

Windows
OS X
Linux

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)
-Magic punch (shotgun)
-Meteor storm (air strike)
-Force field (blowtorch)
-Summon wall (girder)
-Round skip
-Surrender

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:

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
-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)
-backgrounds
-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.

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 6: Cleaning up and unexpected developments

So, another day of coding has passed. I was quite sad at the fact that I don't have any awesome new screenshots, seeing how I spent it finalising gameplay. Nevertheless, writeup is required, to keep you guys posted.

I have started by adding support for all weapon-related things. Limited and unlimited weapons, delayed weapons were the first feature to be added. After that weapon properties - explosion range (foreground and background, but for now I disabled the background explosion as it didn't look as cool as I hoped), explosion damage, and offset for making the worms jump higher in the air when hit by explosion.

After that I have added the kill conditions - damage and falling below water level. With that I have added win con (at most one team surviving damage calculation) and that was it. Whole game. At least, theoretically. Everything was a spaghetti test code that I invented as I went along. So, I took all that and started reorganising: Divided match into proper independent phases between which I could jump, say DamageProcessing or BeardlingPlacing.

Speaking of which, I forgot to mention this the previous time, at first I thought it'd be really hard. After some thinking I had the idea though:

1) Pick a random column of pixels in the level (with some margins so that your beardling doesn't spawn halfway off the screen say)
2) Go through each pixel. If it's top edge pixel (that means: pixel at (x,y) has its opacity not equal to 0 and pixel above it has its opacity equal to 0 add to 'potential spawn points'
3) Go through each potential spawn point. If beardling character could fit in the place above it, keep it on the list, if not, remove from the list
4) If the list is empty, go back to 1)
5) Go through each potential spawn point. If there is no other beardling within certain radius (so that spawned beardlings don't overlap), keep it on the list, if not, remove it
6) If the list is empty, go back to 1)
7) Pick random point from the list. Place beardling there.

I also found a solution for drawing the concrete slab: Why rotate pixels? I rotate 'blueprints', and then iterate over a normal texture. Still looks good, and it's way way faster than rotating individual pixels, without the hassle of having to draw the concrete slab in different positions. Here's the texture I will use for it, pretending to be ground texture:

But most cool of all: When I was working on the game, my girl has shown me some of the pictures that she drew as a kid. I was blown away, she really draws great! And, since I'm not a great 2D artist, I asked her if she wants to join me in the quest to create games, so that we'll become rich faster ( ;) ) and she agreed! She has draw concept sketches for the beardlings, and they were awesome. She has no experience in digital art, but she's willing to train. I have also asked her to try and draw some terrain textures for the game, and after never having drawn tiles in her life, she's created this new ground for my battles to be fought upon:

If this is her art after first day, I'm looking forward to the future. I've asked her to create me a bunch of textures for different level types, so the game will be more interesting, and she'll get some experience under her belt. Everything is going great.

See you on the last day, when I'm finally adding all the pretty explosions, menus, animations, sounds and whatever else I'll manage.

Story so far:

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

## Game in 7 Days, Day 5: Game?play

HAPPY NEW YEAR!

Another day down! That again took bit longer than I thought it would, mostly because I had to split time between programming, spending time with my family, and my other hobby - photography. I don't recall if I mentioned it already, but I want to take pictures in the wild (ZOO doesn't count) of animals from the list I created, which, in my opinion, consists of most cool or characteristic animal from around the world. It has animals like Elephant, Tiger, but it also has Deer or Hedgehog (full list here. Yeah, there's 151 animals there. What can I say, I'm a pokemon fan ;) ). It's a project I'll be doing most of, if not all of my life, so whenever I have the time and weather allows I go to the forest in wee morning hours in hope of spotting something. Which means I have to go to bed early, and it still cuts time from my daily routine. So far I haven't done even ONE picture that I'm proud of and consider something that I'd want on my final list. But I'll get there one day.

So, anyways, back to the game. First of all, I decided on the theme/fluff. The game will be about tiny mages chucking fireballs at each other, and it will be called Beardlings. As I said, I did find some time to code, and progressed with gameplay. At first I looked at my prototype and did a list of what was lacking:

CLICK FOR FULL LIST

Yeah, that is a lot. Seemed that doing all of this in one day would be bit too much. Aware of that I nevertheless started.

First off I have done the menu system. For now used only standard Unity skin, to speed up the development, and didn't really care about how it looks. This has a selectable list of all teams created, and some tweakable parameters. Since game screen and main menu are separate Unity scenes, I needed to somehow transfer the data between them. I didn't want to push everything to PlayerPrefs, so I created couple Serializable classes (for level settings, game settings, and team data), and serialized them with a .NET (or rather MONO) BinaryFormatter.

Once that was done, I started working on level generation. When I write prototypes, due to my origins as a BASIC programmer, I tend to fall back to procedural programming (fun fact: did you knew that whole code of original Settlers was just one file? Yeah, that's just crazy). So, for final level generation I had to put my fugly code with global variables into neat classes. Once I did that, enhancing the level size was simple. What I needed to work on however was island/flat land, and water level (with presentation).

Here's a comparison:

Island type

Flat type.

So, basically, one blob in the middle with water to the sides vs semi-levelled terrain across whole map. The difference in code was how I added values to generated levels (see Day 1). In flat levels they were added equally based on Y position of the pixel in the map, in island levels they were added depending on distance from Lower Center point of the map. After tweaking some other stats, I'm getting quite nice levels, if I do say so myself. Water was just a simple height check + texture at that position that waves in sin(time).

From there it was work on collision. Re-worked the physics/collision system again into something more robust, with some optimisations thrown in. Wrote a simple gravity physics object for testing purposes, and went on to implementing the teams.

First approach was to throw all characters into one List<> and assign nicknames based on their position. First four would be named and given colour based on first team name, then next, etc. Soon I ran into limits of this system and reworked it into creation of list of four Team objects, each of which controlled four Beardling entries, each of which had his own HP, nick, and position in team (important for switching turns).

Next on the list I have created turn system. On most basic level the turn is controlled by timer (which I added for both turn and whole match here). When turn ends, you set the starting beardling in current team as next, and move to next team. I've added the basic weapon GUI back, character movement, and - since it was already 11:45pm, closed for the day and went to celebrate New Year with my girlfriend and son.

I didn't manage to put the new weapons or win conditions in, so that moves to day 6, and from then on it's GFX/Audio/polishing.

So, see you around (maybe tomorrow even?). Have fun in the new year!

PS: If you want to see how I'm progressing with my photography skills (I started as total noob not so long ago), you can check out my 500px page. I usually upload my best pictures there.

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

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 (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:

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.

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.

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

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)

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!

[color=rgb(40,40,40)][font=arial][font=arial]Story so far:[/font][/font][/color]

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

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

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:

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:

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:

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!

[color=rgb(40,40,40)][font=arial]Story so far:[/font][/color]

Day 7
Day 6
Day 5
Day 4
Day 3
Day 2
[color=rgb(40,40,40)][font=arial]Day 1[/font][/color]

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

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

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 .

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:

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:

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

## 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:

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

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:

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(); 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; else color = 1; spriteTexture.SetPixel(x, y, new Color(color, color, color, color)); } } spriteTexture.filterMode = FilterMode.Point; spriteTexture.Apply(); 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:

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:

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

## Never give up. Never surrender.

So... yeah. This is going to be a hard thing to write.

It's been long couple months. I was supposed to do many great things, I was supposed to update this blog. I have to come clean: I didn't.

Now, I have standard excuses: I was tired, I didn't have time, I had to spend time with my girlfriend and preparing for the kid to be born, I was studying lots of things. I was sick.

That doesn't change one thing: I failed. I have set out to make 12 fully polished, even if small games. First month I wanted to create planet-based shooter. It didn't work out. Between me having written very little code and my artist friend not having a lot of time, on the last week I had to cut the losses. It was hard, and I was ashamed, but to just keep making games on the last day of January, I made a 'match 2' game:

Yes, it's ugly. Yeah, it's crappy. But I didn't want to admit that I failed. February I've spent majority of the month being depressed about failing so hard. Eventually I got my act together and wrote a very simple laser & mirrors logic game:

This one was tiniest bit more polished, but still nothing to write home about. I felt that I was back on the right track. Alas, in March again I didn't do much work. What I did was a tiny racing game for blind people. Basically you could hear your wheels falling off the road and starting hitting roadside gravel more and more, until you spun out of control and crashed. Cute experiment, but I didn't even add stuff as simple as announcer explaining controls or telling the score. Since the screenshot won't really convey much here, here's the link. Just click on the Unity screen to enable controls (and make sure you have surround sound enabled). In April ever since the beginning of the month, I had an idea for a very simple game, but I have spent the month developing a system for isometric tile based RPG.

Needless to say, again I didn't have enough time for such a big project. Or rather mental fortitude. I have worked on it for a week and gave up. I had the time to develop the small game about a cube that I have designed, but never went for it. I even had the PERFECT Ludum Dare for it: The theme was Minimalism, which would fit my game to a T. I haven't participated. I have created cool, really optimized mesh system for Unity3D, I have played with voxels for a bit, but all in all - I have failed in what I have set out to do - 12 games in 12 months were no more.

Now it's middle of May, my kid is due in about 2-4 weeks, and I have picked myself up. I have thought about it a lot, and talked with friends about it. I have failed, but I can't give up - the goal wasn't to make the games just so I can show off on my blog. Sure, some of my games that I have made in 1 day for the 7 games in 7 days challenge were better than what I have done here. Is that painful? Sure. Am I ashamed to admit that I failed on the Internet? Sure am. But the goal for this year wasn't just to have these games made. The goal was much more: learn to manage my time on longer projects, so that sometimes next year I can start working on full commercial games from home, hopefully to secure my family's future. I haven't achieved that goal, but that's no excuse to stop trying.

So, while I'll be trying to keep within confines of the monthly schedule, I'm no longer going to feel shackled by it. I won't be hiding just because I didn't manage to do what I wanted to do. The project is tough, but I have to do it. Want to do it. And will do it. I have picked the game I wanted to do most: RPG as simple as possible. I want a top-down view, similar to Zelda, I want lots of cool explosions, fighting with lots of enemies, and generally old school beat'em'up feel (think Cadillacs and Dinosaurs, Punisher, Dungeons and Dragons:Shadows over Mystara or Aliens vs Predator). I want to have fun while making the game, because that's the only way I'm going to finish it. After first day of design, here's the first screenshot (obviously, everything is temp graphics only):

The faux-scanline is to make it look even more retro. Like I said, I'm going all out with what I love here, and scanlines make me feel young again ;).

Well, that's it for today
Talk to you all soon!

-------------------------------------------------------

So far in the series 12 Games In 12 Months:

1. Announcement
2. Game 1: Intro
3. Game 1: Week 1
4. Never give up. Never surrender.

## 12 Games in 12 Months, Game 1: Week 1

Week one is done. It wasn't that long, only 3 days really, as on the New Year I wasn't working, due to it being a day off. I had unfortunately bit more things to do than I anticipated - to be precise I had to do coding for my day job over evenings and even on the weekend, but I found some time to write game.

The goal for the first week was simple enough: Write a minigame in which you move around with a marine, and shoot monsters that follow you and want to eat you. The assumption was that if there will be not enough time to add more features, I can always take the minigame and polish it properly. As I have written in the previous entry, the goal was to have marines walking on planet, but implementation took bit more than I had time allocated for it, and so that feature has been cut. After all, what's the point of having pretty looking game if it's unplayable?

So, CUT CUT CUT! Gameplay is all that matters!

Speaking of making a playable game - how do you get there from nothing? If you're making a one evening game, it's easy to keep things under control, but on longer projects, especially if you make them with other people, it's good to have some kind of a plan. What I usually employ is a methodology called scrum. To keep it simple enough: the creation of the game is divided into short time periods called 'sprints'. Why are they called that? No idea. But let's not dwell on that. Each sprint has certain set of goals that must be met. These goals may be 'implement shadows', 'create sounds for Boss #2', 'add death animation to Blob enemy', or whatever you can think of. It's good to keep them simple, as this way you can really see the progress. Writing 'programming a game' as a task sort of defeats the purpose, as you can't really see any progress for too long.

Usually when you meet IRL with people you work on projects, it's good to have real life board to display the progress, but if you're working with your online friends, you don't have such luxury. What comes handy then is some online software for tracking the project status. In our project we use Trello , which I used at my day job already, and quite liked. It gives you good enough overview of what's going on, and labels to give quick visual feedback on what each task is about. Here's screenshot of one we're using:

Each of the coloured labels has a different meaning:

• Green label is anything related to programming. If you see this label on a task duplicated by task with another label, it means coding backend for it. For example enemies need both graphic part (models, animation, textures), and coding (AI, spawning, interaction).
• Yellow label is anything to do with graphics. 2D and 3D objects, menus, concept art, or animations, it goes all here.
• Orange label is sounds. Music, SFX, voices go here.
• Red is design. It's a catch all for both things that need to be still polished or designed, and general Quality Control. Sprints fall under this, as finishing a sprint means passing quality check to see if it actually works.
• Purple means temporary. Tasks with this field means that they only have to implement certain part of the full task to be 'good enough' for current sprint. Usually it's better to divide the tasks to give as clear distinction between what needs to be done and what doesn't, but I use this to give whoever is working on the task some leeway - if you can implement more features, great. If not, just implement the minimal amount, and we're still on the path to finish game without any delays.
• Blue means that task is to be done for the current sprint. Simple as that.

As you can see, the tasks are divided into couple lists: To Do, Current Sprint, Doing, Done, and Final. The distinction is as follows:

• To Do has all the tasks that need to be done to finish the project. Obviously listing all of them at the beginning is nearly impossible, but here's where all the tasks that are thought up start.
• Current Sprint is tasks that need to be done during this sprint. They are technically the same as 'To Do', but this distinction helps them to not drown in the sea of other tasks for the game, and it means they're easier for people to browse.
• Under Doing you put whatever feature you're working on at the moment, so that your friends can keep track of what you do, and if you are on your own, it's a quick reminder of what you were doing, so you can resume where you left off on previous day.
• Done is a feature that is completed for current sprint. Feature put here needs to be tested, and from there it can move to 3 places: 1) if it's not good enough, it goes back to 'To Do', and needs to be re-done in some sprint (preferably current). 2) if it is good enough, but it's temporary, the description of the feature changes to reflects that, and is put back into 'To Do', so that it can be fully implemented. 3) if it is good enough and not temporary, after the sprint is checked, it moves to 'Final'. Congratulations, you're one step closer to completion.

Doing this (like writing a full Design Document) might seem unnecessary to some of you, especially if you work alone, or think it's just a dumb waste of time for things that aren't game development, but make no mistake - this does make the workflow smoother, and if there's even two of you, it does help a lot. So give it a try, and if you like it, write me a line. I'd love to hear about your experience.

Oh yeah, I also bought a sketch book and couple pencils (2H, 2B, and 2x HB), and I will be studying drawing in my (definitely slowly disappearing) past time. I want to get better with 2D art, especially to be good at concept art. I know it takes years, but I'm not backing off. Oh yeah, if you know of any good online course (especially free online course ;) ) or videos on drawing, I'd gladly hear bout it as well.

Well, that's it for today. Next week is looming already (no, really, it starts in 15 minutes here), so I better go to bed. This week it's time to implement nearly all elements of the gameplay. See you then!

-------------------------------------------------------

So far in the series 12 Games In 12 Months:

1. Announcement
2. Game 1: Intro
3. Game 1: Week 1

## 12 Games in 12 Months, Game 1: Intro

Happy New Year, people!

Today is the very first day of development for my 12 Games In 12 Months project. I have really looked forward to this, but I'm also bit afraid. This year will be really tough, with me working essentially 1.5 shift for the whole period. I need to keep the goal in mind though: Get better at creating games, and prepare to earn some serious cash this way, so I can worry less about not being able to support my family, especially the kid that's on the way. He/She is also my first kid, so I'm in for a ride ;). Let's see how this will turn out.

I decided that, since writing on how the project is coming along takes a lot of time, I can't keep you posted every day, but I need to share my progress at least every so often, I need some kind of updates schedule. It will work like this: first day of every month I will write a post about the new game. The design document will be there, and I will outline the challenges that lie ahead of me. Then, every weekend (preferably on friday evening, after wrapping up the work for that week) I will write about my progress and what's left, doing a tiny post mortem and saying how my goals went. Final upload will be when the game is finished, at the very least with the last day of month.

I will be working only on weekdays (at least if I can pull it off), so that I have weekends still off. I have no doubt that rest will be needed, so I need to keep my 'just one more line of code' attitude in reins. Hopefully I'll manage ;)

So, without further ado: first game, as mentioned before, will be a shooter. It will be ripping off a lot from old Cannon Fodder game, but I hope that choosing that great of a role model, it will force me to work harder and make sure everything is tip top.

I have put up a Design Document that I will be using (and most likely modifying) during the development. I tried to write down as many rules as possible up front, to make the coding easier and more to-the-point. I plan to have gameplay demo as soon as possible - the latest after the first week, so I can figure out if the game is fun. There's not much point in re-making the game from scratch 3 weeks in, when I see that it's not as fun as I hoped it would be. The second week should focus on making the game complete. Create the menus, the pre-mission view, make sure that all the functionality is working. Third week should focus on building interesting levels, applying the polish and weeding out the bugs.

My friend said that he'd help me, so at least for this project I don't have to worry as much about the gfx content. Which will hopefully mean that the 4th week I'll have off, so I can rest a bit.

The hard bits I foresee:

-Camera: I have created couple planet-based games, and there are many challenges here. Getting good camera view that shows you the action as well as shows the curvature of the planet is really hard if you try to go for differing planet sizes.
-Obstacles: creating paths for player units to walk through will be hard. I'll most likely will have to write some kind of level editor plugin for the Unity3D, so that the maps are more than couple obstacles sprinkled here and there, but have also dense, unpassable forests (that aren't too high on polygons, but still LOOK unpassable).
-AI: it will have to work in 3D, along the curvature of the planet. I don't know what problems it may cause, but I suspects some demons hide here.

See you again soon, wish me luck!

-------------------------------------------------------

So far in the series 12 Games In 12 Months:

1. Announcement
2. Game 1: Intro
3. Game 1: Week 1

# 1) INTRO

Hello there. The year is ending, and it's time for a new challenge. I'll be making 12 Games in 12 Months, over the next year. \o/

Since I've turned 30 years old couple days ago, and have a kid on the way, it's high time for me to stop loafing around and go for the goal I always aimed at - create awesome games that will be played all over the world. If you've seen my previous challenge, '7 Games in 7 Days', this may strike you as suspiciously lacking ambition. On the contrary. My goal, like with 7G7D, is to expand my skills and prepare for something bigger after I finish it. To be precise:

• Create 12 full games, with all basic features of a commercial game (menu, help, intro, or whatever applies)

I think that best way to prepare for finally releasing commercial level games from home is to create games that meet that requirement. 1 month should be long enough to help me whip up full games, and doing that couple times will reinforce my resolve to help me work on even longer projects in the following years. I also think that if any of the game will show promise of being profitable, I'm going to put it to App Store and Android Market, maybe some other places.

• Have all games be high quality. no temporary leftover art after the month is finished.

This has a lot to do with previous and next points. I want to make the games look good, So that they can stand proudly among their peers. I will either be making the graphics myself, and learning a lot, or have a friend, who is a wonderful artist help. Hey, maybe we'll turn into a full time indie studio one day? ;)

• Learn to plan my work schedule in longer term projects

12G12M isn't my final goal, it's one of the first steps. I want to make commercial games in the following years, and to do that I need to be able to have as good planning skill as possible. If I will take on the indie job full time (I'm now doing it only after hours), I need to be able to estimate how long a given project will take, so I can secure enough money to provide for my family up front (and have some buffer, obviously). Learn to design games that can be implemented within confines of the schedule, minimize cutting of features. With my previous challenge it was all about doing as much as possible within time limit. This time it's all about finishing polished games.

• Get better with my tools, and improve on the workflow.

This goes both for programming tools - that is Unity3D (getting to know the engine itself and write shared library of scripts for situations I visit often), and for art tools. Yeah, there is a chance that I will have a help of a professional artist, but it's always good to have some fallback plans.

# 2) DETAILS

This time the games will progress slower than full release once a day, so it may be that I'll be updating only once a week or so, but with bigger amount of news. If I won't have help of my friend, I'll be aiming to be as close as possible to developing in following cycle:

• 2 weeks programming
• 1 week of gfx/audio
• 1 week of polishing

During the 7G7D I've noticed that I did about the amount of work I'd be able to do in relaxed work week, ~2-4 hours of work after time, with free weekends for recovery. Since I'm aiming for whole year of development, I really can't overwork myself, and have to keep a sane schedule. This split allows me for about 3-4 more time per game than I had for my Strategy, without the danger of burnout. Of course I'll be monitoring the state of my health both mental and physical (and making sure I have enough time for my family), and if anything seems off, I'll adjust.

Last time I had a list of genres of the games I want to make, and although I can see that over the course of whole year I may have some brilliant ideas for games that may be made in month's time and bring MILLIONS, I've whipped up a temporary list, which will be at least true for first month ;). So, in no particular order:

• 1 - Shooter

The asteroids clone I did for 7G7D was bit too limited, as I was just beginning to experiment with Unity3D back then. I want to tackle something bigger, but I so far I don't think it'll be a standard top-down shmup, but rather a mix between Super Stardust and Quake. Enjoy the first ever design drawing (yeah, I'm cheating by starting already, but I reckon I'll be thinking about next games during development as well).

If any genre is going to take over my list, it's this one. I'm going to make at least one action/arcade game, in the like of Q*bert or Marble Madness, and possibly more. Ideas for this kind of games pops into my head most often, so if I'll find any worthy of implementing, expect some other genre to be pulled down.

• 3 - Puzzle

What can I say, my girl likes puzzle games, and I want to make something for her. I'm not sure if I'll do action/puzzle game in the vein of Bejeweled Blitz, or rather something akin to all those memory/logic games

• 4 - Management sim

Inspired by Theme Park and the like, I want to make a game about a restaurant, maybe with educational bit, and real recipes? We'll see.

• 5 - Platformer

Like with the shooter, 7G7D version of platformer was severely lacking. And I don't mean just bug-wise. I didn't find any time to put some nice levels in, and I didn't have the time to figure out how to create cool procedural level generated platformer that wasn't a clone of Spelunky. Of course after that I just made a bad clone of Robot Unicorn Attack. This time I would really like to create cinematic platformer (like Another World or Flashback), if time allows.

• 6 - RTS

Again, I have a cute game for which design sat idly in my drawer over long time ( first time I mention trying to implement it was over 4 years ago). When I was bored I reworked the details, but never found the drive to actually write it. Since it seems I'm actually making games this time, I think I'll give the idea a shot.

• 7 - Space sim

I haven't yet decided on which route do i want to go - combat or otherwise, with both Freespace and Elite being great inspirations. Will see how this will progress as I'll decide to work on it.

• 8 - Beat'em'up

I always was a huge fan of Cadillacs and Dinosaurs, Punisher, and other Coin-ops (and I've wasted plenty of lunch money in arcades as a kid on them). This seems like a perfect opportunity to write one myself, and see how I fare.

• 9 - RPG

The game in 7G7D I've played the most was easily the RPG. It was simple, broken at times, offered no level progression or items, but I just enjoyed it so much. I really want to make it into a complete game, possibly one that feels like one of those huge roguelikes. If I'll manage to do it, I definitely want to put it out on iPhone/Android. Even if I'm the only one playing, having a roguelike on the go will be sweet

• 10 - Sports game/Racing game

I'm thinking about creating something with arcade control scheme - something like Skidmarks, Micro Machines or Ironman's Off Road back in the Amiga days. Just fun for couple friends, with no unnecessary complications.

• 11 - Point and click adventure

There is a big 'if' here. If I will feel I'll manage to write a complete game, if my gfx artist friend will be willing to take this on, and if by the time I'm developing it I'll have enough scripts for basic functionality that I may focus on the story for the most of the development part, then I'll go for it. Writing the text adventure game for 7G7D was really fun, as it allowed me to cram tons of jokes in, and made me really happy. Add to that the fact that adventure games were always (ever since I played Leisure Suit Larry in '89. yep, I was 7 years old then. good times.) my favourite genre, and you'll have something I really want to do. But, like stated, don't know if I will be able to. We will see.

• 12 - Music game

Yet another game I designed ages ago (this one in 2004, nearly a decade ago) when I was working at my first gamedev company and wanted to impress bosses by showing them a new IP. Of course they didn't want it, and (no doubt as the result of that) the company fell. Now I have the chance to re-make the game, and earn BILLIONS! Basically, first design it was something similar to Lumines, with music playing key role in tetris-like gameplay. I'll obviously be revising that idea, and hopefully something good will come out of it. Here's a picture of the first version running on NDS emulator:

# 3) OTHER

I know that I may not be able to finish all of those games. There's full year ahead of me, I have a full time job that I need to keep to feed my family, and my kid will be born around June, probably causing severe stress and lack of time. I want to do this though, because it's something that may help us in the future. Also, making games for yourself is FUN

After deciding on this challenge I have noticed that there's a website by one of Ludum Dare guys, OneGameAMonth, for people who basically attempt to do same thing I want to do. I immediatly joined. As usual, it's nice to be part of a community.

If you're interested, currently I'm using the following tools:

Unity3D as my game engine.
GraphicsGale and Paint.NET for my 2D graphics.
Blender for my 3D graphics.
SunVox (maybe FL Studio later on) for my music.
BFXR and Audacity for sounds.

This is subject to change, as the time goes by, but I don't predict I'll move away from Unity3D. I feel comfortable with it, it runs on C#, it's on all the platforms I'd like to support, honestly, I can see no good reason for me to not stick to it.

Well, that's about it. I hope you liked this start, and will follow my little project as it goes. And of course when I'll be rich and famous I'll remember people who cheered me early on ;)

-------------------------------------------------------

So far in the series 12 Games In 12 Months:

1. Announcement
2. Game 1: Intro
3. Game 1: Week 1

## 7 games in 7 (plus a bit) days finished!

Finally!

I have finished it. And on my birthday, too . What a wonderful gift to myself

After not having that much free time on the weekend and during the week, I finally managed to closed the deal (more or less) on the strategy game. This concludes our challenge. Sure, the last game took longer than one day, but I have finished it, which is most important after all. Giving up is never an option.

It's not fully equipped, there are bugs, there are features missing (intro/help menu, display of attack range), but the game is playable, from start to end.

So, how did I go around creating it? As this was the biggest game, I had to combine everything I learned to make it happen. I've started, as always, by drawing some characters and textures to get me in the mood, trying to figure out what style should I go for:

During that phase, I laid out the game design in my head. I decided that it would be a turn based tactics game, similar to XCOM. For that kind of game I needed couple new things:

-Pathing algorithm (I'm using A*), on which I spent majority of the first day, setting up the tile system, character-tiles interaction. It still doesn't take into account many things, so opponent units can stack themselves, and the AI is wonky at best, but we'll come later to that.

-Menu/notice system: the game was complicated enough that the feedback that can be given by simple icons was just not enough. I wrote a tiny script that displayed overlaying menus and notices, and shaded the screen using dithering (later on I decided that it was shame I didn't use same thing for the floor hilighting system

Second day I have spent mostly connecting the pieces I wrote earlier, and adding AI.

Holy shit, the AI.

Now, I had basic pathfinding, but it was written in the wee morning hours, after loooong day, so it was far from perfect. My code started getting more spaghetti like, and I had to write ginormous state machine to govern the AI. The turn based system support was also something that I haven't had prepared place in code for the start, so it needed to be hacked in by tons of bools and timer variables. The pathfinding worked only on tiles, checking if they were passable or not, didn't check if there were other units already there. Picking nearest unit to attack also didn't work that well. The AI would be cruising in same, A*-predicted lines as soon as it saw you, so they'd form nice conga line for your skeletons to shoot.

On the other hand, it worked well enough. It could kill the player, and that was fine enough for me.

Last hours (over the week, like I said - had to stop developing game over the weekend) were mostly making sure that the game is actually playable and some early polish.

# HERE'S THE GAME!

Select unit with left mouse button, move them within their move radius with right mouse button, you can attack units you're next to with your melee warriors, ranged warriors can kill units within their range.

Middle mouse button hold + mouse move or arrow keys move the screen.

Back/Next icons jump between your units.
Cast icon lets you summon units and cast Heal.
Floppy disk icon lets you enter options (restart only in this version)

Story fast version:

World is heading downhill in the Fantasyland. Feudal lords are oppressing the common folk, and abusing their power to do 'good' deeds, that are only good for them. One necromancer has had enough, and decided to wage war on the Lords. With his awesome powers he tries to overcome the obstacles and win against the evil knights.

Gameplay:

This is a turn based tactics game. You control a squad of units, each of which has following stats:

-attack, governing damage it can deal
-defence, governing how likely is it to defend the strike and take minimal damage
-health, when this runs out, the unit dies
-speed, governing how far can can it move every turn

You, as the necromancer, have spiritual energy. You start with 20, and can use it to summon more army, and empower the one you have. You replenish the resource by killing enemies.

-knight gives you 1 units of spiritual energy
-goat gives you 2 units
-Lord gives you 10 units

Killing the Lord also ends this version, so that doesn't matter, but in full version, where you would have to defeat many lords, that would be important.

You can summon 3 kinds of units:

1) Ghost, your basic scout unit. Moves quite fast, is cheap, and has average health, but poor attack power.
2) Skeleton Archer, your ranged unit. Can shoot units at a distance of 4 squares. Hits decent, but has poor defences, needs to be kept out of front lines
3) Zombie, your toughest warriors. Slower than other units, but pack quite the punch, and are very tough.[/quote]

And that's it for the game.

And here is a list of the entries in the series:

Last Day summary and Challenge Post Mortem
Ludum Dare preparation
Day 6 summary
Day 5 summary
Day 4 summary
Day 3 summary
Day 2 summary
Day 1 summary
Series kick off

So, how about a little summary of the long week?

# 7 Games in 7 Days Post Mortem

The week was tough. Like, really tough. But I got through it, I managed to refresh my skills, and I am looking happily into my future as a past time game developer. Let's see what I learned.

General lesson was, as expected, don't overwork yourself. I could've finished the Strategy game if I've crunched hard, but I'm happy that I didn't. 2-4 hours every day of afterwork development is good enough to make a game in short amount of time, and way better for your health and personal life.

- When I was really in the zone, I lost track of time. I spent 24 hours straight in front of computer developing the Dungeon Crawler. That didn't make my girlfriend happy, and when she's unhappy, that means something's really wrong. She knew that I was preparing for the LD, but whole week of coming to bed later and later every night did put a strain on the relationship (nothing serious, but really REALLY unnecessary and whatever the earnings, not worth it).
- The tempo. I had really tough week at work, and the challenge meant I didn't get even one day of rest, but rather not sleep till 3am+ every night. My sleep schedule started slipping, and last day I pulled an all-nighter, going to sleep at 1pm. I was recovering from that most of this week.
- Art before coding. Sure, it might've helped me stayed focused and interested, but I was supposed to write games, and while first games were fast enough, starting from Adventure Game, the art took WAY too big part of the game development time. Because of that, I had only one drawn screen in Adventure Game - I noticed how late it was, and I was still playing around with art, not having any gameplay to speak of.

The good:
- I did make 7 games. That's a massive boost to the self confidence. I haven't really finished a personal project in ages, so when I look at these games, I feel like I can take on big challenges again. I even feel like picking the games (especially Dungeon Crawler) and expanding on them, possibly turn them into full products.
- I haven't given up on the challenge two times: first, when I worked really late in the night and didn't finish any real game (with the Racer), and second time, with the Strategy, which I had to put off in time, due to work and personal issues. I have continued the challenge after the first, which was really discouraging, and I didn't give up on the second till I decided it was 'good enough', even though the 7th day (or, indeed, Ludum Dare) was long over. I was rewarded with huge feeling of satisfaction for both of them.
- I really got from 0 to hero, engine knowledge wise. First game was a really bad clone of Asteroids, and last game was quite complicated strategy game, combining every single lesson learned so far.
- Art before coding. Sure, it might've stopped me from doing awesome stuff, but when I was doing them, my brain was resting, I wasn't thinking about solving some hard problems with code, but rather looking at happy little pixels.
- Choosing the VIC-II palette was great. Limitation has turned into inspiration. Less colours make my sprites look better and more interesting. Working on them and trying to figure out how to achieve certain effects was FUN, with capital F, U and N.
- 7 different game genres. Each day new, exciting set of challenges waited for me, and that at least a bit alleviated the challenge fatigue.
- Tools. As the days progressed, I got more and more skilled in using GraphicsGale and Blender. That helped me every next day, when I had to do more complicated stuff in same percentage of development time.
- Simplicity. Each game was designed to be as simple as possible, and for the most part it worked out really well. I rarely if ever had to cut features, and there was enough time to implement full games.
- SUPPORT OF THE PEOPLE: thanks to people that were interested and commenting, I found strength each day to sit in front of computer and continue coding, for the 16th+ hour that day. Without you guys, I would have never managed. Thanks! Really, that meant a lot to me.

And on this, I will end. But keep your eye out on the lookout for more projects that I'll be working on. I hope you'll enjoy them as well.

## Ludum Dare #25, Post 1: Let

This was gonna be hard. I woke up at 3 am, and noticed that the theme chosen was one of the few I've downvoted. But I wasn't going to let go that easy. Welcome to Reviving Necromancer Roaring Rampage of Revenge (title pending)

So, I started dissecting the 'you are a villain' theme. Just what IS a villain?

-Somebody out to cause harm to good people, your cliche 'do it for the evulz' villain'
-Somebody viewed from nonstandard angle (like humans in Bambi. they're unseen, evil monsters that cause pain to forest life)
-Somebody could have been a villain in a past and now is righting wrongs, and trying to make good of his life
-Sometimes you have to choose between two lesser evils, and that can make you a villain in eyes of observers
-Maybe somebody is out for revenge for their beloved ones, and he crosses the moral event horizon, becomes what he was fighting (think Punisher)
-And lastly, maybe he's just branded 'villain' by the governing forces, like Rebellion in Star Wars

I decided to go for the last one. It's easy enough for king and his lords to brand somebody dabbling in the dark arts a villain, and superstitious villagers will easily believe that.

Well, that's the story at least. What about the game itself? I didn't get to finish my 7 games in 7 days warmup challenge (done only 6 games, and as those of you who followed it know, I had to do some work stuff, because suddenly a deadline at work reared its ugly head), so I decided that my Ludum Dare entry will be the unofficial 7th game. My temporary graphics look quite similar to my 6th Game, Dungeon Crawler, as there is a limitation I gave myself: use only VIC II (Commodore 64 graphics chipset) colours. There's only 16 of them, and that's quite limiting in how many different, say, bricks I can draw. Here's the palette I'm working with:

As for the game, it will be a squad based tactics/strategy game, akin to XCOM and Laser Squad. Look out for future updates, and hope you'll enjoy them!

And here is a list of the entries in the series:

Last Day summary and Challenge Post Mortem
Ludum Dare preparation
Day 6 summary
Day 5 summary
Day 4 summary
Day 3 summary
Day 2 summary
Day 1 summary
Series kick off

## 7 games in 7 days, day 6 finished

I had terrible problems with logging in to GameDev, so I had to post my Day 6 update on my Ludum Dare blog. But since the wonderful staff of the GDNET fixed the problem ( <3 ), I can post it here

HERE'S THE GAME :>

So, day 6. Only ONE DAY LEFT! I'm nearly there, even though I have again been awake for over 24 hours, I'm only now getting tired. Today I've been working on what partially inspired me to start this challenge - a dungeon crawler. My goal was to create something akin to Moraff's World, which was kind of a roguelike, but from first person perspective. to deal with lack of peripheral vision, it displayed the world through four cameras - one for each direction.

I started by creating couple textures: for Thong Goblin, Gold, Ladder Down, ceiling, floor and walls. Yeah, I know that programming is more important than art, and I should stick to temporary graphics till I'm done, but I've enjoyed working in C64?s 16 colour palette so much yesterday, that I wanted more of it. Being limited really does make you think more carefully about which colour to use to achieve what effect. Also, because of that, I created name for the game: DITHER CASTLE . I wrote a quick billboard class, so that 2D sprites in the world would always be looking at the camera. (speaking of camera, I've learned how to use split/multiscreen)

So, after wasting some time on making myself feel better, I've started working on the game. Firstly, I needed some kind of level generation. I have already been working on procedural dungeon generators, but it was mostly for Diablo-like levels (which, as far as level generation was considered, had zero thickness walls). After several failed attempts, I have managed to write something decent, here's the algorithm, maybe it'll be useful:

1) Generate X rooms (X is most likely some random number between minRooms and maxRooms). The rooms can overlap, actually, if they do, it sometimes looks better. So your only worry is to create them in a way that makes them fit on the screen.

2) Create a list (vector in C++ most likely) 'unvisited', and put all rooms on it.

3) Create a list 'visited'. Put first element of 'unvisited' list on it

4) Find closest to it room on the 'unvisited'.

5) iterate over all rooms on visited (1 so far), and check which one is closest to the new room.

6) connect the rooms (here's my algorithm)

6a) pick a random tile within both rooms (as defined by Room class - origin.x/origin.z (y is up), width/height, or something to those extents)
6b) from one of the tiles, check difference between X an Z coordinates of two tiles (y is up still).
6c) if vertical difference is greater than 0, move one square in that direction, mark the tile as clean/empty/floor/whatever
6d) if vertical difference is still greater than 0, go back to 6d)
6e) once you've created vertical route, do the same (one by one 'eat' tiles)

There. Really simple, and looks quite nice:

After the levels were created, I've started adding features:

First was ladder to a new level, which just picked random room (but not player starting room), and when you collide with it, it generates the next level.

Second came AI. This was really simple, just a bunch of 'move towards player, check for collisions' routines, and it was good enough for the demo.

Then came player stats. I decided to make a scene with player creation, and I had to learn how to share variables between different scenes (turns out it's incredibly simple in Unity - just use PlayerPref.Set/Get Int/String/Float(), and you're done. I decided to create 3 classes for the player, and following mechanics:

Character consists of: HP/MaxHP, Strength, Dexterity, Constitution, Minimum Damage, Maximum Damage, Gold carried. Base stats were calculated by rolling six sided die (or, to be precise, Random.Range(1,6) ), and adding 6 to the result. Also, each class has one 'strong' stat, and one 'weak' stat.

Berserker gets +3 to Strength, -1 to Constitution
Warrior gets +3 to Constitution, -1 to Dexterity
Monk gets +3 to Dexterity, -1 to Strength

Combat is calculated by comparing attacker's Strength score + result of rolling a six sided die, and defender's Dexterity + result of rolling a six sided die. If attacker wins that, he then subtracts from defender's HP random score between his min and max damage. If player dies, well then, he dies and is taken to results window, which shows how much gold he managed to collect, but if he wins, then monster dies and drops the gold he's been carrying (determined by kind of monster, dungeon level, and - as always - chance).

Speaking of monsters, we have 3 of them, from common Thong Goblins, through strong Cookie Monsters, to incredibly powerful Christmas Elementals. More powerful monsters start appearing the lower in the dungeon you are.

So, what else? I sprinkle the dungeon with gold, but obviously would like to add more enemies, items (currently we only have gold as pickable. there is even no inventory).

What more would I want to fix? Well, there's a problem with converting floats to integers, and since I use sometimes floats, sometimes ints (because I was lazy), then at times you encounter invisible wall where you should be able to pass freely. That's the reasong [D]ie shortcut was added :/. Also, since I didn't have any place left on screen, I didn't put any output telling you what you pick up, or how much damage you do. Same is the reason why [L]ook command doesn't work, and it's a damn shame, because i put funny descriptions there .

Since it's already 13:40 on Sunday as I'm writing it, I don't think that I'll be finishing 7th game today - I need to prepare some code for owrk on Monday as well. I will try however, and as always - keep you posted. Before I go, let's look at our the game list again

- [s]Shoot'em'up[/s] - done
- [s]Platformer[/s] - done
- [s]Puzzle game[/s] - done
- [s]Racing game[/s] - done
- [s]Dungeon crawler[/s] - done
- Strategy game.

Sweet!

And here is a list of the entries in the series:

Last Day summary and Challenge Post Mortem
Ludum Dare preparation
Day 6 summary
Day 5 summary
Day 4 summary
Day 3 summary
Day 2 summary
Day 1 summary
Series kick off

Ta ta for now!

## 7 games in 7 days, day 5 finished

Woah. After sleeping only for 3 hours yesterday, having been to dentist and visiting my landlady, I was facing a pretty big wall, and nearly dropped the challenge. However, I did pull through. After I've decided to use Commodore 64 style graphics for my project, I could feel the excitement, and was really enjoying myself. Using the 16 colour VIC-II palette, and non-square pixels is fun, even if annoying to draw by hand.

Today I was working on an adventure game. I have decided against 3D, and later on against most graphics at all. The game was to be fully text based, and I managed quite ok I think. I wrote a tiny parser with couple keywords, I wrote a decent room system. Sure, the item system is a bit of a hack work, the console isn't working properly, and most of the graphics are just placeholder. But the game is complete adventure (even if a very simple one), from start till end, it that really makes me happy.

With this, the biggest hill in the challenge is over - I've finished the week. Now it's weekend, and I'll have plenty of sleep, and plenty of time to develop.I think I'll add all the graphics sometimes next week, to have this working fully as intended.

Mini post mortem:

What went wrong?
-Well, haven't ever coded adventure game before, I had no idea how to properly implement inventory, and ended up with clusterfuck that I would very much like to purge with a fire.
-Not enough time. Again, due to lack of experience, I had to spend a lot of time looking things up on internet, and the fact that I didn't start before 10 pm, due to my schedule for the day didn't help at all
-Not enough sleep. Sure, the coding kept me alive and happy, but this is not a good long term way to spend time. I plan to sleep a lot over next two days, and code sensibly, not till the broad daylight again.

What went good?
-Graphics style. I really enjoy it, and it made me attached to the monitor, even if by all rights I should be lying unconcious right now.
-Type of game. I always was an adventure fan, and writing one for myself for the first time really made me happy. I could insert some of myself into the game, and even though the final product isn't as big or as funny as Lucasarts/Sierra games, in my mind it feels great, because of what it could have been.

Oh god, it's 6:50am. I really lose track of time when I'm enjoying myself while coding. Will need a lot of sleep to regenerate from that.

How are we looking game-wise? Let's see.

- [s]Shoot'em'up[/s] - done
- [s]Platformer[/s] - done
- [s]Puzzle game[/s] - done
- [s]Racing game[/s] - done
- Dungeon crawler
- Strategy game.

Oh right, here's the game.

And here is a list of the entries in the series:

Last Day summary and Challenge Post Mortem
Ludum Dare preparation
Day 6 summary
Day 5 summary
Day 4 summary
Day 3 summary
Day 2 summary
Day 1 summary
Series kick off

Good night, and have a nice weekend.

## 7 games in 7 days, day 4 finished

Well, this was another long night. First of all, I decided that the racing game will be inspired by Crazy Taxi/Quarantine. You'll be riding around a procedurally created city, with a VW Beatle taxi, picking up people and taking them to wherever they want.

So, at first I decided to learn 3D modelling with Blender, and woo, after some (well, considerable amount of) time, I got this far:

Well, once I got that far, I hardly could stop, now could I? After couple 2D games I have decided to finally test 3D, as there is a chance I'll be doing 3D stuff for the Ludum Dare. So, I have spent the better part of the rest of the night trying to get car to properly work, but it's been rolling every time I turn. After browsing the nets (I have never actually done car code myself), I found out that it needed roll bars, and suddenly it was working, sure, a bit jerky, but working.

It was bit late though, so I haven't added any gameplay, but I do enjoy riding around the city. Damn, I love procedural worlds. To be honest, I could spend couple more hours working on it. Hell, I could spend couple more months improving on the city and the ride. I really feel like writing a game based on that. For the purpose of the warm up week, I call it done: I have done some basic work with Blender, some procedural cities (really basic, but still), and set up car physics for driving in 3D. But for now, it's 4am, and I have lots of work to do, and have to grab a bit of sleep.

So, here's the city. You can drive around it for a bit, but there's nothing to be seen.

State of the list is as follows:
- [s]Shoot'em'up[/s] - done
- [s]Platformer[/s] - done
- [s]Puzzle game[/s] - done
- [s]Racing game[/s] - done
- Dungeon Crawler
- Strategy game

Next up, either Dungeon Crawler or Adventure game. I'll be really having a busy day (and by the time I'm writing THIS part, it's 4:40), so I need to pick the one that'll take less time, to leave the longer one for weekend. I think I'll go with single-room adventure or somesuch.

That's about it for today. Nighty night!

And here is a list of the entries in the series:

Last Day summary and Challenge Post Mortem
Ludum Dare preparation
Day 6 summary
Day 5 summary
Day 4 summary
Day 3 summary
Day 2 summary
Day 1 summary
Series kick off

## 7 games in 7 days, day 3 finished

Day three finished! Today I have, as planned, did Puzzle game. A classic one indeed - Tetris. My goal for today was to recall how transitions between Scenes in unity worked - and I have done as much, dividing the game into Splash Screen, Main Menu and Game View - and custom GUI, which I have also achieved. After that it was simple implementation of the gameplay, which although simple, gave me some problems, due to switching between implementations in the middle. There may be some bugs due to that, but I'm not going to bother to look for them, my goals were achieved.

I didn't want to waste time on creating fancy level, so I took the same graphic that the blocks use, constructed wall out of it, and had it cycle through Hue in HSV mode, the effect is quite funky.

I haven't implemented High Score, which in the middle of the game creation I thought that I could implement, because my 8 hours were up. Still, I will do it for some other game.

The game is here, controls are arrows for the game, and escape to quit from any scene to menu.

Also, if you'll look at the screenshot, you'll notice how freaking awful my luck is. How many times in a row can you NOT get I-block? GAH!

State of the list is as follows:

- [s]Shoot'em'up[/s] - done
- [s]Platformer[/s] - done
- [s]Puzzle game[/s] - done
- Racing game
- Dungeon Crawler
- Strategy game

Next up, racing! Woo!

And here is a list of the entries in the series:

Last Day summary and Challenge Post Mortem
Ludum Dare preparation
Day 6 summary
Day 5 summary
Day 4 summary
Day 3 summary
Day 2 summary
Day 1 summary
Series kick off

## 7 games in 7 days, day 2 finished

Second day of my challenge finished. I have done a simple 'run to the right, press button to jump over obstacles' game. I didn't have that much time today, so I'm finishing my day at 2:40 am. Not that great, need more sleep.

Today there was a lot of drawing (animating the main character - squirrel, drawing tiles and objects). It wasn't that hard, nor did I try really really hard, but it ate about half of my work time. I don't think it's that awful, for the time spent and my utter lack of drawing skills. I quite like the ground tile, and the Squirrel animation ain't that bad.

First code was the parallax effect/level display. It was done by dividing objects into 3 speed groups, with front one moving fastest, and the furthest away one moving the slowest. Quite standard stuff. Then I took my tiled animation of the squirrel, and wrote quick-and-dirty sprite animation system. I have noticed that the scaling produces some ugly results, and causes some animation frames to 'bleed' into another one. But honestly, it's good enough for now. After that was done, I've plugged in Rigid Bodies everywhere, and was good to go. Couple collisions added, one particle effect for fancy death, and the game was done.

It's here if you want to give it a go. Control/Space Bar jumps the squirrel. There aren't any other controls. Try to survive as long as possible and eat acorns as you do, for more points.

State of the list is as follows:

- [s]Shoot'em'up[/s] - done
- [s]Platformer[/s] - done
- Puzzle game
- Racing game
- Dungeon Crawler
- Strategy game

Next up, Puzzle game. It'll most likely just be Tetris. But hey, a game is a game is a game is a game. And I bet I'll learn something new.

And here is a list of the entries in the series:

Last Day summary and Challenge Post Mortem
Ludum Dare preparation
Day 6 summary
Day 5 summary
Day 4 summary
Day 3 summary
Day 2 summary
Day 1 summary
Series kick off

## 7 games in 7 days, day 1 finished

As I have mentioned in my previous post , I am preparing for newest Ludum Dare by making 7 games in 7 days, to refresh the knowledge of tools I will use. Day 1 has just ended.

So, I launched Unity for the first time in loooong time, and wrote a game! Complete game, with dying, points and score even!

It's just a poor clone of Asteroids, but it's good enough for my purposes. Recalled plenty of functionality, played around with couple new ones, but 8 hours have passed and it's time to close for today.

I took mesh game objects, added 2d nearest neighbor scaled textures, added Rigid Bodies for collision, and most of the game was set up. Put there some basic spawn/destroy logic, some sounds, and called it a day.

Tools used: SFXR, Graphics Gale, Paint.NET (I have absolutely no idea how to make pixels transparent in Graphics Gale, and that bugs me a lot, as the tool is great for pixel art. after drawing my objects, i then loaded the PNGs within Paint.NET and magic wand + deleted the pixels away)

The game is here if you're curious, just don't expect anything amazing.

State of the list is as follows:

[s]- Shoot'em'up[/s]- done
- Platformer
- Puzzle game
- Racing game
- Dungeon Crawler
- Strategy game

Tomorrow I may save more pictures in progress, so that there's more to see.

And here is a list of the entries in the series:

Last Day summary and Challenge Post Mortem
Ludum Dare preparation
Day 6 summary
Day 5 summary
Day 4 summary
Day 3 summary
Day 2 summary
Day 1 summary
Series kick off