Archives

Typed Lua source-to-source tooling for LuaJIT and LÖVE projects.

Tua starts with normal Lua syntax, adds erased type syntax and a small amount of LuaJIT-safe sugar, then emits readable Lua 5.1-compatible code.

Why it exists

I like Lua because it is small, direct and works very well for games, but larger projects can make it harder to understand what a value is supposed to contain or what a function expects. Tua adds stronger editor feedback and static checks without asking me to leave the normal Lua and LÖVE workflow.

The generated result is still ordinary Lua source. It can be read, debugged and shipped without putting a new runtime between the game and LuaJIT.

What Tua provides

• Erased local, function, alias, table-shape, optional-field and union types.
• Readable Lua 5.1-compatible output for LuaJIT and LÖVE 11.x.
• A CLI for init, check, fmt, lint, build, traceback, watch and lsp.
• A compiler-backed language server and VS Code extension.
• Diagnostics, completion, hover information, signature help, rename, references, semantic tokens and inlay hints.
• LÖVE-aware helpers, API catalogs, callback guidance and asset-path validation.
• Mixed-source builds where .tua files compile to .lua while normal Lua files and assets are copied into the build output.

This repository contains the compiler core, CLI, language server, VS Code extension, documentation site and bundled example projects. It is one versioned toolchain instead of a group of unrelated editor scripts.

Lua first

Tua is designed to be adopted gradually. Existing Lua modules can stay as Lua, and .tua files can be added only where stronger tooling helps.

Types are removed during compilation, so the code that runs is still Lua 5.1-compatible. The generated source stays readable instead of becoming a format that only the compiler understands.

That part matters to me. A language tool should help me understand the project while i am working on it, without making the final game harder to inspect.

Built around LÖVE

The compiler and editor understand common LÖVE callbacks, constructors and asset paths. Tua can catch missing assets, provide API completion and help navigate between typed source and generated Lua.

Opt-in helpers cover some of the systems that repeatedly show up in games: vectors, sprite sheets, typed input, signals, state stores, state machines, ECS and object pools.

They are there when a project needs them, but the language still starts from normal Lua syntax rather than replacing everything with a framework.

The editor is part of the toolchain

The VS Code extension bundles the matching Tua language server for each platform. It provides compiler-backed editing, project commands for running or debugging LÖVE, generated Lua inspection and source-linked explorers for assets, modules, signals, state machines, ECS and object pools.

The repository also includes the CLI, documentation, release binaries and examples, so the same language behavior is used from the terminal, editor and build pipeline.

What you can do with it

• Write typed gameplay code that still ships as ordinary Lua source.
• Keep existing Lua modules and gradually adopt Tua.
• Build mixed Tua and Lua LÖVE projects.
• Navigate generated Lua with source maps.
• Debug runtime tracebacks against the original Tua source.
• Use project graphs to understand modules and game systems.

Tua is still an active project, but it already represents the kind of development workflow i wanted for my larger Lua and LÖVE projects: more information while writing the code, and normal Lua when it is time to run it.

The language guide, installation instructions and complete CLI reference are available in the documentation. The compiler, editor tooling and examples are available in the GitHub repository.

Feather is a CLI for debugging, inspecting, and manage packages for LÖVE games.

It gives you a live window into your running game (logs, variables, errors, performance) without touching your game’s release build. Inspired by LoveBird and Flipper.

Why I made it

The goal is to make the day-to-day loop of writing and testing a LÖVE game faster: less time adding print statements and restarting, more time actually building.

I wanted the kind of development tools i was used to having in other environments, but made specifically for the way LÖVE games work. It started from making my own workflow less annoying and slowly became a much bigger devtool.

What it does

• Live log viewer: See print() output in real time without a terminal window.
• Variable inspection: Watch values update as the game runs.
• Error capturing: Errors are caught and shown with a full stack trace.
• Step debugger: Breakpoints, step over/into/out, call stack, local variable inspection.
• Session Replay: Record inputs plus game-defined state checkpoints so playthroughs can be replayed, exported, and debugged later.
• Console / REPL: Execute Lua in the running game.
• Plugin system: Built-in plugins for collision debug, animation inspection, audio debugging, particles and more.
• Multi-session: Connect multiple games at the same time.
• Mobile and platform builds: CLI-managed web, Android, iOS, Windows, macOS, Linux, and SteamOS workflows.
• Screenshots & GIF capture: Built-in capture plugin.
• Package manager: Install packages from a curated list of popular LÖVE packages.

