Clockwork Brains

Software degradation

2011-09-18T21:49:00.002+02:00

Do you still remember BSoD (Blue Screen of Death)? In the times when Windows OS crashed because software was unable to handle hardware failure, users were cursing software developers for bad product. But has anything changed since then? Are there any new technologies to gracefully handle failures and avoid user disappointment? Or perhaps software developers have matured and never ever release programs that simply don't work?

We're tightly surrounded by technology these days and whenever I'm about to buy a new item I wonder if it will have a microprocessor and software running on it. Recently I've upgraded my TV from CRT to LED and, guess what, - now it's called "smart", which probably means I am dumb compared to it. And before TV there was smart phone, smart oven and I see there are coming along smart cars, smart robots, smart nano-medicine, smart prosthetic limbs...

And I wasn't so surprised to find out how buggy smart devices are - I've spent nearly a week trying to configure my laptop and desktop PC to stream media files to the TV. On the way I've seen my HDD disappeared from the drive list, then TV just rebooted (probably software crashed) and many more glitches that made me rip my hair in desperation.

Software is complex and there's no reason to believe it will get simpler any time soon. Actually complexity cannot be reduced, it can only be changed in form, or moved to another place by introducing abstractions. Testing can cover only main scenarios plus few alternative and error scenarios, but typically one simple user can think of use case that no tester has ever dreamed of. There is a paradigm known as "crash early", that basically states that one should never try to handle an error if origin of this error is unknown. Sooner or later software encounters unexpected exceptions that are not handled because there is no code that knows how to handle it, and program crashes (hence the name of a paradigm is "_crash_ early"). Paradigm is good for debugging, but really frustrating for a user, and that's why some software developers decide to catch all errors and silently ignore them. Perhaps that's even worse, because errors happen for a reason, and user can get even more upset when he's clicking on button but nothing happens.

So, what will happen when software approaches infinite complexity? I hope we never do reach this point, but if this fate is unavoidable, then I suspect software development as a concept or technology will cease to exist. It's hard to imagine what comes next, I foresee a kind of "smart components" capable of decision making and self-testing that would interact with each other to build algorithmic system to solve defined problem. Perhaps a next generation neural-networks or self-aware computer systems?

I definitely know one system of infinite complexity - it's our universe. Can you imagine a software system that would make this universe run? ;)

No more paradoxes for ya, old man!

2011-04-29T14:14:00.000+02:00

"Science is beautiful and if you don't like it - f*ck off!", R.Dawkins

Once in a while I like to contemplate on highly useless things, 'cause I think that's fun and feeds human curiosity. Oh well, let's roll out sc-fi classics - time traveling!
Talking about time traveling, there are many speculations on the mechanics and physics of the process that lead to certain paradoxes and the problem is, that one can't be sure which way it works - 'cause there are no observable evidences of time travel to the past. What's been troubling my mind recently, is grandfathers paradox (I wonder why it's not simply a "fathers paradox"?), which says that if one travels back in time and slaps his beloved grandpa with a "Quantum physics Vol.I" so hard that poor fellow loses interest in proceeding with his life duties, let alone having children, then... what would happen to the time traveler? Would he still exist? Well, he just broke his heritage line, didn't he?

As a computer science expert I see a problem with this paradox explanation, - there should exist some complex information processing mechanism to remove time traveler from universe (and his father and children if any), once his grandfather has been eliminated. And how would particles forming his body cease to exist? Just simply pop out of existence? But these particles are not special, they just happen to be so lucky to get into one place and build time travelers body.

Alternative explanations, e.g. parallel universes/timelines and Novikov self-consistency principle doesn't look too promising either. Well, they explain the paradox, but then bring serious task to explain how they work at information field level.

