Before, I did a thing that probably wasn’t the most advisable – have a mesh for the background of my buttons, with the color material added on, and then scaled it like crazy to make it the size I wanted. That was then embedded in my prefabs for each moveable letter.
Unsurprisingly, this got wonky in the following ways:
- every time unity updates, it lost its link to the material, or to the prefab, and turned bright pink
- it was scaled bonkers-like, making all other scaling around it really annoying (particularly since text, notoriously tricky to scale, is involved)
- It just didn’t seem like the most elegant way to do this
So today I finally decided to fix this. I didn’t do it in the most elegant way, but I used Grab to get the color and shape out of it (I actually like the color and shape for a beginning draft, and it’s what I prototyped with and it worked, so no need to change it now). I checked the scale size on Unity to find out that it was approximately 4/3 x/y. Then I sized and resized it in GIMP, and brought each png back as a prefab and compared. Wound up being pretty perfect at GIMP’s canvas size 122 x 88 pixels at 144 ppi.
I believe that I can’t add in prefabs after the fact – is that true?
I followed these instructions to get my textmesh to appear above my new 2D sprite. The textmesh is childed to the sprite. The sprite is Z=0, textmesh is Z= -1.
The sprite I’m using is from the png onset-block-updated-122-88. I’m going to child that to an empty game object just named “1” so that my scripts work with the onsets.
With the textmesh childed to the sprite, the sprite is no longer involved in the scale shenanigans I’ve been using to make the font quality look nice. I’d like to return to this, and to try out TextMeshPro again, bc this is some buuuullshit that I have to do this wonky thing with the text and there HAS to be a better way, right?
Alright, now I have an empty gameobject parent (1), that has childed to it the sprite (onset-block-updated-122-88) [gotta name that better] and the text (Text).
It needs the following components:
- Box Collider 2D [for Move Object Script]
- Rigid Body 2D [for Move Object Script]
- Move Object Script
- Play Sound Child Script
This way, the children only have one component each. For the sprite, it’s just a sprite renderer. For the text, it’s just the textmesh.
Hopefully this will keep it simpler!
So on the one hand, my next goal could be:
Completing this for all of the prefabs inside this scene, so that everything looks beautiful. That includes:
- middle block (same as onset but different color)
- end block (same as onset but different color)
- 3 answer slots
- flashcard (this one is particularly inelegant, with the textmesh offscreen – I should probably just make the textmesh in the back, and I could consider having a button to press to show the answers (which should only be possible if all the answer slots are filled in)
- This is an exciting idea, because it’s one step easier than checking the answers and giving feedback. It basically just gives *you* the answer, and then you can correct it. Not sure how this would work with kids, but there’s a chance it’d be good. It’s at least a thing to make and see how it works – maybe the feedback system isn’t even necessary and this is enough. But at the least it’d be a useful step as a comparison in prototyping.
- This is also useful to think through because when I redo the flashcard, it should be with this in mind.
- Also, how do kids know they’re supposed to press the flashcard? Wouldn’t that be nice if it was more obvious, or if there was a brief tutorial
Question for self – if I have the textmesh overlaying the sprites as *part* of the prefab, will that mean that when/if I change the prefab, I’ll have to change all of the text again? That feels unfair. And feels like it relates back to – I should have the text brought in automatically. Maybe I should go ahead and build it that way, and hope that I can do it well and it passes the app store. Cuz otherwise I’m going to spend an ungodly amount of time putting text in.
Hm. Nah. One thing at a time, Brittany. Let’s get this in the app store and build up features from there.
Next step – make a good prefab for the middle bits.
- get png from the onset
- get Grab of the middle block, to get the color
- use GIMP to change the purple to orange
- save as .xcf
- export as .png
- put in sprites
Then, make a duplicate of the onset prefab, rename to middle, and switch out the sprite. Everything else should be the same.
#todo – this is probably a great instance of a branching prefab. Or a linked prefab. I don’t know how to do those, so I’m just going to have them be entirely independent. Excited to someday make these link up.
As part of this, I should decide on some naming conventions and keep them stable. For instance “onset-block-updated-122-88” is not a great name. It should probably just be
Unsure if I should keep in it what size it is, bc it was actually a real pain to figure out the size. I think that means I keep it in. How about:
That feels optimally clear without looking too awful. Still looks kinda bad. Okay I’m gonna try that out with the middle blocks and see if it feels good.
Actually it looks like textmesh content doesn’t change with prefabs. This is GREAT news for me in this instance – I just realized my textmesh color was grey-ish, and that it was making the blocks look weird. I changed the onset prefab textmesh color to white (FFFFFFFF) and ALL of the onsets changed. Didn’t need to even press any buttons. YAY
what should z be on gameobject
I dislike how when I zoom in on a gameobject, it disappears bc of where its z is. That’s a frustrating thing to happen in a 2D space, but I guess I get it. #todo – I’m unsure what to put my z objects at. It feels weird to put them artificially back (z = high positive number like 20) just so that I can zoom in, but it’s also annoying having them disappear when I zoom. I don’t really understand spacial relationships very well so this might be interacting with it.
Also somehow all my onset collider boxes are totally off. Gonna see if changing the prefab works. YAY – I couldn’t change the collider box *in* the prefab, but I made an instance of it in my scene, changed the collider box, and hit “Apply” and everything else changed. Crucially, the textmesh contents did NOT change (like before). This is very exciting.
So I need to change the sprite names, both under Onsets AND middle block. cuz they both wound up being wacky. Going to finish Ends first.
Curious, I’d never noticed before that the end blocks were a different size than the others. Or, I noticed, and didn’t care, cuz this was some pretty rapid prototyping that I’m leveling up!
Alright, this is good progress. Slow, but good. Gonna take a 30-min lunch break and set this laptop aside so I get out of work mode. And charge this laptop, too. Maybe it’d be good for me to switch locations after lunch.
Nevermind, the kitten’s asleep on my foot, so I’m never moving again. The only things in reach are popcorn, red wine, and my computer, so I think I’m all set! Time to get working again.
- onset: purple, hex color : 8A3FE7FF
- middle: orange, hex color : F85757FF (I think?)
- coda: green, hex color : 3BCC36FF
I don’t *quite* know how to put that into GIMP, but it seems to be working to just use the grab method followed by color picker.
#todo – make kerning / vertical and horizontal centering consistent with fonts on these buttons. In the meantime, I’m going to just eyeball it.
Okay I just want to reiterate that now that I learned how to deploy prefabs better, they are AMAZING HOLY COW. This little “apply” button is the BEST THING EVER.
#todo – related to kerning, I might need to have different prefabs for different widths of texts, if I want this to be automatic. OR I can just do it manually for a while. It really doesn’t interfere with anything, and I believe that having automated feedback would be FAR more desired by teachers than having the kerning be perfect. So let’s keep to our priorities here!
Okay, so possibly instead of having just the answer block as prefab, I should maybe have the entire answer situation (3 colorful slots + block) as prefab. That way they’ll each look the same. This argument could also be made for onset, middle, and coda rows, but I’m not sure about it yet. It feels right-er for the answer portion, but I can’t pinpoint exactly why.
Ooh now that my z numbers aren’t bonkers, I can zoom in on everything. Was that actually just because they weren’t even, and it was messing with it? Can’t say for sure but whatever it is, this is nicer this way.
Okay, so when all the blanks are filled in, there can be a big “check your work” button. This avoids having kids try to press the button before finishing. It’s not ideal, because it may encourage them to hit it and get the answers – so something about the feedback system will eventually want to be encouraging them to do self-reflection.
#todo Plan for giving feedback: I’ll start just giving them the answers. Then I’ll move on to saying how many they got right on the first try, then the second try (and recording it somewhere, so that they’re encouraged to go back and check their work before pressing the button), then I’ll potentially move on to automated/guided feedback.
#todo Gosh I gotta fix the appearance of my menu. It’s needlessly html-looking.
I wonder if I should try to just get a single scene into the app store, or if I should try to get a small menu up and running. That might make more sense, and look less like a Beta version. Although if that doesn’t work, I can always go back to the single scene version.
Thing to fix – now that they’re all beautifully in the same z spot, they actually overlap each other in disturbing and distracting ways. Fix this soon.
#todo : make prefabs for quiet blocks that don’t have playsound script on them
wth is “graphic raycaster script” on the menu? Without it the buttons don’t work. Fascinating.
I removed “Canvas scaler” and it still works, but doesn’t get rid of the 2 yield signs “the rferenced script on this behavior is missing” and “the reerenced scirpt on this bheavior (Game Object “) is missing!
So I put canvas scaler back on cuz I think that has something to do with how the canvas appears on different pieces of technology.
Okay, so now I’ve got it reduced down to just 3 levels, and it’s mad at me for something about the buttons in the menu.
WOOOOO I FIGURED IT OUT it was something about the Menu button inside the levels. Basically when the scene loaded it seems to have noticed that the Menu button’s script was defunct, and then threw a warning. Odd that it didn’t show up when the level was loaded by itself (as opposed to through a button on the menu), but that’s okay – I feel pretty good about being able to find errors like that faster now.
That being said, there’s apparently this magic script that can go find them – but after about 30 seconds of trying to use it, I couldn’t figure out how to.
#todo – at some point I’d love to figure out how to use this as a tool. Wasn’t worth the rabbit hole this time tho.
Do I need to compress the audio and/or delete all the audio that’s not immediately relevant? That might be worth it, keep the size down.
Now I’m going to the backup copy to find out what words were in the other scenes, since I totally messed with these. Backups are important!
I’d like to go make mockups of everything, with the content in it, so that if smething happens iwth Unity, it just isn’t a big deal.
8/17 – So yesterday evening around 6:30PM I finished getting it set up pretty-like with 3 levels (2 difficulties each) and a single menu screen. No errors or warnings!
Today my goal is to start the process of getting it on the app store. This is going to be pretty painstaking so I’m going to keep careful logs of it and be patient with myself.