My longest-running game idea is to create a moddable MMOG - one which encourages private servers, creation and sharing of custom graphics, and adding unique features to private servers; while still maintaining a central "default implementation" server.

I've been working on MMOG servers on and off, by myself and collaboratively, for over a decade. I know how to make them and I've run into and found fixes for all sorts of common pitfalls. I'm not worried about implementation details on either the client or server end.

I think I'm ready, as a programmer, to start this game and make a high-quality product, even if I'm the only one who ever works on it and it takes me another decade (...at least I'll only be almost 40?).

I already have an idea how the primary implementation of the game will play overall, and I could use some help with that aspect, as I'm not the greatest game designer. For the rest of this post, when I say "game", "map", etc.; I'm referring to the default implementation.

The game will be an action RPG, and will rely heavily on typical hack-and-slash mechanics. The map will have plenty of traps for the player to avoid and utilize to defeat monsters, and certain monsters will be designed to try to get the player to fall into these traps. It will also feature puzzles that the player must solve - and a good many of them will require multiple players, just to push players into collaborating. When players die, I want to set them back a ways, to make death a genuinely bad thing.

What I'm most torn on is how to give the players a sense of advancement. The typical way is to make their character better. I'll discuss problems I have with how RPGs typically handle this:
1) EXP and levels / trainable skills - this leads to grinding behavior to catch up in capability to other players. Death commonly leads to a loss of EXP and possibly even "leveling down", which if not scaled by level can cause "rage-quitting", but is scaling by level fair to newer players?
2) Skill/attribute rewards for completing quests - this is either automatic, reducing the ability of players to direct their own advancement; or leads to players spending a lot of time carefully figuring out which of the many skills or attributes to improve.
3) Better items becoming available - in MMOGs, these items are later given or sold to lower level players to make the game immediately easier to them, reducing their own feeling of advancement early on. MMOGs add level or attribute requirements to stop this, but I already covered issues with these systems.
4) (Zelda-esque) items as quest rewards make it easier or quicker to traverse the game world and dungeons, solve puzzles, and/or get past obstacles designed to require such item to progress - I love these games. But this leads to a feeling of linearity which I wouldn't like in an MMOG, there's only so many of these which can be practically implemented (the idea doesn't scale massively), and these items need to have restrictions placed on them to prevent the same issues as better items becoming available.
5) New classes in a class hierarchy become available - I've never been a fan of class systems in ARPGs.
6) Rewarded items that improve health slightly - great for games of a fixed duration. For a game that hopefully spans forever, this can lead to practically immortal characters. It also reduces general skill requirement as the game advances - it becomes easier, instead of more challenging.

Ideas from other games I don't see any real problem with, but are a little too subtle:
1) Fame system - New and more challenging quests become available as you grow in fame (or infamy).
2) Increase difficulty of monsters and puzzles for later quests
3) Keeping global rankings - let the player see as they rise towards the top.
4) Make NPCs aware of player's accomplishments.

I'm really stumped here.

I'd also be open to ideas about how to monetize such a game, at least enough to probably cover operating expenses.

The game will be an action RPG, and will rely heavily on typical hack-and-slash mechanics. The map will have plenty of traps for the player to avoid and utilize to defeat monsters, and certain monsters will be designed to try to get the player to fall into these traps. It will also feature puzzles that the player must solve - and a good many of them will require multiple players, just to push players into collaborating. When players die, I want to set them back a ways, to make death a genuinely bad thing.

The game will be an action RPG, and will rely heavily on typical hack-and-slash mechanics. The map will have plenty of traps for the player to avoid and utilize to defeat monsters, and certain monsters will be designed to try to get the player to fall into these traps. It will also feature puzzles that the player must solve - and a good many of them will require multiple players, just to push players into collaborating. When players die, I want to set them back a ways, to make death a genuinely bad thing.

Something to think about: if you are going to encourage modding and make it easy, how will you prevent those modded clients connecting to your server rather than some other modded server