So here I come, one more speculation to explain time travel paradoxes. It is often considered that time is a fourth dimension of space-time continuum, however there's one main difference between Euclidean dimensions and time - all known particles are moving only forward in timeline, but they can move in any direction in space. To be very precise, timeline direction points towards increased entropy, which brings us to a finding that traveling backwards in time reduces entropy. Stephen Hawking has kindly explained all this in such a style that even dummy physicists like me could grasp the idea. And I make a conclusion here, that if time traveling to the past is possible, then either information field should memorize life-time of each particle in the universe (that's about 13.6 billion years!) or there exists a mechanism to move particles backwards in time. And again - the first way has problems to store gazillions of information, and the other one has to deal with uncertainty principle somehow. Or maybe when time is moving back, there's a symmetrical "Certainty principle" that can state where and how particles are returning? These are the weakest parts in my theory, but if somehow they survive, I shall continue with my idea.

I find that traversable wormholes are most realistic (but still theoretical!) time traveling "devices", so let's illustrate how it works when time traveler enters mouth of the future wormhole. For simplicity I'll assume that time traveler is an elementary particle.

Click images on the left to enlarge basic scenario: particle advances forward in time and gets into future wormhole which reconnects with space-time some-when in the past, and the particle gets out just to see itself still traveling towards future wormhole mouth. At this point we two instances of the same particle at the same space and time region, which is basically the reason why grandfather paradox may occur: if older instance of the particle hits the initial particle, and it changes motion path, it won't enter the future wormhole mouth, so what happens to the older instance of the particle? Two clone particles exist now in the universe! If we keep repeating the process, it would multiply particle clone count beyond infinity (imagine what would happen if you put money into wormhole - woohoo!) and puffffft - law of conservation of matter is gone. Just like that. If there would be any natural future-to-past wormholes of reasonable size in the universe, then this described matter-bloat would be easy to notice.

So, I made an assumption here - what if time traveling particle does not meet itself in the past and how could it happen? To illustrate I need another particle (the red one in the image on the right) that exists alongside time traveler particle, but does not enter the wormhole. Here's what red particle observes: both particles hang out around and then suddenly blue particle "disappears" in the wormhole. And the blue time traveler particle observes that red particle is sticking around, until wormhole approaches. Space-time starts bending and time traveler is seeing how time slows down for red particle (similar effect can be observed close to the massive body, like a black hole). At some point time for red particle stops (when wormhole timeline becomes perpendicular to the main timeline) and then is reversed - red particle starts moving backwards. However, note that unlike when moving forward, now it is moving alone - time traveler is in the wormhole moving forward in local space-time frame. At the end of the journey time traveler exits out of past-wormhole mouth and finds out that only red particle is here. That's it folks, no more clones and paradoxes!

So, that's particles. And how about human time travelers? The more I think of it, the more fun it looks. While time traveler is in wormhole, his absence in main timeline causes effect that looks like some eraser is removing a person from existence. The more he travels in the past, the more of his life is "erased". People are still remembering this person, shaking hands with empty space when greeting and looking at the photos of someone who will be erased soon. Okay, that looks weird, maybe even creepy :)

Post factum. It took me a week to write this post, so now when I look at it in the end, I'm pretty much convinced that traveling via wormholes is not possible at all...

Six legs - more power (Part I)

2011-04-17T15:26:00.000+02:00

This post is dedicated to special kind of robots, - hexapods. Literally it means "six legged" robot, and I bet you imagine bug- or spider-like mechanical walker that is hiding under your bed and has come to claim your soul...

