Hi GameDev, I come here seeking a little wisdom.

I aim to design and develop an MMO game that I've pondered over for a number of years. I envision a game similar in style to Club Penguin, targeting a demographic of children between the ages of 6 and 14.

• The player controls an avatar, 'interacting' on a basic level with other players, e.g., public/private messaging, competing in mini-games, etc. I say 'interacting' in the sense that players observe each others actions, but they do not directly affect one another, i.e., if c00lguy444 chops down a tree, the tree remains standing to all those except c00lguy444.
• There will be no combat system.
• AI will be primitive to non-existent.
• The world itself will comprise of a number of locations, e.g., the forest, the beach, etc. Each scene is a 2.5D space with an interactive background, i.e., clicking on a tree will make it shake.
• There will be a variety of educational and just-for-fun mini-games, with badges and cosmetic gear as rewards. The majority will be single-player, but some shall be competitive.
• Players should be able to personalise their avatar, wear cosmetic rewards, and show off their badges on their public profile.
• Players will each have their own customisable space to entertain friends.

My question is: what will I need to learn in order to accomplish a project of this magnitude; and for those who may have attempted something similar before: what general advice would you give me before I start? I'm under no illusion that this is going to be a quick or cheap process.

My experience is in Java, Python, C and HTML/CSS, although I'm certainly no expert. Am I right in thinking that ActionScript 3.0 would be a good place to start?

Any help would be greatly appreciated!

TL;DR: What languages / resources are required to create an MMO such as Club Penguin.

My first and formost advice is: drop the MMO monicker when talking to game devs of any kind. It might be a good marketing fad at the moment to sell stuff as "MMO" that actually only qualifies as MO (as in, multiplayer games without a MASSIVE amount of players interacting). It is kind of a taboo word around here for multiple legitimate reasons I will list below. And yes, I know that the MO <> MMO distinction is a very blurry one, but that is besides the point...

1) A true MMO is a MASSIVE undertaking no matter how primitive the graphic is or how simple the game design. The sheer amount of networking black magic needed to keep a world persistent and have thousands of players on the same server and potentially interacting with each other is staggering, it is many magnitudes more complex than simple multiplayer game networking.

Clearly above what a small team can achieve, and even a six figure investment will not get you far. Yes, most people on this forum would not believe that you have a the ability to secure a seven figure budget from anyone as long as you are not a known name in the gaming industries.

2) Most Poster asking about MMOs have little expierience (because most expierienced devs would steer clear of it anyway without massive backing), and most of the time the attitude and unreasonable expectations that come with that. Not saying that is the case with your post, just giving you examples why the MMO monicker has gotten a bad name around here.

3) A lot of MMOs out there are actually not really MMOs... its basically a marketing fad at the moment to call everything an MMO... WoW Killer and whatnot.

World of Tanks an MMO? don't make me laugh! They might have 100'000 players on the server cluster... yet only 30 interact with each other ingame. that is not an MMO, persistent world or not.

Still a brilliant game and makes just as much dough as some of the most successfull MMOs...

With that out of the way, lets see what we have here:

First, you want to create a Client/Server archtiecture most probably... for an MMO you definitely need a server, and its also highly advisable to go with that for any other kind of multiplayer. Its more complex and more expensive, but you can avoid some of the pitfalls of peer-to-peer networking.

And of course, if you want to have a persistent world, you gonna need a server too.

Picking the language to develop the server or the client in is pretty much up to you. Personally, for the client, I'd say as long as you are looking for a 3D Graphic and a medium to high graphic fidelity, go with an existing engine. This way you can go straight into programming game logic and building your game without worrying about low level plumbing, as soon as you got comfortable with using that engine.

If you want simpler graphics, 2D for example, writing from scratch or using lower level frameworks is also a good option if you want to do that. Wheter you use C#, C++ or Java for that is up to you. Some languages might have some small advantages over others, but you will see most languages being used by some devs. Main ones at the current point in time must be C++ and C# for PC, Java and Objective-C for mobile AFAIK.

For the server things get more muddy. You could look at some readymade game server frameworks to lighten the low level plumbing burden again, but you would most probably get more problems tuning the server for best performance later on. don't know, haven't tried. Some keywords here are smartfox server, photon, and most probably a dozen other similar services and frameworks.

If you decide to write from scratch, use whatever language is most efficient for you, just don't forget that server performance is even more important than client performance. A bad performing client can be a PR desaster... a bad performing server might triple your server cost!