How it works

Feather is injected by the CLI for development runs and debug builds, so the game code does not need a manual require for every target. The desktop app becomes the place where i can inspect what the game is doing while it is running.

The project now includes the CLI, desktop inspector, VS Code extension, plugin system, build tools and a package manager. It is a lot more than the first debugging experiment, but the reason for it is still the same: i want to spend more time making the game and less time fighting the development loop.

Try it

You can explore the interactive demo, read the documentation, or get a stable build from the release page.

The source code and current development version are available in the GitHub repository.

Generate sprite sheets and export renders from 3D scenes, fast and simple.

Built with Vite + React + Tauri for a lightweight, native desktop experience.

What it does

Sprite Sheet Helper takes 3D models and turns them into assets that can be used in a 2D game. Instead of manually rendering every frame and organizing the result, the tool handles the scene, camera, animation capture and export process in one place.

It supports GLB, GLTF, FBX and OBJ models, with lights, camera presets, transform controls and post-processing effects. Animations can be played, trimmed, slowed down, looped and captured frame by frame.

Camera animation capture

Animation clips can also be recorded directly from a webcam or a photo using pose detection. The captured movement can be reviewed frame by frame, corrected and saved back to the model before exporting it with the other animations.

It is one of those features that made the project much larger than a simple sprite sheet exporter, but it also makes the tool useful even when the original model does not already contain every animation i need.

Exporting for actual games

The result can be exported as a PNG sprite sheet with JSON metadata, individual frames, an animated GIF, or code and resource files prepared for different engines and frameworks.

Current export targets include Unity, Godot, Bevy, Phaser, Pygame, raylib, LÖVE 2D, anim8 and Turbo. The export workbench can also apply outlines, shadows, glow and color adjustments before packing the final atlas.

Workflows and automation

The desktop app is only one way of using it. The CLI can run the same capture process without opening the interface, which makes it possible to generate sprites from scripts or a CI pipeline.

Workflow presets automate common multi-angle captures such as top-down, isometric and platformer views. A single workflow can render every animation from every required camera direction and keep the sequences labeled in the final output.

The project also provides Docker and GitHub Action workflows, so generated game assets can be rebuilt automatically whenever the source models change.

Try it

The tool can be used directly from the web version, or downloaded for macOS, Windows and Linux from the releases page.

The documentation covers the interface, export formats and automation workflows. The current source is available in the GitHub repository.

farming mets roguelike elements on a capitalist environment

The project mixes farming, roguelike ideas and capitalism because apparently one gamejam idea was not enough. More importantly, it was a test of how me and kraft3r could divide work and make decisions together.

Why I made it

Me and kraft3r wanted to see how we work together on a gamejam.

Challenges or lessons

Second Place in https://itch.io/jam/mini-jame-gam-56/rate/4725573

Getting second place was a very nice surprise, but the collaboration was the part i wanted to test from the beginning.

Open

feel.lua is a tiny LOVE2D-first feedback sequencing library for making actions feel good.

Why it exists

Game feedback can very quickly become animation code mixed with particles, sounds, camera shake, flashes and a lot of small timers. feel.lua lets me describe those pieces as one reusable sequence instead.

The game still owns the actual particles, audio and rendering. The library focuses on the order, timing and values, so it can help an action feel better without trying to become the whole game engine.

What it does

• Defines reusable named feedback sequences with feel.define.
• Plays named or inline sequences with feel.play.
• Animates lightweight target values.
• Emits host-owned events for particles, camera shake, flashes, sounds, haptics, shaders, and more.
• Runs steps in order, including waits, nested sequences, repeats, random branches, and parallel groups.
• Controls individual runs with stop, pause, resume and completion signals.
• Controls the whole clock with global pause and time scale.
• Routes gameplay intents to feedback with lightweight feel.channel() pub/sub.

The result is a small recipe for an effect instead of the same timing logic being spread across the player, camera, audio and particle systems.

Feedback stacks

feel.feedbacks lets gameplay call one named feedback while a feedback module owns the actual camera, post-processing, sound, time and 3D adapter events.

That means something like a heavy hit can freeze time, flash the screen, shake the camera and play a sound as one action. The gameplay code only needs to say that the heavy hit happened.

LÖVE first, but not locked to one setup

