As an android game dev, virtual gamepads are a very common feature to find in a game but I’m struggling to find a good way to implement a SINGLE virtual joystick and the only method I can find is the bundled haxe script that ads 2 joysticks to the game, so I was wondering how to make a SINGLE virtual gamepad from scratch to be able to customize it fully. Or at least get a script to generate only the left side joystick?
The joystick wont be a problem, but without multitouch support is impossible to get it working right. Better to wait for Koui touch support or something related in Armory. You can try to see how the existent example is done to see how it works…
Below is just my opinion about android because i dont like to see people struggling the same place i were. Hope this makes sense because i am not using translator to check it…
Sometime i read “if you are putting gamepads in smartphone screen you are doing something wrong”, so always think about that. And for profit, smartphones are the wrost place to be… requires a lot of effort to create a shop, items, etc or spam ads. The game must be addictive, but yet some games do a great job on that like supercell ones… they are online but still have a great quality (but as always, addictive…).
For now i recommend you to focus on PC, and then you can port any game you do for where you want. I think you are a good guy and you are with a lot of energy, i hope you use that energy on learning and not waste it with frustration, like i’ve done most of the time before. That is it!
Edit: i am not talking about the lack of multitouch for the joysticks, but for other stuff that can be in a android game, like clicking objects, etc.
I agree with that, my next topic was ganna be about how to implement multitouch anyway
But the thing is, I’m well aware of Armory’s “difficulties” when it comes to Android development but that is one of the reasons Y I want to do it even more. I’ve requested a bunch of feature and reported many problems that probably won’t all get fixed but I still did it because I can see Armory’s potential and I want to help get it to as far as it can go and not ditch it because I can’t get this thing to work or because something else is a little buggy.
I guess what I’m trying to say is that I’m not a great android game dev so it doesn’t matter if armory isn’t great either… LOL (guess I’m the lab rat)
For a single virtual gamepad, all you need is to remove everything from the 2-pad code which has either
right in its name, depending on what you need. Luckily the variables are all named like that in this script
Btw, I really recommend you learning how to code and trying to understand how the bundled scripts or individual logic nodes work, it makes your life much much easier. But programming has a steep learning curve unfortunately.
You can create something like this from scratch with logic nodes only, it will just be a little bit of work. In general, using a UI library for the touch input might not be the best choice here as you can do the same with nodes with probably even less work but much more control. Get the touch location, position the gamepad accordingly with a bit of vector maths and then do whatever the gamepad should do based on the touch location.
I guess the virtual stick node might be useful for testing purposes in case someone doesn’t have a gamepad like me In my opinion it deserves a node like we have ones for sliding on screen (i don’t remember the name correctly). @Willbot_studio i made a small node for this purpose, but it needs improvements that i can’t do right now. If you are interested in see how it works or even improve it by yourself and be more acquanted to Haxe and send a PR, feel free to do so: https://drive.google.com/file/d/1Z2_P6LxcwliTHuqhLGMcgIr8LIdLjWl8/view?usp=sharing
These are the things to be done:
output normalized values (or no ?), but for some reason when i normalize the “coord” vector the values breaks
need to output the coordinate where the touch starts/end to draw some cool button or whatever
and the last is this needs to keep some proportion on the screen (bigger resolutions will require less “physical” area to be touched by the user)