But there is another kind of hexapod robots, that have less scary looks and are supposed to be very precise. Yes, I'm talking about Stewart platform, a six-cylinder positioning device. The most surprising is that they have very simple closed-form mathematical solution to the inverse kinematics (IK) problem, that is usually a hard nut to crack for regular joint-robots. But this advantage comes at a cost - the forward kinematics (FK) solution is a real challenge for your math skills (and again - FK is a piece of cake for joint-robots).
To remind what is IK and FK, I'll provide an example:
suppose you can figure out exactly the position of each part of your body, and by position I mean rotation angle (because humans don't have telescopic joints :) - something like "my upper arm is rotated by 45°, lower arm by 15°, palm 5°..." etc. up to the very last bone of your finger. By the way, it's called "End effector" - the very last part in kinematics chain. Assuming that you know exact length of each of your bones and applying some math one can figure out the exact position of finger-tip in space. This solution is called forward kinematics in robotics world.

And now, as one can simply guess, inverse kinematics does just the opposite: suppose you want to use your finger to say.. pick your nose (yuck!). You know exact position of your nose, and you still remember exact length of your bones. The question is, how do you know what force of muscles you should apply to rotate your bones into positions so that end effector hits your nostril? One can easily guess, that there are many solutions to this problem and that's why there is no simple answer.
Luckily for us, humans, we're equipped with many-thread processing unit called "brains", that have evolved an astonishing approximation algorithm - just think how professional basketball player is capable of real-time body coordination to make a three-point shot from a distance! Yes, approximations and data from zillions of sensors - that is receptors - are working in a clockwork mechanism to deliver you a flawless nose-scratching service.

And how about robots? Well, approximation algorithms exists, but on top of that one needs additional layer of rules how to pick a solution from set of available ones. Sometimes it doesn't matter, consider that you're trying to push a light-switch on the wall. Do you really care which way finger touches the switch as long as the light goes on? You don't, unless the switch is broken with plain wires sticking around and a slight mistake would electrocute you.

In the past ten years I've been working with hexapod devices to precisely position patients in 3D space. But up till now I didn't know how controller calculates IK and FK problems for the Stewart platform, my software simply pushed end effector targets and that's it. Recently I've started doing a research on mathematical hexapod model, still hoping to find simple solution for FK problem (do I have to remind why I've miserably failed? :), and came to a conclusion that FK is rarely needed for hexapod device. Especially real-time FK. Usually robot controller application needs to know cylinder positions when end-effector position is known, not the other way around. I'm not gonna drill down to the technical details now and will explain the math in Part II next time.
As for now, enjoy the walker show:

Article references:
Kondo Hexapod
Rubedo Sistemos

Mindstorms robot has arrived, humanity gets one step closer to extinction

2011-03-13T14:22:00.000+02:00

So here we have it - the ultimate toy of all geeks and robotics fans, the Mindstorms NXT 2.0. The kit comes with 3 servo motors, four sensors (ultrasound, color, touch), 32 bit programmable microprocessor and a whole bunch of LEGO building blocks.
Along with the kit we've got a CD with visual editor to write programs for the microprocessor (the unit is called LEGO brick - the size of it is really "bricky" ;). It doesn't look complicated to program with this editor, but still the result has limitations - the program is compiled and uploaded to bricks internal memory (something like 256kb). So, I'm looking forward on using Microsoft Robotics Studio via Bluetooth, that should open a whole new dimension of features.
The first task on our list says we need something simple, that is able to hold a tool with markers and move this tool along predictable path. Well, maybe next item on this list should be something more destructive, like for example a battletank? ;)

Beercan robot

2011-02-13T11:55:00.000+02:00

Just came across Sandy Sanderson's page who has a hobby of making cars from cans. The result is quite amazing, check photos and the making process!

This brings me an idea to make some kind of a robot out of cans. Well, not that it could move or something (or maybe he could?), but sculpture or dummy. I guess I'll start with 3DS Max modeling or WebGL rendering anytime soon..

Robots, Software and Beer

2011-02-12T16:18:00.001+02:00

I've been regretting to see "Clockwork Brains" blog covered in thick dust layer, so finally here I am - back online. Thinking 'bout reorganization now and how to use this blog for general topics on Robotics, Software development in general and, of course - ~~Beer~~ The Fun stuff of mechatronics world.

"Plyushkin Syndrome" project is history, but I hope to have new projects, and whenever possible - reincarnate our lovely bot.

So, stay tuned!

Plyushkin Syndrome 1.1 is out!

2007-11-17T10:16:00.003+02:00

Yes, finally it was announced on Indago contest.

----------------------------------------
Download Plyushkin Syndrome 1.1 (23MB),
----------------------------------------
Happy playing！

Minimum system requirements.

* Windows NT/XP/Vista with .NET 2.0 Framework and DirectX 9.0c
* 64 MB video card.
* 512 MB of RAM
* Pentium 4 (2400 MHz) or analogous machine.

Recommended requirements.
* Windows NT/XP/Vista with .NET 2.0 Framework and DirectX 9.0c
* 128 MB video card.
* 1024 MB of RAM
* Pentium Core2Duo.

If you experience performance problems, it is recommended to quit all other memory-hungry applications before running Plyushkin Syndrome and reduce screen resolution to 800x600 (that will automatically reduce mirror resolution and give you extra FPS).

Use default configuration if you experience crashes. We are sorry about that.

Sitting and waiting

2007-11-08T09:58:00.000+02:00

That's the current status. Demo has been polished and presented. 9 projects will compete in the finals for the right to challenge best Latvian project.

Meanwhile I have discovered a few post factum crashes in our demo if engine is misconfigured. I feel sorry about that and suggest to use engine configuration utility only if the game doesn't start, otherwise use in-game options dialog to configure video resolution etc.

Also, after demo 1.0 release I've heard complaints about keyboard configuration and carefully thought about it. Still I find it more convenient to bind up/down actions to W and S keys, while keeping Right/Left mouse buttons bound to forward/backward.

I'd like to inform those who are out of context that demo will be available for download anytime soon and you'll be able to vote for your favorite project at www.games.lt .

Week #X: the end draws near

2007-10-22T14:42:00.000+02:00

Weeks of silence passed and now we are ready to announce final development phase. We could not present demo 1.1 version in public because INDAGO contest authorities requested to keep it secret until the 1st of November, when voting will start.
Thus we're still allowed to show screenshots. So here we are, probably the very last screenshots presented.
Good luck to other contestants and see you all in next stage!

Britney Spears in Trouble

2007-10-11T14:25:00.000+02:00

Ok, actually I do not know much about BS, but our team really has some trouble. Yesterday, after some malfunction in power supply line, our nightly build and svn server went down and now it is on the way to the PC's heaven ... Good news is that our HDD was not damaged and all data is safe. I hope the only damaged part is PSU and we will restore our development sever. In any case I believe we will finish our tasks in time!

Week #17: Every working program has an even count of bugs

2007-10-05T08:43:00.000+02:00

This time no major feature updates or anouncements, only a few interesting screenshots from debugging session. Kind of modern art, huh? :)

