I remember one of my first hobby projects was trying to simulate the universe with python (thousands of 3d celestial bodies gravitating around each other). About a month later I tried to simulate a economic system with Ruby.
Let's not become the old people telling the kids not to have any fun.
The problem with making MMOs is that they're massive projects that are difficult for large teams of seasoned developers with large budgets to complete and succeed with.
Just how much fun is someone going to have trying to tackle one of these things as their first game? It's a guaranteed setup for failure, for being overwhelmed by the scope of your project, for not knowing how to even begin to tackle the problem, for - well, mostly a lot of frustration and not a lot of fun.
I see it happen over and over again. People join gamedev communities, ask how to make an MMO, and then get fustrated, leave, and never return when nobody has a tutorial on "how to make an MMO from scratch with no previous experience required in 21 days".
Kids, go have fun. Make things. Accomplish things. Dream big - but start small and work your way up to those big things. You'll get to your goal quicker anyways - more feedback from more projects - successful or not - means you learn faster.
MMOs do not have to require massive development if you strip the requirements back to the bare essentials. There are a lot of software engineering concepts involved (and tons of messy business logic), but this just makes MMOs better as learning projects/teaching tools.
For example, as an exercise to test the ability of code golf-style/APL/array programming languages to handle messy business logic, I recently built a 2D tick-based MMO in kdb+/q: https://github.com/srpeck/kchess
Note the design decisions/constraints that reduced development time:
- High programmer efficiency kdb+/q platform
- Simple client-server architecture
- All-on-one-box - kdb+ is both the front-end server and the datastore
- Websocket-based networking
- Tick-based - 1 second ticks to limit latency issues, though the server fully supports near-realtime ticks
- No differentiation between players and AI - both are networked clients (e.g., see here for the simple websocket client docs: https://github.com/srpeck/kchess/blob/gh-pages/docs/kchessdo...)
- No player identities (generally a commercial showstopper, but not for a side project)
- No 'content' - simple 2D graphics (though making the engine 3D would be trivial due to the vector paradigm), no progression/quests/RPG elements
Of course, there are the MMO pieces that generally increase development time:
- Game state cannot be globally fanned out given the sheer number of possible client connections (the first M - Massively)
- Untrusted players/clients
But once you have a simple, solid base engine, converting the result into an instance-based MOBA or a full MMORPG is not difficult, just time-consuming.
Equally however people who attempt large projects will accomplish at least a number of small successes along the way, each carrying value as a learning / growth opportunity. Many times those small accomplishments could never have been had with a small or even medium size project.
People learn and engage differently. Some people will gain a lot from starting at a fundamental level and working their way up. Others will be much more stimulated at the macro level, and let's be honest the goal of learning is rarely to create a true product but for the sake of learning itself.
> Equally however people who attempt large projects will accomplish at least a number of small successes along the way
That frequently hasn't borne out from what I've seen. People try to tackle MMOs without even understanding basic programming. They're so focused on trying to build their MMO that they can't be bothered to read a programming tutorial long enough to learn what loops are. They just become help vampires - accomplishing nothing truly on their own, frustrating both themselves and those around them.
Small successes require small projects, sub-projects, or sub-sub-projects. You can carve some of them out of projects where you've bitten off more than you can chew, but MMOs tend to be an additional magnitude of order larger - and from what I've seen, that much more difficult to get even small successes off of.
> Many times those small accomplishments could never have been had with a small or even medium size project.
I'd question this. Care to share any examples? I can't think of any sub-projects which can't be spun off into project of their own.
> People learn and engage differently. Some people will gain a lot from starting at a fundamental level and working their way up. Others will be much more stimulated at the macro level,
Sure. Keep dreaming big. I'm not knocking it's effect on motivation.
I am questioning how motivating the actual act of trying to tackle an MMO as your first game is, and how much you'll learn from it. Where are all the indie developers trying to jump straight to making MMOs with no smaller games in the middle? How many of them have gotten so far as making a chat server? Why can I count the number I'm aware of on one hand - outnumbered by the number of entire communities of indies, each bristling with untold numbers of games - both in the progress of being made, and outright completed?
Where are all the indie MMO developers, if it's so motivating?
> and let's be honest the goal of learning is rarely to create a true product but for the sake of learning itself.
This is bordering on a truism - the goal of learning is to learn? Sure. But if that's your only goal - why make games? And is tackling an impossibly large project really the most effective way to accomplish that learning?
Another extremely common goal of making games - I'd argue far more common than the goal of pure learning - is to have fun playing the game with the idea you had. Which project is going to let you actually scratch that itch - the never-complete MMO or the quick and dirty shmup? Which one can you share with your friends and have them play? Which looks better on your portfolio when applying to that game development studio that makes MMOs, giving you hands on experience with the real deal?
Maybe, maybe not:
https://en.wikipedia.org/wiki/Vendetta_Online#Development
[ed: But sure, as a first game/application, maybe not]
Agreed. There is a reason MMOs didn't appear until 30-40 years after the first video games. They are extremely complex, require a large number of assets, and a large testing team.
I am still waiting for that 100% science based dragon MMO.
MUD came out about 5 years after Adventure. It's not really a tech limited genre.
I wonder if any MMO has tried using specialized hardware accelerators like ASIC or FPGA boards for acceleration of e.g. voxel based physics?
If anything, it's easier to justify running exotic hardware on a server, where its cost will amortize among thousands of players, than it is to expect users to install it on the client. And the game industry has tried physics accelerators for clients (PhysX).
I suspect H1Z1 to run its server-side phisics simulation on GPUs. Definately not ASIC / FPGA, but still a co-processor ;)
Well, maybe GPUs are good enough and more specialized hardware isn't needed, or does not justify the additional development costs?
It is not only about development costs, but also about hosting costs. As a rule of thumb, when running an MMOG you won't have your own servers in your own office, but will rent them (apiece or as a part of the cloud) from an ISP/CSP. And then it is not about "what you'd like to have", but rather about "what they have". You may find a provider with GPUs (though they're going to be damn expensive), but with ASIC - no way (by definition, as ISPs are only dealing with commodity stuff). Hosting with FPGAs might exist in theory, but I've never heard of it. Of course, there are also colo options where you can host pretty much your own servers, but they're usually too much headache to deal with - and too expensive too :-(.
Yes, there is colocation. It is too much headache to deal for me, on my own, but if someone is using it (it exists for a reason, right?), I expect the companies operating MMO games to be one of them. World of Warcraft costs $200M worth of infrastructure [1] (annually?) including salaries; surely you can afford colocation, as well as whatever you need, for such kind of invoice?
[1] https://www.nethosting.com/world-of-warcraft-case-study/
Is the entire book completely free or was this just some parts of it? Its too good to be true.
This has to be the first book that extensively goes through writing one, right?
> Is the entire book completely free or was this just some parts of it? Its too good to be true.
"beta" of the entire book is going to be free. "Release" version is going to be paid (sorry). OTOH, if you make a "useful" comment (the one which makes me to change the text, by pointing out a mistake, suggesting something, or asking a good question which is not covered yet) - you'll get e-copy for free.
> This has to be the first book that extensively goes through writing one, right?
To the best of my knowledge - yes. There are bits of information available here and there, but certainly not everything in one place.
Hey man best of luck! Looking forward to see how this ends up going. I won't be tackling this again but I've always hopped someone write a book about it. I read some. You're doing awesome work. Reminds me of the game pattern book by Nyström!
Thanks! And BTW Nystrom's Game Programming Patterns is one of a few great books on game programming, so I take comparison as a compliment :-)
"This book is targeted towards at least somewhat experienced developers (in other words, it is NOT “how to develop your first program” book with IDE screenshots and copy-paste examples). If your game project is your very first programming project – you’re likely to have difficulties understanding this boo"
After spending sometime around people that want to become indie developers, I cannot emphasize this enough. Please do not try to make an MMO as a first game.