The core stays small and table-driven. LÖVE-specific work lives in optional adapters or user callbacks.

There are optional helpers for g3d and Menori, allowing the same target and sequence ideas to control models, cameras, glTF animations and shader uniforms.

It also includes a no-LÖVE core example, which makes it easier to test the sequence runner separately from a complete game.

How it works

The library wraps a vendored copy of flux so game feel can be described as small Lua recipes: animation, timing, emitted effects, audio cues, callbacks, random choices, loops and grouped steps.

It can be installed through Feather with feather package install feel, or explored through the documentation and GitHub repository.

Declarative UI for Love2D 11.x, shaped for game HUDs, debugger panels, editor tools, and in-game menus.

Why it exists

Game UI usually starts with a button or a small HUD and slowly becomes layout, input, focus, animation, styling and a lot of custom state. glyph.lua puts those shared pieces in one UI engine while still letting the game decide what its actual widgets should look like.

I wanted something that could work for an in-game menu, but also for the debugger panels and editor tools that show up around a game project. Those interfaces have similar needs, even when the visual result is completely different.

What it handles

• Declarative components and state.
• Rows, columns, panels and game-friendly layout primitives.
• Styling and reusable visual tokens.
• Mouse, keyboard, controller and touch input.
• Focus, navigation and accessibility metadata.
• Animation and visual feedback.
• Scenes and layered interfaces.
• Drawing primitives designed for game interfaces.

The common behavior lives in the core. Game-specific widgets stay in the examples or the app code, so the library does not need to know what an inventory slot, mission console or dialogue choice means for every game.

Declarative, but still Lua

A Glyph interface is made by returning a tree of components. State can live beside the component with helpers such as ui.useState, while ui.update and ui.render connect the interface to the normal LÖVE loop.

The result feels closer to describing the screen than manually keeping track of every rectangle and input check. It also makes it easier to move a piece of UI, reuse it or render it with a different style later.

Built for games

Glyph is not trying to reproduce a browser inside LÖVE. The components are shaped around the things games and game tools need: controller navigation, draggable inventory items, HUD feedback, custom drawing, scenes and interfaces that need to live beside the game loop.

The inventory example in the preview uses the same system for scrollable item slots, visible drop targets, tabs, drag and drop feedback and a game-specific visual style.

Small core, optional integrations

Glyph has no required runtime dependency beyond LÖVE 11.x. Optional adapters such as Push or Shove viewport backends, SYSL rich text and anim8 sprite animations are provided by the app when needed.

This keeps the default library small while still leaving space for the tools a specific game already uses.

The full API, examples and setup instructions are available in the documentation. The source and current development version are in the GitHub repository.

Codebase Notebook is a VS Code extension for keeping structured notes about a codebase and connecting those notes back to the code they describe.

I made it for the moments where understanding the code is the actual work. Maybe i am investigating a bug, learning how an unfamiliar project works, reviewing a large feature, or trying to remember why something was implemented in a very specific way. Normal comments are useful, but they are not always the right place for the complete story.

Notes that stay close to the code

Each note can reference specific files and line numbers. From the note i can jump back to the code, and from the editor i can see which notes reference the current file.

The extension watches for changes and updates line numbers when the code moves. It can also detect references that became stale or broken after a file was moved or deleted. This makes the notes more useful over time, instead of becoming another document that nobody trusts after a couple of refactors.

Markdown first

The notes are readable Markdown files. There is no special database and the project does not need to depend on an external service just to keep its documentation.

They can be stored globally for personal research, or inside a .codenotes/ directory in the repository. Workspace notes can be committed with the code and shared with the rest of the team using the tools that are already part of the development workflow.

Notes can also be organized with tags, templates, pinned references, archives and comments. For larger investigations, the reference graph gives another way to see how notes and files connect.

Optional AI helpers

AI is there as an optional layer, not as the place where the notes live. It can help generate an annotation from selected code, summarize a note, find related references, search annotations using natural language, or check whether an explanation might be stale.

The extension can use the VS Code Language Model API, or an external OpenAI-compatible endpoint such as OpenAI, Anthropic or Ollama. Without an AI provider, the normal Markdown notes, references, navigation and organization tools still work.

The useful small interactions

The extension includes shortcuts for quickly adding an annotation without interrupting the current train of thought. References can be added in bulk, reordered, pinned and opened directly from the sidebar. CodeLens and hover previews make the notes visible when i return to the code later.

