I’m trying to make a pocket pet game, like the evolution of all the little calculator screened toys in the 90’s and 00’s. I don’t want it to be the whale hunting, spyware riddled garbage that most phone games are. I’d rather like to release it on F-Droid instead of Google if I release it at all. I have all of it worked out on paper, from the random tables to the creature stats, to the combat mechanics, you can play it as a pen and paper if you wanted to. Problem is, I’m a pen and paper guy, and I’m having an awful time trying to learn anything about code. Where do I go to get help with this?

  • listless@lemmy.cringecollective.io
    542·
    17 hours ago

    When you hear “I’ve got this great app idea—it just needs someone to code it,” it may sound to you like you’re halfway there. But from a programmer’s point of view, that’s actually the least interesting and riskiest way to start. Here’s why:

    1. There’s no roadmap—just “code this”

    • Undefined scope: If all I have is a vague idea, I don’t know what “done” even looks like. Am I building a basic prototype? A polished product? What features must it have on day one, and what can wait until later?
    • Endless scope creep: Without clear boundaries, every conversation becomes “Just one more little thing,” and suddenly what was supposed to be a weekend project balloons into months (or years).

    2. You’re asking me to invent half the project

    • UI/UX design: How should it look and feel? What screens go where? How do users navigate? That’s a specialized discipline all its own.
    • Product strategy: Who exactly is this for? Why will they use it? How will you reach those users? If you can’t answer that, I can’t write code that solves a real problem.
    • Testing & polish: Code needs testing, bug-fixing, documentation, deployment, maintenance… none of which you’ve accounted for.

    3. No incentives, no commitment

    • Why me? Great programmers want to work on problems they find meaningful, challenging, or fun—and ideally get compensated for their time. “Just code my idea” won’t light anyone’s fire.
    • Who owns it? If I invest weekends or nights building your vision, what do I get? Equity? Pay? Recognition? Without a clear agreement, it’s a recipe for frustration and resentment.
    • Long-term support: Apps need updates, server maintenance, user support. If you haven’t thought through who handles that, you’re building technical debt.

    4. Real success stories are team sports

    • Cross-functional collaboration: The best apps come from teams that include product thinkers, designers, data analysts, marketers—and yes, developers. You can’t outsource half the work and expect a hit.
    • Iterate and learn: You start with sketches or clickable wireframes, show them to real people, iterate, then bring in developers to build a minimum viable product. That way, you’re coding something people actually want.

    What you can do instead

    1. Write a one-page spec: Describe the core problem, your ideal user, key features, and success metrics.
    2. Mock it up: Even hand-drawn sketches of each screen help communicate your vision.
    3. Validate your idea: Talk to potential users. If they’re excited, you’ve got something to build.
    4. Find a partner: A developer who’s excited by your clear plan—and who sees a fair path to reward for their effort.

    In short: coding is only about 20% of what it takes to launch a successful app. If you can’t show a programmer that you’ve thought through the other 80%, they’ll politely pass—because turning a half-baked idea into a working product is a lot more work (and risk) than it looks.

    • Postmortal_Pop@lemmy.worldOP
      12·
      16 hours ago

      This response is sort of the issue I keep running into. I’ve already gotten this talk, learned from it, and moved forward. I now have nearly two notebooks detailing every mechanic, mock ups of ui design, animation ideas, sprites, complex dice roll mechanics to engage with tables for content generation, and even a roadmap for the first 15 major updates to assess timeline based on the time it takes to convert to a digital format. I’m not even looking to offload the work, database entries are like 90% of this.

      I’m here asking because I don’t know how to do the next part where I find the other 20% of making this happen.

      • Higgs boson@dubvee.orgEnglish
        11·
        8 hours ago

        Some constructive criticism? This is info you should have put in OP, it would likely have made the thread more productive.

    • DeathsEmbrace@lemm.eeEnglish
      6·
      17 hours ago

      I got another suggestion, use the game development design to start. This will get all of the foundations of the games design that you just need to implement.

      Edit: GDD(Game Design Document) search what it is and what’s the purpose and it will help the most.

      • Deestan@lemmy.world
        43·
        17 hours ago

        I have even bigger aversions to anyone coming with “I have this fully specced Game Design Document”

          • Deestan@lemmy.world
            63·
            16 hours ago

            “Waterfall process” is a curseword in software development for a reason.

            To me it proves the person is thinks that a game can be created without prototyping and iteration. In addition to only doing 10% of the work, they are under the illusion that they have done 80% and completing it is just a rote exercise. They have also overdesigned untested features and mechanics which makes any iteration harder. I’d have to break their thing down and iterate over the parts with them while also explaining this to them.

            It’s just double worst.

            • DeathsEmbrace@lemm.eeEnglish
              5·
              16 hours ago

              To be fair tho this is what happens when you get involved with passionate but ignorant people? Where else would people go to get help if you just shut them down? This seems like gatekeeping but maybe there needs to be more context to game development in general? This is about someone who has an idea but no knowledge about implementation.