Flying time and flashy words

Wow, it's already been 2 days since my last blog? Time sure does lose track when programming so much.
Well, since the last post, I have made quite a few accomplishments (although they look short compared to how many hours have passed)

1. The spools and menu items now move correctly. For the longest time, I was using the direct movement of the user interaction to change both. The reason that is bad is because the spools need increments of 30 while the menu text needs increments of 44. What the code is using now is: the user's interaction is controlling the spools directly and the menu items are taking that number, diving it by 30, then multiplying it by 44. To the user, they move at a 1:1 ratio, which is how it should look.

2. On the note of movement requirements, the spools need movement increments of 30 (which is treated as degrees). To spin the spools, they need radians (damn those pesky things). So, I made a function which does the conversion within the spool class to deal with that. Now the spools spin smoothly with the user instead of spinning at the slightest touch.

3. (not visible in previous releases due to the lack of movement precision). When moving the blocks up/down, after a certain amount past the other blocks, the next block will active (light up). This was done by checking if the user has scrolled 2/3rds past the middle point. This was not only discovered today but also fixed today. :-)

4. The menu items are now more descriptive on what is selected (by flashing the selected menu item). I don't know how to make animated screen shots from the emulator, so here is 3 pictures. The flashy text fades brighter than normal, then fades below normal, then brightens back again above normal. This continues while the user is scrolling and automatically starts flashing the new menu item when it's selected.

4b. The "GO!" button fades out when moving. The button still doesn't do anything, but at least it looks less static.

5. When spinning the blocks, often the lit up block would not be in the middle. Now I am 90% guaranteeing the lit block will be the middle block. This is just done by a tighter watch of what numbers are being changed.

6. The game no longer uses *.obj files, instead its using *.3ds files. This makes my previous work of coding a loader to populate the game with the objects name as a waste of time (damn). Then there was some problems of "the object is on it's side" and "the spool is backwards, all the panels are backwards" and "the names have some extra junk added to them". All of those problems were fixed yesterday.


Now, today's problems :-). i REALLY want to add multi-threading to this game. It is disgusting of how long it takes the game to load. To load all of the resources, IT TAKES 2 SECONDS...well, 1.5 seconds, but thats still too long. If I had a splash screen, that might make the time look less troubling, but I don't and the waiting time disturbs me.

Here is a picture of the loading time for the basic elements (fonts, panel walls/ back, gui image, models) and 3 panel images. 2 are being colorized and 1 is just being used as-is.

0.5 seconds per panel....and this is all done in the UI thread. So, I need to figure out how to toss all of the panel creation into their own threads for some parallel panel processing.
Another thing I want to research into is of how the spools are drawn. Currently, the game makes new spools from the loaded spool data  which helps reduce the time to load in the data. The idea I thought about is to just make 1 spool and the reel will contain "spool points".

Here is how it'll look. The reel will be created, which makes spool points (where each spool will be), then it generates panel data for each spool, then it's done.
When the reel needs to be rendered, it will move a spool into one of the spool points, rotate it, texture each panel to the spool point panel data, draw the spool to the buffer, then move the spool to the next spool point and repeat the process. If my calculations are correct, this should dramatically lower the memory requirement (less vertices = less memory), and enable each spool to be given a "light amount" to simulate it's acquired light from the selected spool.


What hurts the most about this game is that I have 2 weeks left to do these changes and make a playable level. For now, the threading and spool idea will be tacked onto the end of the todo list.
My current priority goals are to enable proper lateral movement of the spools, then make the first level (no goal, just movable spools which are not the menu spools).

= Todo (in this order) =

1. Make the camera move across the spools properly.
2. Create a second reel (of random length that is less than 20, for testing) for the game play.
3. Add block data to the movement ability to enable/disable movement
+ and to change the user's color, which will currently just be displayed as some text on the screen.

= Additional notes =

In the previous class meeting, my goals till the next meeting were:
- Finalize block and menu code (80% done)
- textures finalized (done)
- at least one gameplay/ puzzle mechanic working (not done)

So, I'm getting there to being done with this weeks goals. It would be awesome if I could add some music/ sound effects...but I haven't had time to look at the engine Chris mentioned (JavaZoom)....well, back to coding.

Shiny White Walls

After sitting at the computer, coding something which should have already been built into the engine, I finally got the objects in each spool working. AND, I even have screen shots this time ;-)

