Posted on

Building an Indie-MMO (2/2)

More Information about how to build an Indie MMO can be found at our friends website: Indie MMO

4. Don’t twist and turn the asset (beyond its original use)
Im now with uMMORPG for almost a year and met a lot of new and interesting people on the forums, as well as the official uMMORPG discord server. Every now and then I come across somebody who wants to use the asset in a way it was not intended by the original author. For example by adding dynamic,  destructible terrain, custom playerworlds, realtime action combat system, level- and classless systems and so on. Basically, all of these changes are possible if you have the proper skills, time and resources at hand. But those changes are also major modifications that make the asset do something it was not designed for. This is also referred to as a total conversion and is a daunting task, especially if you are lacking high grade coding skills.

I strongly disadvise such an undertaking unless you are 100% dedicated, willing and competent enough to do so. Your plan might start well, but after a while you will run into serious issues as well as the impossibility of receiving official updates, the usage of AddOns and a whole lot of maintenance and compatability problems. Just imagine the amount of content you can create using the time spent on a total conversion in a different way.

If you want to actually finish a game using uMMORPG, stick to what you get and expand the core asset via AddOns (your own, free ones and maybe a few commercial ones). But keep the core aspects like movement, targeting, combat, the world itself, class and level system – as they are. If you plan to re-design any one of these sensitive areas – you might be better writing your own asset from scratch instead.


Warcraft 3 Digimon Total Conversion

5. Don’t get AddOn greedy (use a few selected ones instead)
Another lesson I learned in almost one year of uMMORPG projects, tests and writing AddOns: Some people out there are not satisfied with the number of features the core asset ships with. Of course I agree with that fact, but I also understand that the author is not able to provide each and every feature the community wants to see. Vis (the author of uMMORPG) is in fact adding features to the asset in regular intervals, and a sprawling scene of AddOn developers emerged as well, trying to fill the gaps and expand uMMORPG wherever possible.

This particular situation: “We don’t have every feature we want yet, but we might get that in the near/mid/far future” has lead to a form of AddOn greed that took toll on several developers out there. AddOn greed on the one hand makes you scavenge the web for all kinds of AddOns to put into your project. Trying to get as close as possible to the “next WoW killer” in terms of feature quantity. On the other hand, it causes a stalemate to project development because you go into a “I can’t continue to develop my project unless feature X becomes available” endless loop. By playing the famous MMOs out there (look – so shiny!), some Dev’s become even more AddOn greedy and completely cancel out their own development cycle. Waiting for better days instead of advancing the development of their projects.

My advice: Don’t get AddOn greedy, as you will never ever gonna catch them all. And there will always be new stuff on the market. There won’t be that “golden 1.0 version” you are waiting for. Limit yourself to a few selected AddOns and maybe one unique feature. AddOn greed will put your project into eternal stalemate. Development is the exact opposite of standstill. It means you have to take the destiny of your project in your own hands in a pro-active way.

Comic by http://themeatly.com

6. Don’t think of “development” as a simple asset flip (understand what dev means)
Another thing I’ve encountered several times over the course of the last months is that many people think that game development using Unity 3d is just a simple asset flip. But exactly the opposite is the case – the more assets and technology you have at your hands, the more complex development becomes as all parts must work together in harmony. Just think of every asset as an instrument in an orchestra, your job as a developer is to conduct them to work together in terms of rhythm, harmony, length, volume and pitch.

Amost every day, I encounter people who saw just another asset on the store and want to combine that said asset with uMMORPG. Multiply this by the number of subsystems found inside the uMMORPG asset like inventory, combat, ingame shops, npc dialogues, networking, character progression, enemies and so on and you get a massive list of assets that seem to fit your needs at first.

But you should be aware, that all of those assets are standalone and where not designed to be used as part of the uMMORPG asset or a networking environment. This means, all assets require professional coding to integrate them into your uMMORPG version. Now each and every asset was written by an individual, with individual goals and a individual coding style.

If you go that route, your job as a developer will be far more than just a simple “asset flip”. You have to understand (that means “learn”) each asset as well as the uMMORPG assets code in order to bring the loose ends together. As 99% of those assets are not plug-and-play-able in the unique “MMO client/server networking environment that uMMORPG is” – you will need a solid skill set and a couple of hours per asset to make that work with uMMORPG.

In theory, it sounds so cool to simply dump the “Third Person Controller” into your uMMORPG3d project and have immediate access to all of its features with 0 coding involved. In practice it’s more like opening the gates of hell (alongside a 75$ waste)…

 

Posted on

Building an Indie-MMO (1/2)

More Information about how to build an Indie MMO can be found at our friends website: Indie MMO

Introduction
Time for some myth busting – in this new blog series I would like to share some personal thoughts on the process of creating an Indie MMO using Unity and the uMMORPG asset. It’s all about realistic game design and how to manage such a project – things you should do and things that you should better not touch (not even with a stick). Please note that the following pages represent my personal thoughts and are in no way representative for all opinions out there. Also note that I write exclusively about creating indie games using Unity and the famous uMMORPG asset (but I am not the author of uMMORPG).

