DGD02 Complex systems

DGD02 Modelling Complex Systems

Dounia Bourjila S092488 Assignor: M. de Graaf Industrial Design B3.2

Technische Universiteit Eindhoven 4 April 2012

CONTENTS

- INTRO

- THEORY

Introduction Problemdefinition Real life situation Simple Rules Hypothese Iterative process Systematic parameter study Conclusions

- APPENDIX

INTROOur world and surroundings are charged with a lot of complexity, which can be found in the creations of na-ture, or of us humans. Complex systems consist from certain patterns that lead to certain resulst. To under-stand the total one needs to understand the simple rules from which this system is built up.

The previous counts for central systems where all leads to a certain predictable result, whereas in de-centralized systems the result is sometimes supris-ing. I chose to into the subject of understanding and mod-eling complex systems, to be able to get a better un-derstanding of our surroundings and human behaviour for example, to be able to explore and walk trough a pattern from the beginning to end, and at last to test a concept which is related to my project. I have worked with decentralized systems before, in a B1.2 project, where I was inspired by the patterns of

flocksofbirds.Iwasfascinatedbythefacthowun-predictableandvariatedtheshapesoftheflockscanbe, and I tried to copy that into a game that I created for children. The fact that the system seemed to be-come a ‘person’ (it didn’t seem it was programmed) with it’s own conciousness and decisions, made the game for the children challenging, playful, innovative and never boring (like other games).

REAL LIFE SITUATIONThe idea is to create a model that is triggering and adaptive towards the user, so he can learn to re-spondfastertotriggersandgetintothis‘flow’whicha boxer needs to deliver the best performances.So what I want to design in a hanging punching bag with patches on it that have to be hit by the boxer/user. These patches light up one by one at a certain speed. The patches can be seen as agents with sim-ple rules, and the user the ‘agent’ which the model is triggered by. Both parties interact with each other

THEORYINTRODUCTIONThe examples we got so see about decentralized systems in nature inspired me a lot for making new designs, but what I was looking for was the complex-ity of human behaviour explained.

I decided to relate this assignment to my project, where I am exploring human responses in the context of boxing. I am designing a responsive and adaptive feed-backsystem for boxers. I would like to know explore the best way to trigger a boxer to give his best punches, to stay challenges, and to get a certain feeling of amusement.

PROBLEM DEFINITIONBeginning boxers have difficulties in understand-ing certain techniques and using them. And if they do understand them, they are exercised with a lack of speed and power. This due to the fact that the techniques aren’t in their ‘automatic’ system yet, they have to think a lot before they anticipate.

But boxing isn’t only about powerful punches, but is a total of speed, ancipation, short contact, rythm, footworkandbeingfit.All theseaspectsarebeingtrained separately during boxing trainings, and get together during sparring. To get the most informa-tion possible out of one model, it would be better to focus on one or two things.

HYPOTHESE

With this model I expect that in the ‘game’ a cer-tain balance will be set automatically in the speed of the lighting up between patches. The perform-ance can show one’s level over a certain time, and this way. At the same time the lighting up of the patches is interesting enough to trigger a person to interact with it. There is a possibility where the level of the game becomes too high so a player cannot keep up with the speed. But after a certain time the game will become slower again.

SIMPLE RULESThe “game” The model consists from 9 patches (agents) which represent the 9 patches on a punching bag. Each time one will light up. If it is hit in time (speed) and the right place(precision) itwill go off and an-other will light up. After hitting, the patch lights up in a green or red color, in which green stands for ‘the correct patch’ and red stands for ‘the wrong’ patch. If the patch isn’t hit in time, it will light up blue, and stay like that until you hit it. So the challenge is to keepasmanyblackpatchesaspossible(andfighttheblue ones) by hitting in time and the right patches.

The challengeThe challenge, or the goal of this game is that the user/boxer will adapt to the speed of the game, but at the same time the game recognizes the level of the user. So it becomes like they are competing against each other, while the user and the patches are one team together actually. In boxing we see the same case; one boxer is competing against his opponent but at the same time he is competing against himself.

InteractionSo how does the game become adaptive and respon-sive then? The ‘game’ keeps track of the users level by counting how many blue patches there are against how many black ones. With this point of reference, the patches adapt their speed in lighting up the next time.

Right patch Wrong patchKeep the total black!

ITERATIVE PROCESS

Ifirststartedwithmodelingthevisioninascematicoverview. The idea was to make several patches, that light up randomly at a certain speed. At the same time they should be able to keep track of the players level, and to adapt to it by memorizing it.