Servers will be responsible for transmitting content packs to clients that do not have them already (this will be done in the handshake step).
Content packs will have a public key and a 128-bit GUID associated with them. The GUID has same number of unique IDs as IPv6 has addresses, so even randomly generated GUIDs should practically never conflict. I've considered a GUID registration service to prevent conflicts for sure, but I'm not sure it's necessary. The client's code will only allow downloading content packs with a new GUID, and communicating updates for content packs will use asymmetrical encryption using the public key in the content pack to ensure that only the proper source is sending updates to a content pack.
My server would only use my content packs, so the client would only have my content packs loaded while playing.
Obviously I can't keep source-modded clients from breaking here by removing these checks, but if I do things right, source modded clients shouldn't be necessary except for the most radical of changes.

...and hacking your game?

I assume you mean "breaking" or "cheating" my server? The same way every other server on earth protects against it - verify EVERYTHING the client sends on the server.

What are your plans for abuse prevention?

I can't help what other server hosts do with their servers. I might make a blacklist of IPs if I need to, this is a trivial thing. I'm not sure what you mean by abuse prevention if not this.

How will you deal with a mod that brings your core game into disrepute, e.g. it Becomes as popular or more popular than your own server, but goes against everything you wanted to do with your game (imagine a pornographic mod which has all players naked for example).

Unless they made the game all about pretty princesses falling in love with handsome princes and riding around on ponies, I'd probably be fine with whatever. I can't say I've played a game I've outright detested. (If the graphics are good, I might spend more time on it than my own server ;P)

Will you have in game currency, and if so how will this also be secured against the mods?

Servers would run completely separately. At best, I would provide a gateway service to "approved" servers. There would be no exchange of player characters, my server's player account IDs, and no private servers would have access to my game's database.


Like I said, I'm not worried about the technicals. I've been doing this type of stuff for over a decade.

How will you deal with a mod that brings your core game into disrepute, e.g. it Becomes as popular or more popular than your own server, but goes against everything you wanted to do with your game (imagine a pornographic mod which has all players naked for example).

Unless they made the game all about pretty princesses falling in love with handsome princes and riding around on ponies, I'd probably be fine with whatever. I can't say I've played a game I've outright detested. (If the graphics are good, I might spend more time on it than my own server ;P)

And what if a mod does something unlawful? Like n4zi propaganda, racism or wathever? What if this becomes big and people start looking your way as you are the original developer?

I know this is a common problem with all games that allow mods, especially graphics or sound mods. Still, most of the devs I have seen have a rather weak stance on it, they tend to just turn a blind eye to it. That might work out fine 90% of the time, but it is still worth thinking about it.

IF the offending graphic or sound is just being used in a modded fork of your game run on a private server you are probably fine. You just put the bare bones online used by the culprit to create the offending product.

But if you run the servers that allow the sharing of graphics or sounds YOURSELF, you need to defend against such things. If there is offending material on YOUR server, it doesn't matter anymore who put it there. It is now YOUR responsibility to find it as fast as possible and pull it.

Do you have an idea already how to handle this? Do you want to use automated means (which most probably is never accurate enough)? Manual ones (which is tedious and slow, or uses A LOT of manpower)?

An MMOFPS called "Face Of Mankind" handled many of these issues very well from a gameplay fun standpoint.

1) EXP and levels / trainable skills - this leads to grinding behavior to catch up in capability to other players. Death commonly leads to a loss of EXP and possibly even "leveling down", which if not scaled by level can cause "rage-quitting", but is scaling by level fair to newer players?

In it, levels were purely something social. For example, at level 2 you gained storage space, at level 3 you could open harder doors without lockpicking them etc.

2) Skill/attribute rewards for completing quests - this is either automatic, reducing the ability of players to direct their own advancement; or leads to players spending a lot of time carefully figuring out which of the many skills or attributes to improve.

The game had randomly generated quests (Generated based on inputs from faction leaders) that showed you your rewards before you accepted it, so you could choose which ones to do. It always generated 5 quests for you, and after doing 2 you could re-generate new ones.

3) Better items becoming available - in MMOGs, these items are later given or sold to lower level players to make the game immediately easier to them, reducing their own feeling of advancement early on. MMOGs add level or attribute requirements to stop this, but I already covered issues with these systems.

The game had a maximum of 50%~ improvement in weapons/armor. So every item had High/Medium/Low quality, but while a low quality item might do 10 damage, medium would do 15, and high might do 20.