As usual with development, start small, and don't try to tackle everything at once. In your case it might make little sense to write a singleplayer client without networking... but you could write the client and server as separate processes on the same machine to test your first build locally, yet get the structure in place for a later networked version. Then move to a simple networked game without persistence.

Then tackle the wonderful world of databases and other persistence tools if you still got the appetite for it.

As to what is needed to build something like that in skills:

lots of programming skills, networking most of all, db programming and administration skills for the persistence layer. Depending on how you tackle the client Graphics Programming is a must (if writing from scratch) or a very handy add-on (if using an existing engine and not writing your own shaders).

Depending on what you have in mind for art, you either need 2D artists (or art skills), or some 2D concept artists and either a host of different 3D artists(3D modellers, texture artists, riggers (maybe), animators, special FX (maybe)), or very good 3D generalists that can fill multiple roles at once.

Music and Sound effects most often gets outsourced. Else you will also need somebody who can produce these.

Game designers will be needed to come up with the game systems, and balance everything when the game starts coming together. Level designers of some kind are needed to set up your ingame locations.

These things can be done by others or yourself, just don't understimate it. Coming up with good systems and tweaking / balancing them until they are fun is hard work and takes a lot of time. Similar with level design: no matter how much of a procedural approach you take and how much an engine editor can lighten the load on the level designer... in the end somebody needs to get in and tweak everything that needs to look good, and correct all the stuck points and whatnot.

Actually his scope's reasonable if he's moderately experienced.

As he said, players don't really interact with each other much, so I'm guessing it wouldn't be a problem if he runs most logic clientside. Also, correct me if I'm wrong, but club penguin isn't Really a MMO, right? Doesn't it have room limits of 8 people or something?

Actually his scope's reasonable if he's moderately experienced.

As he said, players don't really interact with each other much, so I'm guessing it wouldn't be a problem if he runs most logic clientside. Also, correct me if I'm wrong, but club penguin isn't Really a MMO, right? Doesn't it have room limits of 8 people or something?

No, you can have more than 8 people per room.

I agree with you. A lot of the logic can be handled client side which is good for a server.

tbh the most flaws are conceptual

im a parent, why would i let my son of 10 join this MMO?

mmos are bad community even at 20 surely i would be stupid to buy this MASSIVE game for my children..

not to consider that a low age online game would be impossible to defend against predator and not necessarly adult predator, even a 16 yo is a predator to a 8 yo

last but not least the most common problem in online games is bullism and even here, i wouldnt put my young son in a place where he can be bullied even more

Actually his scope's reasonable if he's moderately experienced.

As he said, players don't really interact with each other much, so I'm guessing it wouldn't be a problem if he runs most logic clientside. Also, correct me if I'm wrong, but club penguin isn't Really a MMO, right? Doesn't it have room limits of 8 people or something?

True, but:

a) he didn't state prior expierience...

b) even with a reasonable scope, a persistent multiplayer game can get out of hand quickly depending on the amount of feature creep.

Running logic clientside might be possible, but it has to be carefully weighted against the potential to cheat. Of course, things that do not affect other players might be a good candidate for clientside calculation, but: does the player gain anything if hacking it? ingame money, resources, points, whatever? In a persistent online world, especially if linked to a F2P model, you do not want to leave anything to chance that might affect your ingame economy.

Who will buy your premium currency packs when he can just create ingame currency with cheats?

So I would be really careful before putting ANY logic into the client. Even 12 yo nowadays quickly start to cheat if a game is successfull thanks to quick and easy online distribution of cheatpacks, mods and hacks.

EDIT:

Okay, on my first read through I missed the line where the TO mentioned 2.5D Graphics. That certainly makes graphics much easier to achieve, as long as animations are kept to a certain limit (If lots of buttery smooth anymations are required, a 3D game with an isometric view most probably is the better solution).

It also means an engine like GameMaker most probably is the TOs best bet to shorten client dev time.

Server development is not affected much by that though....

Sorry for the delayed response. I've tried to answer the majority of the points raised.

As for my experience, I've made a couple of basic games. The most advanced being a dungeon crawler with a client / server model architecture, but never anything on this scale.

@Gian-Reto, I appreciate the time and effort you put into the response, I'll be sure to take it on board.

My first and foremost advice is: drop the MMO monicker ...

You're absolutely right, the game I'm describing is more of an MO than an MMO.

First, you want to create a client/server architecture most probably ...