It also includes a chat participant for questions about the current notebook, annotation history, a chronological timeline and tools for surfacing relevant notes during code review.

Codebase Notebook is an experiment in keeping the context around a codebase as portable as the code itself. The notes stay human-readable, the references make them practical inside the editor, and the optional automation is there to make documenting easier without taking ownership of the documentation away from me.

The extension is available from the VS Code Marketplace, and its source is available in the GitHub repository.

Hit all the targets… ALL the targets!“

This was another chance for me and kraft3r to keep testing our gamejam teamwork. The idea stayed direct: there are targets, there are too many planes, hit all of them.

Why I made it

Me and kraft3r wanted to continue seeing how we work together on gamejams.

After our previous jam, working together was no longer completely new. That meant we could pay more attention to how we split the work and keep moving during the jam.

Open

Display Organizer is a desktop tool for arranging multiple monitors visually, saving those arrangements as profiles and switching between complete workspaces without rebuilding the setup every time.

The current app is a macOS MVP built with Tauri. React and React Flow handle the visual canvas, while a Rust display engine talks to the operating system and applies the real monitor configuration.

Arranging displays visually

Connected monitors appear as draggable nodes on a canvas with pan, zoom, a grid, snapping and a mini map. Each display includes the information macOS reports, such as its position, resolution, scale, rotation and whether it is the primary screen.

Moving a monitor updates a draft first. Pressing Apply sends that layout to macOS, which makes it possible to experiment with the arrangement before changing the actual desktop.

The app can also change the primary display and apply supported resolution or scale modes. Rotation is more complicated because public CoreGraphics APIs only expose it as read-only, so experimental rotation support uses displayplacer when it is installed.

Layouts become workspace profiles

A profile saves more than the coordinates of each screen. It can also contain actions that run after the display layout is applied successfully.

Profiles can open apps and URLs, place an app window on a selected monitor, ask an app to quit, wait before running an action, or execute a local script when advanced scripts are explicitly enabled. Conditions can limit an action by platform, connected display or display count.

This turns a display preset into something closer to a workspace. A focused coding setup, a gaming setup and a desk with an extra monitor can each restore the screens and then open the tools that belong there.

Switching automatically

Automation rules can react to display changes, time schedules, running apps, power source, Wi-Fi context or the app launching. Confirmation is the default, while individual rules can be allowed to apply automatically.

The menu bar also provides a smaller way to refresh displays or apply a saved profile without opening the complete app window.

Recovering from a bad layout

Changing a display arrangement can go wrong in a much more annoying way than changing a normal app setting. Before applying a layout, Display Organizer saves the current configuration as the last-known-good state.

After a successful apply, a recovery banner gives 20 seconds to keep the new setup or revert it. If the app closes while a recovery state still exists, it offers that recovery again on the next launch.

The project also includes local diagnostics export. Display identifiers and Wi-Fi names are hashed, while serial numbers, raw EDID data and script commands are left out of the export by default.

Platform scope

macOS display detection, positioning, profiles, workspace actions, automation and menu bar switching are implemented. Windows and Linux X11 adapters are planned, while Wayland support remains future work because display management varies between compositors.

The source, implementation notes and platform limitations are available in the GitHub repository.

Lua Obfuscator is a deterministic, TypeScript-based Lua obfuscation engine with a focused Node.js CLI and defaults made for LÖVE2D projects.

This is my fork of BillChirico/LUA-Obfuscator. I pushed this version toward a workflow where a complete LÖVE project can be prepared from the terminal, instead of only transforming one isolated piece of Lua.

What it does

The CLI can read one Lua file, receive source through standard input, or process a complete game directory. The result can be written to a file, printed to standard output for another tool to consume, or exported as a playable LÖVE folder.

Its transformations include identifier mangling, string and number encoding, control-flow obfuscation, minification, dead code and anti-debug helpers. A protection level controls how much of that work is applied, while individual transformations can also be enabled separately.

Made around LÖVE projects

The --love preset preserves the globals a LÖVE game expects. Project export copies the game into a new output folder, obfuscates its selected Lua files and leaves assets or excluded files alone.

A Lua configuration file can define which folders should be copied unchanged, limit which files are processed, and give individual files different settings. This matters for real games where vendor code, configuration files and public member names cannot all be treated in exactly the same way.

Repeatable output