I know I know - beta version should have been released already according to plan. But missing the deadline by a week or two is not a tragedy I think, we have estimated that risk too.

Week #16: Game Over

2007-09-26T20:17:00.000+02:00

Yeah, well "Game over" doesn't mean we've abandoned our project. On the contrary - all major features have been completed and we've entered bug fixing and polishing phase! Just a few moments ago I've committed some AI fixes into repository and now enemy robots are staggering around the map and chasing poor Plyushkin69... Seeing their funny postures brings smile on my face - that's the view worth waiting for :)
Ok, now summary of remaining tasks. First thing is to fix few annoying bugs that would make me blush if anyone else would see them. Then we launch another demo - 1.1 beta and wait for feedback.
Next I plan to announce a contest of making demo maps. Easy to do - simple 2d text files just like ol' good Lode Runner maps. The best ones will make it to the final version and will participate in INDAGO! ;)

Week #14: crazy funny and sexy adventures in space

2007-09-11T10:55:00.000+02:00

"So what kind of background music you prefer? Kind of relaxed ambient or what?" - I've been asked by DJ Jonine.
That was the right moment to think again about project goals and art direction...
"Let it be a crazy and sexy adventure in space." - I've said. - "After all our bot has malfunctioned, right? And it also carries number 69".
Can't wait to hear the final version, cause intermediate results are very promising :)

Once again, back to StarWars episode in the sky. This time I've updated screenshots section
with rendering of textured XWing and TieFighter models. Please note that renderings performed in 3D Studio Max, but you can get the idea how it'll look in the game.

Week #13: Summer is over

2007-08-31T11:38:00.000+02:00

Yes, sunny days are over and it's time to boot up our bots that have been shut down for maintenance during our vacation. I have a bad feeling about INDAGO as I haven't heard a thing from contest authorities since middle of June. And it's only 3 weeks left till beta version. Pity...
Nevertheless we'll try to finish our project. Good luck to our competitors (btw where are they? :) !
---
Picture source