Summary: The purpose for this blog series is to give advice to game designers who are set for one single thing: To create and finish a game using Unity within a reasonable amount of time, using a reasonable amount of resources and still generate a reasonable amount of joy/revenue.

Thanks for reading and enjoy!

SamuTale Unity based Indie MMO (Unity Client + Custom Backend)

1. Do Not…switch to MySQL (if you are not a programmer)
uMMORPG was built with simplicity in mind and therefore uses SQLite as it’s database system. SQLite is a subset of MySQL with reduced complexity and stripped down features. It also has several advantages as it does not require you to setup a database server and can therefore be run locally and on a dedicated server without further configuration. The uMMORPG core scripts and all of our AddOns where built around SQLite, if you want to switch to mySQL now, that means replacing each and every database script in your project. Now imagine you add a new AddOn (that will most probably also be based on top of SQLite): You have to replace that script syntax with a proper mySQL syntax as well. This goes on and on for every AddOn you add and everytime the core uMMORPG version is updated.

Of course you can still do that, especially if you know how to program both in C# and mySQL. But if you can’t – I highly recommend you get a programmer on board of your team or pay a freelancer. Otherwise just keep your hands off. SQLite is not bad at all. The only problem are networked databases and multiple databases. But do you really need that? Do you have one server up and running – and how about three? Do you? Do your game and your community allow for such a complex setup already? Furthermore imagine all the content and features you can get done in the amount of time that is required to switch uMMORPG over mySQL.

Finally, there are several Indie MMOs out there that rely on SQLite for years – and they are still alive and kicking! Just do a quick google search or check out Wurm Online for example.

Wurm Online (SQLite)

2. Do Not…aim for MMO (aim for MO instead)
Unity (and especially UNET) was in fact not built for massive multiplayer games. There is not a single MMO out there that utilizes Unity as it’s server backend. Of course there are several Unity MMOs on the market (not just Indies – check out Crowfall for example) but they all use a highly sophisticated and very powerful server backend written either inhouse from scratch in C++ or C# or using professional 3rd party software. What Unity is used for in terms of MMOs is the client. And just the client (Summoners War is another example). There might be exceptions, but thats what I observed in the past years.

Im not saying that a MMO is not possible, just ditch that “massive”. In my eyes, any Indie game will always have to struggle for players and you will have a hard time attracting thousands of online players to your game. If you do your job right, you will be able to have hundreds of players online. Thats not MMO, thats MO – and thats absolutely perfect both in terms of revenue and technical limitations.

Just imagine how much marketing power is required in order to attract 10.000 players – and how many servers and people who manage those servers must be paid (or be very dedicated to your project). It’s a nice dream but nothing realistic. Instead you should aim for a small but tightly knit community and good content. Content that offers your players areas to explore, quests to complete, monsters to fight and items to acquire. And all that represented in a appealing and polished way, with a special care to the details. You won’t be able to populate a world with content, that is capable of satisfying 10.000 players – but if you work hard, you will be able to create a world with enough content to keep 1k players around.

Project Gorgon (Indie MMO)

3. Do Not…alter the core beyond recognition (use AddOns instead)
I tell you the story of my very first uMMORPG project: After getting used to Vis coding style and a bit of knowledge about the asset, my first thought was: This is lacking so many features – I have to add as many of them as I can! Said and done, new features where tacked on and stuffed into the core asset. A few days later, Vis released the first update on the store that contained only minor changes. I was able to update by hand and did setup a GIT repo for the future. Several tiny updates followed that where all easily manageable, but the process got slower and more tedious each time. This made me skip one update or another, leaving a gap in my personal series of uMMORPG version numbers.

After a while I wanted to start a side-project based on the same uMMORPG asset and realized that I cannot move my features from one project to another. Then – all of a sudden – Vis released a new AddOn that allowed parties. This rendered my own party code obsolete and I had a hard time A. removing the old code and B. updating to Vis new code. A period of smaller changes followed that I spent stuffing even more features into my Frankenstein core, updating turned more and more into a chore. I was so happy when everything worked that I skipped a few of Vis official versions. You should know, that when you do – catching up to the newest available version becomes even more difficult. My little frankenstein engine was only missing a proper pet script now, the code was all spaghetti like but it worked. And then Vis released the Pets update. And I jumped around, screaming and pulling my hair out!

My advice: It’s OK if you want to modify the uMMORPG core system, we all want to add our own features and make the asset unique. But do by using the AddOn system. Because that is was the AddOn system was made for. That system also allows you to sell your AddOns, but thats not it’s primary use. The AddOn system enables you to add more or less extensive modifications to the uMMORPG core system (using partial classes and hooks) while the core scripts remain intact. This means you can update your uMMORPG asset, you can import/export AddOns, you can move them to other projects and share them with your team members. The AddOn system will make your life easier and your project much more manageable. Think about it!