So, my sister’s glasses broke.
This is going to be a short project lasting one devlog…here we go!
Getting to the bottom of the issue
The hinge part connecting the temple to the screw broke off. After many hours trying to glue them back together, I decided to 3d print a whole new temple, alongside a stronger hinge for the screw.
Temple dimensions
Using a trusty ruler, I measured the parts of the temple, first from the top, then at the side, so that I could replicate these dimensions in Onshape.
I constantly had to compare the physical proportions to the CAD, so that it (hopefully) looked as accurate as possible.
CADing
Finally, it came down to using sketches on the top, front, and slightly angled planes to establish the structure of the temple. Then I extruded separate parts on each plane and connected them using lofts (with tangents) for smooth transitions.
The struggle with hinges…
No wonder the metal hinges on the original glasses broke. They’re like a mm (maybe less) thick, and the 3d printed hinge definitely broke!!
So instead of accuracy it was time to prioritize strength.
Instead of wedging the hinge into the cavity of the glasses hinge, forcing it to be thin and weak, I would wedge the hinge OVER the glasses hinge! (Makes no sense in text but hopefully in the images)
Finale
After printing, gluing, and sanding, the temple was finally complete. I used a slightly longer watch screw to connect the part to the glasses, and viola! It was done. :)

After attempting to print more air-tight pistons, I realized a flaw: I had changed the piston multitudes of times, and then printed all the different versions once over a series of trials!

Oops. So that means I don’t know which dimensions are air tight?

… Yes.

That meant experimenting more! I definitely had a better idea of what dimensions worked, but, er, that took a while.

After successfully printing a air-tight piston, I now had to face an even bigger issue.

See, the beta stirling engine actually has overlapping pistons, meaning one rod goes through another. This is pretty easy to design; just make a whole for the piston rod to slide through. But the big question is how I’d make this airtight. The solution was a tiny o-ring at the opening of the aforementioned hole.

This took quite a while to perfect. I needed the o-ring to compress a bit, while not being too hard for the rod to pass through.

The solutions:

1. Make the end of the rod rounded; sharp edges don’t transition smoothly.
2. Glue the o-ring so that its hole is slightly smaller than the rod diameter.

I also printed out the base with some adjustments:

1. The cylinder is separated from the base so that it can be printed more precisely.
2. The base is cut down to use less filament.
3. The screw holes are smaller to actually be compatible with my screws.

(I’ve done it again! I’ve went over the 10 hour limit TT-TT)

10 hours. 10 hours to make a piston that seals air in a cylinder.
(And 1 more hour that won’t count because technically at 10 hours I still hadn’t sealed the air yet TT_TT)

I realized that rubber bands would not seal effectively, so I just got some cheap o-rings from amazon instead. But gosh, sealing was way harder than I thought it’d be!

The Process
At first I just created a simple groove in Onshape and experimented with my existing cylinder. But there wasn’t enough space for the o-ring to compress.

What followed was a lot of testing, trying out thicker and thinner o-rings, experimenting with the cylinder size for the power piston to slide smoothly, etc.

I fell down this deep rabbit hole of using a bigger cylinder bore and a thicker o-ring, printing and reprinting with different dimensions to find what worked.

To figure out if a piston seals correctly, the piston should “float” back up once you push it down, as without your compressing force the air can expand once again.

But none of these tests worked. I couldn’t figure it out, haha. I even tried Parker’s handbook of o-rings, but couldn’t figure out how it worked (my own skill issue :’) ).

But when I examined pistons that worked, I realized (after a while) that the problem was that the piston was too small! For the cylinder, anyway, so much so that when I pushed the piston down, it didn’t go in a straight line. It had the ability to tilt, letting air escape. So I made the cylinder smaller, but with enough tolerance to let the piston slide, and used lubricant!! I’m happy that after how many tries, the piston finally seals the air.

However, there’s much to improve on.

• The tolerance between the piston and the cylinder may be too small. There is friction between the two that interferes with performance.
• The groove is a bit too deep. Also the piston can seal air now, there is still quite a bit of air lost.

Hopefully these will be easy fixes. I’m glad I’ve learned from my many trials and errors.

I have added more to the inverse kinematics of my robot dog. Targeting the bottom left leg, I:

• Created the functions Calc_femur, Calc_tibia, and Calc_hip to individually calculate the designated angles for each part based on the variables x, y, and z.
  • The code had already implemented the math from my Desmos demonstrations in the previous devlogs, but this allowed for a more organized system.
• Created a void move_to_position function that collected outputs from Calc_femur, Calc_tibia, and Calc_hip, using them to run the servos in turn.
• Used an array system to realize the pins of the servos (on the PCA9685) and their respective max and min PWM (based on calibration)

