Výměna ložisek v bruslích Rollerblade

Včera jsem si v bruslích vyměnil ložiska. Při jízdě brusle už vydávali nemožné zvuky, tak jsem nakoupil ložiska s tím, že to pomůže. Ložiska SG7 nejsou všechna stejná - ta nová lze alespoň rozebrat a vyčistit (na rozdíl od těch co jsem koupil s bruslemi). Pro výměnu ložisek doporučuji zároveň koupit i nové šrouby. Po roce ježdění a pravidelném otáčení koleček se některé šrouby roztáhli a nešly rozumně vytáhnout, nebyl rozumný nápad je vyklepávat kladivem a znovu používat. Nakonec dva šrouby nešli vyrazit ani vyrážecím klíčem (doporučuji originální klíč na brusle od Rollerblade - je sice drahý, ale pěkně padne do ruky a dobře se s ním pracuje), ale musel jsem použít lis a svěrák. Takže jakmile šroub nejde hladce vyndat, tak ho ihned vyměnit.

Samozřejmě jsem po výměně zjistil, že určité skřípání způsobují i kolečka, tak uvidím jak se projeví až je dojedu a vyměním.

Global game jam

Minulý víkend jsem ze zůčastnil malé zajímavé akce. Soutěže možná spíše hecu global game jam resp jeho místní buňky. Abych to vysvětlit, cílem soutěže bylo přemoci své limity a vytvořit počítačovou hru v krátkém limitu 48 hodin. Je zřejmé, že za tuto dobu mohou vzniknout jen jednoduché hry. O to víc mě překvapila kvalita her, jež byli nakonec v klání ukovány.

Ale abych nepředbíhal. Soutěž začla v pátek a tak jsem trochu unavený po celodenní práci vyrazil na křemíkový kopec vyzkoušet své schopnosti. Nejel jsem tam sám, ale s kamarádem, který se uvolil mi dělat grafiku a bral to též jako zajímavou zkušenost (sám je ostatně velký fanda do všech her).

V zasedací místnosti jsme si vyslechli organizační věci, téma a zkoukli motivační video se zívajícím japoncem (u kterého jsem měl správný pocit, že ho plně pochopím na konci soutěže). A pak začli vymýšlet...

Neřekli byste jak je těžké vymyslet originální a zábavnou hru (resp. něco o čem byste uvažovali jako o zábavném). V té chvíli si člověk plně uvědomí o čem je pozice herního návrháře, a že tento člověk není jen snílek, který neumí programovat ani kreslit a tak se rozhodl ostatní kybicovat. Po několika hodinách přemýšlení nám už jakýkoliv realizovatelný nápad přišel skvělý a začali jsme pracovat. Pak přišla noc, kterou jsme se rozhodli strávit na místě. Pár hodin spánku v umělém světle záářivek není odpočinek. Přesto jsme se ráno vzbudili s hrůzou co za tisíckrát ohranou trivialitu se to snažíme udělat.

A tak nastalo další přemýšlení, uvažování přemýlání. Kolem 10. dopolední jsme téma trochu modifikovali a řekli si že to zkusíme a začli opravdu pracovat. Druhou noc jsem strávil doma a celkem odpočatý hru v neděli v kvapném spěchu dokončil. Bohužel né vše se nám do hry vlezlo a něco jsme museli opustit. Celkově jsem však s naší hrou spokojený a na to že vznikla za 2 dni můžeme být právem hrdí,

Na konci jsme byli velmi příjemně překvapení, že úroveň her byla srovnatelná a že jsme nezapadli. Do budoucna se plánujeme soutěže účastnit znovu, protože mimo únavy, bolavých zad ze židle a unavených očich od monitoru nás hřeje pocit, že jsme udělali něco pěkného.

Na závěr bych chtěl ještě zapsat co jsme si ze soutěže odnesli pro příště.

Nápad je to nejdůležitější a příště budeme více odvážní. Hra je cenná kvůli nápadu protože ničim jiným nejspíš zaujmout nemůže a hratelnost je bonus, pokud se vše vydaří. Nebylo dobré se začátku omezovat představami o tom co je hratelné a co ne.

Dostatek kvalitního spánku je rozdíl mezi zombie vývojářem trčícím nad rozdělanou hrou a produktivním člověkem. Za neděli jsem naprogramoval podstatnou část hry a to za daleko kratší čas, jelikož jsem byl odpočat.

Znalost platformy je důležitá, v časovém kvapu se některé věci prostě nedají řešit - nás například nepříjemně překvapilo, že jsme neuměli přehrát muziku, kterou jsme ke hře vytvořili a, že se postavení windows distribuce hry zaseklo na několika problémech s knihovnou SDL_mixer. Exe soubor s hrou jsme vytvořili až po soutěži.