Actually thinking about it, it may have been even less then that.

5) New classes in a class hierarchy become available - I've never been a fan of class systems in ARPGs.

The game had no classes, so your loadout determined your class. For example, you could choose to forgo armor and instead use a super-lightweight but temporary-battery powered shield and you'd be something of a rogue (super fast running). You could bring a medigun (Shoots healing laser) and you'd basically be a medic.

1) Fame system - New and more challenging quests become available as you grow in fame (or infamy).

New objectives were available for random generation as you increased your rank (Level that gave no stat bonuses)

As for the modding idea, Air rivals had this... They had mesh/editors and texture editors at one point (Client side only, but encouraged sharing). Unfortunately they implemented client wide CRC's after a while to deal with speed hacks.

How will you deal with a mod that brings your core game into disrepute, e.g. it Becomes as popular or more popular than your own server, but goes against everything you wanted to do with your game (imagine a pornographic mod which has all players naked for example).

Unless they made the game all about pretty princesses falling in love with handsome princes and riding around on ponies, I'd probably be fine with whatever. I can't say I've played a game I've outright detested. (If the graphics are good, I might spend more time on it than my own server ;P)

And what if a mod does something unlawful? Like n4zi propaganda, racism or wathever? What if this becomes big and people start looking your way as you are the original developer?

I know this is a common problem with all games that allow mods, especially graphics or sound mods. Still, most of the devs I have seen have a rather weak stance on it, they tend to just turn a blind eye to it. That might work out fine 90% of the time, but it is still worth thinking about it.

IF the offending graphic or sound is just being used in a modded fork of your game run on a private server you are probably fine. You just put the bare bones online used by the culprit to create the offending product.

But if you run the servers that allow the sharing of graphics or sounds YOURSELF, you need to defend against such things. If there is offending material on YOUR server, it doesn't matter anymore who put it there. It is now YOUR responsibility to find it as fast as possible and pull it.

Do you have an idea already how to handle this? Do you want to use automated means (which most probably is never accurate enough)? Manual ones (which is tedious and slow, or uses A LOT of manpower)?

If it's illegal things, racist things, something like that, then I'd definitely add a blacklist.
I'm just providing the framework. I won't even be providing hosting. So I don't see how I'd be held any more responsible for this than any other framework provider.

Content packs will have a public key and a 128-bit GUID associated with them. The GUID has same number of unique IDs as IPv6 has addresses, so even randomly generated GUIDs should practically never conflict. I've considered a GUID registration service to prevent conflicts for sure, but I'm not sure it's necessary. The client's code will only allow downloading content packs with a new GUID, and communicating updates for content packs will use asymmetrical encryption using the public key in the content pack to ensure that only the proper source is sending updates to a content pack.

Ah okay I understand. You're going to encourage modding of content packs, but the source of the game itself will be off limits, so they can't use a custom content pack to connect to your server, as the server sends it and they can't change the code that fetches it?

That makes sense and might work.

Do you have plans for a community site or such where content packs can be shared?

The general idea is that the server would know what content packs (and content pack versions) should be required, so they'd stream what was required to the client.
An interesting problem could come up when a private server uses content packs provided by another private server, only the client's is out of date, but I'm not going to bother trying to fix this right now, I'll find something that works in practice.

I will definitely make the source code of the server available. I will probably make the source code of the client available, too, but I'll definitely try to design things so that it's not worth the effort of source-modding a client. The design in my head is basically that I implement things that need to be fast and play together properly - process input, graphics interface, music playback, core network - in C++, and everything else (GUI controls, parsing unknown network messages, etc) is done by scripts.

In it, levels were purely something social. For example, at level 2 you gained storage space, at level 3 you could open harder doors without lockpicking them etc.

The game had no classes, so your loadout determined your class. For example, you could choose to forgo armor and instead use a super-lightweight but temporary-battery powered shield and you'd be something of a rogue (super fast running). You could bring a medigun (Shoots healing laser) and you'd basically be a medic.

As for the modding idea, Air rivals had this... They had mesh/editors and texture editors at one point (Client side only, but encouraged sharing). Unfortunately they implemented client wide CRC's after a while to deal with speed hacks.