What’s great is that the femur is working as intended! In comparing its position to the position on the Desmos graph, the calculations are accurate.

On the other hand, I’m still struggling to properly calculate the angle for the servo moving the tibia. The issue is that I have to take into account the angle offset (the angle the servo is turning is not the same as the resulting angle between the femur and tibia) and the fact that the rotating femur influences the angle of the tibia.

Another thing I have to fix is the discrepancy between the math for the hip servo and the output. Yet another issue to handle (TT-TT)

But it’s a learning process that I’m happy to take part in :)

Woah, I got a lot of stuff done!

Here’s a layout of what I finished:

• Designing the real layout of the Stirling engine (linkages that don’t overlap)
• Cylinder and base
• Gear holder
• Holes for screws
• Completed power piston
• Completed displacer piston
• Flywheel

However, after printing the first few parts, I realized a few issues at first:

• The linkages were too thick for the screws
• The displacer piston couldn’t be threaded through the hole of the power piston (that was my mistake)

So, I made the linkages thinner and adapted them to be more screw-friendly, and sliced the displacer piston into multiple pieces so that it would be possible to build and use.

On the second iteration, I printed out the base and an official gear holder to attach. There I found more issues:

• The power piston had too tight of a fit. It couldn’t smoothly slide into the cylinder.
• The flywheel wasn’t heavy enough. The goal is to have the gears spin for an extended period of time once the flywheel is spun, but the gears only rotate about twice.
• The connection between the gear holder and the base had bigger screw holes for smaller screws, so I have to make that connection thinner.

For the future, I think I should add a cavity in the power piston for something like a rubber band. Since I have no o-rings, that’s my cheap alternative for sealing, haha.

Ok, I’ve been working on the Rhombic Stirling engine for a while now!

I tried to use math to figure out the lengths of the linkages for the optimal dimensions, and a phase offset of 90 degrees. I even tried to use MotionGen. Unfortunately, the math was faulty––the website I found it on even calculated the wrong answers for the practice questions. And MotionGen wasn’t working. The minutes of Google searching wasn’t getting me anywhere in troubleshooting, and I just gave up.

So I resorted to good ol’ guessing and checking XD. Like I stated earlier, I will be using Schmidt analysis to determine if the engine will really run though, so no worries! I’ll still use math…

After a few iterations I was able to reach one I was happy with. It not only ran smoothly in Onshape’s assembly, but also allowed the displacer to be about 90 degrees ahead of the power piston, as is optimal.

However, figuring this out was not as easy as for the crankshafts. For the Rhombic Stirling, to determine the phase angle, one must:

1. Mark the gear in some way.
2. Turn the gear until the power piston is at the topmost of its stroke. Take note of the position of the mark on the gear.
3. Turn the gear until the displacer piston is at the topmost of its stroke. Again, take note of the position of the mark on the gear.
4. Measure the angle between the position of the first mark and second mark.

Fortunately for me, my 4th-5th iteration produced a 90 degree phase angle, which is lucky for a guess and checker :).

The first two photos are missing a linkage for clarity. The third features the full linkage.

I finished the design of the Stirling engine and printed it out! But I’m far from done.

I’ve added:

• A cylinder
• A stand
• Deeper holes to make it easier to screw into the design

Printing this took about 4+ hours, and putting it together who knows how long.

However, there were major flaws that I was able to pinpoint:

• The cranks don’t always move uniformly. Although they are screwed together, as 3d prints, they don’t actually have threads, so the screws are able to rotate independently from the other cranks.
• It’s hard to spin the shafts, and the cranks, at the same time, because of the issue above and friction.
• And…the most obvious…it doesn’t work.

I think it’s because of the aforementioned flaws, and because I was designing the beta engine based on mechanical linkages alone, not size or pressure, etc.

So now, I’ve decided to redesign the beta Stirling engine as a Rhombic Stirling engine, and go deep into the math using formulas from stuff like Schmidt analysis.

Yes…I made another mistake that I had to fix -_-

If you look at the photo in the previous devlog, you’ll notice that the connection between the displacer piston and the crankshaft actually overlap the power piston’s shaft—it moves in front of the connection between the power piston and its crankshaft! This was very hard to model in Onshape.

So I had to improve the linkage so that the power-crankshaft connection moved in the front instead. After a bit of tweaking (and painful double-checking), the linkage seemed alright.

So, I modeled the system in Onshape and it seemed to run well.

Now I have finalized the linkages, making sure that they don’t overlap and run properly, and everything finally seems to check out!

I’ve learned that prototyping, design, and checking my work is very important when it comes to engineering. I should learn to be less careless and spot these mistakes before investing too much time into them!

