Selecting a Game Engine
Before you can select your game engine you need to make a few choices. Who is my target audience? Is it PC, PS3, iPhones or anyone with a webbrowser? Then you will need to start looking for technology that you can use to develop for that platform. This may give you a number of different solutions to choose from, after which you then pick one that best suits your needs based on your skill set and requirements.
The game platform(s)
Before looking for the game engine you need to decide what platform (or platforms) you are going to be targeting and how you would like to deliver the MMO to your user. Firstly lets look at a few delivery mechanisms.
Browser based
You could create your game so that it runs within a browser. This usually has the benefit of being easier to install and allowing the user to access the game from multiple machines. I say "usually" because depending on your engine the user may still have to install some component on their system, that could be Flash, Silverlight, ActiveX controls or some other such thing. And depending on the users browser and security permissions it may be difficult for the user to do.
Flash/Silverlight
Most machines these days trust Flash and have it installed. So for a safe bet you could develop your game so that it can be played in flash. However Silverlight is gaining momentum and I personally prefer Silverlight over Flash because (1) its free to develop for and (2) I already have C# development experience so I don't have to learn Action Script (and I personally know a lot more developers who also know .Net languages which can also be used to develop in Silverlight).
Even though reskilling yourself is good, its also very good to see if you can take advantage of your existing skillset as well (hence my Silverlight over Flash decision).
Even though reskilling yourself is good, its also very good to see if you can take advantage of your existing skillset as well (hence my Silverlight over Flash decision).
For those interested you can develop Silverlight applications by downloading the Visual Web Developer 2008 Express Edition.
Since I am not a flash user I can not say what is possible for flash. But for Silverlight you can get access to some storage on the users computer to store extra files and information as a kind of caching if you feel the need. It is called "Isolated Storage". Flash most likely offers a similar system as well.
Both Silverlight and Flash web apps now also have the ability to let the user run them directly from the users computer without being in a webpage. They also allow you to let the work offline, although for an MMO this is somewhat limited uses. But this does allow for some more flexibility to how you deploy your application.
Now some of you may be wondering why I am bring up Flash and Silverlight at all in this discussion. One reason is that you may very well decide to forgo the entire 3D route and stick to a nice tiled based 2D engine. But the main reason is that you might like to offer some kind of interactive experience on your website and doing this with Flash or Silverlight communicating to your Game server could offer some interesting ideas (a real time map of where everyone is in the world, running statistics).
ActiveX/Other
Some engines these days offer Web based players (Unity, Esperient, Virtools). These allow you to use the engine with all its 3D abilities running it from within the users Web browser. In reality the application is installed on the users computer and simply runs in a window within the Web browser. They have varying abilities and usually sandbox the software so that the engine can not access the users files direction via the engines API.
You must also check which platform the web player supports. For example some may only support Internet Explorer under windows, if your target audience is Mac users or even Firefox users then you are out of luck. One product that has good support for multiple platforms and browsers is Unity3D.
AJAX
Just to throw in one other way. You could even write your entire MMO in javascript and do asychronous calls to your game server (AJAX). Just do a google search for AJAX MMO, you might be surprised what you find.
3D in a Browser
There are already a few products out on the market today that let you publish 3D games directly to the webbrowser. These will run directly in the browser by using technology such as ActiveX controls. Here are a few companies that currently offer this kind of technology...
Remember also that 3D in the web browser is just around the corner with HTML5 and WebGL.
And with the ability of projects such as Project Darkstar offering a Javascript based client to communicate with a Project Darkstar Server we could see more 3D based MMO games being delivered straight into your browser using 3D graphics.
Mobile devices (iPhone, iPodTouch, Android, Cell Phones, Zune).
There may also be a future in using Mobile phones to play MMO games (well maybe just an MO since it might not be able to scale to something Massive on a phone just yet). It is certainly possible to use RakNet (a game networking engine) with an iPhone and a custom back end server to create an MMO. You could also look at what Google are doing with the Android platform. You can make games for Zune using XNA Studio by microsoft so why not an MO?
To further investigate the iPhone path I can suggest taking a look at sio2 interactive, its an open source 3D game engine for iPhone and iPodTouch. Perhaps you could hook this up with RakNet or Project Darkstar to make a 3D MMO. If you have some money you could also just use something like Unity3D and publish to the iPhone ( as well as other platforms). You could also use Photon and Neutron to have a complete networking solution developing with iPhone, Android, Unity, Win32, .NET, J2ME, BREW and Flash.
Consoles
If your dream is to make an MMO that runs on Playstation 3, XBox360 or the Wii then there are also a few good commercial Game Engines that you could use to start up your company. And here I say "start up your company" because unfortunately if you are going to make a game for these platforms then you will need to be a set up commercial company with a solid game idea that you can pitch to some executives at a Game Publishing house (or try going direct to Microsoft, Sony or Nintendo if you are able to), with the exception of indie games for Xbox360 made with XNA studio (more on this later).
And then of course you can always build your own Game Engine for these consoles as well (more about this later).
Xbox360 XNA Studio
Now there is one exception to this rule and that is the Xbox360. Microsoft released the XNA Game Studio that you can use to develop games that get published directly to the Xbox360 and you can share them with the Xbox360 community in the Xbox Live Arcade. Note that with XNA you can also publish to the Zune and PC so its not a bad platform for beginning programmers (and you get to develop using C# which is a really nice language).
PC/Mac/Linux based game engines.
There are a lot of game engines out on the market today, both Open Source and Commercial. For a list of engines check out the Game Engine section in the links page.
Build your own using Middleware
Now you could write your own 3D engine, physics engine, scripting engine... engine engine engine... In my opinion, don't waste your time (unless you are extremely passionate about learning the finer details), but seriously, don't do it!
OR you could use Middleware (free or commercial). This is the approach I am taking.
Note: An excellent resource to find an engine that suits your needs, go to http://www.devmaster.net/engines/ click on Advanced Search and select what you require.
The Game Engine
For the game engine I have decided to not use any of the available game engines on the market. Instead I am going to select individual middleware and put together my own game engine.
Why did I make this decision?
Cost
By basing the engine on free middleware it not only saves me money but will also save you, the reader, money as well.
Bloat
The current game engines can do alot! Sometimes they do so much that it can be overwhelming to use. By using smaller parts it will keep the overall design of the game and the game engine alot simpler.
Portability
By selecting code that is cross platform it allows us the opportunity to develop a fully cross platform game.
Swappability
Each part of the game engine can be swapped out for a different part if required. Different sound system? Different physics? Different Rendering engine? Scripting?
Source Code
You can upgrade any of the middleware components yourself if you need to since you will have the source code.
Learning
Since this article is about how to develop an MMO I am going to show you what middleware you can choose and how to integrate it into your own game engine.
Artist and Designer Friendly
Finally I want the engine to be very easy to use by Artists and Designers. It should be very simple to create new graphics and get them into the game. Because of this I am going to write all the tools so that they work within Cinema4D. Artists can design levels, create creatures, do animations and visualize that in the game with the click of a button. This is the only part of the engine pipeline that actually costs money, but if you are going to make a game and need to create content then you should have at least one content creation application at your disposal. Most, if not all, of the game engines on the market today do not have good modeling and animation toolsets. And why should they? They don't have to, they are a game engine not a modeling application.
How to make your own Game Engine using Middleware
This section will focus on what a game engine actually is and what parts are required to make a game engine. One thing to keep in mind when searching for all these engines is to think about cross-platform ability, if you wish your game to be cross platform that is. If your perfectly happy to just release for windows machines then who I am to judge.
What is required in a game engine?
3D graphics engine
The 3D graphics engine would be built on something such as OpenGL, DirectX or some custom software renderer. It would be able to load in a scene file with geometry, textures and animations and display these to the screen. It will also have good scene management, animation abilities, cameras and lights. If you want to make your graphics look as shiny and realistic as possible then you may also decide to use hardware shaders in your engine. You might even look into using normal maps and displacement maps to give a higher quality look to some low poly models. I am not going to go into a lot of detail here, there is simply too many things that could be discussed regarding 3d graphics engines. However I will go over this in a lot more detail in later articles.
One thing to consider when choosing a graphics engine is your own level of programming ability. So far the most easiest graphics engine I have come across today is the Irrlicht graphics engine. Other engines may have a lot more features, but the added complexity of the code makes them hard to learn for beginners. A few other engines which are free to use for commercial products are Ogre3D, Crystal Space and Wild Magic. Wild Magic is interesting because you can buy the book, by David H. Eberly, that explains the entire engine and its design.
Another thing to consider when making your MMO is how much effort do you want to put into the graphics. If you are thinking of something along the lines of World of Warcraft then Irrlicht may be fine for your needs. But if you want to make something that has the graphics like that of the new MMO Aion, made using CryEngine that was used on Crysis, then you might have to look for a more commercial graphics engine. But what I will say is that if you are serious about making an MMO, and you are a team of one to none, then just choose a simple graphics engine and concentrate on everything else, trust me you are going to have more than enough work to do without having to worry about getting some lens flare looking pretty when viewed near a normal mapped, high poly creature doing back flips with flaming god like particles flying out of its ear holes. Sticking to a simple graphics engine that is understandable and easy to work with is a good place to start. And I should point out that Irrlicht is more than adequate for your gaming needs.
Animation System
Now even though I mentioned above that the graphics engine can load in and display your animations you may still want to have a dedicated animation system. This system would blend between different animations and maybe also blend keyframe animations in with physics driven simulations. One common example is the mixing of Physics ragdoll simulations with imported motion capture data. You might have a few actions that were captured in a motion capture suit, then sampled down to a reasonable amount of keyframes. These are then imported into your animation system. There could be a run cycle, walk cycle, firing a gun, getting shot etc... Perhaps when your character gets shot the physics system initially takes over the animation of the character flying away then as he is nearing the ground an animation that moves the character into a landing position is slowly blended in with the physics simulation to make the character appear like the has landed on his hands and knees, followed by a standing animation and then back to running at the opponent to kick there ass.
This kind of system could be done with some kind of state machine to move between the animations and also simple linear interpolation between what the physics engine is giving you and what your keyframes should be at a given time. But in saying all this you don't need to have such a system if you don't want to. You could just as easily getting away with straight switching of animations, which is what it looks like in a lot of games anyway, the player runs, then stops straight away, no slowing down from a run to walk to stopping. But does it really matter? No not really. The game play is still good, it just looks a little strange. Not as strange however as players popping into different locations when walking around due to some server communication delay, but still a little strange.
Some systems that you could use to get this kind of system running are Havok Animation and software by Natural Motion
Physics Engine
Now we move onto the Physics Engine. Again, same decision as the animation system, is it really required. And my answer to that is.... maybe. Its up to you. For an MMO I would not expect to create the same physical simulations on all players machines. Instead I would let each animation system do its own thing on each client and the things that are controlled by physics would just be for effects purposes, ie exploding things with debris flying around or a large stack of boxes falling to the ground only to disappear from the scene 10 seconds later. The reason for not keeping all clients in sync with all the physics objects is because it is too much networking overhead. Sending the locations of every physics object in the world to every client just seems like a lot of work that's not really required. One other possibility is to have a dedicated server doing all the physics calculations and sending the data to every client, but again its a lot of work for not much gain.
Instead what I would do is have every client use their CPU and GPU to full potential and let things explode, fly around and bounce and blob all over the screen for pure graphics thrills. I would not send any data about any of these physics objects the server, or any client (if your doing a P2P game). This gives you more freedom to make fancy stuff and not care about game objects in the scene.
As far as getting a physics engine goes you could write your own. There are a lot of resources on the internet and writing one can be a lot of fun. But since you want to make a game and not play around with some pretty hard maths and optimizations its best to use one of the excellent libraries that are already out there. The most notable are Havok, PhysX, Bullet, ODE and Newton Dynamics. I will add more to the links pages as I find them (and think they are any good).
PhysX was initially a company making physics cards what would sit in your computer along with your graphics card and provide a hardware boost to your physics. This didn't take off and eventually NVidia bought them out, not for the hardware, but for the SDK they had. It has since been optimized for their GPU's and now if you use the PhysX engine in your games and happen to be running a game on a computer using something higher than an NVidia 8800 GT then you should see some speed improvements. It is free to use.
Havok is now owned by Intel and they have made it free to use for windows based game developers. You can download a binary only distribution and get started straight away. It comes with excellent integration with 3D applications such as Maya, Max and XSI. If you decide to sell your game for more that $10 you will have to get a distribution license from Havok, but I think this may be free as well. If you want to use it for any other purpose, such as PS3 or Xbox360, then you will have to purchase the full license.
Bullet is an open source, cross platform, physics engine that is free to use. You can also get all the code and add to it if you wish. It has a large community following and is gaining increased momentum as the physics engine of choice for a lot of projects. It is third in popularity according to a recent survey by the game developer magazine.
ODE and Newton Dynamics are two other open source physics engines. It has been reported that ODE has some problems with simulation stability in some cases. The Newton Dynamics engine is also a very popular physics engine and has been used in some simulation based projects as well as products like Esperient Creator.
Scripting engine
A scripting engine is good for writing your game logic in. The reason for its goodness is because you do not have to recompile one line of code, you could even set up your engine so that you could edit the scripts in game while its running. This frees the game designer from having to worry about visual C++, compiling code and other nasty stuff when all they really want to do is get into the game and tweak some of game logic for getting that last level playing super sweet. There are a number of languages you could choose as your scripting language, each has their own pros and cons which I will not go into here. Here is a list of some commonly used scripting languages in games....
And once you have chosen your scripting language you will need an editor. You could just use notepad of course (or EditPlus or your favourite text editor of choice). Or you could add an IDE to your engine by using something like Scintilla, which has nice syntax highlighting features.
One thing to mention here is that most of the game logic scripts are actually run server side and not client side. But even so there is a lot of things that can be achieved by using a scripting engine on the client side as well. And either way you will need to make a decision on the scripting language and how and where you are going to edit them anyway.
For this project I will be using C# via embedded Mono.
Networking engine
You need to be able to talk to your game server and send things like player locations, health information and 30 million creatures just spawned and attacked you at the same time information. To do this you will need some sort of way of sending and receiving this information from the server. You could go the hard (or not so hard for some people) way and write your own using sockets and TCP/IP. Or you could decide to use one of the free or commercial packages out there to do all the underlying hard stuff for you. I personally would rather spend as much time making the game than investigating some packets to see why the right information is not in them.
One good, and free until you earn a lot of money, engine is RakNet. This is a cross platform C++ game networking engine. But in addition to its ability to handle all game object replication and easy serialization and construction of game objects it also has a lot of other neat things that are ideal for making online games. These being a Lobby system, voice communication, RPC (Remote procedure calls) and a patching system to download the latest data to the client machines to keep them in sync, very nice. So you could in effect use this one system to handle all the communication to the server for your games and allow voice communication via P2P for players to communicate to each other.
If you were a flash developer you could use something like SmartFoxServer. Its not just for flash however, you can also use it with Java, .Net and iPhones etc...
Perhaps you would like to code your game in Java. If this is the case then take a look at Project Darkstar. This is a fully capable back end server with client code for both Java and C++. You will still need to serialize the data yourself but the main communication mechanism is all in place and the server has full persistence of all game object data. This means that it handles all the saving and loading of data for your world to the database for you so you don't have to worry about it. You can just write your server side game logic and get your game going.
There is also a commercial Networking engine called NetDog. I do not know what projects it has been used on or its reputation, but it may be worth a look. It is a commercial engine however and they do not disclose how much it costs.
And finally one other system is Photon. Photon is interesting since it can be used in conjunction with Neutron to give a full MMO networking solution including the backend server and game logic scripting using C# and has SDKs for iPhone, Android, Unity, Win32, .NET, J2ME, BREW and Flash.
Sound engine
Your game will want to have sound. Its a must really. Without sound its really only half a game. You will need to be able to load in sounds, change their basic characteristics, such as pitch, speed and tone. Maybe add some effects over the top to distort or add reverb to the sounds ( or you could just have loads preprocessed sound files of each type you require). You will also need to be able to change the volume of the sounds and mix them together, perhaps pan around for stereo sound, maybe even go for 5.1 surround sound. If you are going to use the Irrlicht graphics engine then you might consider using the Irrklang audio library since it works in with Irrlicht quite well.
Another well known sound library is OpenAL. Where as Irrklang can cost anywhere from 0 Euro for non-commercial to 1950 Euro for a full commercial product, OpenAL is free.
OpenAL will be used for this project due to its cost.
AI Engine
If your game has non player characters (npc's) running around then you might also want to have an AI Engine to control them. Bearing in mind that the main control for AI characters will most likely be done server side you might still want to have some purely client based characters running around in the game. One such system for path finding is Havok AI. Another, which is still being worked on, is IrrAI.
Resource Management, Memory management, file loading and streaming
This is not really an engine but just something that you will need if you make an MMO. You will need to be able to stream in data from hardrive while the game is playing and update your graphics, sound, animations etc... on the fly. You will also have to dump unused memory as you go along as well. This is particularly required for textures and geometry as you move through a large open world. You will need to pre load in various parts of the world in case the user is going to go that direction in the game. If you keep your graphics and textures simple then you will have to do this less often, something to keep in mind.
Editors
To make your game you will need to be able to layout the levels, add sounds, setup characters with the right textures, animations, statistics etc... for all this you will need one or more more editors. This section will go over some of the mainly used editors that you will require to make your games.
What kind of editors will you need
Level Editor
The level editor is how you create your game worlds. It lets you load in geometry and place it in the world. This is where you lay down the terrain, add trees, rocks and buildings. Tell a building it has a certain amount of hit points before it will fall apart after been hit by multiple rockets. You setup sound in your scene, where the sound direction is coming from and how large of an area the sound can be heard in. You need to be able to add Trigger locations, usually in the form of a large wireframe sphere or cube, to the scene to trigger scripts, effects or sounds when a user comes in contact with the trigger. Here you will setup the lighting of the game, perhaps some simple geometry for navmeshes (Navigation geometry used by the AI system to determine where AI characters can walk) as well as physics settings to mark things as solid or movable. You will also place monsters, traps, treasures in your levels and many other things. The list can go on and on.
Your levels will most likely be broken up in to square zones in your world. Each zone will be streamed in and out of the game engine as the players walk around the world. The Level editor will need to be able to save all its data and export out all the settings in a file format that the game engine can use, most likely in the form of an XML file.
Unless you get a system that contains a level editor already in it, such as the CryEngine3 Sandbox Editor, you are going to have to build one yourself. However another option is to incorporate all your tools into an existing system such as Cinema4D, more on this later.
Sound Editor
The sound editor needs to be to load in sounds in various file formats, adjust and tweak the sound, make sounds loopable, remove static noise etc... basically any sound editor out there on the market today will do the job. You do not need to write your own sound editor. If the sound editor you have chosen doesn't output to the required file type for your sound engine in your game engine then you may have to use a separate converter to do the job. This is usually not a problem since it will be handled by your asset pipeline, ie you check in the WAV file to the Digital Asset Management system and the asset pipeline system automatically converts it to an OGG file and saves that back into the Digital Asset Management system to be used by the game when it runs.
Animation Editor
Unless you have a game engine that already has such a system you are going to have to write one of these yourself. You can write it onto of your graphics engine, but remember to keep it as separate as possible. This system is mainly going to be used to setup characters with animations and setup the finite state machine to tell it how to blend between the different animations for that character. As an example you might load in a mesh for a character. Then select a few different run and walk cycles for the character and tell the game how it would blend between them using some non linear animation system. You can then preview how the animation looks on the character.
You might even give this system the ability to tweak the animations a bit my modifying the keyframes. But this is not really recommended since you will then have to remember this modifications and try to apply them each time you modify the original animation data in Maya, Max or Cinema4D.
Character Editor
This could very well be integrated with the Animation Editor itself. The Character Editor would be where you setup a full character. You select the mesh, maybe change some textures, tell it what abilities it has, what weapons it can carry, what its initial health points are, allowed spells etc... anything you can think of that might be useful for setting up on this character should be able to be done in the Character Editor. This could also include the animations, as described previously. Now this is not to say that this data is the final definite data for the game. The scripting system when the game is running could of course alter any of these values.
Particle Effects Editor
An editor to create particle effects like fire, smoke, explosions, waterfalls, rain and lots lots more. This again is something that you will have to write yourself and is very specific to the graphics engine that you have chosen to use.
Facial Animation Editor
A lot of games these days have in-depth stories and complex character dialog. If you want to have any of this stuff then you could look into creating a facial animation editor. I will not go into this in too much detail other than to point out a few sites like lifemode, Image-Metrics and Quidam.
Content Creation
Needless to say really but you will need a content creation package such as Maya, Max, XSI, Cinema4D, Modo, Blender or one of the many other products. Each are good.
For my project I will be using Cinema4D.
AI Editor
Perhaps your game will have crowd simulations, a vehicle traffic system, bird flying around in some flocking behaviour or maybe each of your characters has their own brain and you need an editor to setup how everything works... if this is the case then you may need some kind of AI Editor.
Other Editors
There are many other types of editors depending on the type of game you are making. For example vehicle editors and tree editors to name just two. Take a look at an engine like CryEngine3 or UnrealTechnology. The number of things you can do with their technology is astounding.
All in one editor
Perhaps you might want to create an all in one editor, something like Crytek's sandbox editor or the Unreal Editor. This could even be based on your actual game engine and provide a play mechanism within the editor, ie WYSIWYP (What you see is what you play) functionality. This is a nice idea and can easily be designed for. But one thing to avoid is just jumping straight into the game engine and adding all this functionality. It is still best to think about all these as just components that can be used independently. By doing so you get a clear separation between the different parts of your system. This is useful to stop any kind of spaghetti hacking code from making your system unusable.
You could create an editor so that is has each of these "sub-editors" as plugins. Each of the sub-editors would work with their own data and file formats, but could be accessed via a unified UI. These editors could use the game engine to preview the changes, but make sure not to make the game engine rely on any code from the editors, with the exception of perhaps the loading code. An editor does not have to actually do anything other than allow the user to "edit" the data. An editor could be something as simple as Notepad describing an XML file.
Building your own editors
Eventually you will have to build an editor. As I said previously an editor could be something as simple as a text editor or editing an XML document, or it could be a fully integrated 3D level editing and all in one monster super cool application. Whatever the case may be you will need to learn a few things before you can create your level editor. Firstly lets think about what platform your editor is going to be on?
Editor Platform
For a moment here I am going to expand upon a few things a bit further than 3D games. Lets think about ways we could write editors for our games and where they might be used.
Editor in a web browser
If your game is going to be silverlight of flash based then perhaps you might want to open up the opportunity for the community to create content for your games (make levels etc... ) by using some online editor. It certainly is possible to create a level editor in Flash/Silverlight, have that publish content to a back end database and get real time updates in a game running on the web. Just something to think about.
Editor within the game (Little Big Planet)
Perhaps you have heard of, or played, Little Big Planet for PS3. All the levels were created on the PS3 itself, and they have also allowed the community to create their own levels and share them with the world. This is a very interesting concept and something that perhaps you may want to allow for yourself in your game engine. This doesn't have to be restricted to PS3 however, you could do this on any platform if you wish. Going back to the idea of a flash/silverlight based game, the game itself could very easily be made into a level editor if that's the kind of interaction that you wanted to provide your users. The thing to note about this concept however is that if you are to do this, then ONLY do this. By forcing yourself to only ever create levels within the game it will make your tools better. If you cheat and say... "hmmm I really just want to get this done, I will write an XML file and import that to create my level just this once" then you will get lazy and continue to do this over and over and your tools will never end up being any good for the end user to use.
Windows / OSX / Linux based
Do you want your level editor to be used by Windows users as well as OSX and Linux users? Perhaps you want Solaris users to be able to edit levels. Keep this in mind in the very beginning. If you want your editors (and in fact your entire game engine) to be cross platform then you must care for this at the beginning of the project. You can very easily get lost in a pile of really nice libraries and code that will only ever be usable on a single operating system. One point to note here is the language that you choose. If you are going to develop your editors (or game engine) in .Net then you should consider looking at the Mono-Project. This will let you run your .Net applications on other operating systems, but you need to check what is supported in Mono before you start adding functionality to your application otherwise it might not run.
Who is your target audience?
When building your editors you should keep in mind who is going to be using them. What level of expertise do you think they will have, are they kids aged 5 years old making a simple play world for them and their friends or are they professional 3D graphics experts who already know how to make games, or anything in between.
When designing your editors you should try to keep things simple, try not to overwhelm the user with a million options on one screen. And perhaps, maybe one day in the not so distant future, you may want to sell your system to a potential game developer. If this is the case then you will have to provide lots of documentation and tutorials on how to use the system, so the easier it is to use the less work you have to do in documenting it all up.
GUI Systems
To make your editor its best if you use an existing framework for doing GUI's. They can be a real pain. I have used many of them over the years and I haven't actually found any of them to be perfect for my needs. I am not going to go into much detail about the GUI systems other than to point you at a few and let you experiment for yourself. I will say however that it is, in my opinion, very easy to develop 2D based level editors in .Net using C#. But QT, or wxWidgets experts may say the same thing about their favorite system.
MFC pretty old microsoft technology (windows only)
wxWidgets(cross platform, open source)
QT (cross platform, LGPL licence available)
Winforms or WPF (Windows, or via Mono)
Build as much as you can into Maya, Max, Cinema4D
One practice that is used within the games industry a lot is to build the tools directly within your preferred 3D application. This could be Maya, Max, Cinema4D, Blender etc...
The benefit of doing this is that the artist do not have to be retrained in a new system. They can stay within Cinema4D and create the characters, rig them up, add animation, textures, trigger and hit locations, create full levels with spawn points and navmeshes etc... These are then exported to an intermediate file format (more on this in the Digital Asset Management section) and then processed to get the assets into the right game format and away you go. Most applications these days have features for adding extensive GUI's, ways of marking up objects in the scenes (IE physics, trigger points etc...) and also provide good API's and scripting systems for exporting that data out again.
While working at one game company the standard practice was to build all the tools directly into the 3D application being used by the artist. The application was Maya. All the level editing, setting up of physics, sounds, character placement, trigger locations etc... were all setup within Maya and then exported out to intermediate files. At the time we kept wondering when, or if, we should create a separate stand alone editor. This would allow people to edit the levels and game data without having to have a licence of Maya itself as well as enabling some faster updates by not having to launch maya, find the files, edit then republish them, every time we needed a change. Instead of actually making this stand alone level editor we instead added real time asset manipulation of the game as it was running on the PS3. The PS3 could tell you all the assets currently in the game level, you could find them in a tree based editor running on your PC (or select them in game on the PS3 and then have the editor select it in its tree view). You could then tweak all the values for your scene and see exactly how it would look in game. The editor also new what the intermediate files were for this and could write out a patch file which would be used next time the asset was imported into Maya to do any editing, or simply used to alter the existing intermediate file the next time anyone ran the game.
Now this may sound overly complicated, but it worked quite well. There was no need for a complex 3D editor, everything was done in maya. The editor that we used was quite a simple program written in C# .Net. All it had to do was display a tree view of objects and their properties. That was it. Well not entirely, there was still the asset pipeline in the background and file loading and saving, but that is something that is a definite requirement anyway and not something only required by the editor.
The main downside to this approach is that you will have to have a copy of the 3D application to edit your levels properly. But if you are a small dev team then you will already have a 3D app of choice already. And if your a large team then you can probably afford a couple more copies for a dedicated level editor, and possibly have some other non-graphics intensive editors built as simple .NET applications. IE for setting up game object properties like hitpoints, weapons statistics etc...
For the game engine described in this article most of the tools will be developed within Cinema4D. It has a very extensive GUI system and allows you to create any kind of GUI functionality that you may need.
The Game Asset Pipeline
One final thing to mention about the level editors is that you should keep in mind the Game Asset Pipeline. This is the flow of the content from the editors to the final game. As an example a typical workflow for a 3D model would be to edit it in your 3D application, export the file to an intermediate file format, save the intermediate file format and its original 3d file in a digital asset management system, have some system that checks out the intermediate file and processes it extracting out different files required by the game engine in optimized file formats for that engine (you might have a separate mesh file format, skeleton file, multiple animation files, textures, lights, camera files etc...). These game asset are then published to the game and viewed.
For this project Cinema4D will also contain functionality to hook up to a Digital Asset Management (DAM) system to store all versions of the levels and any intermediate files created from them. There will be tools built directly within Cinema4D to load in assets, change them and check them back into the DAM. You can also trigger a game preview which will process all the files and load up the game with the latest content.
Deploying game content
Some all in one systems have a method of deploying their games, usually a "one click deployment" method. These work quite well for all in one solutions such as Esperient Creator or Unity3D. What they generally do is convert all the assets to the required game format required by the game. These files are then packaged up (maybe like a Zip file as in the Quake pk3 files). The file is then copied over to a location with all the executable files for the game and voila! You have a game ready to ship.
Incremental updating
Now what about doing updates to a game sometime after release? You could ask the client to download patches to the game. Or you could let the game engine itself look for updates. This could happen while the game is running and do some sort of hot loading, or you could make it happen when the game starts up. When it starts it downloads the latest files from the server and then runs. You can in fact do this very easily using RakNet.
P2P delivery
Another interesting way of delivering content could be for clients to tell a game server where they are located and then each player could download files from the nearest player via a P2P mechanism. This would reduce the load on the asset server by not having to upload potential gigabytes of data to every user when an update is required.
Conclusion
After reading this article you should have a better understanding of what might be required in a Game Engine. You should make sure to explore many of the game engine components out on the internet today and become familiar with at least a few of them. Unity 3D has just released a version that is free for Indie developers to use, so this should be one that you should definitely take a look. The Unreal Engine has also recently become free to use for developers, with a 25% royalty payment required after you earn more than $5000, which is quite reasonable for the use of this technology. Other engines such as CryTek's CryEngine, that ships with the Crysis game, is something you should also consider having a look at also.
But if your not into 3D then checkout the many flash based MMO development kits and see what suits your needs there as well. Whatever you do make sure you keep having fun, since as soon as it starts feeling like hardwork you will loose momentum and your MMO may never end up being finished. But like alot of people out there already say... is an MMO ever "really" finished?
Coming up next will be an article on Digital Asset Management followed by one on The Game Server.
Comments
Post a Comment