Week #10: Plyushkin Syndrome demo 1.0

2007-08-13T16:37:00.000+02:00

Just like I've promised, demo 1.0 is here. A few things you may be interested in before downloading:

Minimum system requirements.

Windows NT/XP/Vista with .NET 2.0 Framework and DirectX 9.0c
64 MB video card.
512 MB of RAM
Pentium 4 (2400 MHz) or analogous machine.

We cannot tell recommended requirements as they are not confirmed yet.

Also check screenshots section for updates.

Disclaimer: at this stage game is not finished and cannot be played. One can start application and have a look around but don't expect any enemies chasing you. Climbing up/down also is not implemented. We promise to remove GUI and sounds re-used from NeoAxis in the final release.

Week #9: may the Force be with you

2007-08-06T09:05:00.000+02:00

No, we're not making Star Wars shooter yet, although I believe it would be pretty cool. According to our vision, we planned to launch an epizode from this movie in the background of the game. So last weekend I've spent playing around with XWing Starfighter model and tried to make it orbit around space station in random paths. With all my experience in 3D I still have learned it's quite tricky to program such a behavior using only roll and pitch controls of the ship and in the end I still got no result - either my XWing flew away into space or started orbiting very slowly with sudden turn-arounds. Maybe I should have preprogrammed random Bezier curves or even made it orbit around station in regular rotating circles.

---
XWing picture source

Week #8: demo 1.0 milestone

2007-07-31T10:01:00.000+02:00

So, last sunday we've hit our "Playable demo 1.0" milestone. Actually it's not so "playable" as one may think - there are no enemy bots runing around, nor bricks can be destroyed yet. But we have already dynamic environment, a gigantic space mirror and static maze, where our P69 bot can run around and observe surroundings. Pretty cool! :)

In two weeks I plan to release demo 1.0 public, so stay tuned. Meanwhile we're continuing on our next development stage - demo 2.0, - and mostly concentrated on gameplay issues.

Week #7: Houston, we have a... space station?!

2007-07-22T22:23:00.001+02:00

Unusually productive weekend: 11 tasks out of 19 completed. Following feature roadmap we're approaching demo 1.0 milestone. I assume public release of this demo will be available within 2-3 weeks, but some screenshots are already available. Most of them are experimental shots, you will notice Plyushkin wearing old rusty texture that has been rejected.

That thing in the sky is a space station, with a maze in the middle docking station (not presented in the shot). As you may notice, the shape differs a little from initial concept.

Week #6: dunkles weizen

2007-07-19T13:52:00.000+02:00

Yeah, spending a few days in Germany becomes very "dunkel" because of all the weizenbier. Nevertheless I insist you should taste german wheat beer even if you're not a beer-lover. Especially the dark one.

No wonder Plyushkin Syndrome progress has frozen - it's the very middle of the summer and everyone is out of town. Similar situation can be observed in other INDAGO projects. We still have around 19 tasks to complete till end of this milestone and I have a strong feeling we will miss the first deadline. This weekend I'll take a decision if we should make first demo release public or only a few screenshots would suffice.

One of the key elements in the game - a side mirror - is nearly completed and I hope to start performance tests soon. Another important feature, a dynamic maze loading, has been "lost in translation" somewhere between SDD and NeoAxis Map Editor, and became a static one.

Week #4: to walk or not to walk?

2007-07-03T14:26:00.000+02:00

As you reach a stage of development when something already looks decent, lots of ideas start storming in your head - I can imagine this-and-that would look really cool in our game. But that's the problem - if you want to make it all, you will make nothing and it's time to choose. Especially when time frame gets tight.
One of the most recent dilemmas: should environment map be some techno-style space or warehouse-like place filled with cardboard boxes? We've received a few sketches from an artist, who suggests to make Plyushkin look like an abstract creature made of cardboard boxes - I really like this idea, 'cause it perfectly fits the spirit of our hero. But on the other hand having only few weeks till first demo release is a bad decision to make a 180 degrees turnaround and remake the concept. Most probably we will make intermediate choice and take best parts from both art directions.
Meanwhile I have developed textures and walk animation for "Plyushkin Bot"- the two most difficult tasks for my skills - it's programmers art, you know :)
What do you think If I'd replace this old metal texture with cardboard material?..

