ManTis

Members
  • Content count

    215
  • Joined

  • Last visited

Community Reputation

1025 Excellent

About ManTis

  • Rank
    Member
  1. 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: [youtube][/youtube] 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!
  2. 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!
  3. 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: 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. 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. 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. Holes: Holes or trap doors appear, you have to stay on the board. Snake: Normal board, but your speed increases, you can fall off the board. 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. 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. 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 Rubbing the dirt: like standard game, but instead of tile you just use your fingers 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!
  4. 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
  5. 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: [youtube][/youtube] 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!
  6. 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 Without further ado, 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
  7. Game in 7 Days, Day 7: DONE!...ish

    I actually thought about releasing it (at least for iOS), but I'll need to sit down with somebody that knows legalese to check if it's ok to release a game that's basically worms clone in different clothing. I'd love to put in some elbow grease (about 3 months worth of work I reckon), and turn it into a proper polished game.
  8. 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) -Exploding skull (grenade) -Magic punch (shotgun) -Deadly mixture (dynamite) -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 -Add music -Replaying match on same level -Pretty much everything from configuration menu -Hall of fame -Proper list of teams to choose from (don't create lots of teams ;) ) -How some weapons work (blowtorch being the biggest offender) -Special weapons would be nice -Voices in one pitch. I've never done any voice acting, and so the voices of the beardlings vary in pitch and speed a lot - I've tried to mitigate it, but there is a lot of noticeable differences ( compare "fireball" to "exploding skull" for example) -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
  9. slicer4ever: I got some time off at the work, so I probably will be working on 7th day progress very soon.   I know that not knowing the schedule is annoying, and I'm sorry for not working faster, but I just didn't have time earlier. I sometimes wish there'd be RSS feed that I could subscript for some blogs on gdnet.
  10. 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
  11. Off-road futuristic racing(yes, it exists!)

    Pod racing! :D
  12. 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
  13. Largest Fireworks Display World Record 2014

    Happy New Year! May it bring you a better laptop! :D
  14. End of year gas bagging

    It's amazing the amount of progress you have. And it's great that you keep coming back to the project, my hard drive is full of unfinished ones.
  15. 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) I've also added some navigation tools: Shovel. To get to those unreachable places. Currently the problem is that, unlike Worms, it uses your movement speed to progress, so when you accidentally point your shovel down, you're going to do a free fall while digging your own route to hell. This definitely needs fixing. Concrete slab. It can be used defensively - to protect your character from enemy shots, or to run away. It also can be used offensively, to create route to enemy or to guide weapons towards him. From coding perspective, this was a nightmare. Original Worms had girder rotating not only at 90 degrees, but at 45 deg increments. So, how would I solve it? First, find axis-aligned bounding box that contains whole concrete slab (or girder, as it was in the original), whatever its orientation is. Then, for each pixel on the map that overlaps with AABB, check if it's within tightly-packed oriented bounding box. If there is any, don't allow player to place the girder. If the map allows, place the block there by looking up each pixel from the girder based on coordinate and rotation. This is costly. Like, really costly. My solution for this is pre-drawing concrete slab in 4 positions (vertical, horizontal, and angled up-left to bottom-right and down-left to top-right), and use them as look up textures, to alleviate the calculations done on per-pixel basis. But for now, I've just used the horizontal and vertical positions, which don't need no calculations (also, their AABB is equal to their OBB, accelerating the collision checking process as well). That's it for today. Haven't added Skip Turn and Concede, as they actually need gameplay implemented to be used, and, most importantly, haven't implemented Ninja Rope. This one will be a biggie, and I hope to implement it before the 7 days is up, but I don't want to do it before I'm sure I have everything else done. Going back to these steps cost me one day, which means that probably Audio and GFX day will have to be merged. And as usual, all art is temporary, but concrete slab is really temporary, as it was done at 1am (when my usual sleep time now with kid around is around 9pm), and I wanted to just get it over with as fast as possible. I hope I'll manage to squeeze in Day 5 before the weekend, but we'll see. See you then! [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