My first test time....a little disappointing. The only visible blocks were the pink null blocks (created in code for testing) and the stone block (loaded straight from image, no processing was done).

Then after looking through the code, I found the problem. Each panel which was getting new coloring was using the wrong transparency. It was using the blue channel (which is at 0) instead of the green one (which was at 200).

But, something was still missing. Last time I ran the program, The first non-end spool was lit up. I have no clue how this happened, so I just lit up the whole spool. (so I could at least see the images better).

Closer to what I was looking for, and shows that each test is indeed generating random spools in random colors.....but the panels still don't have have transparency :-(. So, I looked through the code, did some research to make sure the generated colors were using transparency, and scratched my head a lot. Then it clicked, I need to set each object's setTransparency(x) to something. Yea, I know its weird, since the image has transparency and it's loaded into the engine with transparency.

What is happening is that although the image is transparent, the object it is on isn't. So, I have to make the object transparent. Anyway, IT WORKED.

Because the spool is now (hub sides, block backs, block sides, and block front), I have more range of control of the block images. For example, you can now see the inner sides of each block AND the block's back :-D.

Using a previous picture to show my point. Looking at the top of the lit up "B", you can see the block side, but what your actually seeing is the block above it's side. Look at the right of the lit up "B" block, and it has no white side, just goes straight through and picks up color from the next spool's side (depressing and primitive).

Now that I FINALLY have a generatable blocks.....I get to tackle that massive and massively overdue todo list. But at least I get to look at some pretty blocks while doing it :-).

= Todo (in no particular order) =

- Look for code of how to save each panel's generated bitmap on the device so the panels won't need to be generated each time (and hope that it won't hog too much space).
 - Update the xml parser to recognize when it needs to loop over the same object multiple times to include each color combination.
 - Add action data to the block (and incorporate it into the user's left/right swipe to allow/disallow movement)
 - Code up a level generator (which will also tell each block which panel it will be using)
-+ using a scheme like in Minecraft, using numbers and letters
 - Scrolling left/right will fade in new menu items and out-fade the old
-+ and add more menus 
- Fix the lighting problem on the blocks (so only the current block and it's neighbors light up, like in the previous release).
- Implement my camera idea
- Fix the spool rotation and sliding
- Make the menu item text more diverse to distinguish which item is the current item
- Add sounds effects/ music. This will be added last though, because it's the lowest priority.

Lessons learned

I was finally able to test the panel generator code, and there was some glitches, nothing outside of my bounds though.
First most, using "==" to compare strings doesn't work. It apparently compares where the strings are located instead of their values. So, by using StringA.equals(StringB), it properly compares the names.
Second, using getPixel() and setPixel() are VERY slow. I should have known this from my C# days. So now each unique image is converted to an int[] and saved. Then that array is used each time a new panel is needed.
And lastly, creating a new array of panels for each spool was stupid and slow. Now, each spool has panels already applied to it. After all, it's not like a spool will have less panels than it's max number of panel slots.


Now, the problem I'm having is accessing each object in the loaded model. Previously when each model was just one object, I didn't care about the object's name...now it's one of those important things. When loading the objects, the engine seems to like naming each object something besides it's actual name. I've already sent a message to the developer of how to fix this problem, hopefully the reply will be quick :-/.

Till then, I'll work up some hacky and use assumed places (modeled after the obj's file object placements). After I get this workaround finished, the panel generator should be complete and I'll be able to get my first screenshot of generated panels :-).


Here is some finally good news though, I know how to fix the camera problem :-D. The reel will be on an angle and the camera will be facing it directly and move left/right. The difference is that there will be an invisible object (named cPoint) which will move across the reel (not attached to it, just along it). it's pivot point will be 0,0,0 (the same as the reel's pivot point). Each time the camera wants to move, it will un-rotate cPoint, move it left/right, rotate it back, move the camera left/right, then adjust the camera's z by using cPoint's z value + some number. Damn, I can't wait till the panel upgrade code is finished so I can test this. It's been bugging me for the last 2 weeks (and these weeks have been very long).

In with the new and still with the old

After a good 6 hours today, I finished: the xml data file (which holds info about each panel), the xml parser (makes panels from the data), and the panel class which holds all the data. Which looks mighty impressive.

My only stumble now is determining which/ how to assign colors to each panel. Sure, I got the color codes in each picture to assign the colors to the picture and the panel class holds data about which colors it has, but thats not enough. Currently each panel is assigned its own name in the xml "One Way - Left - 2", which would mean the panel is a one way panel, the user can only enter it from the left (as opposed to the "Right" version), and it has 2 colors.

But that is causing a logical problem (in my head, not the code), that this prevents truly unique panels (by color). So, tomorrow I'm gonna replace the naming convention from a number to a "#". While going through the loading process, the code will see it has colors assigned to it and look through that panel X number of times till all of the colors are accounted for.

Since I have not done any testing yet (there was no place where I could), I don't know how long it would take to make all of the panels

= New Todo =

- Make a new type of spool which will have panels attached to it. This should enable faster object loading and less faces (24 to be exact).
- Change the naming in the xml to allow a more unique name for each panel (easy)
- Update the xml parser to recognize when it needs to loop over the same object multiple times to include each color combination.
- Look for code of how to save each panel's generated bitmap on the device (and hope that it won't hog too much space)

