InfiniTime
InfiniTime copied to clipboard
New dice-rolling app: InfiniDice!
InfiniDice is a dice-rolling applet where you can roll random numbers from d2 to d99. The functionality is:
- Set the number of "sides" of the dice
- Roll to randomly generate a result number in the interval from 1 to the number of sides
It starts at d2 (ie coinflip), and when you first open the app, a roll is made, so you get a "free" coinflip. Then you can change the number of sides and use it as a d6, d20, etc. The color of the result alternates with each roll (so that you can be sure it was actually rolled even when the result is the same).
Tested on PineTime hardware with InfiniTime 1.10.0, and found to be in good working order. See video:
https://user-images.githubusercontent.com/45940010/189685541-4fb9899f-cb8c-4026-8d25-8971b0421565.mp4
I often find myself looking for dice and think this could come in handy for tabletop players :) Any testing, feedback, or suggestions on optimization would be appreciated!
I believe this has been implemented before, check #565
I like the simple interface and think they solve different problems. Maybe we could have both apps in a world where we are able to choose which apps we want.
One feature that I think is quite nice to have in a dice app, is being able to specify a number of dice, rather than just always rolling one die. I don't think that for this you would need to show the results of all the dice individually, just the final result.
For the rest I think this app looks good! 👍
#565 is doing exactly that already.
You're right, it does do that. But it hasn't been updated in quite a while, and so doesn't merge nicely with some of the changes in InfiniTime. The author of that PR also doesn't seem to be very active, so it's uncertain as to whether it will be updated.
This problem is fundamental for InfiniTime. We need to fix the app problem. Shameless plug: #1296
Thank you @NeroBurner kindly for your improvements on the code :heart: Thank you everyone for your comments and feedback as well.
@FintasticMan :
One feature that I think is quite nice to have in a dice app, is being able to specify a number of dice, rather than just always rolling one die.
I definitely appreciate your sentiment, rolling multiples is a frequently needed and useful function of dice! :+1: However I tend to agree with @minacode , there's a value to keeping the interface simple and intuitive, and #565 already implements multi-roll in a lovely way. But I might be thinking about ways to implement that smoothly without crowding the UI too much.
Implemented rolling multiple dice in 52e4af53332a4e6d8c6e54b4862c08df300aeef0
(Thanks for the suggestion @FintasticMan ! 👍)
The number of dice can range from 1-9 (default 1), and the sides can range from d2-d99 (default d2). The individual rolls are shown as well. Here's the new look:
As before, any feedback or further suggestions are much appreciated. I'll try to keep it up to date with the official develop branch in the meantime. Thanks everyone :)
Maybe sort the results from highest to lowest?
Also: how about showing only the sum or the single values and swapping between them with a tap on the label?
Thanks for the suggestions @minacode , I really appreciate it!
Maybe sort the results from highest to lowest?
This is a neat concept, however after thinking about it I'm hesitant to implement it, as I see two plausible use cases it would affect:
(1) User wants the rolls sorted (eg if they need to know the highest of N rolls). (2) User wants the exact original sequence of rolls (eg if asked "roll three dice, the result of the 1st will determine A, result of the 2nd will determine B, result of the 3rd will determine C").
If the rolls were sorted, it would be convenient for use case 1 but make use case 2 impossible. If the rolls were left in original sequence, it would only be inconvenient for use case 1 (but still possible/pretty easy, given 9 dice max), but make use case 2 possible/easy.
Also: how about showing only the sum or the single values and swapping between them with a tap on the label?
This is an interesting idea, but IDK, with the current implementation, one can fill the display maximally (3-digit sum and 9x 2-digit individual rolls, as pictured) and it still fits nicely within the provided area.
From that standpoint I feel it would be better to have more info displayed at a time on a single static screen, if it can be helped, rather than make the user flip between modes. Also, the tapping would represent a hidden feature/function, whereas currently the function and control of the applet is plain just by looking at a static image.
The other thing influencing my thinking here is that when I feel ambivalent about whether to include a feature, the approach I'm favoring is to err towards keeping things simple and doing as little as possible, given the current memory/resource constraints on the PineTime.
Ok, you convinced me 🙂
Btw, I've clang-formatted all files, but the error & warnings I get when I run clang-tidy appear to be false -- I suspect this is the cause for the code formatting check fail. I get similar errors when running clang-tidy on other pre-existing files in the repo as well. For example:
Error while processing /home/yusuf/PineTime/InfiniTime-InfiniDice/src/displayapp/screens/Dice.cpp.
/home/yusuf/PineTime/InfiniTime-InfiniDice/src/displayapp/screens/Dice.cpp:1:10: error: 'displayapp/screens/Dice.h' file not found [clang-diagnostic-error]
#include "displayapp/screens/Dice.h"
^
(While Dice.h exists and the include is working otherwise)
/home/yusuf/PineTime/InfiniTime-InfiniDice/src/displayapp/screens/Dice.cpp:11:34: warning: parameter 'font' is unused [misc-unused-parameters]
lv_obj_t* MakeLabel(lv_font_t* font, lv_color_t color, lv_label_long_mode_t longMode, uint8_t width, lv_label_align_t labelAlignment, const char* text, lv_obj_t* reference, lv_align_t alignment, int8_t x, int8_t y) {
(This warning appears for all parameters of the functions in the local namespace in Dice.cpp, while all parameters are used)
Do you know why this might be happening? Have you run into this problem before?
Thanks!
how do you call clang-format? The script used in the CI can be found here https://github.com/InfiniTimeOrg/InfiniTime/blob/develop/tests/test-format.sh
According to the script you should be able to do the following (not tested locally, and maybe you need to install packages for git clang-format)
git clang-format-12 -q --style file --diff "develop" src/displayapp/screens/Dice.cpp
What are the real world use-case(s) for such an app? This is an honest question, as I've never felt the need for this kind of app ;)
Thanks for the help @NeroBurner -- will work on using that call for clang-format and loop back soon! (edit-- fixed in https://github.com/InfiniTimeOrg/InfiniTime/pull/1326/commits/349e63a87b16ef4b5738f8630132926c5bfd35af )
Btw, the build error is due to a typo in the code in one of the recent commits to the main InfiniTimeOrg:develop branch -- line 118 in displayapp/screens/Clock.cpp
:
notificatioManager,
@JF002
What are the real world use-case(s) for such an app? This is an honest question, as I've never felt the need for this kind of app ;)
The question is appreciated! Same as the reasons one would want physical dice or a coin to flip :) For anyone who plays many tabletop or board games, looking for dice or not having enough dice handy is a common problem. Or for randomizing the starting player, picking which path to take on a walk, or which friend will go get the food (similar to drawing straws). I made the app because I thought it's something I would use fairly often, and it's just neat to have dice on my wrist!
Like with any app, for the PineTime or otherwise, some people may enjoy and use it while some others may not find a use for it. As mentioned previously and in the InfiniTime Vision, in an ideal world, people could just pick which apps they want to include in their version of the firmware. But for now, for something that doesn't require many resources, I would argue towards including it and having that extra provided functionality available even though everyone may not use it. One piece of evidence favoring that at least some portion the PineTime community might appreciate some wrist-dice is that this is the third instance of such an app-- see #565 and #1199 .
I like the dice rolling app idea, and would be happy to make some visuals for it, if there is interest in the display of something resembling a traditional dice. It could also be nice to add vibration to accompany the "roll" given that the most common use case will be be tabletop gamers.
Thanks! I like the vibration idea; I've added that in https://github.com/InfiniTimeOrg/InfiniTime/pull/1326/commits/b47b13aecb5db37ea0d592e224d7b3de3e72c58e since it is a small change. Agree with getting basic functionality in first.
Thanks for the offer @Danimations -- I love the idea of displaying something resembling the traditional dice down the line (may be more realistic to implement now, given our recent newfound access to external resource storage)! I think it would be tricky with certain rarer dice sizes, but could be done with the more common ones (eg d2, d6, d20). The individual result label could display a sequence of images of the dice with the result shown, with the sum still shown numerically. Or the images could be used only when 1 die is rolled, and show the image of that die result while hiding the total / individual result text.
Thanks for the offer @Danimations -- I love the idea of displaying something resembling the traditional dice down the line (may be more realistic to implement now, given our recent newfound access to external resource storage)! I think it would be tricky with certain rarer dice sizes, but could be done with the more common ones (eg d2, d6, d20).
Cool, glad to see you like the vibration idea and that external storage has been unlocked with some wizardry! What would work best, vectors or raster images for dice faces? And if vector, what format should I supply these in?
It'll be a little bit before I get a chance to look into using the new external resources in the code (and probably separate PR to let this one go through when it's deemed ready), but I'd say raster in png format would probably work best!
Cool. I will make a rudimentary set of .PNG for D2 and D6 when I get a chance or an idle moment. The coin flip visual will be nice with some spinning animation... I'm an animator too, so I easily give you spinning and landed sprites for the coin toss/spin. Thanks for bringing this idea to life.
I think you could draw dice programmatically as well, shouldn't be too difficult. Loading resources is not instant and some aspects might be easier in a hybrid-graphics way.
It'll be a little bit before I get a chance to look into using the new external resources in the code (and probably separate PR to let this one go through when it's deemed ready), but I'd say raster in png format would probably work best!
I've made some D6 .png files for you to play with... how shall I send them to you?
Awesome, thanks!! Can you attach them / post a link here? Will play with that and/or the concept of drawing them programmatically soon when I get a chance. (I think at least for d2 and d20 it can be a single base image, with HEADS/TAILS or the number written atop it as a changing label text.)
Hey there, just checking in-- what's the current status on this? It is ready from my standpoint. What are the current obstacles to merging and anything I can do to help get it closer to that? Thanks! 👍
Hi Yusuf. I have art for you, but broke my leg on the weekend and haven't had a computer in hospital. I also haven't worked out how to upload files to GitHub yet.
Dan
On Tue, 25 Oct 2022, 11:53 am Yusuf Ebrahim, @.***> wrote:
Hey there, just checking in-- what's the current status on this? What are the current obstacles to merging and anything I can do to get it to that point? Thanks! 👍
— Reply to this email directly, view it on GitHub https://github.com/InfiniTimeOrg/InfiniTime/pull/1326#issuecomment-1289854188, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJNR274N624VYI2HB5GWDOLWE4ZA5ANCNFSM6AAAAAAQKRTMSI . You are receiving this because you were mentioned.Message ID: @.***>
That sucks, sorry to hear that- hope you have a smooth recovery! No rush at all with the files, it'll take me a little while to get to figuring out how to integrate them and I would probably open a separate issue for it.
Hey there, just checking in-- what's the current status on this? It is ready from my standpoint. What are the current obstacles to merging and anything I can do to help get it closer to that? Thanks! +1
I think the only obstacle left mostly my free time :) We do plan to review and merge this app soon, I just want to have a closer look at the code ;-)
Hi Yusuf. I have art for you, but broke my leg on the weekend and haven't had a computer in hospital. I also haven't worked out how to upload files to GitHub yet.
Sorry to read this, I hope you'll get well soon! You can upload file simply by dragging them into the text area when you're editing you comment, or by clicking on the 'link' button above the editor. Not sure how to do it on the phone, though.
I think the only obstacle left mostly my free time :) We do plan to review and merge this app soon, I just want to have a closer look at the code ;-)
Thanks! I know the maintainers work on this in their free time and have lots to review so no hurry :) I don't mean to rush/be pushy, just wanted to check if there was something I was supposed to be working on! Take your time. 👍
That's fine, your question was totally relevant knowing that it was initially planned for 1.11. But there were already quite a lot of changes so I preferred to release while it was stable before adding new changes ;)