Although this was frustrating, I’m very happy that I learned that lesson :)

Ok, so I solved an issue while making a mistake. Silly me!
I created another linkage in MotionGen that fulfilled all the requirements from the previous devlog:

• The pistons don’t overlap
• The areas connecting the linkages don’t overlap

Unfortunately, in focusing on this, I forgot a crucial requirement: that the displacer crankshaft should be 90 degrees ahead of the power crankshaft. I had done it the opposite way. Instead, I set it up so that the power piston’s crankshaft was actually 90 degrees ahead.

By that time I had already modeled a prototype in Onshape and started CADing the final. But oh well, I should fix my mistakes anytime.

So! I have redesigned the linkage in MotionGen and it should fulfull all the requirements and have no mistakes (my peanut brain is bound to make one more though :’) ).

I hope to create a working prototype in Onshape to finally build and test it.

I experimented on the linkages for the beta engine and found a way for the displacer and power pistons to not overlap. I did this by:

• simulating different linkage lengths in MotionGen
• using a rotating crank and a slotted link.

Unfortunately, while one problem was solved, another problem appeared: the linkages were overlapping now!

If you look closely, the areas connecting the pistons to the linkages overlap. Obviously this is a big issue that I will have to solve.

So, now I have two goals:

1. To have the power and displacer pistons not overlap
2. To have the linkages not overlap, either. (How many times have I said “overlap” in this devlog?)

I plan to do this by examining the positions of the pistons when they are at their most extremes (when the displacer is at the left-most and when the power piston is at the right-most).

Hopefully this gets solved by today!

Now was the time to delve really deep. Now that I had the layout figured out, I needed to make the mechanism actually function. If you’re interested, the theory is in the photos down below!
In case you can’t read my horrendous handwriting:

1. The hot air moves to the center of the Stirling engine.
2. Because the hot air moves to the colder area, it becomes colder and compresses. The compression moves the power piston.
3. The cold air is then shuttled by the displacer to the hot end. The cold air becomes hotter and expands, moving the pistons and flywheel. The flywheel’s angular momentum continues to move the pistons, returning the cycle to its first stage.

Throughout steps 2-3, the flywheel keeps the momentum and continues to move the pistons. Unfortunately, I haven’t pictured the flywheel in relation to the engine, but you can imagine that the flywheel is at the axle of the crankshaft.

So, from what I knew, the cranks of the pistons needed to be, optimally, 90 degrees offset, with the displacer piston 90 degrees ahead so that it could shuttle the air first.
Then, using the diagrams I drew below, I configured one of the phases into Onshape to hopefully create a working mechanism.
The design is still in the works, but I think I at least have a nice working structure! :)

OK, I’ve decided to stick to the crankshafts for now! I figured that I at least need to know the basics of designing SEs before diving into the more unique variations.
This is less of a design, but more of a lay-out (albeit incorrectly :P). It has:

• The displacer piston (blue), which moves the working fluid through the engine
• The power piston (white), which transmits the output rotational force
• The linkages (aka crankshafts) for each piston (with their corresponding colors)

The difficult part was laying out every part in such a way that they didn’t overlap or cut into each other (at least the linkages). I was focusing more on the structure rather than the function, so the pistons are positioned incorrectly and will overlap each other when put into Onshape’s assembly!

I’m aiming to create a mechanism that actually functions correctly.

Stirling engine redesign

First of all, what is a Stirling engine?
A Stirling engine (SE) is an external combustion engine powered by heat. What did that jumble of words mean? Basically, unlike conventional engines, SEs don’t require fuels inside the cylinder to react. Instead, they use fuel or fluids outside of the cylinder, the aforementioned hot air. Interestingly, SEs can also be powered by cold air, so technically SEs are actually engines powered by temperature differences, not simply heat.

Okay, but what’s a beta Stirling engine?
Stirling engines have so many types! The alpha, beta, and gamma are the main ones. What these random names describe are the different configurations of a SE. The beta engine is a specific structure.

The dilemma
I was working on the SE in Onshape until I reached a pit stop. I was using mechanical cranks, but they cut through the axle! I checked some simulations and found that there had to be literally no axle in between––meaning that the axle would have to be cut. So I’m wondering if I should switch gears to a Rhombic drive mechanism. I’ll delve more into that next devlog. Seeya there! :)

(I know the video assembly looks wonky because it’s not put together properly, but you can see the issue pretty clearly)

I finished the game! :D
Added sound effects for:

• Clicking buttons
• Player attacks
• Phoenix attacks
• Phoenix caw (to signal to the player that a barrage of projectiles is coming if they are too busy with the attack button)
• Background music!