= Still on the Todo =

~ 5/21 ~
- Add action data to the block (and incorporate it into the user's left/right swipe to allow/disallow movement)
- Code up a level generator (which will also tell each block which panel it will be using)
-+ using a scheme like Minecraft, using numbers and letters
- Scrolling left/right will fade in new menu items and out-fade the old
- Add lighting to the blocks for a more elegant look
- Add sounds effects/ music
- Get the camera working

~ 5/23 ~
- Menu
-+ The spools don't rotate properly
-+ The sliding of the spools is off, they are constantly too much or too little
-+ Lighting up of the blocks is off, and often the light block wouldn't be in the center
-+ Make the menu item text more diverse to distinguish which item is the current item

- General
-+ Add music and sound effects

= Pictures =

This is what the panel used to be. Colorful and distinct to one panel (the "Cycle Colors - CCW - 3").

But it takes up too much data and can only be used once. THIS (shown below) is the new version of the above block. It not only shows the same (after being processed) thing as the above panel, but can be used multiple times.

Now I won't have to worry about the game becoming too large with all the panels in it.

oh, and the rest of the block (sides and back), they will each have their own pictures. White sides with black linking for the sides and I-don't-care for the back. Well, actually the back may just be a white panel. I haven't been able to see the back yet, but after the new spool upgrade and some testing....I'll post another update.

Unpictured panel problems

After some thinking about the panel pictures....I'm gonna scrap using png files. In fact, the panels won't be using any panel specific image. The number of combinations for each panel (colors), animations (eventually), and levels for each panel...the game will be huge.
For the 6 basic tiles in 6 different colors, the file size will reach ~3MB and be over 90 pictures.
For 6 basic tiles modeled as 3d objects and dynamically colored, the file size will be ~1 MB and only need 6 objects.

What I'm thinking about doing is one of two things. Have a panel made, then moved into position with the rest of the block. Or make a block with the panel already in place. I'm hoping for the former (due to a smaller file size)....but the latter sounds more plausible.

Block schema

= General Updates =

Yesterday (Tuesday) was the bug testing day and my game was passed around and tested....well, what is there so far.
The requests I got were:
- Add a game to the menu
- Make a more drastic color difference between menu items
- Make blocks on the spool represent the selected menu item
- Game crashes after scrolling a lot in the same direction
- Some blocks flicker while scrolling
- Add some music

And the most request....add more :-). I am fully aware of that, but I am killing 2 birds with one stone in this game. Not only do I get to finish the menu, but I am also working on the actions/ looks/ physics of the spools for the game while making the menu.
The day of the bug testing, I woke up early and started making some last minute coding, so the user could scroll left/right. But I didn't have enough time for a complete test and it was looking really bad, so I ended up taking it out....although I should have left it in so people could complain more.


Ok, Now for the game updates.

= Game updates =

The day before the bug testing and today, I was working on making an xml file (and schema) which will allow the importing of panels. It looks very impressive. Able to load in arrays of panels, enable/disable requirements/actions to make each panel unique and able to have multiple traits (easier for making new panels). Now I have to create an xml which will have all of the panels, which isn't to hard of a task, the program I'm using (Liquid XML Studio) has a nice GUI to make new items. My only problem now is Chris making the panel images, which is that he's not producing enough with quality.
I could easily make all of the panels, but I still have too much to do on this game to do pictures. Plus, what else is having another group member besides to do assets?