The same source, options and seed produce the same result. That makes the obfuscator easier to use in builds and automated workflows because a release does not change randomly every time the command runs.

The tool also exposes the core engine as a Node API. The CLI and library use the same implementation, so it can be called directly from another build tool without having to shell out to a separate command.

What i learned from the fork

Obfuscating source is not only about replacing variable names. Lua still has to parse, the transformed program still has to behave the same way, and engine-owned globals need to remain available after every pass.

Working on this meant thinking about deterministic code generation, safe identifiers, preserved members, project-level configuration and testing the generated result inside an actual LÖVE game. The repository includes unit, integration and end-to-end tests, including an export test that runs an obfuscated LÖVE demo.

Obfuscation does not turn source code into perfect security, but it can make a shipped Lua project less immediate to read or modify. The useful part for me was making that step fit into the normal game build instead of being a manual process at the end.

The CLI, engine and test suite are available in the GitHub repository. The work is based on the original LUA-Obfuscator project.

Roguelike rock paper scissors

Taking rock paper scissors and pushing it toward a roguelike was the kind of small, strange idea i wanted for a jam. The rules are familiar, so the interesting part was what happens when actions start affecting the next actions.

Why I made it

I wanted to practice game dev, love2d and participate in another gamejam

Challenges or lessons

Recursive procedural actions

That was the brain-twisting part. It was easy for one action to create another, and then another, so i had to think carefully about where that chain should stop.

Open

Week #3 of 1 game a week

By the third week i was getting more comfortable with the PICO-8 limits, but finishing a game every week was still the actual challenge.

Why I made it

I wanted to practice lua, game dev, and pico 8

Challenges or lessons

Making a game in a very constrained amount of time, flood and fill algorith usages

Repeating some of the same problems was useful too. It gave me another chance to work with flood and fill without treating the first solution as the final one.

Open

Week #1 of 1 game a week

Starting the one game a week experiment with a tower defense sounded small enough at first. It was also a good excuse to stop planning forever and actually finish something.

Why I made it

I wanted to practice lua, game dev, and pico 8

Challenges or lessons

Making a game in a very constrained amount of time, how to deal with mouse interaction and item progression dynamics

The mouse interaction and item progression were the parts that made the idea feel like a game instead of just a test. Having so little time meant i had to make decisions and keep moving.

Open

Week #2 of 1 game a week

The second week was about taking a simple idea and using it to understand one system better. In this case, that system was creating and filling the maze.

Why I made it

I wanted to practice lua, game dev, and pico 8

Challenges or lessons

Making a game in a very constrained amount of time, flood and fill algorith usages

Flood and fill was one of those things that made more sense once i could see it working inside a game. The time limit also kept the project from turning into another endless experiment.

Open

Technologies Used

• Docsify
• Plop
• Vue.js

Purpose

I needed a website, and wanted to explore ways of doing it, at this point i didn’t want to fully work on react js, but see ways of creating a simple website without fancy frameworks

The idea was that writing a markdown file should be enough to add something new. Docsify gave me that starting point, and Plop helped me automate the repetitive parts.

Challenges or lessons

Creating and maintaining a custom framework was taxing when it came to doing new stuff

The simple website slowly stopped being simple. Every custom behavior made the framework more mine, but it also made the next change harder.

Demo

Visit the Website!

Additional Information

This project is the same website you’re on right now.

Technologies Used

• SwiftUI

Purpose

I wanted to understand how app development for the app watch worked.

The Apple Watch felt like a good place for a small game because the limitations are impossible to ignore. A snake game was familiar enough that i could focus on SwiftUI and the platform instead of inventing a huge design.

Challenges or lessons

Apple Watch Only App publishing.

Building it was only half of the experiment. Publishing an Apple Watch only app had its own set of questions, and getting it into the App Store was part of learning the platform.

Demo

Try it out now on the App store now!

Screenshots

Easily create an endpoint in your web server that redirects deep links to mobile apps

This wasn’t created because i wanted another package to maintain. We had a real deeplink problem at work, and turning the solution into a package made it easier to reuse.

Why I made it

at work, we needed a way to deeplink the app from a custom endpoint, so i repacked this library, and added some improvements to it

Challenges or lessons

Publishing NPM packages

The code was only one part of it. Packaging it and publishing it to NPM was a different kind of work than building the endpoint itself.

Open

React Native compatible package to parse RSS feeds

