Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Do you see any value in an open source mmo?
cochs
Member UncommonPosts: 92
A bit of back story. I am the author of an open source server side mmo platform that was specifically designed to handle games like ESO and GW2 with massive open world pvp. I started the project after leaving a successful studio where I was the server lead, and worked on several successful multiplayer games.
So far I've been focusing on providing the platform to other developers, and currently we are getting ready to launch a cloud hosted version. You can see the project on github at https://github.com/gamemachine/gamemachine. The main website is down right now as we are taking advantage of the holidays to update it for the commercial launch.
Lately I've been thinking about actually creating a sandbox mmo based on this platform, where the majority of the client code would also be open source. The end result would be something like Minecraft crossed with Archeage with some interesting twists.
- The game produced by our team would most likely be subscription based, with the subscription providing not just access to the game, but the ability to create your own area of the world with your own rulesets in many areas, and even your own art and terrain if you want.
- The client side engine would be based on Unity3d (the server is java based). While not the most technically advanced engine out there (the next version has some nice improvements FYI), it is a very accessible engine that lends itself well to modding and allowing the largest number of people to play around with creating their own worlds. One thing to remember is that instead of separate modding tools, we would be providing access to the full development toolchain.
- We would have something resembling what Unity has with their asset store for modding the game. If you create some cool mod, you can put it up for free, or sell it for whatever price you want. We would run the store and handle the payments, taking a reasonable cut for mods that were not free.
The end goal is more than just creating a great sandbox game. My personal goal is to create a framework that other indie developers can use that will give them a head start, especially when it comes to the server side tech which is normally where a lot of mmo's struggle, and where we happen to have a lot of expertise. Don't get me wrong, we still want to create a great game, but if we can drive down the cost of producing indie mmo's accross the board, I think that benefits developers and players alike.
As for the game and kickstarter project, we would have a minimally playable version within a couple of months. Contributors would have read access to most of our development code, and would even be able to submit pull requests and contribute to the project. Because we already have a good head start with a working server framework, a lot of what needs to be done is mostly higher level game systems and visuals. Not that there isn't a lot of work to do, but time to getting something playable will be dramatically reduced compared to many kickstarter mmo's.
There are two main questions I have for everyone out there.
First, does the above even have an appeal for you, or is it too technical? Or maybe you just think I'm explaining it badly (entirely possible) ?
Second question has to do with how early to release new content/features. Visuals are normally one of the first things people look at when judging a new game, and I'm concerned about finding the right balance in how fast stuff is released. Would you prefer to see more polish before something is released, or would you like to see something more like a fixed release schedule where you get a new build every week so you can monitor progress?
Lastly, we are also looking at different way for players to contribute other than through cash contributions. Contributing code is fairly straight forward. We will spec out the systems and our development list will be open. You can fully partake in the process and submit pull requests via github.
Visuals are a bit more difficult but we are looking at using the same process. Instead of providing specs for what needs to be done we would provide sample art that shows the look and feel for what we want, along with guidelines and specific lists of models/props/terrain/etc.. that we need in the next milestone. At the least we will be doing this on a trial basis to see how it goes.
Any and all feedback appreciated (even negative, actually especially the negative).
Comments
Yours is an interesting project.
I've long believed that, while licensing a game engine could greatly increase the odds that a given studio could successfully launch a game, it would often decrease the odds that they'd launch a good game. Too often people rush off to license some off-the-shelf game engine because they don't have the capability to make their own, and then not having the capability to do for themselves what they need really bites them later on in unexpected ways. Even if that's more a problem for small, indie developers than big, established studios, if you're trying to make an open-source game, you're dealing with amateurs.
There's always the problem that, things that are basically trivial if you have them in mind before you write any code can be completely intractable if you try to patch them on after much of the code is already written. That's not to say that a game studio should write everything themselves; licensing a library that does exactly what you need and does it well often makes a ton of sense. But the larger and more interconnected a set of libraries is, the less likely it will be to match your needs. Relying too heavily on finding the right libraries to do too much stuff for you without understanding exactly what the libraries are doing is a surefire way to end up with really weird bugs that you'll never be able to fix.
I don't think that an open-source MMORPG would have much chance of working unless you had a number of professional-quality programmers on it full-time who were really committed to making it work. It's likely that most of the things people submit would amount to changing play balance: nerf this, buff that, change loot, etc. That's only a tiny fraction of the work that goes into making a good game.
Letting people choose their own mods could also fragment things very severely. In order to do stuff with other people, you really have to be playing the same game as they are. You can have a few different server options (e.g., some games have PVE and PVP servers), but you can't allow people to pick arbitrary subsets of available mods unless it's extremely restricted what the mods are allowed to do. If you let people submit whatever mods they want, then a Double Loot Mod will be all the rage until someone comes out with a Triple Loot Mod, and so forth. There will be no semblance of balance anywhere if you don't have some very severe ways to crack down on that.
Good points, and I left out quite a bit of detail in the initial post.
We do have a core team. The idea is not to base development on contributions but rather to open the process. With almost all open source projects you have a core team that does 90% or more of the work. Over time you do get new developers this way too, and even more important IMO it gives your core team an incentive to write better code.
For the player owned worlds that would definitely have limitations. The idea right now is that all player made mods go into the player store, and are tagged as being usable in the commercial game, or only usable in your own game. The mods you can use in your own world that is attached to the commercial game would be limited. 3d models and terrain would have to conform to specific guildelines, and rules on combat, the economy, etc would always be global.
One lesson I learned from working on a game that had player driven content is that you just can't have an anything goes policy. At launch it took 2 hours before someone submitted a penis (something we all had bets on because we knew it would happen it was just a matter of how long). What did work well is we let players submit content but put a time limit on submissions, with the limit being lower for players that had previously submitted content we chose to go into the store. Basically a simple reputation system that was used to screen content. It did take some time to select content and test it, but it still worked pretty well. We ended up with around 25% of our content being player made.
In short, the player driven world concept will look more like what they had in shadowbane. You can build your own cities with guards, merchants, etc.. And you have some ability to provide your own content or at least customize it from a a catalog of approved items. You can script stuff like the pathing for guards, the dialog for npc's, stuff like that. But if you really want your own global rules and your own content without restrictions, you need to run your own servers.
This video talks about an open source by someone with experience working on an open source MMORPG from beginning to end (If I remember correctly). I watched it a few years ago and it's very interesting.
Ya I'm aware of that project. I don't think that an open source mmo is really viable if that's all you have. In fact I'm starting to see already that this is the impression people are getting. The game we envision will not be open source per say even though it's based on an open source platform. To us, the game is a vehicle to drive the platform which is open source. But the game has to survive on it's own merits and have a business model that makes it profitable.
I think that's a common misconception when it comes to open source. Most of the websites you visit, and most of the software that runs them is based on open source platforms. There is no hard data that say's open source is less secure. In fact the data we do have points to open source being slightly more secure.
Security through obscurity more then often results in studios that take all sorts of shortcuts that result in even more hacking. Just look at Archeage. Most of the hacks in that game come from letting the client be authoritative when it just should not be, which is completely not excusable in this day and age.
With an open source game if a hack comes out, you can be sure that players would be going over the source to find out what made the hack possible. And if they found something utterly dumb like what the archeage developers did, there would be hell to pay. Open source keeps developers honest. You can't say one thing when your code tells a completely different story. There are just too many players who are also developers and will call you on it.
Overall security bugs would probably surface faster as hackers go over the code, but they would also be fixed faster.
no .. i don't see any value.
Values in games are no longer having an engine, and a structure, and it is really about the content. And that, you have none.
Relying amateurs to provide content probably won't work very well. You will have a small player base without good content, and you can't attract good content providers if you don't have the player base. It is a chicken & egg problem that cannot be solved unless someone will invest a boatload of money.
I'd expect an open source client to be much easier to hack than a closed source one precisely because you can see what it's doing in great detail. Any information that the server sends to the client will be available for bots to do whatever they want with, even if it's not yet visible on the screen.
And open source doesn't necessarily mean that exploits found, other than by people looking to abuse them. Remember heartbleed?
The premise that open source is easier to hack because the source is easily available is not really accurate. The fact is that security depends on a lot of things that can offset each other. Open source gives hackers more access for example, but closed source by definition precludes being able to audit it for security issues. The only real consensus on the subject is that it depends.
For games in particular, the only secure client is one that doesn't make any decisions. You have to make the server authoritative for everything that matters. The vast majority of game hacking is because developers violate this rule. Once you fix that, the attack vector starts to look a lot like any other piece of software, where most security issues come from not handling user input in a secure way.
The thing is that it's always the 1% you have to worry about when it comes to hacking, and those people will not be stopped by hack shield, code obfuscation, encryption, or whatever trick you are trying to use. And it just takes one guy who writes a hack tool to do the damage. This is especially true with mmo's, because they tend to have longer lifespans. You can use some of the above tricks now and then to prevent hacking for short time periods, but it's only a matter of time.
"This may hurt a little, but it's something you'll get used to. Relax....."
All I am reading is a game with mod-able content. For example:
I am a professional programmer with many years terrain engine development experience but not really interested in art, level design or animation. My strengths are GPU shader, c++ and .Net, though I am professionally competent in other areas such as DB work, web services (I've done enterprise Java, tomcat, ASP, PHP etc) blah blah. By trade I am an Integration Specialist, mostly in Network Security. Would you consider contributions, or are you just after artists and modders?
First I agree for players it's about content. I think I did a poor job explaining. The core game would not rely on player generated content or player mods.
Player generated content being a value is something I also question, especially if it requires knowledge of traditional 3d modeling tools. Shroud of the Avatar started out crowdsourcing player made assets but from what I can tell stopped at some point. It probably became too difficult to maintain a consistent look and feel when you have a bunch of different people contributing. That was actually my primary concern.
Thanks for the feedback.
Have you looked at games that have open sourced their clients. The one that immediatly comes to mind is Wurm Online. With Haven and Hearth allowing players to use their own version of clients as well(not orginally developer intentioned though).
EDIT:
Open source also isn't a selling point.
The normal player that isn't aware of it won't know the difference. There are also a subset of normal players who will see themselves as being "out of the loop"(which is a dangerous things for MMOs, IE: a genre where players get really involved).
Practice doesn't make perfect, practice makes permanent.
"At one point technology meant making tech that could get to the moon, now it means making tech that could get you a taxi."
A lot of this is still rough, but most likely it would be usable for a mixture of skills.
Coding would be the easiest place to contribute, it would work almost like any open source project. You would have access to the milestones and what needed to be done, and access to the developers list to coordinate. Coding standards is something I'm actually working on now as I've been getting more requests from people who want to contribute here and there to the server side platform.
Content is a bit more fuzzy because we still haven't nailed down the process, or even decided how far to go. Our biggest concern with content is maintaining a consistent look and feel. My current thought on the subject is that we would have specific limits on a lot of stuff, so that if you go to a lot of effort to create something, chances are it would get approved if you are following the specific guidelines. For example we might allow you to create building models however you want as long as they fit within the allotted space, but we might have a specific set of textures available. There would always be some manual approval process, otherwise there WOULD be a penis house in rather short order.
Just because something is open source doesn't mean it is not secure. Just because you know the code doesnt mean you can hack it. Many of the encryption algorithms are open source and they are still secure.
The whole thing of seeing something before it is on screen depends on the server-client communication. If the server doesn't tell you a player, ressource node or whatever is 200 units away you cant know it is even if you read everything/hack the client. And the time spent of taking advantage of an open source client to hacking it isnt that much of a difference if you know what you are doing.
Besides most MMO exploits exist because the server is done badly. For example the famous teleport hacks exist because the server doesn't check the client location properly. I can tell the server all day long that I am over there but if it says I can't be then I am not.
@OP How would your game be different from Landmark?
Astonia 2 is open source, M59 is open source. Both have more than 1 version available with their own small player bases. Just 2 examples that people here would probly know about.
From past experience it has the capablility of the game being greatly improved by the community but instead it is the game as it was at the state it got open sourced with perhaps some minor improvements on rare occasions. More often than not your just dealing with the kid next door who doesn't really know what he's doing.
Something like adding a new skill in which you thought would be easy turns into something which takes alot longer due to unexpected results eg: changing the name of a skill from herblaw to herblore which cause other bugs elsewear which patches more often than not can't fix properly due to having to go back and rewrite the code.
You can get stuff to do what you want it to do but unless you know everything it does you could be facing more problems like if you got something which did a cool thing it could be doing something else on the server and lead to restarts needing to occure or something else.
It's doable for sure but you need something more than just the guy down the road who knows how to write code to pull it off at a successful level otherwise it's just basicly the source code and usually nothing more.
I find that if there is more than one version of an open source game out that it splits up the playerbase and there are some people out there who will grab a source code and try to run the whole thing themself. You can't go to the other game without starting over.
This isn't a signature, you just think it is.
As far as player created content it would not have a voxel based system with integrated tools. Content creation tools would be off the shelf tools that developers normally use. The player generated content is not absolutely critical to what we want to do.
The game is focused on large scale pvp combat in a sandbox with a fantasy theme. Eve online in a fantasy setting. That's basically it. We will be launching with the massive pvp part first, and the go back and add in economy and crafting. A big goal is to have something that's actually fun to play with other people from day one.
Overall I would say being innovative is not our goal. We want to create a fun game that doesn't make big mistakes, and do it in a short time period with as little money as possible.
That is your problem. You cannot make a MMO with enough content (even not innovative) on the cheap with no time spent. If you want to make a fun game with little time, and little money, do a iOS puzzle game, or something like that. MMO, or even a meaty RPG is not the way to go.
There are different classes of exploits that you need to worry about. I'm not claiming that this will create duping bugs, teleportation hacks, or some other such things. You can defend against those in the traditional ways, and open source doesn't hurt you there.
But there are purely client-side hacks possible in just about any real-time game. This isn't a case of Alice sending a message to Bob and trying to conceal it from Eve. Alice has to send a message to Bob's computer and conceal the message from Bob. Security by obscurity is the only thing possible there, and open-source makes that much, much harder to do.
Suppose, for example, that you want to have some line of sight considerations so that you're not aware that a character is there until you have a clear line of sight to see the character. If the server doesn't tell the client where the other character is until he's in line of sight, then the client has to further wait for Internet latency and then for the relevant assets to be loaded from storage before allowing the character to abruptly pop into existence. If the server informs the client a little ahead of time, then the client can have that information loaded and display the character as soon as it should.
This, of course, creates the possibility that a hacked client could read the message coming from the server and inform the player that there's a character around the corner before it should be visible. If the client is closed-source, you can encrypt the information, move it around, and generally make it a pain to find. In an online game, you can even change the encryption scheme, encoding, or location of the data every single patch to constantly break exploits. With an open-source client, you can't do that, a would-be hacker can read the source code to your security measures and work around them as fast as you can create them.
I think this is more a case of it being easier to use obfuscation, but needing to? I can see FPS games being more of an issue with this scenario then mmo's.
There are known ways to deal with the issues you laid out. You can have low poly default skins that load quickly and then load in the complete detailed skin over time. Or you can just use low poly skins to start with, like ESO does.
And with good optimization you can run network updates between 30ms - 60ms even with mass pvp. And that's generally good enough to deal with the issue you brought up in an mmo setting.
That said, there is nothing stopping you from adding obscurity on top of an open source, or not releasing some parts as open source. I think this is entirely practical in many cases. There are other good reasons to not release all of the code, like not wanting to expose specific algorithms you use for combat/crafting, etc.. And remember that the vast majority of a codebase is not really any different then any other piece of software used on the internet. There are only a limited number of cases where you have situations like the one you describe that might call for some type of obscurity.
My issue with obscurity, especially in the game industry, is that it has almost become the go to response for way too many cases. Some of the better studios with the most talented people get it right, but I see indie developers messing this up all the time. And very often real security suffers.
It's just a very dangerous tool to use. In the right hands there is nothing wrong with using it, but given to an amateur and they are more likely to just shoot themselves in the foot.
I think you're falling into the trap of thinking yourself superior to every other professional out there. Large companies who can spend millions of dollars to their engine have a lot of trouble with these things. Assuming that you don't need to take the shortcut of using obscurity because you can make better quality product than other professionals is a sure-fire way to fail.
With that said, I don't think hacks will be that large problem with open source. I believe bots will be much larger problem with open source.
OP, you should read this about the amount of effort it would take to make a serious mmorpg.
http://www.gamedev.net/blog/355/entry-2250155-why-you-shouldnt-be-making-an-mmo/
Epic Music: https://www.youtube.com/watch?v=vAigCvelkhQ&list=PLo9FRw1AkDuQLEz7Gvvaz3ideB2NpFtT1
https://archive.org/details/softwarelibrary_msdos?&sort=-downloads&page=1
Kyleran: "Now there's the real trick, learning to accept and enjoy a game for what it offers rather than pass on what might be a great playing experience because it lacks a few features you prefer."
John Henry Newman: "A man would do nothing if he waited until he could do it so well that no one could find fault."
FreddyNoNose: "A good game needs no defense; a bad game has no defense." "Easily digested content is just as easily forgotten."
LacedOpium: "So the question that begs to be asked is, if you are not interested in the game mechanics that define the MMORPG genre, then why are you playing an MMORPG?"
You haven't explicitly stated this, but you may be thinking of Kerckhoffs's principle or something like it. Basically, it asserts that the security of an encryption system shouldn't depend on knowing the system, but only on knowing the key. That's sensible when your adversary has no obvious way to get the key. But the client necessarily has to have the key in order to function, and if you're trying to keep things secret from the player--and from any bots he might want to run--he already has the key.
In this case, obscurity is the only thing available. You don't have to design and implement your own custom encryption system that is better than AES. But you do need to avoid any obvious shortcuts so that attacking your system is most easily done by taking apart the program binary to figure out how it works. That's a lot harder if you don't have the source code handed to you for free as part of an open source project.
Now, there are a lot of things that can and should be verified server-side. I'm not denying that. Security by obscurity should be a last resort, not a first choice; the problem is that sometimes the options are obscurity or nothing. But there are different categories of security problems where you want to keep information on the client hidden from the player, and server-side verification can't help with that.
It's entirely appropriate to discourage people from trying to jump from doing exercises in an introductory programming course to trying to create the next World of Warcraft. But what the original poster has in mind is probably a much smaller leap than that, and in both directions. If you've already been a professional programmer for some years and already worked some some big projects and then want to make an MMORPG, that's a much smaller jump than going straight from learning the basics of programming to making an MMORPG. And not all MMORPGs are on the same scale; if you don't need enormous amounts of stuff done by hand, you don't need hundreds of developers to do it.
That said, making an MMORPG is not a simple project. It's at minimum going to take several man-years of full-time labor from some very talented people, and probably push well into the tens of man-hours for even a small project. But even if 100 people work on an MMORPG over the course of six years before it launches, that doesn't mean it was 600 man-years of labor, as it would be extremely unusual for an MMORPG's staff to remain constant for its entire development cycle. Lots of artists are commonly added after a game is well into development, and other positions also commonly join late in a project. Some people also leave a studio to go elsewhere before the game is finished.
But there have been MMORPGs made successfully on a shoestring budget. A Tale in the Desert peaked at 4 paid developers. So did Vendetta Online. Your very link mentions Minions of Mirth in the comments, which started as a two-man project and expanded after the game was successful.