[{"content":"I\u0026rsquo;ve been wanting to make games for over 20 years.\nI\u0026rsquo;m a programmer and engineer by trade, but I\u0026rsquo;ve always had a creative streak. I make music, I do 3D art, I like building things with my hands as much as with code. Games sit at the intersection of all of it: logic and art and systems and story, all in one place. It\u0026rsquo;s the creative outlet that lets me bring everything together.\nFor a long time, life got in the way. That\u0026rsquo;s not a complaint. I\u0026rsquo;m a husband and a dad to two boys, and building a stable life for my family has always been a top priority. But I\u0026rsquo;ve reached a point where I can finally give this a real run, and I didn\u0026rsquo;t want to wait any longer.\nSo here we are.\nStill Small Studios is how I\u0026rsquo;m doing it. The plan is to build four small games, learn everything I can from each one, and then make the thing I\u0026rsquo;ve been thinking about for two decades: a simulation game, something in the city builder or management genre, made with enough craft and care that my boys and I can sit down and play it together.\nThat last part matters more than I expected it to. My kids are in grade school, they already like playing games with me, and the idea of building something they might be proud of someday is a bigger motivator than I would have guessed.\nThis blog documents the journey. The technical problems, the design decisions, the dead ends, and the occasional thing that actually works.\nThe Stack\nEngine: Godot 4 Art: Aseprite, Blender Language: GDScript ","date":"22 March 2026","externalUrl":null,"permalink":"/about/","section":"Still Small Studios","summary":"Still Small Studios is a solo game dev studio run by a programmer, engineer, and dad of two who has been wanting to make games for over 20 years. This is how he’s finally doing it.","title":"About Still Small Studios","type":"page"},{"content":"","date":"22 March 2026","externalUrl":null,"permalink":"/categories/devlog/","section":"","summary":"","title":"Devlog","type":"categories"},{"content":"I\u0026rsquo;ve wanted to make games for a long time. Not in a vague, someday kind of way. I mean I\u0026rsquo;ve had ideas, notebooks full of them, and zero shipped games to show for it.\nSo I made a plan. Instead of jumping straight into the game I actually want to make, I\u0026rsquo;d build four small games first. One every two months. Each one teaching me something specific. By the end I\u0026rsquo;d have the skills, the habits, and the confidence to actually finish something and ship it.\nThis is the story of Game 1. One week in.\nWhy Picross? # I needed a game that was:\nScoped. No feature creep. A picross game is a picross game: there\u0026rsquo;s a grid, there are clues, you solve it. Mechanical. I wanted to spend my time learning Godot, not designing systems. Rewarding to build. Every puzzle you solve reveals pixel art. That felt worth making. Picross (also called nonograms) are logic puzzles where you fill in a grid based on number clues along each row and column. The numbers tell you how many consecutive filled cells are in each line. You figure out the rest.\nClassic. Simple. Turns out, not as simple to build as I thought.\nWhere I Am After One Week # After one week of work, I\u0026rsquo;ve hit my first milestone: a playable prototype. Not a finished game, not even close. But something I can hand to someone and they can play it start to finish:\nA fully functional nonogram grid with fill, cross, and drag input Row and column clues that generate from puzzle images A solve detection system A completion screen that reveals the pixel art A timer It\u0026rsquo;s rough. The art is placeholder. There\u0026rsquo;s one puzzle. But the core loop works, and I built every piece of it. That matters more than I expected it to.\nThe game still needs a lot of work before it\u0026rsquo;s actually finished. But having something playable this early in the process means the foundation is solid enough to build on.\nWhat I\u0026rsquo;ve Already Learned # 1. Input is harder than it looks # The first version of drag input used Godot\u0026rsquo;s mouse_entered signal on each cell\u0026rsquo;s collision area. Move the mouse slowly: works great. Move it quickly: cells get skipped. The signal only fires when the mouse physically enters a node\u0026rsquo;s collision area, and at high speeds it can jump over cells entirely.\nThe fix was to stop relying on signals for drag detection and handle everything in _process. Every frame, I calculate which cell the mouse is over directly from its position, then fill all cells between the last visited and the current one. No gaps, no skipped cells.\nI also added axis locking. Once you start dragging in a direction, you\u0026rsquo;re committed to that row or column. It prevents accidental diagonal fills and makes the game feel much more intentional.\n2. Animation and state don\u0026rsquo;t mix well by default # When you fill a cell, it plays a little pop animation. Satisfying. But early on, you could right-click a cell mid-animation and cross it out while it was still filling. The state would change but the animation would finish on top of the new state. Looked broken.\nThe fix was a single guard at the top of the state setter: if the animation player is playing, ignore the input. One line. Took me longer to notice the problem than to fix it.\n3. Generating clues from images is elegant # I was expecting to hand-code every puzzle\u0026rsquo;s clue numbers. Instead I draw the solution in Aseprite, export it as a PNG, and the game reads the pixel data at runtime to generate the clues automatically.\nEach puzzle image has two frames side by side: the color art reveal on the left, the black-and-white solution on the right. The game reads the right half to build the clues and check the solution. The left half is the reward.\nIt means designing a puzzle is just drawing a picture.\n4. The state machine I thought I needed, I didn\u0026rsquo;t # Early on I added a node-based state machine plugin to manage each cell\u0026rsquo;s state (empty, filled, crossed). It worked, but it was a lot of infrastructure for a problem that didn\u0026rsquo;t need it.\nEach cell has three states. The transitions are simple. A GDScript setter function (a function that runs automatically whenever you assign a variable) handled everything cleaner: play the right animation, update the display, emit a signal. No extra nodes, no extra files.\nSometimes the simple solution is the right one.\nWhat\u0026rsquo;s Still Left to Build # A playable prototype is a starting point, not a finish line. Game 1 still needs a lot before it\u0026rsquo;s a real game:\nReal puzzle art across four chapters Chapter select and puzzle select screens A gallery to view completed art Music and sound effects A proper itch.io release I\u0026rsquo;ve got roughly seven weeks left on the two-month clock. Plenty to do.\nStill Small Studios is a solo game dev studio. I\u0026rsquo;m building four games in eight months to learn before I build the game I actually want to make. Follow along.\n","date":"22 March 2026","externalUrl":null,"permalink":"/posts/teaching-myself-game-dev-shipping-games/","section":"Posts","summary":"I set out to teach myself game development by building four small games. One week into Game 1, I hit my first milestone: a playable picross prototype in Godot 4.","title":"I'm Teaching Myself Game Dev by Shipping Games: Here's Prototype #1","type":"posts"},{"content":"","date":"22 March 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"22 March 2026","externalUrl":null,"permalink":"/","section":"Still Small Studios","summary":"","title":"Still Small Studios","type":"page"}]