Your code appears to be working exactly as intended.

I've been using Typo and Floating Text to do text rendering things for previous projects. Both have certain implementation details that don't suit my needs anymore, so I decided to make my own. The primary benefits of Scribe/Waft are: Library instancing Runtime customizability Simplified API Optiona...

In case you still want to use hump.camera, I happen to have an old implementation of screen shake using that library alongside hump.timer: local cameraFile = require('libs/hump/camera') cam = cameraFile() local camSmoothing = cam.smooth.damped(8) local camTimer = globalTimer.new() local cameraShakin...

1. 'ar' is a terrible, non-descript variable name 2. 'sav' instead of 'save' for the sake of abbreviating a mere four letter word into a 3 letter filename 3. 'fnt' instead of 'font' for the sake of abbreviating a mere four letter word into a 3 letter variable name 4. 'tmp' instead of 'temp' for the ...

The problem is that you are scaling up the canvas in order to pixelate the circle. You've essentially "zoomed in" on the canvas' coordinate plane, which makes the circle visually snap to a grid. If you want a pixelated circle that moves smoothly, the easiest way is to use a texture, scale ...

Matthew Devander has an excellent video that goes into detail about "honest" level design (more particularly puzzle design). The word honesty here essentially reflects an idea that the level designer's job isn't working to inconvenience the player. The designer doesn't create puzzle soluti...

Is it possible to programmatically determine widgets for the template? I don't mean dynamic widget state during runtime, but rather template generation at runtime. Something like: return Yui.Ui:new{ x = x, y = y, Yui.Rows{ --widgets by iteration for i,v in ipairs(extern_values) do Yui.Button{ ... } ...

I keep a list of all objects that can collide, but I also have tables whose membership is predicated on how it's members would respond to a collision. In other words I have a "damageable" table, a "damaging" table, a table for objects that affect physics (walls), and a table of ...

In the end damage is done and since it should be simple subtraction, order doesn't really matter, does it? The subtraction was just an example for demonstration's sake, my actual game's callbacks are much more involved. By "universal" callback do you mean something like this approach? fun...

In the evolution of my project, more and more objects are interacting and colliding with each other. This is presenting an interesting "philosophical" (architectural?) problem regarding collisions which I can't quite figure out a clean solution to. Not so much a technical "how-to"...