Newsletter / / / 2

WORK IN PROGRESS !

• Arrow Left

/// START UP SCREEN ///

Without Spoilers:"Lilypopia is a Tower Defense RPG set on an early 2000s internet. After a world bending mix-up, Lily, a young homeschooled girl, finds herself lost in her own computer system when it merges with her favourite RPG.After years of reliance on her computer as her only comfortable connection to the outside world, she must meet with the manifestations of applications, processes, and online friends to return to her life, changed for the better."This is a story very grounded to myself, who spent multiple years homeschooled due to a similar anxiety disorder. You'll learn who Lily is through discovering her files on a virtual desktop, and battle across 5 worlds to shape who she becomes.

• Arrow Left

/// START UP SCREEN ///

• Arrow Left

/// START UP SCREEN ///

This first dev diary is going to be a little different from the rest of them, and probably a little bit longer.I have been developing this game since July of 2025, taking breaks here and there, and have reached a clarity point of the work I've done: what is good, what needs to be redone, and what the concrete vision for the game is.Due to that, this is going to detail a lot of stuff that has already been changed, but will hopefully inform those decisions a bit better.Occasionally I'll have Visor pop up a star with a little amendment from future me, but most of these notes were written between July 2025 and February 2026.

-July 2025

The very first thing I worked on, before coming up with a general theme for the game, was this frog girl character. It was my first time splitting a character into sections before animating, and a lot of iteration was involved.My only idea behind her was that when entering the game's setting, her outfit would adjust to fit the environment. In this case: Frogs!This idea stuck for a while, and when I came up with entering a digital world, I based it around her probably having a screensaver of a frog filled swamp.

- Animation Blockout

- Face too stiff

- Final version

In college I made a simple TD game on an isometric grid. It was unbelievably difficult to calculate due to the angles, and I vowed to never attempt it again.HOWEVER, a PVZ-style lanes shooter was still on the cards, and so I created a working version of both gameplay types in Construct 3, a very barebones game engine good for grey boxing.

The idea of using Construct 3 for the full product was entirely plausable from a game-making standpoint. The game wouldn't be demanding, and the simplicity of making it was very appealing to me, as someone who loses motivation quickly when told to code.I have the problem solving brain, not the syntax brain.The larger issue came with export options. Construct can only deal with web-based exports, meaning saving and loading would be a huge issue, and anything outside of PC releases was out of the question.Construct also had its fair share of weird work-arounds required for it to work. For instance, there had to be a single scene with every object in the game in it, inorder to load variables.

Additionally, the web-based version gave me the initial ideas for the Virtual Desktop segments in the game, but using HTML for actual browser sources was too inconsistent when working with window-scaling.

I worked out a framework for the game's general structure. It would be a character focused RPG, with combat mechanics focused around a Tower Defence Game.I wanted to diversify the look from games like Undertale, which the quick template I made strongly resembled. I had an idea that would immediately differentiate it visually from other games.Remember before when I said I had vowed to never make an Isometric Tower Defence game? yeah i lied.Additionally, the frog character had angled feet to add depth, so an Isometric game felt like the perfect way to visually show that I wanted to do something different.This would add an extra layer of both uniqueness, and horrible terrible problems for me in the future.

Back to game engines-About 2 years ago I found an easy code-free game engine called GDevelop. It was similar to Construct, but had a lot less features at the time, aswell as some quirky graphics issues.Lucky for me, it isn't 2 years ago anymore, and GDevelop has become a viable option, and a good one at that! So I ported over my original ideas to the software, now with the game logic set in stone.I believe this is what we call in the biz "grey boxing", but for me it was more "trying to avoid the crumbling entity known as Unity".

The Elements settled on: Silly, Stoic, Feared, Tricky, Polite, Cold, Fragile, & Comfy so usual stuff.