The package came out of another project instead of starting as a package idea. Once i needed to accept different RSS feeds in React Native, keeping the parser reusable made more sense than solving every feed inside the app.

Why I made it

While building a RSS/podcast app, i needed a nice way of parsing any rss in react native, so i created a package for it.

Challenges or lessons

RSS parsing

RSS looks simple until different feeds make slightly different choices. The useful lesson was making the parser handle those differences without tying it to only one app.

Open

Technologies Used

• NestJS
• Vercel
• Railway
• Firebase
• Luxon
• Sentry
• Sendgrid

Purpose

I wanted to solve a very annoying issue at work: Tracking hours, since at the end of the week i always forgot to do it, so i decided to automate it.

It was a small administrative task, but forgetting it every week made it a perfect problem to automate. Auto Clock turned the information i already had in Jira into the hours that needed to reach Clockify.

Challenges or lessons

Accessing Jira and Clockify workspaces

The automation was only useful if it could reliably talk to both services. Most of the interesting work was not the timer itself, it was connecting the two workspaces and moving the right information between them.

Source Code

Closed code.

Demo

Api documentation in progress.

Open Auto Clock

Screenshots

Additional Information

I’ve been using it since mid 2022, it has been an amazing help!

Cara is an image-sharing platform and social network made for artists and creatives. The platform is run by founder Zhang Jingna alongside a group of volunteers.

I joined as a volunteer developer during a moment where the app was growing quickly and needed help. It wasn’t my project, but i liked what the team was trying to do and wanted to be useful.

Why I contributed

I wanted to Help the project while it was on a very difficult moment when it was scaling.

What I worked on

I worked on fixing bugs, and implementing features accross the react native app

Most of my time went into the less glamorous but important part of an app: fixing things and helping new features make it into the React Native app.

Challenges or lessons

Working on volunteering distributed teams!

Working with a distributed volunteer team was different from a normal work project. People were helping because they cared, while also trying to find time around everything else.

Visit Cara

Didn’t have the time, i’ll be working during next weeks :c

The page said i would keep working on it during the next weeks. Either way, the gamejam version is still a useful snapshot of what i was trying at the time.

Why I made it

I wanted to practice game dev, unity and participate in another gamejam

Challenges or lessons

Making a game in a very constrained amount of time, 2d assets in a 3D environment

The time limit made every visual decision more noticeable. I had to make the assets and the environment work together without spending the whole jam polishing them.

Open

A generic 3D platformer with broken scenarios! What a deal!

The project was small, weird and very clearly made during a gamejam. I was more interested in trying the combination of 2D assets and a 3D space than pretending it was going to become a perfectly polished platformer.

Why I made it

I wanted to practice game dev, unity and participate in another gamejam

Challenges or lessons

Making a game in a very constrained amount of time, 2d assets in a 3D environment

Getting those two visual languages to work together was the useful part. The broken scenarios are still included in the deal.

Open

Technologies Used

• React native
• React native paper
• React native codepush
• Detox

Purpose

For 2020 I started to do weekly reviews, so i decided on creating an app to help me standarize the process of these reviews and keep track of how everything was going on.

I wanted every review to follow the same structure without making the answers feel fixed. The app became a way to turn a personal habit into something i could repeat and look back at.

Challenges or lessons

Creating UI from user generated configuration

That meant the interface could not assume every review would look the same. The configuration had to become real screens while still keeping the process simple enough that i would actually use it every week.

Source Code

Link to the source code repository: GitHub Repository

Demo

Google decided to remove the app from the store, even though I constantly specified that the app doesn’t store or share personal user data! (and we complain about Apple being the annoying one 😪).

Screenshots

Additional Information

Not longer maintained, Android only app.

The objective is to keep the driver who is trying to escape inside the light.

The whole idea is built around one simple rule, keep the driver inside the light. I liked that the light wasn’t only visual, it was the thing the game was built around.

Why I made it

I wanted to practice game dev and unity

Challenges or lessons

Making a game in a very constrained amount of time, 2d lighting in unity 2d

I had to learn enough about Unity 2D lighting to make the idea readable while still finishing on time. That balance between learning and shipping keeps showing up in my gamejam projects.

Open

Just a prototype, see it as a proof of concepts

The name is honest. This was never supposed to be a big idea, it was a place to try something, see if it worked and move on.

Why I made it

Wanted to try new skills and making a short game in unity 2d.

