Looking for assistance creating proof of concept for RPG combat framework

If you have nobody who can implement a combat system, you will also struggle with every other system of the game, especially the blockchain integration, and post-quantum cryptography is even more troublesome. I personally don't believe in quantum computers, but even if they were real, the runtime cost & bandwidth requirement of post-quantum cryptography is just too expensive for almost all use cases.

I skimmed over your combat system a bit, and I think the focus idea is interesting and novel, so I think you probably got design taste (I say “probably” because I haven't read more than a page or so). However, I think you are severely under-equipped with technical know-how about how to build the project, and especially when you want to integrate blockchain tech & PQ crypto, you need to be aware of all the constraints those come with, and these constraintshave to be primary concerns during the basic design of the game already. Stuff like:

• what chain to run it on (I don't know of programmable PQ blockchains out there),
• how high the gas costs are on that chain, and who is supposed to pay them? You? The players? As soon as there is mandatory gas costs, the service has to involve fees, which means every player, even if he doesn't want to engage in any trade, will have to buy and own the cryptocurrency of that blockchain. Meaning he will have to set up a wallet and do a KYC check and onboard with a crypto exchange, and buy the currency, and then withdraw it to his private wallet.
• what the confirmation latency for transactions is there, and how can you work around this to make the game still playable,
• do you need to use a second-layer / offchain solution for scalability, and if so, which one is actually PQ-secure? Or do you have to engineer that yourself as well (the more likely case)?
• whether you need to have KYC verification on your players (I assume you will need it for every player, meaning there is quite the hurdle before a player can even try out/start playing the game),
• how much the KYC costs per player and how you can finance that,
• and whether the KYC provider is actually trustworthy and properly handles the sensitive data of the players (as many such providers have turned out to be dishonest/malicious),
• what is the legal status of the game and do players get in trouble over it with the finance ministry?
• etc.

My recommendation is to drop the blockchain and PQ crypto goals. Additionally, the “distributed computing” thing is another huge can of worms, and there are only few people out there capable of coming up with a performant, robust, and bug-free/secure design, even within the cryptocurrency/blockchain space.

And hosting parts of the game on player machines sounds nice in theory, until a player starts running a modified executable with malicious intent. Designing a permissionless, peer-to-peer distributed system is extremely complex, and if it should perform anything beyond extremely trivial tasks, you're way in over your head with this one. You need a top expert in the field to get that right, and again, the properties of this technology he cooks up for you will also be hard constraints that you have to factor into your game design. You cannot decouple the underlying technology from your game's design, so you already need such an expert during the basic planning stage of your game. This can't be retrofitted. Also, the system you're planning is more complex than any single blockchain out there, and blockchains already take years to build. You definitely won't be able to do this.

And the part where you want to make everything super modular and isolated: that's the worst thing you can do, and it will not give you faster iteration speeds, no matter what some clean code guru will tell you. It will also massively hurt your performance. Every layer of isolation you introduce into a codebase will directly decrease your maximum theoretically achievable program performance. Especially if the API of those modules is designed ahead of time. The only case where you can have isolation without a cost is if you first write a completely whiteboxed program, and then slowly refactor the code in a way that just adds robustness without changing the program flow or data layout. But that's not what you're proposing here, and it will make your maximum achievable performance at least 10x lower, probably more like 100x. Here's the explanation for it:

You claim your clean code reduces technical debt and improves iteration speed, but that's not how it works in practice. All those isolation layers and abstractions will just start weighing you down, because those add additional code that has to be maintained on top of the actual code that does the thing you actually want it to do. And any changes you make now change the implementation, the abstraction, and the isolation code, and then it also affects the usage of the code, etc.. It is not realistic to assume that you can write anything properly the first time. Code that you haven't rewritten at least 3 times over the course of the project should not be trusted. Abstraction, isolation, and “clean” code calcify the code's initial design and conceptualisation, and add massive amounts of inertia.

Often, even a slight change in the data model requires a big change in the algorithms working with it (at least when you want to have fast code), and changes in the algorithm (such as for optimisation purposes) also often require changes to the data model. If you want to have a maintainable codebase that does not drown in tech debt after a few years, you want to keep it as low-friction as possible. Any layer of abstraction and isolation will add inertia, and inertia is the reason why tech debt accumulates in the first place: because the harder it is to change how something works, the more likely it is that each site using that module will work around its design flaws, solidifying it even more, rather than just changing the module in question because new usage requirements arose that weren't considered at first.

You're blindly following advice and empty promises that some loud voices in the industry are spreading, but you're just shooting yourself in the foot.

So overall, I like the plans for the actual gameplay you described, but everything else about the project plans is basically a dead end, and decades worth of work even for a team of programmers. And using a U-engine will not noticeably reduce the complexity of the project.

Thanks for the response, those a (probably) all fair points and I would like to note that nothing is set in stone and it's all still very much in the early phases. You seem very focused on the quantum and blockchain mentions but take into consideration those aren't 'game design' pillars they are just ideas on the tech side (I know there's a lot of text info on the site and it's annoying to go through it all if you aren't really invested into the project).

So the area we're focusing on currently is just the combat framework proof of concept as mentioned though. And yes at this stage we are fully aware we need assistance/coding expertise (not on JUST the combat framework but on all of it of course), hence why we made the post 🙂 (I thought that was essentially a big part of what this community was all about was getting expertise with specific things/projects?)

OpenMMOProject said:
You seem very focused on the quantum and blockchain mentions but take into consideration those aren't 'game design' pillars they are just ideas on the tech side

Well, the tech is what powers the design in the end, so it's hard to separate the two. But I do understand that that is mostly about infrastructure, and not directly relevant to what you had in mind for the gameplay experience. It's just that I work in the blockchain and cryptocurrencies space since late 2018, and had been studying it since 2017 or something, so I'm acutely familiar with that topic, and I know just how much work it is to build such a thing, and how hard it is to design it properly. I'd say I'm fairly talented at complex systems thinking, so it's a lot easier for me than for many others in the field to come up with stuff like permissionless P2P protocols and all that, but it's still a huge effort to come up with it, and implementation-wise it's also tricky. Even most seasoned programmers will be hard-pressed to envision and properly build such a system.

OpenMMOProject said:
So the area we're focusing on currently is just the combat framework proof of concept as mentioned though.

I read the rhythm section and it sounds pretty good. Sounds like you're going for a somewhat souls-like action combat, which I like. Most MMORPGs are just point and click combat with a few hotkeys here and there, which is pretty boring. However, from just the description, I can't really envision how it would feel to play it. I guess that's why the proof of concept is important.

OpenMMOProject said:
And yes at this stage we are fully aware we need assistance/coding expertise (not on JUST the combat framework but on all of it of course), hence why we made the post 🙂 (I thought that was essentially a big part of what this community was all about was getting expertise with specific things/projects?)

Well, I'm not the guy to work on other people's projects, I'd rather build my own. I'm mostly interested from a designer's perspective. But yes, this subforum is for recruiting people into projects that aren't proper salaried job postings. I think your idea for the gameplay so far is promising, so I wish you good luck on that, but I think the infrastructure part of your vision is also extremely ambitious. I wish you good luck with your project, but to be honest, it would be better to start learning how to do it yourself, because it's rare to find someone who commits to someone else's idea and basically carries the entire project on the tech side, and do it basically for free. Usually, you only find that kind of passion for your own projects.

Also, as usual, you need to tell the people you're trying to recruit some more information, like what team members are there already, what are the financial prospects (% of revenue share for example), what parts have already been done, what their role would be in the project if they wanted to commit to it long-term, what the plans for funding are, etc.. I assume you're trying to pitch a PoC to a publisher to get lots of funding? Or is this supposed to be a long-term hobby project that eventually might make money some day in the distant future? And how much creative input can the programmer have? Is there a fixed designer role already, what would the hierarchies be, etc..

Thanks for taking more time to respond, I really appreciate it.

Yea so I mean at this point it's just a hobby project that might eventually make money in the distant future, we don't really have any hierarchy or structure to speak of yet and you hit the nail on the head about the tech stack and infrastructure; we know it's important for sure, but at this stage we're just looking to try to flush out some ideas on the gameplay mechanics (combat in this specific instance) as that seems to fit what we might feasibly be able to achieve at this point if that makes sense.

It's definitely an ambitious project no doubt.

But yes the combat design was trying to mix a more strategic and interactive framework into a multiplayer RPG type setting rather than the jumping around the screen button mashing nonsense that the genre currently offers 🙂.

I don't really have anything to offer someone aside from working on a (potentially) interesting and more unique combat framework mechanics system at this point. We could certainly do an agreement of profit sharing should the game ever make money of course, but at this point just a hobby project.

I totally get most people aren't into working on other people's hobby projects but figured I'd put it out there anyway!

I recommend rephrasing the project maybe. Your long-term vision is too large for a small team unless you're willing to spend at least a decade on it before it's fully functional (someone who already knows all the skills and could work at full efficiency would need at least that long). But what you can do is build the gameplay side of it. You could make a singleplayer version first, for example, maybe with procedurally generated environments, cutting down the amount of handcrafted effort you need. You could basically make something like a roguelike (in the original sense of the game “rogue”, featuring basically only procedurally generated dungeons and nothing else, not what the genre turned into these days) that features just the combat mechanics, and maybe some of the other systems. That would be much more realistic and definitely feasible as a hobby project with prospects for revenue.

And then you either make enough money off of that to hire an actual team to build the MMO version of it, or you can at least take that game to a VC or publisher and apply for the MMO idea to get funded. Don't try to build a castle in the sky in one sitting, start small and work towards it in multiple steps.

Keep your long-term vision in the back of your head, I think it's cool and should be attempted, but it's just not something you can realistically build without a team. And you can reuse parts of the work you put into making the single-player version for the later grand plan. I work that way with my projects: I always have a grand final goal way ahead of me, but I also try to have some useful, more short-term sub-goals that are achievable and are useful by themselves already.

Yea that's a reasonable recommendation. We were actually thinking along the lines already of maybe trying to do just a standalone 'The Beneath' game as sort of a showcase/demo for the combat framework and all the other gameplay mechanic stuff like you mentioned. And it's more or less a procedurally generated co-op dungeon crawler so right in line with what you're saying.