is neighbor patch on? Skip turn

Go on in X seconds

Registrate how fast patch was hit

Memorize speed and use it next time

SowiththefirstversionsetupinNetlogoIsuc-ceeded in setting up a grid with 9 patches which light up randomly, in which the waittime could be adjusted. I added a feedback function where a green or red patch lights up, but there is no cohe-sionyet.InthefollowingversionsItriedtorefinethe functions and to make the ratio of black patch-es and blue patches visible by a performance graph for example.

to setup ca ;ask patch -1 -1 [ set pcolor grey ] ;ask patch 0 0 [ set pcolor grey ] ;ask patch -1 1 [ set pcolor grey ] ;ask patch 1 -1 [ set pcolor grey ] ;ask patch 1 1 [ set pcolor grey ]end

to play pick-patch output-print timer tick end

to pick-patch ask patch random-xcor random-ycor [ set pcolor blue wait waittime set pcolor black ] end

to reset reset-timerend

to hit1 ifelse patch -1 -1 = blue [ ask patch -1 -1 [ set pcolor green wait 0.5 ] ] [ ask patch -1 -1 [ set pcolor red wait 0.5 ] ] ask patch -1 -1 [ set pcolor black ] ;ask patch -1 -1 [ set pcolor red wait 0.5] ;ask patch -1 -1 [ set pcolor green ]end

to hit2 ifelse patch 0 -1 = blue [ ask patch 0 -1 [ set pcolor green wait 0.5 ] ] [ ask patch 0 -1 [set pcolor red wait 0.5 ] ] ask patch 0 -1 [ set pcolor black ] ;ask patch 0 -1 [ set pcolor red wait 0.5 ] ;ask patch 0 -1 [ set pcolor green ]end

to hit3 ifelse patch 1 -1 = blue [ ask patch 1 -1[ set pcolor green wait 0.5 ] ] [ ask patch 1 -1 [set pcolor red wait 0.5 ] ]

ask patch 1 -1 [ set pcolor black ] ;ask patch 1 -1 [ set pcolor red wait 0.5 ] ;ask patch 1 -1 [ set pcolor green ]end

to hit4 ask patch -1 0 [ set pcolor red wait 0.5 ] ask patch -1 0 [ set pcolor green ]end

to hit5 sprout 1 ask patch 0 0 [ set pcolor red wait 0.5 ] ;ask patch 0 0 [ set pcolor green ]end

to hit6 ask patch 1 0 [ set pcolor red wait 0.5 ] ask patch 1 0 [ set pcolor green ]end

to hit7 ask patch -1 1 [ set pcolor red wait 0.5 ] ask patch -1 1 [ set pcolor green ]end



Version 1

to setup ca ;ask patch -1 -1 [ set pcolor blue ] ;ask patch 0 0 [ set pcolor grey ] ;ask patch -1 1 [ set pcolor grey ] ;ask patch 1 -1 [ set pcolor grey ] ;ask patch 1 1 [ set pcolor grey ]end

to play every waittime [ pick-patch ] output-print timer end

to pick-patch ask patch random-xcor random-ycor [ set pcolor blue ]end

to reset reset-timerend

to hit1 ask patch -1 -1 [ ifelse pcolor = blue [ set pcolor green wait showtime ] [ set pcolor red wait showtime ] set pcolor black ]

end

to hit2 ask patch 0 -1 [ ifelse pcolor = blue [ set pcolor green wait showtime ] [ set pcolor red wait showtime ] set pcolor black ]end


to hit4 ask patch -1 0 [ ifelse pcolor = blue [ set pcolor green wait showtime ] [ set pcolor red wait showtime ] set pcolor black ]end

to hit5 ask patch 0 0 [ ifelse pcolor = blue [ set pcolor green wait showtime ] [ set pcolor red wait showtime ] set pcolor black ]end




Version 2

globals [gain] ;global variable (overview)patches-own [faults]

to clear ca ;clear all, makes screen black reset-timerend

to play/pause every waittime [ pick-patch ] output-print timer update-plot end

to pick-patch ask patch random-xcor random-ycor [ set pcolor blue ]end

to update-plot set gain count patches with [pcolor = black] plot gainend

to hit1 ask patch -1 -1 [ ifelse pcolor = blue [ set pcolor green wait showtime ] [ set pcolor red wait showtime set faults faults + 1 ] set pcolor black ]end


to hit3 ask patch 1 -1 [ ifelse pcolor = blue [ set pcolor green wait showtime ] [ set pcolor red wait showtime ] set pcolor black ]endto hit4

