No edit summary |
|||
| Line 14: | Line 14: | ||
13.01.2020 | |||
Well, I've made a point. After multiple weeks now trying and thinking about the water sensor and the fact that its data flow is just too undynamic and unstable to really have an impact on the game, I made a cut and a change of plans. | Well, I've made a point. After multiple weeks now trying and thinking about the water sensor and the fact that its data flow is just too undynamic and unstable to really have an impact on the game, I made a cut and a change of plans. | ||
Revision as of 15:08, 27 January 2021
UPDATES
27.01.2020
The patching is done. The game works so far, as far as I know there's no bugs left. The interface in presentation mode isn't finished yet, same as the tutorial text / documentation in the patch.
13.01.2020
Well, I've made a point. After multiple weeks now trying and thinking about the water sensor and the fact that its data flow is just too undynamic and unstable to really have an impact on the game, I made a cut and a change of plans.
Well, I stayed with pressure caption, and the fact that the other data impact of the game will come from a different source than the first players control data. To have a game that's not functioning on just one console or interface, but tries to draw a line between diverse interfaces.
On one hand we have still have the OSC control via Smartphone, that controls the first player. On the other hand (literally) we now have some piezo sensors that collect pressure data from each finger. This gives us two opportunities. We use this new data input to control either the opponent or a second player. It would be amazing if there were both possibilities to choose from.
This far I have arranged the piezos on my table, and connected them to Max. So far only with breadboard action.
This runs through the arduino and gives us values roughly between 0 and 1000. With this arrangement on the table we have some little data hysteresis I want to get rid of. Also I want the piezos to have a minimum pressure to be used to trigger the patch, so that positioning the hand isn't that much of a problem. This can be archieved with the [past] object, which bangs when a certain value is reached and passed by, but just in the upwards direction, so this is perfect for me.
In the patch below we can see the serial connection receiving the data from the arduino. To display the input I used a [multislider] object.
These bangs now can be used to control the pixels that are the enemies in the game, to control for example the position where they get "spawned", which is now controlled by random.
They can also be used as position control for a potential team player mode.
Anyways, I'll have to get back to fixing the multiplayer problems I have. It works so far, but the pixel control has a bug that I haven't solved yet.
I'll come back for updates!