Distribuce hry je u malých her rozhodujícím prvkem toho, zda si hru někdo vyzkouší. Pokud se hra musí stahovat, rozbalovat nebo do konce instalovat je to problém. Tato nevýhoda při velkých hrách mizí. Příště by to chtělo pracovat buď ve flashi nebo javascriptu.

Zvuk je 50% hry, bez zvuku je hra plochá a hráč se do ní tolik nevcítí. Je chybou šidit hru v tomto směru. (spíš člověk odpustí jednodušší grafiku)

Rozdělení práce na hře není rovnoměrné. Je velmi těžké rozdělit si práci rovnoměrně mezi různé profese. Zatímco já jako programátor jsem se cítil pod tlakem deseti atmosfér kolega grafik/zvukař pracoval v klidu a pohodě. Zároveň je náročné koordinovat vlastnosti hry, potřebná doprovodná data a program. Zde je velká výhoda předchozích zkušeností.

Poslední radou je: nebuďte na sebe moc tvrdí, cílem je něco vytvořit něco se naučit, trochu se pobavit a ne změnit svět. To tvorbou hry za 2 dni opravdu nejde.

Sorting with registers

Previous post was about sorting with no advanced functionality, which robot Emil also provides. I tried to rewrite it using memory registers and functionality for checking the height of stack of bricks in front of the robot. The result is terse and almost look like any procedural programming language. Take also a note to function CheckLength which returns value in special register called Counter (only register which can be used for function return value).

Bubble sort in Robot Emil which uses memory registers

Hey robot, sort this!

How to sort in Robot karel? Sorting algorithms are necessary part of any beginner programming lessons. Robot karel is educational programming language in which you control an robot, which can turn left, right, do steps, place bricks from nowhere and pick them up. The robot can also check if there is a wall or brick in front of him. Program structure contains repeating, checking for condition and repeating while some condition is met. So robot is only something like the Turing machine with two dimensional finite tape. The inner state of robot is only represented by instruction position in robot program. I have used extended version robot Emil which is able to stack brick on the floor, so it is possible to more easily organize memory.

In standard programming language bubble sort is quite easy algorithm e.g. in python it can be expressed like.

a = [3, 7, 6, 5, 1, 2, 0]
N = len(a)
while True:
  is_sorted = False
  for x in range(N-1):
    if a[x] > a[x+1]:
      a[x], a[x+1] = a[x+1], a[x]
      is_sorted = True
  if not is_sorted:
    break
print(a)

Robot Karel is nothing like standard programming languages even x86 assembler is more advanced (processor has registers and a lot more instructions). So how to sort in it?

What are basic operations?
Comparing numbers, Swapping them..

The environment has two biggest disadvantages:
All memory is global and you have to make sure that some util will not overwrite something.
All addressing is relative, it is possible to store where have you been (usually by placing brick on some possition and going to a corner of a room, but it takes time).

Biggest strugles
Swithing columns is quite easy. Comparing columns is not. Because robot can see only if is a brick in front of him or not, but not their count. Comparing columns of bricks has to be done by removing brick from them so it is destructive. So we have subtask of cloning columns. Also all conditions in the program are atomic, therefore robot has to go to the right place to test it and even if the condition will fullfill the robot has to return back. So there is lot of moving. Program contains procedures, but there are no parameters and return values, so everything has to be stored on the room floor.

Cloning columns
Checking the height of column is also destructive operation, therefore robot has to enlarge two columns for each removed brick and one column move back to the original position.

Column comparsion
Robot removes bricks from each column until one column is empty according which it will clean used space and put or not put the brick on the floor. Then it only checks if the brick is on the floor and if so, it will swap columns.

Testing of ending condition
If the whole sequence was gone trough and no columns were swapped the algorihtm should end. Therefore if there was some column swapping robot will pull the brick on the floor and after each checking it will check if there is some brick from the previous step and moves it to the next position. When the robot reach the end of sequence it can decide according the brick by him if in the whole cycle was some swaping or not.

Memory representation
The sequence is in the first row the sequence is long as the floor minus one. One column at the end of room has to be free, because the robot cannot travel trough columns heigher then two so it has to goes arround them (and thanks to memory our representation has to have place trough which can go around for the last item in the cycle). Second row is used for robot movement and placing the bit brick, for checking if some swapping was done. Third row is sometimes used for storing result of comparsion and othertimes with other columns for other operations like for swapping and comparing columns. The robot uses columns in these rows relative to his own position.

The program source code