A client / server model was what I had in mind.

If you want simpler graphics, 2D for example, writing from scratch or using lower level frameworks is also a good option if you want to do that. Whether you use C#, C++ or Java for that is up to you.

The graphics will be simple. Avatars will be 2D images as opposed to 3D character models.

I'd favour Java personally given my background experience.

For the server things get more muddy. You could look at some ready-made game server frameworks to lighten the low level plumbing burden again, but you would most probably get more problems tuning the server for best performance later on ...

I'd plan to write a basic server from scratch during the early stages of development, and, should the game be performing well, invest in a platform such as SmartFoxServer as you suggest.

As usual with development, start small, and don't try to tackle everything at once.

Noted. Thank you.

As for required skills, my strengths lie in graphics and game design. However, based on the game's success and performance, I'd outsource professional audio / visual artists before beta testing.

Actually his scope's reasonable if he's moderately experienced.

As he said, players don't really interact with each other much, so I'm guessing it wouldn't be a problem if he runs most logic clientside.

I agree with you. A lot of the logic can be handled client side which is good for a server.

This is reassuring to hear. The reason I explicitly described the game's interactivity was in hope that the client-side could handle a significant chunk of the logic.

tbh the most flaws are conceptual

im a parent, why would i let my son of 10 join this MMO?
mmos are bad community even at 20 surely i would be stupid to buy this MASSIVE game for my children..
not to consider that a low age online game would be impossible to defend against predator and not necessarly adult predator, even a 16 yo is a predator to a 8 yo

last but not least the most common problem in online games is bullism and even here, i wouldnt put my young son in a place where he can be bullied even more

I appreciate your feedback, dworm. Of course, there are a number of health and safety issues which would be addressed in time. I didn't bring any of these to surface, as I was seeking technical advice.

The game would be F2P. Optional in-game purchases would be purely cosmetic. As I briefly explained, the game would be educational.

Running logic clientside might be possible, but it has to be carefully weighted against the potential to cheat. Of course, things that do not affect other players might be a good candidate for clientside calculation, but: does the player gain anything if hacking it? ...

So I would be really careful before putting ANY logic into the client. Even 12 yo nowadays quickly start to cheat if a game is successful thanks to quick and easy online distribution of cheatpacks, mods and hacks.

This is an issue I'm wary of. There will be a form of in-game currency. Could you suggest a way of circumventing this problem, while still handling logic client-side?

Okay, on my first read through I missed the line where the TO mentioned 2.5D Graphics. That certainly makes graphics much easier to achieve, as long as animations are kept to a certain limit ...

It also means an engine like GameMaker most probably is the TOs best bet to shorten client dev time ...

Just as you describe MMO as a taboo word, is GameMaker not another one? I was under the impression it was not well regarded among game developers.


Thanks again to you all. I was a little overwhelmed by the response!

The graphics will be simple. Avatars will be 2D images as opposed to 3D character models.

I'd favour Java personally given my background experience.

Well, I think nowadays Java is quite viable as a game dev language... it might just be that you need to work a little bit harder to get acceptable performance from it, and you most probably will never quite reach C++ levels of performance.

Usually I would say don't worry about it, but with a client / server system, at least the server parts performance might directly influence your profit margin (as in, 20% less performance means 20% more resources needed on the server, which might increase cost)d.

Still, starting in Java now for a prototype doesn't mean you cannot rewrite the game for release in C++, or maybe even create a second prototype in it. Never be shy to refactor your code. It might seem like a waste of time now, your future self will certainly thank you for it! And maybe it turns out your code runs perfectly fine, some Java Game Dev crack tunes into the discussion to give you helpful hints or whatever, and you don't need to rewrite in a different language... who knows?

I am a Java Programmer for Business Apps, I use C# and the Unity Engine for Game Dev, so I wouldn't really have any expertise in how to make Java perform in Realtime applications like games (most Business Applications are not really that performance critical)... there are enough people on this forum that are using Java for their Game development, so if you want specific info on how to use Java for game development, best way is to first search for old threads, and then ask the remaining questions in a separate thread.

This is an issue I'm wary of. There will be a form of in-game currency. Could you suggest a way of circumventing this problem, while still handling logic client-side?

AFAIK that is a very difficult question. Kind of the holy grail of Multiplayer Game programming... current trend seems to be to just move everything to the server that needs to be trustworthy. That is also why the current crop of multiplayer games often have simplified and streamlined game logic compared to some singleplayer games.