---
Cardboard picture source

Week #2: birth of the Bot 69

2007-06-26T07:26:00.000+02:00

Long weekends ain't for working, right? I wonder where I've lost my time, most probably I was looking for fern-blossom...
Ok, back to PS - here I have a few screenshots of our untextured garbage bot model. Follow the Screenshots link on the right menu to see more bot creation pictures in full size.
Not so much of a progress since last week, but I'm still happy that we already have regular builds (Cruise Control). In the upcomming week I will spend only few hours working and most probably there will be no updates.

Week #1: challenging NeoAxis

2007-06-15T22:49:00.000+02:00

"A hammer?" he asks. "Nobody really buys hammers anymore. They're kind of old fashioned."

Why I hate frameworks"

The first few steps may be vital for the project and one must take care when selecting tools and technolgies. Last weekend I've spent fighting with NeoAxis Resource and Map editors, or to be more precise - with the lack of documentation. Followed by countless crying out loud curses and a couple of "Svyturys Draught" an ice brakthrough pleased my heart - by the end of Saturday I had a funny rabbit running around our first test map who managed to take control over our main character Garbage Bot "Плюшкин 69".

The Story
Oh yes, the story now. The idea is pretty much the same, just a few details on what's going on. The rabbit is a character from NeoAxis demo, so - deleted. Our hero, the garbage collecting bot "Плюшкин 69", has malfunctioned and now collects everything it happens to find on the street - cars, lanterns, scouting droids, TV sets, babies etc. Ok ok, I was kiddin' about the babies :)
The bad guys (or as it turns out from the story - the good ones 'cause they're trying to stop a bot that went crazy), are coworkers of Plyushkin, also bots - they are chasing player character around the maze, desperately wishing to shut him down.
Here are a few sketches of our garbage bot on the right.

The Place
At the moment our bot went crazy, he was working on the space station, so that's the first environment for our map. The surroundings and background has only minimal impact on the game play, thus it's more like an eye-candy for the player and a playground for artists. It was also a strategical project decision - we don't have to finish the environment modeling if we're short on time and that won't affect our project much.
Ok, back to the space station (SS) - made a quick sketch how to arrange maze and things. Center disk of SS is a place for our maze and has a floating side mirror. The outer disk rotates slowly around two axes and has attached various fancy-shmancy moving gadgets. A little higher in the orbit let's place a Soviet space station MIR, and maybe some episode from Star Wars - a famous scene of Tie Fighters chasing X-Wing (let's hope they don't do much chaos there, or else player will stop gaming and starts watching this fight :).
Yesterday I've spent a few hours browsing through Hubble Space telescope image gallery on the web and hope they don't mind if I borrow a few star images for background of the game.

Summary
This was quite a productive week, most probably because it was driven by fresh enthusiasm. I'm glad we've solved Issue tracking and storage problems (thanks to TeaMan and Borg).
There are a few critical tasks left for this milestone, but still many of normal priority. Most of the tasks are modeling and content creation.

Project Summary: Registration is over

2007-06-11T18:28:00.000+02:00

First milestone is completed - registration is over: there are 26 projects competing.

Last week was tough, and by "tough" I mean we didn't have much development time. Major tasks achieved - we have developed System Design, but then again - unexpected problems with repository and issue tracking system. We hope to fix these problems soon.

A few tasks still not finished: final framework setup, nightly builds and unit tests.

We do not publish any art-work or screenshots yet as current phase involved mostly set-up and modeling tasks.

Good luck to other contestants!

Great news everyone!

2007-06-08T20:26:00.000+02:00

One of our team mebers has decided to have more fun in his life (huh?), and well... the best we can do is to support his choice. As long as he can raise a bowl of beer together with his friends :)
Best whishes and warm congratulations to TeaMan!

Project Milestones

2007-06-04T16:38:00.000+02:00

Major milestones and deadlines:

End of registration (06/10/2007)
Playable demo 1.0 (07/29/2007)
Playable demo 2.0 beta (09/30/2007)
Final release (10/31/2007)