= Todo =

- Menu
-+ The spools don't rotate properly
-+ The sliding of the spools is off, they are constantly too much or too little
-+ Lighting up of the blocks is off, and often the light block wouldn't be in the center
-+ Make the menu item text more diverse to distinguish which item is the current item
-+ Add code to choose between scrolling and clicking

- Game
-+ Make a level generator which procedurally generates the level (via letters and numbers, like Minecraft)
-+ Code in game types. Was going to make it soft coded, so users could make their own game types....but they already get to make their own blocks (eventually) and reels. Hard Coded game types makes it easier for me (menu wise) and less "what do I do?" on the user's end

- General
-+ ADD MUSIC AND SOUND EFFECTS. A game without music/ sound effects is boring. Sure, the user may turn off the sound, but it's always better to have sound than it never being there.
-+ Switch the engine to Rajawali. jPCT-AE was a great engine. It had a wealthful of features despite it's small size and was a hell lot easier to use than raw OpenGL 2.0 code.....but it just lacks the proper functions I need to get this game working. Like the camera control, directional lighting, and materials (sub, but still wanted). My only beef about Rajawali is the lack of documentation in its JavaDoc....but they make up for it by making the source code freely available (for in case I have questions about a functions actions).

= Pictures =

This is the current block schema. Loads in blocks, actions, and requirements. It would look cooler with all of the items opened, but I don't want to give away too many secrets ;-).

And here is the tree of what blocks would be in the game. After making the schema (what the blocks can be), this tree now looks very small. When I was making it, I thought "wow, 46 blocks, I doubt I would add all of them. I don't need this many...but I'll prune them later". Now it doesn't look that bad.

Looks like my block library would become a success after all....assuming I get those panel pictures before the coding week is over (end of week 6, which is in 2 weeks).

Training for the big game

