JUN 1 Finished up the report.
MAY 31 Finished writing up the results.
MAY 27 Subject 7 completed!
With everyone done, I’ve started calculating the p-values of my results. I’m going to exlude subject 2. Their data is wildly different and wasn’t in the same environment. With their inclusion, my p-value isn’t significant, and without them it is! Subject 5 also has different data than most, but that’s more of an interesting data point than an improper experiment.
MAY 26 Subject 6 completed. They were the only subject to use the widget while drawing rather than writing or researching, so I was curious as to how effective it would be. It seems to still work as intended with the caveat of drawing programs having buttons in the bottom right corner. They said the squish helped circumvent that, though.
MAY 22 Subject 5 completed
MAY 21 Subject 4 completed
MAY 20 Subject 3 completed
MAY 18 Subject 1 completed and subject 2 completed! Subject 2’s trial actually ended up being interrupted a lot. I’m considering marking him an outlier, but we’ll see. Aside from that, the code ran without any issues and people seem to like it!
MAY 17 Completed the questionnaires for people to fill out after the widget trial sessions, and my data template.
MAY 16 Hats all completed and implemented! The hat logic was quite simple.
func hat_logic():
print(hatframenumber)
# if points is a multiple of 10, advance a hat
if (int(points)%10) == 0:
print("Enough Points")
hatframenumber += 1
if hatframenumber > 8:
hatframenumber = 1
$Sprite2D.frame = hatframenumber
I ended up dropping the colours. I couldn’t think of a natural way to include it as a shortcut that wouldn’t be used elsewhere, and I want to keep the UI as clean as possible for the widget. Grey is a good choice, anyway. It’s neutral so should blend in fine. I also (on mac) dropped the movable part of the widget in favour of it being freely resizable. The movable feature has to be done in code on mac, and the code I used was quite buggy and could lag. When people tried to use the moving feature it could even get stuck away from the mouse and just follow forever. The only solution is to restart the widget, and when it’s meant to be a tracker, that can’t happen. The widget can be stretched in a way that isn’t locked to an aspect ratio, which should hopefully help avoid it covering buttons.
MAY 14 Ethics team finally gave me the go ahead! The regular deadline is the 26th, so I’m VERY lucky to have my extended deadline here. I’ve reached out to people to schedule the first trials.
MAY 6 The widget is currently resizable and draggable, it’s only missing quality of life features and the hats.
Part of my plan for the trials was to use the university macbooks if someone forgets their device, but a minor wrench was thrown into that. I took out three macbooks and not a single one booted. My friends allowed me to test the widgets on their macbooks though, and they ran fine. I wanted to try get the widget running on as many devices as possible, because they’re gonna have to for the trials!
Initially, I set it so you could toggle the colours by hitting cmd + c on mac / crtl + c on windows. It was set to that because Godot has a feature that makes it so the program can switch between listening for the “Command” key on mac and the “control” key on windows. During testing of the idea, a user pointed out that ctrl + c is a very widely used command! I mainly work on mac so this didn’t occur to me. I’ll probably have to change it to another shortcut because windows + c does stuff as well.
The colours currently only swap between when the next animation is called, i.e when the buddy gets distracted. This was the easiest way to do it but it would be better if it was immediate. I would then look into shaders to allow the user to shift the hue of the colour buddy, but if it ends up too much I’ll leave that idea behind.
During development I learned that borderless windows on Windows CANNOT be resized or moved at all, which is very annoying. If there’s a way, it has to be handled by godot. I’ve left it as a bordered window for now.
I want to see if for the mac build I can add a little marker in the corner that shows where to drag to resize it because it can be a bit funny trying to find the actual place to drag. If I can manage the borderless resizable windows build, I can apply that to both builds.
When I first implemented the buddy, I attempted to “mask” out the clickable area so that the click would only register if you clicked the sprite rather than the entire window, but I couldn’t get that working. If I had all these other tasks done I would try and get that working and including the hat’s collision. (I don’t think collision is even the right word for 2D but I can’t think of a better one)
APRIL 17 Ethics team have gotten back asking for a project proposal, so I wrote that. I hope they respond soon, I was intending on starting my trials early to give myself time to analyse all the data and get enough participants…
EASTER BREAK END
APRIL 4 I’ve swapped the placeholder assets out for the final sprites. I also implemented the first draft of the timer.
# randi - gets a random integer between b and b + a - 1.
# in this case, between 1 seconds and 10 seconds.
var timetowait = (randi() % 11 + 1)
print("Wait time = %s" % timetowait )
await get_tree().create_timer(timetowait).timeout
# get distracted after the timer is up
focus = false
$AnimatedSprite2D.play("look")
The sprites use Godot’s AnimatedSprite2Ds to allow for the idle animation. Godot’s animatedsprite2Ds can be called (“play”ed) via events and functions, making them perfect for the widget. All it needs to do is
- Idle (work)
- Get distracted
- Get refocused
And these are all event based.
The hats will most likely be implemented via spritesheets. They only depend on the current points value. Ideally, when a threshold is met, the hat sheet can iterate by one, seperate from the buddy sprite.
MARCH 27 I drew the sprites for the buddy. I want to have the option between two colour options, grey and blue. I’ve created variants for both. I also want to make the buddy resizable and movable. Sometimes when I’ve been trying out the prototype I’ve switched tabs to change my music and haven’t been able to hit the button because he’s in the way.
MARCH 20 Out of time concerns, I’ve decided against making the widget in 3D. I’m not experienced with rigging at all, and have very limited experience with Blender. I can apply my general programming knowledge to Godot, but I don’t have many transferrable skills that would apply to Blender. I don’t think this negatively affects the project. Sprites are generally easier to work with, I can draw very quickly, and should be less resource intensive.
EASTER BREAK
MARCH 17 My project involves working with people with ADHD, so I’ve been referred to the ethics board. I sent them the details today and hope to hear back soon. I had to fill out a couple forms, which actually helped me get a better idea of how I wanted to carry out the trials. I’ve decided against asking for any medical records for privacy and data reasons. Not restricting myself to subjects who are simultaneously 1. Diagnosed, 2. Willing to share this information, 3. Willing to share a diagnosis, and 4. Willing to take part in a (possibly kind of boring) trial has made the trials a lot more feasbile. I plan on putting up posters around the uni, but don’t expect many applicants, so I’ll probably have to reach out to classmates.
MARCH 5 Proof of concept built. The widget sits in the corner of the screen, and after a short timer, looks up at the user. Once clicked, it resets and goes back to looking.
Godot has a built in timer function.
await get_tree().create_timer(timetowait).timeout
This was made for the idea presentation in class, but provides a good framework to expand on. The basics of the program itself are relatively simple.
It needs to sit in the corner of the screen on the front layer and be interactible. There’s a type of program called a “desktop pet” that sits in the corner of your screen and moves around. I’m not very familiar with godot, this project was an excuse to start. I followed the beginning parts of a desktop pet tutorial to start the prototype as it fulfils the requirements needed for my widget.
get_viewport().transparent_bg = true
window.transparent = true
window.borderless = true
window.always_on_top = true
window.unresizable = false
A couple of these are redundant (viewport transparent and window transparent) but window transparency can be finnicky, so the more failsafes the better.
txto