Project Summary: Week before registration ends

2007-06-04T16:08:00.000+02:00

Only one week remaining till the end of registration to the contest and I will shortly review our project status.
Main achieved tasks:

Selected development technologies. NeoAxis game engine powered by Ogre3D rendering engine will run our project.
Selected development tools.

Visual Studio 2005 (C#)
Subversion source control
Trac issue tracking system
Google docs for document management
Magic Draw for UML diagrams
NUnit for unit testing

Created System Requirement Specification document - a rough list of use cases we plan to achieve.

What still needs to be done this week:

System Design Document containing game architecture.
Set up application framework with stub methods.
Set up nightly builds.
Define unit test framework.

Shortly I also plan to post a few sketches - game characters and environment.

Projekto vizija

2007-05-13T17:17:00.000+02:00

Disclaimer: INDAGO authorities issued a requirement to present project vision in lithuanian language, so here it is. Original article can be found here.

Pagrindinė projekto mintis - atgaivinti seną klasikinį žaidimą "Lode Runner", tik vietoj dvimačio vaizdo naudoti trimatį ir išplėsti kai kurias žaidimo taisykles.

Retrospektyva
Pirmiausia prisiminsime pagrindines šio klasikinio žaidimo taisykles ir idėjas:

Žaidimo laukas yra plokščias dvimatis labirintas, primenantis nebaigtas statybų konstrukcijas, kurios susideda iš platformų (pastato aukštai) ir kopėtėlių. Štai pavyzdžiui toks labirintas:

Pav. 1. Lode Runner daugiaaukštis labirintas

Labirintą sudaro platformos ir sienos iš plytų, turėklai kabantys ore(skirti įsikibti rankomis) ir kopėtėlės. Kai kurios sienos ar platformos yra vienalytės ( nesugriaunamos).

Pagrindinis veikėjas yra valdomas žaidėjo (t.y. "gerasis vyrukas"). Jo užduotis yra lakstyti po labirintą ir rinkti aukso dėžes, tačiau reikia išvengti "blogiuku". Jis gali lipti kopėtėlėmis aukštyn arba žemyn, pasinaudoti turėklais, kad persikeltu per prarają, ir netgi išmušti duobę grindyse, jei jos yra iš plytų.
Blogiukai (robotai). Nerangūs ir lėti veikėjai vejasi gerietį po labirintą. Kai blogiukas įkrenta į duobę grindyse, jis lieka ten kurį laiką kaboti, o po to išsiropščia ir toliau bando pagauti pagrindinį veikėją. Tačiau išmuštos duobės grindyse regeneruoja - vėl tampa plytinės - ir jei robotas nespės iš jos išlipti - žus. Iškart po to nukrenta kitas bolgiukas iš dangaus į labirintą atsitiktinai parinktoje vietoje ir tęsia savo pirmtako darbus.
Aukso dėžės. Jos išmėtytos po visą labirintą ir geriečio užduotis - jas surinkti. Kai tik surenkamos visos dėžės, atsiranda kopėtėlės vedančios į dangų. Gerietis turi jomis palipti į patį viršų ir tada laikoma, kad jis laimėjo.

Naujos kartos Lode Runner
Taigi, kadangi turime trečią matavimą iškarto kyla klausimas - kaip išplėsti dvimatį labirintą iki trijų? Tarkime dvimatis labirintas pasidaro vienos plytos storio trimatis objektas:

Pav 2. Trimatis labirintas.

O kad būtų linksmiau, tegul žaidėjas mato visa vaizdą iš savo veikėjo akių (t.y. FPS - First Person View). Bet tada Quake stiliaus dvimatis žaidimas turi viena problemą - kaip matyti priešininkus, kuriuos užstoja sienos ir grindys? Klasikinis žaidimas turėjo vaizdą iš šono, tad žaidėjas galėjo vienu metu matyti visa labirintą ir strategiškai pasirinkti tolimesnius veiksmus. Taigi, pabandysim įvesti dar vieną patobulinimą - veidrodžius. Žaidėjas bet kuriuo momentu gali pasisukti ir matys viso labirinto atspindį šalia stovinčiame veidrodyje.

Pav 3. Veidrodis šalia labirinto

Pav 4. Kaip žaidėjas gali matyti labirinto vaizdą

Kiti patobulinimai
Papildomi patobulinimai bus įgyvendinti jei liks laiko. Planuojamos naujovės:

Animuota žaidimo aplinka. Labirintas ir veidrodis patalpinami į teminę aplinką - miestą, gamtos landšaftą, kosminę stotį ir t.t.
Žaidimas per Internetą ar vietinį tinklą su kitais žaidėjais.
Įdėti tikrą treciąjį matavimą, t.y. kad labirintas turėtu atšakų kuriomis galima vaikščioti ir į gylį
Dvimačiai labirintai susukti į cilindrą.
Kitokios blogiukų rūšys ir elgsena
Kitokie platformų ir sienų tipai (neregenruojančios grindys ir t.t.)
Įvairūs daiktai padedantys geriečiui (pvz. pistoletas)

Nuorodos
Lode Runner Wikipedijoj: http://en.wikipedia.org/wiki/Lode_Runner
Indago svetainė http://indago.puslapiai.lt

Project has a name - "Plyushkin Syndrome"

2007-05-12T19:27:00.000+02:00

After long discussions and debates (mostly myself with my reflection in the mirror) we've picked a name for our project - "Plyushkin Syndrome" or as we will refer to it often - PS. Here's a little description for the ones who are curious about origins of this syndrome.
Looks like the name fits our game - our "Good guy" is running around and picking useless stuff (i.e. gold crates). Just like real Plyushkin :)