To be honest, I don't think you should worry to much about server performance... a simple game concept like yours should be easy to calculate on the server. You might be able to lessen the load on the server a little bit by making some things purely cosmetic (example that might not apply to your game concept: Make debris created during an explosion not affect gameplay in any way (no collision model, no influence on line of sight and so on)... that way you can happily calculate debris physics client side, because it doesn't matter if debris falls to different places for different players)...

As said, just beware of the obvious pitfall: just because other players can't see something doesn't make it save to calculate client side. If it has an influence on game logic, even if its just an influence for a single player, it can and will become a target for cheats.

Lets come up with some examples more suited to your concept... be aware that this is all my personal opinion, and I am make a lot of assumption about your game concept:

1) Your player can cut down trees, but only he will see the tree being cut down, and it has no ingame effect other than the tree now lying on the ground, therefore purely cosmetic.

No problem leaving the code in the client. Players might come up with a cheat to cut down ALL trees in the game world with a single click, but that doesn't do much for them. If the effect is persistent, it might even just piss them off because their instance of the game world is deforested now for all eternity.

You could just as easy prevent them from doing that by having a max number trees that can be lying on the ground at the same time and check that at startup (can be cheated again, but allows to reset the cheat), and actually, at some point this update has to reach the server anyway for persistence. If a player cuts down more than a single tree at the same time, something is fishy, and you can reject it, making it non-persistent.

2) You have a puzzle somewhere that needs the player to shove around boxes to reach a new part of a level. IMO can be left client side. Yes, players might cheat the puzzle to get the boxes align correctly without needing to solve the puzzle... but a) people might just read a walktrhough and "cheat" the game in some seconds without hacking your code, and b) the reward for the cheat is just a quicker way to whatever is lying beyond the puzzle obstacle, which has zero influence on your ingame economy, as long as the puuzle wasn't designed to be only solved by a certain % of the playerbase and the reward gained by solving it isn't overly huge.

In the end, the player will just make the entertainment shorter for himself....

3) A player can dig in the ground to find some rewards that might include ingame money, or resources either also sold in a cash store, or linked to the ingame economy. To prevent players doing that 24/7 to get "ingame rich" quickly or not having to live with freeloaders limitations, this action can only be repeated once per minute.

Now, this needs to be on the server. There is no way around it. Just limiting it when persisting the rewards isn't really enough. You might get the guys that try to get rich by spamming the digging 24/7, but the guys that repeat the digging only once a minute, but hack the possibilities to get certain rewards are hard to catch. Your server would need to keep track of what the player dug up in the last few tries anyway to spot a pattern to goes way outside of standart deviations anyway (like getting the super rare sword of IMBAness like 10 times in a row), so you could as well let the server do the RNG diceroll and tell the client what the player dug up.

So, TL;DR: if you don't want move it to the server, it should be purely cosmetic, or only affect a single player without ANY influence on the players resources / economy. Everthing else needs to be calculated server side. If that is too much load, and you cannot improve performance, you need to simplify the logic.

Just as you describe MMO as a taboo word, is GameMaker not another one? I was under the impression it was not well regarded among game developers.


Thanks again to you all. I was a little overwhelmed by the response!

Well, see, different devs have different opinions around here. Some will teach you to avoid existing Engines like the plague and write all your games from scratch (and at least for learning, they have a valid point IMO)... others will tell you to not reinvent the wheel and develop games, not engines.

Same with different Tools and Engines. Personally, I never tried Gamemaker so I cannot really judge... but there are people around here that did use it and are happy with it, and as usual, you will also find the opposite.

Again, best thing is to create a separate thread to ask if your game idea can be realized in GameMaker, or if there are better options around for that. Of course before asking, you should investigate yourself a little bit. Given enough time, maybe check all the popular game engines as most of them offer 2D Workflows nowadays. But a lot of them are 3D Engines in their core and quite overkill for a 2D Game because of their complexity...

Which brings us to why I even mentioned GameMaker: it is a simpler, pure 2D Engine, and as far as I know it is the most used and mentioned 2D engine out there.

First means less complexity and most probably flatter learning curve, second means large community, so lots of tutorials available, and many people you can ask if you get stuck.

In the end, there will always be people that judge a Book by the label (like games that have been built in Unity cannot be as good as the ones built in CryEngine...riiiight), but that is hard to evade as an Indie anyway. Find the tools that let you be as productive as possible, and don't worry about the labels as long as the output is satisfying.