The quiz
I finally added real questions! I wanted to focus on spelling for this one, so I used emojis and asked the user how the words representing them were spelled.

Text stuff

• Added text instruction at the beginning
• Changed fonts of the text nodes featuring emojis (more on that later)

Web shenanigans
I wanted to make sure that the game would be available on devices that did not support downloading .exe (like chromebooks, for example).
But uh…that was harder than I was expecting!
I used netlify to create a url after exporting the game for html5. The first issue in business was that the camera was zoomed out when the website was launched, showing the gray blank space of the Godot dimension. This took a bit to figure out, but apparently I had to adjust the stretch mode and aspect in project settings.
The second issue was that the emojis were showing up as white-boxed hex codes in the web version (for some reason!! >:( ). Turns out that I needed a different dedicated font for the emojis so that they could be compatable on all devices. Oh well, haha. At least it’s more accessible! :D

(PS. I’m sincerely sorry for the terrible audio quality in the video, I can’t screen record and the speakers on this computer are outrageous :’) )

I’m so close to finishing the game! First of all, I finished the attack system.
Basically, you answer a certain number of questions under the “attack” button, filling up the bar next to it. When it fills up, you unlock a new weapon. After it cools down, you can use it; but on the first time of cycling through every weapon, only once! As you complete more cycles, though, that increases to twice, then three times, etc.
I also added pixel art to the buttons. I took away the “attack” label of the attack button because the students I tutor don’t know that word yet. Instead, I used an animation in hopes of incentivising them to click it.
The other buttons include:

• The arrow
• Two arrows
• Copper sword
• Diamond sword

Which brings me to my next development––when you click those buttons, there’s an actual attack! An arrow animation, a two-arrow animation, a copper sword animation, etc were added to the mix.
I hope to add music, SFX, and maybe simple instructions for the future.

Finally, I implemented a losing and winning screen using the same node in the system, detecting player and enemy health.

I added functionality to the attack system! Now it can:

• Show the question and input text box when the attack button is clicked
• Detect correct answers and wrong answers

I also added:

• An attack bar that stores how many answers you got correct. Once you’ve answered a certain number of questions correctly, I plan for a button on the left to unlock
• You may already notice the buttons in the bottom left! When I filled the bar once, one of the buttons unlocked, a timer ran out (signified by the white bar), and I could click the button.

For the future:

• The buttons you have to unlock are actually buttons that allow you attack! So I’ll add different attack functionalities to different buttons.
• The buttons look kinda bland. I’m planning to add some sprites in place of the buttons.
• I’m thinking of putting some transparent gray space behind the text to make it more readable.

I really hope I can finish this game next devlog! Seeya there! :)

I’ve put some of the pixel art into the game, and it’s looking good!
The thing about the prototype is that it didn’t consider scale or size, so I had to change:

• The placement and zoom of the camera
• The size and tween animations of the quiz questions
• The player and enemy sprite + hitbox size

However, I also finished:

• Health bars for the player and boss
• Tweens that would smoothly adjust the health (which was why the red health and the bar were drawn separately)
• Areas where the projectiles would be slow or fast. Initially this was controlled by timers, but I found that this was too buggy for my mom’s computer, so I just used area detection instead to make everything more consistent.

For the future, I added:

• An attack button
• A text input box (line edit node)
• An area for the text questions (label node)

For now, there is no function yet, but this will be used for an attack system. How it will work is that, when you press attack, you are given a question requiring a typed answer. Answering it correctly would send a powerful attack to the enemy, while answering it wrong would decrease your health by a little bit.

Looking forward to implementing this system!

(Also don’t worry, I’ll def add pixel art for the player and the arrows trust :D )

Wowee, I finished the background!
I mostly worked on the tiles and shadows, which I hope makes the environment more immersive and detailed. I also added in some of the complete assets into Godot!
While I still have some pixel art to work on, such as:

• The player
• Arrows
• The projectiles exploding animation
  I think now is a good time to take a break from Aseprite and work in Godot.
  Since the pixel art is already way smaller than the original prototype, here’s what I need to work on:
• Adjusting the game code to the new screen size
  • Slowing down projectiles and adjusting the time when they slow down
  • Changing the question tweens so that the text doesn’t fly off the screen
  • Changing player position
• Adding in the health bar sprites with functionality
• Implementing animation phases for the boss (play this animation when attacking, play this animation when idling, etc)
• VFX and SFX

Worked on the background environment. Added:

• Pillars
• Doorway
• Brick texture
• Shading
  The most difficult thing for me is to make every element fit together. I hope I can finish the background today and probably work on the player and arrows. I also just realized that I should probably work on the projectile dissipating animation, too. Off to work!