Just before this pivot to GDevelop, I had been on holiday. In that time, just as I was away from any ability to develop the game, the creative juices struck me.I created the designs for a few character concepts in a less than optimal phone-based pixel art software, aswell as a general theme for the first area: Emails, and a "Mail Force" that would act as the first roadblock for the player.This is also where I came up with the idea of characters being the manifestations of computer elements, aswell as needing a "corporal form" that would separate the NPCs from the main antagonist, who I knew I wanted to be the manifestation of the OS itself.When I got back, I hopped on call with a professional artist (@heena) and started sketching out some more professional looking concept art.I also came up with a rudimentary "elements" system to add an extra layer to combat, so we discussed what the different elements would combine into and how we could fit funny character ideas around those.From that discussion came Visor and his best friend ######### (wouldn't you like to know)!(as well as many common enemies for the first area)

I decided to set out a plan of development.I would make a build of the game with 1 room detailing every mechanic that will feature in the final product to make sure it was all POSSIBLE.So I created an area of wood to walk around on affectionately named WOODWALK.The idea would be to split development into 3 sections:-Make all the mechanics-Package all the mechanics into a WOODWALK demo and hand it to a variety of friends (*if you're reading this, that's you!)-Gain feedback on that, and then set forth on the REST of the game.

^ Working out camera controls using a radial wheel that tweens an average position between points on the wheel and the player for a drifting affect.

Dialogue boxes, and a novelty of dragging the windows around like a desktop. I figured out pretty quick this was just that, a novelty, and would just add user error issues of accidentally covering characters in a scene. So it was removed.

The game mechanics required for WOODWALK to be a success would be:-Movement
-Z Layering (*After this build Gdevelop added a feature that does this automatically grrr)
-World Interactions
-Dialogue Trees
-Inventory system
-Cutscenes
-CombatI also wanted enough visual presentation to give the vibes of what I was going for, and characters that would act similar to how they would in the main game.

UI and cutscenes were an exciting look at what the game would visually feel like, and so I let myself experiment with this more than grey boxing.In terms of dialogue icons I jumped around the need for these, how much visual clutter they had, if they would be attached to the limited dialogue space, etc.(*July 26 Frogrammer here! After playing Iconoclasts I'm going to look into a dialogue bubble type system to show who's talking, with potential face icons for characters like in some Nintendo games!)

A bug where Visor wouldn't walk off screen, instead doing... this? (you can hear this gif i swear)

After putting together a scene, something became very clear.Working in an isometric environment meant adding triggers to large nettings of the floor to make sure the Z order of the player would never fall behind them. This wasn't an issue, until it came to moving objects.As soon as an NPC had to move, they had to have 12 different tiles glued to their sprite that would track the player's relative position to them so everything appeared clear. And due to the nature of the game engine, it made the viewport extremely cluttered when working on other elements.Not to mention isometric art takes YEARS. I decided that the visual distinction was cool, but not worth an entire game's headache, and that some sections could use this isometric style, but on rare occasion. Something to mess around with in the future now I know the repercussions ahead of time.

At this point in development the Inventory was done, I had defeated my greatest rival: fonts (for now), and adding particles and additional props helped give the life I wanted.

Make sense? No? Good. Glad the game can remain an enigma.Essentially each enemy is allocated access to either A B or C tiles so they don't stack up on the same ones during their patterns.

COMBAT! This was going to be the biggest challenge for the game. I can write dialogue, I can make an RPG, but can I make... balanced and nuanced combat that meshes with it?So I turned to the tried and true method of GRAPHS to work it out. I settled on the best flow for combat being a Defense stage, followed by 2 action stages, allowing for strategy in the order of said actions.This was inspired in part by Deltarune's party member system, but removes the tedium of character-specific moves in favour of full agency.The combat would be unique in 3 ways:
-Genre (Tower Defense, with speed)
-Tower teamups (Towers reacting to towers placed around them)
& - Enemy lineups.The last one was the most challenging to decide on a method for, but I settled on an idea that enemies would work together as a team, slowly adding their own forces to their ally's attacks as they were defeated.Depending on the combination of enemies, they would be allocated different tiles on the board.This would allow combat to consistently get harder throughout a fight, and avoid enemies stepping on eachothers toes.

