r/gamedev

Currently I am in progress of creating a co-op idle RPG heavily inspired by Grimdawn.

My goal has been having actual depth to character progression, without co-op becoming a calculation for how much people are allowed to play without a friend falling behind.

The game I want is grimdawn, but mixed with the idle progression of Poe1 boat league.

Before I make a steam page and release anything publicly I wanted to make sure that I have differed things enough so that I wont have any legal issues.

How close is too close mechanics wise?

I have a similar dual class system, skills are in tiers and unlock as you invest in each mastery.

Each class mimics a similar mastery although they have different names.

Each class has similar skills, druid summons tornadoes ect.

If all skills have different names is that enough, or do they need to also be mechanically different. If I have an elementalist class with a party buff that hands out elemental damage similar to elemental exchange, is that ok? Can there be modifiers to that skill similar to the grimdawn modifiers? How many skills can each class have that overlaps with a similar grimdawn mastery before it becomes an issue?

Am I allowed to have all of the same damage types and resists? Obviously many games have lightning/fire/cold, but aether, chaos ect are pretty grimdawn unique.

If I use stats like offensive and defensive ability is that ok, as long as they are using a different calculation?

If I use items based on grimdawns item db, with the same stats, but different item names and values is that different enough?

TLDR: How closely am I allowed to mimic the mechanics used in grimdawn as an idle game, without it becoming an issue. I dont want to reinvent the wheel, just play a grimdawn like idle and couldnt find a game like that and now am making it.

Gif or what a battle currently looks like:

https://imgur.com/3bgrBZR

Obviously there's a lot of charm to the original version, but I wanted to recreate the effect using particles and give it a bit of an upres. Would people be interested in a tutorial?

https://imgur.com/a/aNgTm7o

First-time solo-dev. Do your worst.

https://store.steampowered.com/app/4971070/Cleanup_on_Aisle_3/

My point in making this post is to hopefully help somebody find a pathway and/or the motivation to actually bring something they love to market, despite "failures" or a tendency to "give up".

I first installed Unreal Engine in late 2023 with the goal of creating a multiplayer, match-based, base-building capture-the-flag game. At the time, I had no formal game development experience, but I did have a programming background. Since then, I’ve sunk a massive amount of time into 3 development projects that I ultimately abandoned. My fourth and current project, ALL GAS, will be my first Steam release!

Every abandoned project wasn’t a failure though. Each one taught me a limitation. Eventually, I decided to start a new project with literally one goal. Release it. Don't care what it is, the only requirement is that I finish. So, I designed a game around what I knew I could realistically finish as a solo developer by specifically avoiding what caused me to abandon my other projects. And in doing that, I actually ended up with a game that I think is really fun. Most importantly, to me it actually feels like a game, not a "project"!

Here are each of my "failures", and what I learned from them to ultimately progress forward.

Project 1 – Multiplayer base-building capture the flag

This project was literally the one that taught me how to operate Unreal Engine. Terminology, how to use certain tools, etc. Importantly, it taught me:

1. Animations, especially humanoid ones are an enormous amount of work for one person

2. Multiplayer, let alone competitive multiplayer, is an incredibly ambitious first project for a solo developer. And, it's not something you just "add later".

I spent over 500 hours building the game as if it were single-player before seriously starting to add multiplayer. I always thought I could just add multiplayer later. Reason being, I was otherwise learning extremely quickly and things were working. By the time I actually got to it though, too much of the architecture assumed everything happened locally, and the project was effectively impossible to retrofit without re-doing everything. Painful, but learned a TON from this "failure".

Project 2 – Physics-based multiplayer sports game

For my second project, I intentionally avoided animations almost entirely. In the painful process of learning replication in my last project, I at least started this one with multiplayer in mind. The gameplay revolved around physics. It was actually very fun! Hard (as designed), but fun and aesthetically unique. I even got multiplayer working across the internet and tested with a few friends.

The problem was that the physics had to be perfect across every client, or it would never work work. In single-player, everything behaved exactly as intended. In multiplayer, small differences in physics simulation caused players to see slightly different trajectories, eventually (quickly) causing the entire match to desynchronize.

Server-authoritative physics solved the accuracy problem, but it completely killed the responsiveness that made the game fun. I know there are hybrid approaches to solving this, but at the time, it was a challenge I wasn’t ready to pour more time into.

Lesson learned: if physics are the core mechanic, multiplayer makes everything exponentially harder. I also learned how difficult UI design / development / debugging can be. I understand why the UI in many games (indie and AAA) are often terrible....

Project 3 – My “dream game”

This one is still very close to my heart, and I fully intend to come back to it someday. It was a cooperative exploration game in an infinite world featuring procedural generation, massive environments, unique mechanics, and procedural puzzles. Very cool atmosphere, too.