ask patch -1 0 [ ifelse pcolor = blue [ set pcolor green wait showtime ] [ set pcolor red wait showtime ] set pcolor black ]end






Version 3

globals [gain] ;global variable (overview)patches-own [faults] ;number of faults (missing a patch)

to clear ca ;clear all, makes screen black reset-timer set waittime 1.5 end

to play/pause every interval [ ifelse count patches with [pcolor = black] < threshold ;if statement that if the number of black patches is less than the treshhold [ set waittime waittime + speed-change ] ;yes: speed of lighting up next time will increase [ set waittime waittime - speed-change ] ;no: speed of lighting up next time will decrease ] every waittime [ pick-patch ] ; starts pick-patch every time update-plot end

to pick-patch ; ask patch random-xcor random-ycor [ set pcolor blue ]end

to update-plot set gain count patches with [pcolor = black] ;graph of results set-current-plot “performance” set-current-plot-pen “gain” plot gainend

to hit1 ask patch -1 -1 [ ifelse pcolor = blue [ set pcolor green wait showtime ] [ set pcolor red wait showtime set faults faults + 1 ] set pcolor black ]end

to hit2 ask patch 0 -1 [ ifelse pcolor = blue [ set pcolor green wait showtime ] [ set pcolor red wait showtime set faults faults + 1 ]

set pcolor black ]end

to hit3 ask patch 1 -1 [ ifelse pcolor = blue [ set pcolor green wait showtime ] [ set pcolor red wait showtime set faults faults + 1 ] set pcolor black ]end





Version4(final)



SYSTEMATIC PARAMETER STUDYInthismodel,therearefivedifferentparametertobe distinguished.

WaittimeThe waittime stands for the amount of time in sec-onds between the lighting up of the patches. This parameter is adjustable on one’s level; if one wants to start with a high speed, it can be slided to a smaller amount of time (0,5 seconds for example.) Thedifferencebetweenthisparameterandtheoth-er ones, is that the waittime changes automatically during playing the game.

TreshholdThe treshhold shows the level of the game. It is a point of reference, the turning point in black patches in proportion to blue patches. It means that if the treshhold is on 8 for example it means that the speed of the game will slow down because apparently blue patches are taking over which means the user is not fast enough. This way a bal-ance can be set. So when the black patches are more than the treshhold, then the speed will increase so the waittime will become smaller. Speed changeThe speed change slider determines the amount of speedchange, on every interval.

Interval Interval is the amount of time of each period where the speed is changed according to the ratio of the amount of black patches. Showtime The time of visibility of the green or red patches.

PerformanceThe graph of performance is the output of the results of the game, it shows the patches status against time. On the Y-grid the amount black patches is shown. So when you have a lot of black patches, the ghraph will become more steep.

CONCLUSIONS

The interesting part is that after playing for a while, a balance in waittime will be set, which stands for the level of the user. So it seems that it starts with a high waittime, goes to a small wait-time and then to the time that the user is best at. I noticed that the hypothesis of the fact that the speed can become too high was right. The majority of the patches become blue, and even if you hit the right ones, it takes a while before the right balance between black and blue is set ‘normal’ again. And with normal I mean at a speed that one can keep up with.

Critical pointsAs for playing the game, the best way to test it is to play it with a keyboard on which the numbers are placed in a grid of three by three (instead of all 9 numbers in one row) . And of course to get the best results of the design as part of my project, is to built the patches on a punching bag.

Model definition work sheet

Situation / context The level of speed | precision of a person doing a boxingwork-out on a punchingbag

short description of what happensTesting a concept: the punchingbag measures the users level in speed | precision, and gives feedback by lighting up at a certain time.The user is being triggered to anticipate and chal-lenged to reach a higher level each time.

Behaviour of the agentsThe agents are spots on the punchingbag, which contain sensors.

SpeedIf the agent gets hit within X seconds, it will light upthenexttimeandthelevelwillgetmoredifficulteach time

Role of the environment No role.

Why is it interesting I want to understand how people understand a certain patternI want to understand how long it takes before a person adaptsI want to see whether this ‘training’ improves the anticipation moments of a person

agent – agent interactionsThe lighting up of one agent depends on when the other agent is hit.

agent – environment interactionsTheagentshaveaneffectontheuser:hewillbeen-gaged to work harder, or to focus more to achieve a higher level.

The agents will focus so the user can achieve a higher level in speed. If the user hits the agents in time, the lighting up will go faster each time.

APPENDIX

Documents

DGD02 Complex systems