Now that the enemy patterns had been conceptualised, I got them working as a system that could send out wave after wave for testing. This would let me focus on the player's abilities, namely across the four types of towers.
Producer
Protector
Projectile
& Mutator (The catch-all, for towers who do something a little special)This brought me neatly onto figuring out how the battle economy should work. I played a LOT of PvZ2 and took a LOT of notes throughout, deciding to take a page from their take on it.
A slow but infinite supply of energy for buying towers, just enough to fall back on, but not enough to rely on.The main difference between this combat and Plants Vs Zombies, is that this is designed to be FAST. That made the UI being slick and easy to interact with vital above all else.

There are several important things to tell the player through the UI, and giving them all their own space was a tough challenge.HP, Power/Currency, and the cost of your towers were the most important info to highlight. I added an effect to the background inspired by Balatro which would flash red to indigate taking damage, which allowed the healthbar to be used as secondary information.Equipped weapon elements, Equipped armour elements, Enemy HP, and Contributing Allies were all secondary, but still important.Outside of gameplay, this whole screen had to be equipped to seemlessley transition to action navigation, and dialogue, whilst still visually showing your Tower arrangement had maintained across rounds.In this menu I found a wonderful shader that when applied over the Balatro inspired background would make an ASCII cutout to help add more visual clarity to the downtime the menu provides.I also built the podiums for the characters around two ideas.
One, the player would be choosing which element to attack with on a radial wheel.
Two, I wanted to make the act of violence more gamified, having the idea that you'd baseball smack the element's icon into one of those little penny swirly machines to lower the enemy health.

Meet Parcelade!Over the course of the game, you'll collect Tower versions of the characters you CAPTCHA.
They'll all have their own fun little abilities, BUTTT-Some of these characters will get additional abilities based on the Towers adjacent to them.Visor is a Producer Tower. He'll generate energy that the player needs to click to collect.Parcelade is a Mutator Tower, he collects all energy produced near him automatically.But if Parcelade and Visor are placed next to each other, Visor will create a star projectile every time he produces, helping to protect them both.Discovering these team ups by befriending the characters you meet in the digital world is the heart of Lilypopia.

Alright, that's roughly the up until now. Obviously I cut a lot of iteration, and illustration time, and having to rewrite the dialogue tree data only about a billion times,
BUT I'M HAPPY WITH IT!I can fully see the vision of a playable game now, and the last month I've done some additional work that I won't show just yet- but the first area has been fully mapped, character plot lines structured, and I have a spreadsheet of every Tower ability ready to go.I have decided to move on from WOODWALK, it was a good experience in finding out what wouldn't work, but now I've gotta delete all that and make the good stuff from scratch ;p

Until then, thank you very much for reading.My To Do List is as follows:
-New dialogue bubble system
-Rewrite player interaction functions
-Make the Spam Folder Forest.See you on the web, Netizens!

• Arrow Left

/// START UP SCREEN ///

• Arrow Left

/// START UP SCREEN ///

I deleted it all.Okay that's an exaggeration, but since my break I have taken a step back, had a fever dream, and reassessed the vision for the game.That sounds like a joke but over the course of one night being the worst sick I've ever been, I spent my fever-based insomnia thinking about little computer guys and hit on exactly what needed to be done to fix the game narratively, structurally, and for the sake of this devblog: mechanically.

A limited colour palette is the fastest way to make something look consistently good amongst other sprites. It will grow, but this is it for now.

Unfortunately it brough with it an issue of some sprites blending into the backgrounds.Take a look at ReplyAll's sash.

Whilst testing solutions, an elegant one I found which would avoid a separate background palette would be to lighten the characters by 1 value in engine.