Well, this menu creation was an annoying adventure. The font -> bitmap program I previously had, it made a bitmap which wasn't quite compatible with the code. The code converted each character to its ascii value, then used that to retrieve the correct letter from the image. I won't go into detail, but it does work. So, I had to look for another program to make a bitmap which I can use.
CBFG (http://www.codehead.co.uk/cbfg/), it's free and works. I chose to use both the bitmap export and its custom file export (which includes specifics of the character's size). Then it took awhile to get the code sorted out till it worked (took about 10 hours to get it working straight).

Then I had to adjust the color of the menu items to correspond to fading in and fading out. Little easier, but still took an hour or 2. For a usable transparency, I had to reduce the ceiling value from 255 to 16, everything above 16 looks the same (yes, very weird).

After the text was properly displayed, it had to be properly moved and faded in/out when the user scrolled up/down. This.....it had a lot of testing. It wasn't until I stopped trial/error testing and drew up a mock action picture that the code worked. The transparency has a few glitches, they skip a bit when near their entrance/ exit, but its good enough for now.

Oh, and I even branched the text drawing code to draw color changing text (as seen in the title in the attached image). There wasn't much new code needed to do the action and the code worked on the first test (which is always a good sign).

At this point, the menu is stage 1 complete (display menu items and change them using the spool). Stage 2, have the menu items actually do something.


Due to time constraints, all the items will do the same thing, which is to start the game. And.....the game is due this Tuesday. Well, something at least playable besides a menu.


To accomplish this game task, I need to learn about loading XMLs (which will contain data about each block), then make a level generator. Lucky me, the physics and display of the reel/ spools has already been completed while working on the menu (short of the camera view).

= Todo =
- Add more blocks
- Add action data to the block
- Code up a level generator (which will also tell each block which panel it will be using)
- Figure out how to start the game (I'm swinging more towards using a new GLSurfaceView rather than a new Activity)

p.s. Nearly forgot to say this. I turned down (off) the ambient light, reduced the worldly spot light, and played with the block's per-vertex additional colors....and now the blocks have the appearance of being "self-illuminated". It's not as beautiful as I was wanting originally and there isn't any light produced by the block, but its enough for now to show what is selected.

= future todo =
- scrolling left/right will fade in new menu items and out-fade the old
- add lighting to the blocks for a more elegant look
- add sounds effects/ music
- get that damn camera working. LINEAR IS TOO PLAIN!!!

Menu-away!

I've given up on the lights for now. The "back lit panels" thing just isn't working right now. And I still got things on my list.

First, The fixes:
1. The previous problem of the weird spacing of the objects.....I have no clue why it was doing what it was doing. I was affecting only the vertex points and the matrix buffers were cleared before each translation.
2. After fixing the previous problem, the blocks would have increment away from the spool. I applied the same fix as #1, and it worked

3. Rotating the spools. Due to the way they were connected to the reel, and rotated in space, the would rotate around 0,0,0 instead of their central point. Or would rotate around their central point but on an angle (not aligned on the z-axis). So while making each spool, I had to tell it "This is your rotation pivot point". There wasn't any complaints and they spun happily.

The problems:
1. The camera. The way the game is supposed to look, requires the reel of spools to be tilted on an angle.
I've tried to have all the spools tiled on an angle, but it looked cheesy and they all still looked linear-like. So I didn't even try using it past that.
Then I tried to tilt the reel so it went into the distance and make the camera follow it while panning across the spools. But it still looked like it was missing something.

Currently, there is just a 5* y-axis rotation on the reel to give it some angle....but I just can't figure out how to make it look like the testing model (as shown above).







2. A "possible" problem...the spool/ reel step-click (yes, that's the best name I could think of to call it). After the user spins the spools then releases, they move to the nearest whole block space "so you're not between 2 blocks". I have the code in the program, it works...but with the new way the spools are spun, the code may not work.
The reel version of it, nothing is coded yet (weirdly, not as much of a problem as the previous one).

= Todo =
- Still have to work on the menu. So I'm gonna put a pause on the spools and work on this first. I found the code for drawing the font and my font -> bitmap program. Now I have to test out making the menu....which I think is going to be in it's own world (engine term, its so the lights won't effect the menu)


After the menu, my week's goals are completed.

Spool placement problems

Well, I fixed the weird problem of all the objects merging onto each other (sadly I don't have a picture of it). The problem was caused by z-fighting, and I wouldn't have been able to figure out the problem unless there was scaring on the colors. So, I manually set the z-buffer on the objects (programmly of course) and the image looks a lot better with more spools on the screen.

I still haven't gotten the per-block lighting worked out. I'm trying to do a back-lit object like portal uses for their level screens (http://www.instructables.com/image/FIE8HZKGWTIJT0J/Portal-Level-Sign-Wall-HangingLamp.jpg), but instead, the blocks avoid using the light :-/, while the spool hubs are flooded with the light. Currently, this is not at the top of my priority (weird of why I set it so high on my previous list).

What is my current priority is the reel class. Yes, I said it was finished...but that doesn't mean its bug free. The structure and and the assumed actions are completed. After getting that z-glitched figured out (and enabled actual testing of the reel class), I got a new.....problem. lol. I am unsure of how it happened. It works half-ish both ways....I'll just post the pictures then explain.


When the game starts, the spools look like this (damn lighting, lights the wrong objects). The rightmost spool (spool 0) is in its correct spot, spool 1 is also in its correct spot, its blocks however are not.

 

 After touching the screen to rotate the spool (works correctly by the way, spins both blocks and spool hub on spool 1), the objects of spool 1 all shift rightward.

The reason I say "I am unsure of how it happened.", is because the spin code doesn't do anything to the spool's translation.

= spool class =

    public void Spin(float val)
    {
        Hub.reset();// resets rotation only
        Hub.rotateZ(30 * totalRot);
        Hub.rotateZ(val);
        Hub.rotateY(110);
    } 

Looks like I got another interesting problem ahead of me. Luckily, I can easily apply all of this knowledge to the gameplay part of the game (whenever I get to that point).

jPCT-AE for the gold

My previous hope of getting jMonkey to work was a bust. The engine had it's own IDE which was bulky and lacked the Javadoc that Eclipse has. When I tried to use the library in Eclipse, the IDE crashed while trying to compile all of the stuff :-/. So, I just trashed the whole jMonkey thing.

After re-looking at the engine site, I found a few engines which I could use. Rajawali, Libgdx, and jPCT-AE. Briefly checked out each one (to make sure it had a stock of documentation of how to use the engine). Then I tried jPCT-AE first....it works pretty well.

Loading the obj file and applying a texture to it was a lot (3x more) easier than using raw OpenGL code. The engine even comes with addChild/ addParent functions. I won't have a use for the addParent function yet, but the addChild one...it's gonna be thoroughly abused if I'm gonna get this game working.

I had a problem the last 2 days, attaching blocks to the spool face. Translate the block to the spool's outside, then rotate it around the spool. Sounds simple, only need to use ~7 lines....not so easy. It would rotate the object THEN translate it. A few mins ago, I found something in the Javadoc which I somehow missed.
"The translation will be applied the next time the object is rendered", which explains my problem. So I switched to using the rotation/ translation matrices (the jPCT-AE built in ones). And it worked.

 

It looks like I'll make the goals for this week....but I'm a little worried if I'd have a playable demo for week 4 :-/...well, no sense in worrying when coding gives more results :-).

= Todo = (for this week, in this order)

- add transparencies to each block (the spool is using global transparency, not texture transparency)

- lighting for each spool

- rotate the spool using touch (adjust lighting after each competed block rotation)

- complete the reel class (it generates x number of spools on command)

-  change selection (left/ right) by using touch and adjust lighting after a spool change

- add text to the screen (shouldn't be too hard, the demo already has code which does it)

-+ refind the program which converts fonts to bitmaps

- make a menu with the font (hopefully get some transparency on the fonts?)

- move the menu items while the spool is rotating

It's a little bigger than the todo list I made with the teacher, but these are more detailed steps of what I'm gonna be doing...I still don't even have block images for the menu items. Oh well, I'll send those tasks to Chris later this week. I already have the concept of what they will look like (written down), they just need to be drawn out.

 

OpenGL problems

....just when I thought I had things working out, another problem happens. Well, actually a few.

1. The texture on the object is not correct despite the texture being from the UV rendering. I have no clue how to fix this.

2. When running the game from the computer, the textures transfer over. When running the game from the phone, there is no textures.

3. The object will not rotate in 3D space. The vertices change correctly, but OpenGL doesn't draw them with the new change. I tried with the vertices being static and dynamic, and 4 different types of rotation methods. The only usable one is to rotate the camera around the object, then render the object....but that just makes the object look bad (the angles are incorrect).

When I add a second object, the first object "rotates"....one face (3 vertices) spins like crazy and another wobbles back and forth while the rest of the object is stationary.


My brain is nearly fried, I spent all of yesterday and today trying to decipher this. So, I'm taking a new attack, I'm on this website (http://www.mobilegameengines.com/android/game_engines) looking for a 3D OpenGL engine to use instead of accessing the raw OpenGL functions/ methods.

Looks like I'm gonna be behind schedule. Hopefully, when I get a good looking engine, everything after that will be smooth and I can finally crank out the features the game needs, LIKE A MENU AND A LEVEL!!

New Look

After a grueling first week of testing to get the 3D OpenGL 2.0 working, I finally got something this morning. I had to end up scrapping my code twice till I got something which worked....I don't know why those batches didn't work, but it doesn't concern me at this point.

For the rest of today, I'm gonna finish adding code to rotate the spool. Tomorrow (and maybe the next day too), I'm gonna work on making the reels and clean up missing things

Terms:
reel: horizontal bar that holds spools
spool: vertical wheel which holds blocks, the player can only be on one spool at a time
block: what the user "interacts" with. The different blocks determine how/ where the player can move

= Todo =
1. Finish work on the spool
-+ Shrink it to reduce un-needed size
-+  Rotate the spool so it's correctly aligned. Currently only the side is shown instead of the front angle

2. Add the blocks onto the spool
-+ Each block needs it's own picture
-+ Attach the block so when the spool rotates, the blocks will follow with

3. Menu
-+ The menu will consist of half display and half reel. Each spool will be a main category, and each block will be a sub-item
-+The left side will show info about the currently selected item. I haven't quite figured out how to display the text. OpenGL or standard text?


The first window shows what the game will look like. The left side box with 3 dots will contain the items the player can use during the game (implemented during beta). Below that is a block with a colored ball, the ball will represent the player, and the blocks (behind, left, right) will represent the nearby blocks. Clicking on them will open a window to show info about the block (implemented during beta). At the top will be a drop down map of the reel...also implemented during beta. The vertical wheels in the middle is the game. Player swpes up/down to rotate the other spools (camera is locked on your spool), swiping left/right will move between spools.

Second window shows the main menu. The first few demos will only have one active spool, more active spools will be in beta or late alpha.