I'm a self-taught, early-career developer, game designer, writer, and artist. I enjoy building systems for simulations, autonomous agents, games, and practical tools—especially projects where state, rules, and many small decisions have to work together over time.

My strongest current languages are JavaScript, GDScript, and Python. I also work with HTML and CSS and have prior experience building small Android projects with Kotlin.

I am still growing as a developer, so I value readable code, honest documentation, focused milestones, and feedback from people with more experience. My GitHub username remains RaoulTheF00l while I use Foolish Dev as my public developer name.

Plant a world. Give it rules. Let its residents build a history.

WORLD_SEED is my current main project: a local-first engine for persistent simulated worlds shared by AI residents and a human-controlled avatar.

The public repository currently contains the project specification, draft JSON Schemas, a portable world-pack template, architecture and safety documentation, and milestone evidence. A private Python reference implementation is being developed through small, automated-test-backed milestones before any language model is connected.

What this project demonstrates:

• Deterministic state and event design
• Validated actions and fail-closed boundaries
• JSON serialization, semantic validation, and snapshot persistence
• Privacy-aware separation between engine, world, and resident data
• Incremental planning, acceptance criteria, and technical documentation

I am looking for thoughtful opinions and potential collaborators for WORLD_SEED. The most useful perspectives right now involve simulation architecture, schema and API design, deterministic replay and persistence, testing and conformance tools, AI safety boundaries, local-model adapters, and eventual Godot integration.

If the project interests you, please read the Project Status and Contributing Guide, then open an issue with a focused question, critique, or proposal.

A modular JavaScript controller for a persistent Screeps colony.

It coordinates specialized worker roles, population priorities, source assignments, energy logistics, defensive towers, live diagnostics, and a cached road planner built with PathFinder and cost matrices. The project has taught me a great deal about state machines, resource allocation, failure recovery, and code that must keep making decisions without direct supervision.

A configuration-driven JavaScript system for coordinating a four-character Adventure Land party.

The modules handle party formation, combat, healing, movement, stuck recovery, inventory rules, item progression, cross-character requests, merchant supply runs, and long-running asynchronous behavior. This project is one of my clearest examples of refactoring a growing script into smaller responsibilities with defensive checks.

A non-commercial Godot 4 demake based on my own Persona 5 fan fiction.

The current prototype explores top-down movement, scene flow, time-restricted activities, social statistics, NPC interaction, turn-based combat, rewards, and UI state. It combines my programming, pixel-art, game-design, and writing interests in one project while I learn how to turn disconnected mechanics into a playable vertical slice.

A small browser-based cultivation adventure made with plain HTML, CSS, and JavaScript.

It separates player state, actions, persistence, and UI updates into modules and includes incremental progression, exploration, breakthrough mechanics, and local-storage save/load/reset behavior.

Play the current demo

• JavaScript
• GDScript
• Python
• HTML and CSS
• Kotlin fundamentals

• Godot Engine 4
• Git and GitHub
• Visual Studio Code
• Node.js and npm
• pytest
• JSON, JSON Schema, and YAML
• Windows and Linux

• Deterministic simulations and autonomous-agent systems
• Gameplay systems and small vertical slices
• State management, persistence, and validation
• Movement, pathfinding, and recovery behavior
• Modular architecture and guard clauses
• Automated testing, debugging, and technical documentation

I work best by reducing a large idea to one testable milestone:

1. Define the smallest useful behavior.
2. Write down its rules and failure cases.
3. Build a simple working version.
4. Test the real behavior, including invalid inputs.
5. Refactor only when the code has earned more structure.
6. Document what works, what does not, and what comes next.

I care more about making steady, verifiable progress than presenting unfinished plans as finished software.

I am open to:

• Feedback and code review
• Small, clearly scoped open-source collaborations
• Entry-level or junior development work
• Gameplay, tools, automation, or front-end programming
• QA, software testing, and technical support work

I would especially value environments where I can contribute to a real project, learn from experienced developers, and steadily take on more technical responsibility.

You can reach me through GitHub or at Ra0ulTh3F00l@gmail.com.

Thanks for visiting and taking a look at my work.