Project vision

2007-05-11T11:40:00.000+02:00

Classics revisited. The idea of the game is to resurrect Lode Runner game in 3D and add new features that new third dimension can offer to us.

Retrospective
First, let’s recall the basic concepts and rules of this classical game.

The field of the game is a flat 2D maze, kind of a construction site with platforms and ladders. For example it looked like this:

Image 1. Lode Runner multi-platform maze

Maze consists of brick platforms and walls, ladders and hand-to-hand bars suspended in the air. Some walls or platforms are indestructible.

The main character controlled by the player i.e. the “good guy”. His task is to run around the maze avoiding bad guys and collecting gold crates scattered around the level. He can climb ladders up/down, use hand-to-hand bars to slide and even crush a pit in nearby ground if it was made of destructible brick.
Bad guys (the robots). Clumsy and slow characters chasing the good guy around the map. Once bad guy falls into the pit, he stays there for some time and then climbs out. But alas - pits regenerate after some period and if robot fails to climb out – he’s dead. Another robot falls from the sky at random place instantly if his comrade has died in the pit.
Gold crates. That’s the purpose of the good guy. If he collects all the crates, the ladder appears leading to the sky. His task is to climb up to win.

New generation Lode Runner

Now that we have third dimension, it brings us a challenge – how to extend the maze. We had a pretty nice 2D multi-store map, why not reusing it? So let’s consider our maze will be one brick-block wide 3D maze:

Image 2. Three dimensional maze

To make it even more fun to play, let’s make it a first person view. A quake style 2d game has one problem – how to see opponents if platform floors and walls are blocking them? The old game had side view so player can see the whole field and plan play strategy a few steps ahead. Here’s another trick we’re about to introduce in our fancy Lode Runner version – side mirrors. A player can take a look at any time to one of the side mirrors and observe current situation.

Image 3. Side mirror and the maze

Image 4. Character view from the platform to mirror

Extras
Other improvements will be implemented based on available timescale. These include:

Animated game environment and surroundings. Maze and the mirrors are placed inside themed environment – city, nature landscape, space stations etc.
Multiplayer mode.
Adding real 3rd dimension - some platforms may extend along depth axis.
Making circular maps i.e. 2D map is curved into cylinder
Different enemies and their behavior.
Different brick types.
Different bonuses and items.

References
Lode Runner on Wikipedia: http://en.wikipedia.org/wiki/Lode_Runner
Indago homepage http://indago.puslapiai.lt