Davide De Vita

A better death

Solo designer & developer — RPG Maker MZ, JavaScript — 2025 to present 

Turn-based RPG with a tactical grid combat system: unique mechanics and a distinct skillset for each playable character, a wide array of status effects, elemental damage, map-shaping effects and tight in-fight resource management.

Two unique mechanics per character. Every playable character carries two mechanics nobody else has: one that governs the distinctive effects their skills produce, and one that shapes their rhythm and progression within a single fight. Allys, for instance, accumulates elemental experience as she fights, and her abilities grow in area, damage and status probability as her mastery of an element rises; however she gets unstable if she neglescts an element for too long.
Other characters' per-fight arc works on entirely different principles. The party isn't a set of stat variations on one chassis — each member has to be understood on their own terms.

You choose how many actions your turn is worth. Combat runs on Breath (Fiato), a resource that recharges and depletes quickly. Rather than a fixed number of moves, each turn is a trade-off: one exceptional turn now, or several sustainable ones before you start running on empty.

The battle shapes the map. Abilities leave the field changed behind them. Fire leaves ground burning; other elements reshape the terrain in their own way. Positioning stops being a question of range and becomes a question of what the board will look like two turns from now.

A fair game. Player characters and enemies run on the same ruleset — the same Breath economy, the same costs, the same skill structure. Nothing an enemy does is something a player couldn't do. It is a game design philosophy I always found fascinating.

Everything is data. Skills, characters, combat parameters and enemy AI all live in 25 JSON files, roughly 5,500 lines. No balance pass, no new content, no AI change requires touching JavaScript. This is deliberate: a designer who doesn't program should be able to retune the whole game — and so should I, six months from now, without rereading the engine.

Scale. ~51,700 lines of JavaScript across 38 modules, 113 commits, and 19 design documents covering system bibles, roadmap, data schemas and UI specifications. Two playable characters complete, two in development, five designed for post-demo content.

Adaptive Pac Man

Designer & developer — Java, reinforcement learning
2021 MSc dissertation project, University of Naples Federico II

A faithful Pac-Man rebuilt from the original designers' own documentation, then fitted with a learning layer that watches the player and retunes the game around them.

The design constraint came first. Adaptive difficulty is easy to do badly: push too hard and it feels unfair, ease off and it feels condescending. The system was built never to grant a free win or a certain loss — only to move the fight toward the player's actual level, under several selectable adaptation policies depending on the experience you want to produce.
The approach draws on the design philosophy of dynamic scripting, where the game assembles its behaviour from a weighted pool of rules that shift as it learns what works against this player.

Training without players. The learning logic is a variant of reinforcement learning called TD learning. The model was trained by having player-simulating bots play large numbers of games against varied setups, producing the data needed to learn which configuration suits which kind of player. At runtime it reads the player and proposes the setup that best matches them.

Then it was tested on people. I ran a study with real players across ages, genders, backgrounds and skill levels, comparing a non-adaptive build against two adaptive ones. Participants weren't told the purpose of the experiment beforehand. I measured which version they enjoyed most, whether they noticed the game was changing at all, and collected their comments.

That last part is the piece I'd defend hardest. Building an adaptive system is an engineering problem; finding out whether players can feel it, and whether feeling it ruins the effect, is a design one.

 Hold Close

Designer & developer — Android, Java — 2021

A complete mobile game: an Android drag-and-throw adaptation of a popular online silent story, where a fire spirit and a water spirit fall into an impossible love and look for a way to be together.

One world, for opposite gameplays. The two spirits share the same levels and read them oppositely. Rain heals the water spirit and is lethal to the fire one, who must hurry and refuel at the flames scattered through the forest. The water spirit is gentler, but walking on dry leaves drains it. Nothing about the level changes between the two campaigns — only what it means.

Health is size. The less health something has, the smaller it becomes. Being weak lets you slip through narrow crevices; it also puts you one hit from oblivion. A single rule that turns damage into a spatial resource — and it applies to ground and some enemies too, since every hit affects both the entity struck and the entity striking.

Ants that have their own reasons. The ants aren't hostile, they're protecting their home. They flee fire and carry water to extinguish it, which means as the fire spirit you dodge their drops, and as the water spirit you keep your distance for entirely different reasons. Each ant accepts either a decision tree or a state graph as its AI module, interchangeably.

Authored in data. Levels, characters, NPCs and events are all defined in XML, so anyone can build a new scenario without opening the code. The game also recycles its resources at runtime.

Tools

Dungeon Generator & Editor

A procedural dungeon generator with a post-generation editor. Generation is tunable, and several algorithms are selectable to produce different structural styles and feels — sprawling and organic, tight and deliberate, and the range between. Once a dungeon is generated, it can be edited by hand rather than rerolled until it happens to come out right.

Built for the reason most of my tools exist: whoever is tuning the content shouldn't have to be the person who wrote the engine, and procedural generation is only useful to a designer if they can steer it and then override it.

Other work

Research — orchestration and scheduling. Two years as a research fellow at the University of Naples Federico II, designing multi-objective scheduling algorithms for industrial edge clusters: deciding how many redundant replicas of a workload to deploy, balancing a hard reliability requirement against energy cost. Modelled as a multi-dimensional knapsack variant and solved with dynamic programming. It raised workload acceptance from 74–88% to 87–94% and cut average cluster energy cost by up to 39%. Two peer-reviewed papers came out of it, one as first author, which I presented at the S2AIM workshop of IEEE/IFIP DSN 2025 in Naples, where I also chaired a session.

I also took part in MICSathlon, the partnership's national hackathon: randomly assembled teams from different disciplines and institutions, each building out a real startup concept from scratch. Stripped out of my usual role and field of expertise, we all had a few hours to work out what each of us was the right person for and start doing it. In the end my team's project was judged the winner. 

Machine learning in industry. Two years at Machine Learning Reply in Milan. The project I'm proudest of: a live stress-detection system supporting VR therapy for autistic children, where I was the only engineer and designed the detection logic, the algorithm and the streaming pipeline end to end. In trials with around twenty participants it correctly flagged stress episodes and alerted the clinical staff.

Smaller things. Arcade replicas in Python, logic and maths games in C++, a maze game in C, and Unreal 5 C++ work in progress. All on GitHub.