By this point I’d figured that cooperative multiplayer would probably be much more achievable than competitive multiplayer. A few imperfections wouldn't matter all that much like it would in a competitive match-based game. But, combining multiplayer with procedural generation, large-scale worlds, complex systems, and custom movement modes eventually became more ambitious than I realized it would be. There are some systems in here that, ever since I was a kid, I always wanted to see in a game and never have. And to a surprising extent, I was even able to make them work! A lot of the issue here was that it is simply just difficult (and not particularly fun) to test multiplayer games as a solo developer on one computer. And, it's even less fun to spin up a second computer for testing. It's even less fun than that trying to run multiple instances on one computer....

After putting well over 1,000 hours into it, I made the difficult decision to shelve it—for now.

Project 4 – Something I knew I could finish from the start

Before I even came up with the idea for this project, I gave myself one goal: Finish It.  I didn’t start with a genre, I started with a rule: "Avoid the two things I know will eventually burn me out". If I realistically want to finish a project:

1. No multiplayer.

2. No animations.

Those constraints eventually became ALL GAS. It's an endless traffic-weaving roguelike where you upgrade your car and modify your run as you weave through cars on a completely nuts road in the sky. The road is falling behind you and it's getting faster and faster (unless you sacrifice upgrades to slow it down). It’s a simple concept, but is extremely satisfying especially when playing with a controller. Skill is rewarded. Soon, it'll be even more fun with a steering wheel and pedals! 

Ironically, by deliberately limiting myself, I’ve made more progress than I ever did trying to build my “dream game” or the idea I had which caused me to stumble into learning game development in the first place. Similarly, I've produced some pretty incredible (and re-usuable, and sellable) plugins for Unreal Engine in the process. It was nice not to be burdened by animations or multiplayer, and it really allowed me to polish the game more than I ever thought I could. Still a lot more to do, but I'm quite happy with where I have gotten in the 5 or 6 months I've been working on it.

The limited scope of the game also allowed me to gain experience around other important parts of bringing a game to market. Things I never would have bothered messing with if I had any doubt the game would ever release, but did in this case because I knew my goal was attainable this time:

• Steamworks platform - store page, review process, publishing builds, launching a playtest
• Stats, achievements, leaderboards, cloud saves
• Creating trailers / marketing assets / creating ways to record those things
• Marketing
• Full controller support, including UI navigation, glyph localization, and Steam input
• Language localization
• Building systems for future scalability
• Custom subsystems and engine modifications to support all of those things

  

I’m curious - has anybody else come to a similar realization? What did it ultimately take for you to launch your first project, or for that matter, even start sharing it with people?

Also - if so inclined, please feel free to join the open playtest!

https://store.steampowered.com/app/4658550/ALL_GAS/

About a year ago I quit my job because I was incredibly stressed and decided to go full time on Quantum Quartz, my “dream” game.

It’s a precision platformer, so basically the exact kind of game people tell you not to bet your financial future on. It has a very interesting main mechanic about switching platforms on/off.

I live with my parents, so I was lucky enough to be able to take that risk, but I still need money to live. I was burning through the savings from my previous job, so from the day I quit there was basically a timer counting down on me :/

Quantum Quartz hasn’t become some massive success. It’s doing relatively well, has a really nice little community around it, some speedrunners, and I’m extremely happy with where it’s going. But something unexpected happened.

Someone noticed the effort I was putting into developing and promoting it, and I ended up getting a job doing marketing for another indie game. My pixel art commissions have also been going really well, probably because of how the game looks on my portfolio. And now I can support myself and pay a programmer to work on Quantum Quartz with me.

For the first time since I quit, the timer is gone.
I know “don’t quit your job to make your dream game” is generally very good advice, and I’m definitely not telling everyone to do it. But I think sometimes we’re so afraid of encouraging bad decisions that following what you genuinely want starts sounding inherently stupid.

My game didn’t need to become a huge hit for pursuing it to change my life for the better. Now I just get to keep making the thing I love, and pour everything I can into making it amazing and most fun game I can think of, while also having fun doing my other game related jobs.

I really want to encourage anyone reading to take a leap of fairh once in a while. Don’t quit your job, its stupid, but if you have enough passion and you enjoy what you do you’ll eventually have success!!

TL;DR: Quit my stressful job to make a platformer while living off savings. The game hasn’t blown up (at all) but working on it led to a new job in indie game marketing, more pixel art work, and enough income to keep funding development. Sometimes following the thing you genuinely want actually does work out.

Quantum Quartz on Steam for context: https://store.steampowered.com/app/3824680/Quantum_Quartz/