Small prototypes are useful because they let me learn without turning every experiment into a project i need to maintain.

Open

Made with @Kyonru for the Global Game Jam 2020

Working with another developer changed the rhythm compared with my solo jam projects. I could focus on being the second dev, contribute to the Unity 2D game and see how a tiny team makes decisions under the Global Game Jam deadline.

Why I made it

Wanted to try new skills and making a short game in unity 2d.

The project is also a reminder that trying a new skill does not always need a long roadmap. Sometimes a weekend and a strange jam idea are enough.

Open

Your goal is get to the end.

Embustero was my first gamejam, so finishing anything was already part of the goal. I went into it wanting to see what making a game under a real deadline actually felt like.

Why I made it

I wanted to practice game dev, unity and participate in my first gamejam

Challenges or lessons

Making a game in a very constrained amount of time, 2d lighting in unity 2d

The answer was: stressful, messy and fun. Working with 2D lighting gave me something specific to learn while the deadline forced me to stop adding ideas.

Open

All entries for songtember 2019

Game development isn’t only code, so Songtember was a way to spend a month on the part i knew less about. The goal was to keep making small pieces instead of waiting until i suddenly knew how to make music.

Why I made it

I wanted to practice music creation for game development.

Challenges or lessons

Creating coesive and pleasing music.

Making sounds was not the hardest part. Making them feel like they belonged together was.

Open

Due to interviews and other business here is an unfinished game for the GMTK Gamejam 2024.

Interviews and other business reduced the time i had for the jam, but i still wanted to submit something instead of skipping the year completely.

Why I made it

I wanted to participate on a gamejam for that year

Some projects are useful because they show what happened under the actual constraints, not because they became the complete version of the original idea.

Open

Technologies Used

• NestJS
• Typescript
• VScode Extension

Purpose

I was doign live stream at the time, so i wanted to see how to do custom integrations for text to speech and using AI to answer questions in the chat about my code

Streaming was a good excuse to connect a lot of things that normally live separately. Every small idea from the chat could become another command, alert or experiment for the next stream.

What it did

In the beginning, I developed this API primarily to incorporate custom alerts into my weekly streams, specifically for subscriptions and follows. As I progressed, I expanded its functionality to support Spotify music queues, allowing chat followers to contribute songs to the current playlist. Additionally, I incorporated text-to-speech support, enabling any messages typed in the chat to be both spoken and displayed on the screen through a special command.

Ultimately, recognizing that most of my viewers were not proficient in programming languages like C# and TypeScript, I decided to create a Visual Studio Code extension. This extension allows individuals in the chat to inquire about specific lines of code, and with the assistance of OpenAI API, I can provide explanations for those lines of code. Furthermore, chat users can post questions on any topic to Chat GPT and get the responses as a reply in twitch chat.

Source Code

Closed code.

General diagram

Screenshots

Text to speech demo

Additional Information

I’ve used this tool in every single stream, and it has proven to be incredibly valuable, particularly when it comes to addressing spontaneous questions that arise during the stream.

JIO is a mobile app built around location-driven Web3 experiences and interactive digital collectibles found in the real world.

This was a chance to work on a mobile project that mixed real locations with game-like interactions. That made it very different from the more traditional React Native apps i had worked on.

Why I worked on it

I had free time and was offered the chance to work on a new group project.

Challenges or lessons

Mapbox customization and Pokemon Go like gaming on React native

Mapbox wasn’t only there to show a map. It had to feel like part of the experience, which meant spending time on customization and thinking about interactions closer to Pokemon Go.

Follow JIO on X

The idea of the game was a adventure rhythmic game, where enemies were going to be spawned based on the music bits.

The rhythmic adventure idea was bigger than what i could finish during the jam. I still wanted to try connecting enemy spawns to the music and see how far the idea could go.

Why I made it

I wanted to participate on a gamejam for that year

Kenney Jam 2020 gave the project its deadline and its reason to exist. The jam version is still a record of the experiment, even if the complete idea stayed larger than it.

Open

This game is submission fot the Brackeys Game Jam 2020.2, where the theme was REWIND.

The team approached the theme by letting the player shoot chips that rewind things back in time. It gave us one clear mechanic to build around during the jam.

Why I worked on it

I wanted to participate in a gamejam with a bigger team,

The team was part of the experiment for me. I had already made small games, but i wanted to see what changed when more people were making decisions and building the same thing together.

Play on itch.io