NetGore is a free, open source online RPG engine created in C#. The purpose of NetGore is to provide a base framework for creating your own multiplayer games as easily as possible while not imposing many limitations on what kind of game you can create. Even though it is designed for RPGs, there is nothing stopping you from using the engine to create a wide variety of other games such as a turn-based or real-time strategy, player-vs-player shooter, or even a "virtual life" style game.
NetGore is completely free, and always will be. Period. You will never, ever have to pay a single penny for access to or using the engine, even if you charge players to play your game. This should be all most people need to know. But if you really must know the details, read on.
The license for NetGore's code is something that won't concern most people. For the most part, the only restrictions you need to know about are:
The following dispels some common misconceptions about the licenses:
NetGore is designed for the indy developer, by indy developers. You won't be able to pump out something as powerful as a modern MMORPG, but no free engine is going to provide you with that kind of power. The following is a list of the restrictions in the NetGore engine:
Sorry all of you 3D fans or those inspiring to make the first awesome 1D MMORPG. The reason for using 2D was because it is often faster and much easier than 3D for a large variety of things, making it a far more reasonable choice for indy games. While you can still add 3D models into a 2D world, having a 3D world is something NetGore is never going to support. If you want 3D, there are many better commercial game engines out there that you can use (often for a large fee).
NetGore uses a UDP and TCP hybrid, while twitch-based games (such as fast-paced shooters) usually require a pure-UDP implementation and a different approach to pumping messages about the world state. But the engine will still work fine for faster-paced games that don't require such high-precision accuracy and low latency. In general, if you are not making a fast-paced shooter, you are good to go. If you are making a fast-paced shooter or other kind of game that requires a very low latency, you may have to rewrite the networking a bit. If you are unsure of whether your game is twitch-based or not, please ask in the forums.
The design of NetGore is simply just not built to support the "massive" aspect of MMOs. But again, this should be no problem for an indy developer. With a decent server machine, you should have no problem hosting at least a couple hundred players (depending on what kind of game you have) at once. This is plenty for most all indy games.
If/when a game created with NetGore becomes popular enough to need to support more players, then better scalability features will be added so you can support more players. But there is no use in spending time working on that until someone actually needs it.
Everything in NetGore is free and open source. There is no chance that, in the future, you will have to end up paying for any part of it. As long as the kind of game you want to create is well-supported by NetGore (see above), it is at least worth checking out. There are a few other multiplayer game engines out there written in C#, and quite a few in other languages, that are similar to NetGore. But as far as free options go, there are very few choices. Most all of the large multiple game engines are either commercial and come with a very hefty fee and are targeted towards a more professional development team instead of indy developers.
NetGore uses the typical client-server network architecture. As many people as you want can join in the same world just like any online multiplayer game you have played. You can chat, kill, throw items at each other, or whatever else you want to do.
All of NetGore is open source, so you can theoretically change any aspect of NetGore. Though ideally, you won't have to modify the base engine components at all while still having plenty of flexibility in what kind of game you create, how it functions, the features available, etc.
There are quite a lot of features in games that are quite specific, which makes it a bit tough when trying to create a "one-size-fits-all" engine. Though we do our best at providing a base implementation of many features that you can either use as they come, or modify them in a derived class to alter the behavior. If the base implementation is nothing near what you want, many parts of the engine pass around interfaces so you can implement what you want from scratch without having to touch the base engine.
All of the basic components of a game are implemented for you. This includes, but is not limited to: stats, skills, items, inventory, equipment, GUI system, fighting, chatting, NPC chatting, shops, and leveling. As time goes on, we will add native support for more obscure features like, say, the ability to craft items, elemental attributes for characters and items, etc. For these features to make it into the base engine, they have to be able to be implemented in a way that does not impact those who do not want to use it, so you never have to worry about "feature bloat". But just because it isn't in the base engine, that doesn't mean you can't add it to your own game. Some features may even be added as "extensions" to the engine so you can easily add it to your own game without the engine itself becoming bloated.
There is a lot of stuff in NetGore related to automatically generating "stuff" and making manually creating "stuff" as simple as possible. This will make more sense as you start to use NetGore. Though one example is the DynamicEntity, which is any entity (a physical "thing" that resides in the world) that is synchronized between the server and all clients. The most popular dynamic entities are users, NPCs, and items on the map. Normally, creating a new entity would require writing quite a bit of code to synchronize the clients when any of the values change. However, with NetGore, you all it takes is placing the [SyncValue] attribute on a property of a class that is derived from DynamicEntity, and that property will automatically synchronize when it changes on the server. In fact, this is how most of the synchronization is actually done between the client and server. Best of all, it even works when serializing an entity to/from file, allowing you to save and load entities to/from maps without any additional code!
Another example of how NetGore eases development is the NetGore.Db.ClassCreator project. This tool allows you to specify a database, and it will automatically generate the corresponding classes for performing I/O for each database table and view. This gives you strongly-typed access to the database, along with support for accessing data in a variety of other ways.
Definitely not! There is always improvements that can be made to NetGore. New features can be always be added and existing features can always be improved, so development is something that will never end. But even if you are waiting for certain features, you can still develop your game's content without it, and creating content will be one of the most time-consuming aspects of making your game.
You can also still familiarize yourself with other parts of the engine in the meanwhile so, when the time comes, you can spend it developing instead of learning. You can also contribute to the development of components by suggestion improvements and changes. If you really want to move things along, you can even help out by contributing with the actual programming of features. So please don't just sit around and wait for others to do all the work for you.
In reality, you don't know. But NetGore has made it this far, and it won't just stop so easily. Spodi, the creator of NetGore, has spent over two years working on this engine and is in it for the end. Most everyone developing for NetGore is doing so because they have plans of using it for their own games in the future. So you should feel safe in assuming that, at worse, development will only slow down but it will not stop for a good long while.
If the worst comes to, and for some ridiculous reason NetGore actually completely stops with development prematurely, all you are missing out on is people writing the code for you. Since it is open source and you have access to everything, you can still do whatever you please.
But again, we're in this for the long run, and it will take a lot to halt NetGore's development. Heck, just look at our SVN commit log! ;)
Keep in mind that NetGore is a free engine, created by volunteers on their free time. We do not get paid to make this engine, so its not like we can contribute all day of every day towards developing it. So it is hard for any of the developers justifying spending months developing tools to simplify some tasks that they may only spend a week or two actually adding with the existing tools. Commercial engines can justify this since they are competing with other commercial engines, their programmers are getting paid (a lot) for their time, and they charge a hefty fee for using their engine.
In short, improvements will be made to certain things by developers when they deem it necessary so people can build their game more easily. But don't ever expect this to be some magical MMO version of RPG Maker. If you want an engine like that, I believe there are a few out there that only cost a few hundred thousand dollars.
If you are noticing poor performance, it is most likely due to running the engine in Debug mode - which is a good thing! When the DEBUG symbol is defined, many parts of the engine will perform anywhere from quick value comparisons to exhaustive collection scans to ensure that everything is in a good state. The purpose of these checks are to catch issues when they happen, not just when they cause some problem. This makes debugging significantly easier for everyone.
These checks are performed using three common methods built into C#: 1) "Debug.Assert()" calls, 2) "#if DEBUG" directives, and 3) "[Conditional("DEBUG")]" attributes. All three of these will result in code that is generated only when DEBUG is defined. When you build your code for release, these checks will all be omitted from the final binary.
There are some places where NetGore is legitimately slow. It happens to every program. However, we don't know about them. So if you find stuff that takes too long, please let us know and we will see if we can do anything about it.