@Anna Stoilova What mechanics are you talking about? You are not controlling a character, walking around in an isometric world, thats correct. But beside from that the style of the game and how the items drop didn't give you any nostalgia?

@Jodessiah Sumpter AI tools? Mostly cursor and lovable for the first prototype. For the full game I also use photoshop / photopea, sometimes godot.

@Nathan Campbell If you don't menage to play the android app, you can play it online on https://merzleckeier.vercel.app/ - but I really need the android testers ;)

@Morgan Page

I’d probably separate this into two phases: For the very first prototype, tools like Lovable can be great because you can move incredibly fast and get something playable/visible without getting stuck too early in architecture or setup. But I personally wouldn’t stay there forever for a game project. My preferred workflow would be: Start with Lovable or a similar AI builder to quickly validate the idea and UI/flow. Then sync/export the project through GitHub, pull the code onto your machine, and continue from there in VS Code, Cursor, Antigravity, Claude Code, etc. That way you still own and control the codebase, but you don’t lose the speed of the first prototype phase. For a beginner, I don’t think your current approach is “wrong” at all. Working locally with Pygame is actually a great way to learn how games really work. It just means you’ll have to handle more of the structure yourself: assets, sprites, animations, UI, packaging, etc. For graphics, I wouldn’t try to create everything from scratch at the beginning. Use placeholder-friendly asset packs first: - Kenney.nl has tons of free/cheap game assets - itch.io has huge 2D sprite, UI, tilemap, and strategy game asset packs - OpenGameArt can also be useful - Later you can replace the placeholders with custom AI-generated or commissioned art The main thing I’d avoid early on is spending weeks polishing assets before the game loop is fun. Get the movement, combat, turns, win/loss conditions, and basic UI working first. Then improve the visuals step by step. So my recommendation would be: 1. Keep building locally if you want to really learn. 2. Use Lovable only if you want a fast prototype or UI direction. 3. Use GitHub as the bridge so you always own the code. 4. Use Kenney/itch.io asset packs first instead of making all sprites yourself. 5. Don’t worry if the first version looks rough — almost every good game starts ugly.

Really good question. I think it’s absolutely realistic to make money with your own games, but probably not by thinking about monetization too early. I worked in the games industry for several years and was involved in games that served millions of players, so I’ve seen a bit of the business side. But now, as a vibe game dev, I’m taking it step by step. For me personally, the current focus is: build the skills, ship games publicly, learn from feedback, improve the quality, and build in public. I’m not even adding monetization to my first games yet. I first want them to be good enough, and ideally have some real players, before I think about ads, paid versions, Patreon, Steam, or anything like that. I think the most important thing is that you genuinely enjoy the process of building and improving your games. If you don’t enjoy that part, it will be very hard to turn it into a business. But if you do enjoy it, then yes - I think it’s absolutely possible. The path could be paid games, free games with ads, mobile games, Steam, Patreon, building an audience, selling assets/tools, or even using the games as proof of skill for client work. I’d see it less as “how do I make money from this one game?” and more as “how do I build a long-term creative business around making better and better games?”