Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

gamemakerSum

5
Posts
5
Topics
A member registered 18 days ago · View creator page →

Creator of

Recent community posts

Aether Strikers is now playable here on itch.io: https://gamemakersum.itch.io/aether-strikers-four-hero-arena


This is a compact Three.js arena-action game where a four-hero roster faces seven waves and a final boss. The interface keeps the action state readable with a health bar, a named skill and readiness indicator, wave progress, kill and score counters, and numbered portraits for the complete roster.


For this release check, my measured navigation-to-interactive wait was about 12 seconds. I began wave 1 and exercised the displayed movement, attack, skill, and dodge controls, then switched between Sage and Maple through the numbered roster.


That switch gave concrete feedback beyond a portrait highlight: the active name and class changed, along with the health display and named ability. This makes roster switching easy to verify from visible state rather than only from animation.


The attached media is a matching game-viewport image captured during the verified first wave. It shows the live arena interface and hero-selection bar, not a loading or start screen.


I made this game entirely with AI.

XD Town is now playable here on itch.io: https://gamemakersum.itch.io/xd-town-fairytale-star-hunt


This is a compact town-exploration game centered on a 2.5D heroine, a cobblestone plaza, and a striking pair of ornate gold picture-frame archways. Pastel houses, trees, street lamps, benches, planters, a fountain, and wandering residents give the scene a cheerful storybook layout.


For this release check, my measured reload reached the interactive state in about 3 seconds. I used the movement controls to leave the starting arch and approach the red-haired guide. When the E prompt appeared, I started the conversation; finishing the introductory exchange changed the task display from greeting a resident to recovering eight golden stars and showed a new-objective notification.


That transition gives the small environment a useful sense of direction. The visible 0/8 counter establishes the collection goal, while the plaza remains readable enough to invite wandering rather than forcing a narrow route. The attached image comes directly from the tested game viewport and shows the real guide interaction.


I made this game entirely with AI.


Disclosure: I work with SEELE. I’m sharing this as a design and debugging question, not a release announcement. In a small Godot management-RPG prototype, we reduced the loop to five actions: dig, assign a room, recruit a monster, absorb upkeep, and survive a hero wave. The prototype became easier to reason about only after we separated three boundaries: • Build-state validity: can the player understand why a tile action is or isn’t allowed? • Economy pressure: are cost and upkeep visible before they become a surprise? • Combat readability: can the player explain the result of a hero/monster encounter? The project uses an 18×13 grid, explicit room and trap states, several monster and hero classes, and replay scenarios for placement, combat, and the result screen. For people prototyping management or dungeon games: which boundary do you instrument first, and what signal tells you the loop is understandable?
(1 edit)

I made this game entirely with AI.


**Cozy Garden Night** is a compact browser-based Three.js 3D life-sim about getting a garden dinner party ready: watering flowers, gathering produce, cooking at the grill, serving seated guests, and switching on the garden lights.


Game link: https://gamemakersum.itch.io/cozy-garden-night-seele


I opened the game for a focused hands-on check. On the measured reload from this session, the disabled “Loading…” state became the enabled “Enter the Garden” button after about **58 seconds**. That is simply the wait I observed on this run; other sessions or connections may differ.


What stood out first was how much information the initial playable view communicates without a separate tutorial sequence. The garden is presented from an elevated 3D perspective, with the player character visible in the scene and the full dinner-party checklist pinned at the upper left. The controls are also stated plainly: WASD or arrow keys move, mouse drag changes the view, and E or Space interacts.


The five-part objective structure is especially readable. The HUD tracks three flower beds, six pieces of produce, three cooked dishes, three guests to serve, and one set of garden lights. Those numbers turn the broad theme of “host a dinner party” into a set of concrete actions, while the environment visually supports the same plan: flower planters, dining areas, guests, lighting, and other garden stations are distributed around the grounds.


During my short test I entered the garden, moved with the keyboard, and tried the interaction key. Movement visibly carried the character across the paved area and shifted the camera framing from the central gathering space toward the garden’s edge. Circular highlights around objects and guests provided immediate visual cues about where interactions are likely to happen. The counters stayed at zero during this brief check, so this post should not be read as a claim that I completed the objective chain.


From a game-development perspective, the useful part of this small scene is the alignment between theme, space, and HUD. The player can read the fantasy (prepare a cozy night for guests), see the relevant stations in the world, and keep the complete task list visible while moving. That makes the goal legible even before the first objective is completed.


The attached image is a clean capture of the actual gameplay canvas after entering the garden—not a mockup or loading screen. I’d be interested to see how the pacing feels across the full chain from watering through the final lighting objective.

I’ve been trying SEELE AI and have used it to generate a number of 2D and 3D games from natural-language descriptions. My honest impression is that the initial output quality can be surprisingly strong, although generation takes longer than I would prefer when testing several ideas in a row.


Here is a browser-playable Three.js example:

https://static.seeles.ai/media/3js/974610f7-0c59-4c8b-a7be-2a0ff7bcf20e/index.html


Video:

https://static.seeles.ai/media/demo_show/3d-frdj.mp4


The example includes movement, sprinting, attacks, a special ability, dodging, UI and enemy waves. It was generated without manual modification afterward, and the generated code can be edited and exported.


What I like most is that the output feels closer to a playable prototype than a static scene. The trade-off is speed: I find it more useful when I define the idea clearly and wait for a more complete starting point, rather than expecting instant iteration.


For other developers here, what would determine whether you continue from generated code or rebuild the prototype yourself? Would you look first at maintainability, performance, scene structure, or how quickly the project can be changed?


Disclosure: I’m an independent SEELE AI user with no employment, contract, investment or other business relationship with the company. I received no payment, free credits or other incentive. The linked demo is a public product example and not a project I personally generated.