Frequently Asked Questions

Please read the descriptions of the Indie and the Indie Source license. You may be getting some source code and documentation of varying levels depending on what you have elected to purchase.

You need knowledge of Linux and Windows game development ideally. And no, this is not a drag and drop 'game kit'.

This is a commercially developed game engine, built for demanding and leading edge game development. There is extensive programming documentation. Many elements of BigWorld Technology are graphically driven or 'artist friendly' - such as the World Builder, Model and Particle Editors. However, you will require knowledge of Python (and for the Indie Source version, Python and C++) to implement your game ideas and drive the machinery of the game logic. You will need programmers, and if you are serious about the development, probably more than one. The smallest commercial development groups building on our technology have perhaps 8 - 15 people on their team, and the largest teams are more than 120-200.

Games are inherently software driven applications - although as an artist or designer you can build layers of graphical detail into an online environment, you can't breathe life into it without getting programmers involved. Do not buy any of the licenses listed on this page without taking that into consideration - the game is not going to write itself, nor is it a simple spreadsheet that you just 'configure' to look like your game.

You will need programmers to make game systems for you such as combat, character progression etc. This is not a WYSIWYG game authoring system. At the very least your developers will need to learn Python.

BigWorld Technology does come with many examples of art content needed for a game, so you should be able to create at least a demo of your game. You will undoubtedly need additional (or completely different) art content to finish your game. You can purchase art from various sources, but you will still need access to 3ds Max or Maya to export models and animations.

We are a business with real engineers developing real software and tools. We only want to be engaged with focused teams who are intent on making games. Every year, the renewed subscription continues your access to the support forums, and new releases - this can even be after you ship your game to enable you to 'refresh' your game in the field. Should at any time you wish to cease access to support forums or receiving new builds, you are still bound by the contract regarding payment of royalties.

This means you will lose access to the support forums and not have access to new builds, but you may continue to use the product. Any games created using this license will be allowed to continue, but royalties must still be paid.

BigWorld Technology has been designed to create various games, but does not come as a complete skinnable game. Out of the box it comes with a demo that looks like a MMORPG, but it does not come with many of the systems needed to create a complete game (such as Quest systems, or Character Progression systems). We have provided low level interfaces to the game engine so that these can be created as needed, but you will need to write your own Python code to do so. From Python you can customise many things such movement, player cameras, and rendering features. Game specific features such as AI logic, Quests, combat etc will have to be created by yourself in Python code. The Fantasy Demo provided provides some examples to help. The main limitation faced by Indie developers is all your systems will need to be written in Python, which does not give you access to everything. For example, if you wanted to write new physics routines to do a car racing game you would be severely limited without C++ source. If you have the Indie Source Edition, or the Commercial Edition you have access to the C++ source code of the engine. This can be customised as needed to create almost anything.

Certainly with the Commercial License all of these game types are possible. The Indie version provides Python access only and allows you to create an MMORPG.

The Indie Source license provides greater flexibility with access to the C++ source to the 3D Client, enabling modifications of the core 3D functionality and operation of the graphics engine.

Implementing all of these game styles in the base Indie version would be a significant challenge using only Python, but may be possible depending on the scope of your project.

Sorry, no. We think we are offering a very good deal at the current price.

10% is indeed a lot for a royalty share. All licenses are upgradable to a more modest commercial license royalty scheme, so - buy the commercial version of BigWorld Technology! Other, less complete, unproven or unsuited engines may have differing pricing or royalty schemes.

Any commercial revenue from the game - revenue from subscriptions, advertising, virtual item trading, in-world or linked-to-world commercial transactions of any kind.

Indie developers have been asking for an affordable version of BigWorld Technology from the day we started licensing it. We think that we're now in a position to make it available.

Additionally, getting a groundswell of engineers, artists and developers who are familiar with the scope and capabilities of BigWorld Technology going forward can only be a good thing for game development, our commercial customers and the gaming public. The Mod and Indie scene is arguably stronger and better positioned than ever before in the brief history of game development, and many of these groups want to try their hand at Virtual or graphical social worlds or MMOs.

No. However - if you are interested in publishing assistance we can provide services.

The Indie Edition comes with Python source code, has limited plug-in support (only FMOD, no SpeedTree, Umbra etc), but no C++ source. The Indie Source Edition comes full C++ source to the 3D engine and all content creation tools. There is also full plug-in support with Indie Source Edition. With the source code in the Indie Source or Commercial package, you have the flexibility to scrap, re-implement, extend and improve the client.

Yes you can migrate from an Indie license to the Indie Source, and from either Indie or Indie Source to the Commercial edition. We do not support mixing licenses - a single company or individual is eligible for only one license type. And no - you cannot refund the difference and downgrade from one license to the next.

You are certainly able to have multiple licenses of the same type, however you cannot mix-and-match licenses of different types.

Many reasons - negotiable and smaller (or potentially no) royalty, focused support infrastructure, comprehensive training and third-party technology integrations. Optional on-site availability of key lead engineers during testing phases, and slightly fuller source code on the server side providing greater flexibility. If you are a serious, funded company and want a great technology partner, this is why you would go the Commercial License route.

Companies serious about getting their game across the line - big games - games with vision and sophistication and polish - are generally larger companies, capable of sustaining dozens or hundreds of developers, artists, engineers and producers. Practically speaking, a commercial license for BigWorld is a small fraction of the initial year's development budget but allows them to get into gear with quality support, training and a partner in their game going forward.

There are many cheap, incomplete or unsuitable solutions out there - our chief source of revenue is commercial developers who need - and are prepared to pay for - a dedicated, supportive, innovative and focused technology provider. BigWorld builds a massively multi-player game engine and supports companies who are building large scale worlds. This is who the Commercial License is for.

Not at all. BigWorld has been in the engine licensing business a very long time. It is our expectation that large-scale games - as a general rule - require significant commitment both financially with professional game development practices. Consider - a large game can take several years to craft so we are talking about commitment at a company level to the longevity of an idea and a vision that smaller teams - with little or no backing (but potentially fewer overheads) generally don't survive long enough to build upon.

There is room in the pantheon of game development Gods for an innovative idea that can be achieved on a more modest scale, that has a rightful and potentially profitable spot in the gaming marketplace, but requires some - or all - of the kind of technologies we have spent a decade improving upon. Not every world has to be as vast as Second Life, not every MMO as ambitious as World of Warcraft (neither of these are powered by BigWorld Technology). It is our expectation that if the demands of development warrant it, that a number of companies will migrate from a Indie Source to a Commercial License because it offers commercial levels of engineering support and more flexible revenue terms(more profitable to run, license and operate).

Most Indie Source licensees are signing up to build a great demo for publishers or investors, or sometimes even to piecemeal release a game that is really small in scope and then grow larger beyond that, with a view to upgrading to a Commercial License when the business case allows.

1. BigWorld Client and Tools development environment (minimum recommended requirements):

GeForce 7900 GT or Radeon X1800 XT
Dual Core CPU
4GB RAM

Windows XP / Windows Vista / Windows 7
Visual Studio 2005 (for customers using the Indie Source Edition)
3ds Max / Maya for creating game models and animations
Photoshop (or equivalent) for creating textures

2. BigWorld Server development environment (minimum recommended requirements):

Dual core CPU
4GB RAM
Linux: Centos 5 64 bit

Yes. BigWorld Technology supports any client/platform that has socket support. The Indie Source Edition contains source to the network layer, which runs on Windows, Linux, Xbox360 and PS3. The Source Edition also comes with example programs written in C++ that show the most basic level of communicating with a BigWorld Server. Usually you would use the Python level libraries that sit on top of the C++ network libraries.

Depending on the type and scope of your game there are a number things you've still got to implement. You will still have to build a server farm, playtest your code, review and appoint a billing solution if your game is commercial, establish a community manager and other online game systems and staff that go around hosting a successful game. Presumably before this point you have already got the mechanisms of your business in place as well. If you're serious about profits you expect to make your game then you should probably also think about upgrading the license to reflect the Commercial License, as the Indie and Indie Source licenses are meant to just that from a business perspective - non-commercial or pitch work, not delivering a full-scale commercial MMO.

All the content seen in the FantasyDemo is included. This includes various terrain textures, buildings, trees, and a couple of creatures. These can be freely used, but are not enough to create a finished game -- realistically you will need to add lots of your own content.

No, there is no demo available. We are progressively posting more shots of the tools in action (keep watching the web site), and you might want to visit the public MMORPG Maker forums (http://mmorpgmaker.com) for additional user feedback.

If the software does not work as advertised, yes. But if you have just decided that creating a MMO is too hard for you after playing with the software for a few weeks, I'm sorry no. Read the public forums on MMORPG Maker (http://mmorpgmaker.com) to get a feel for what you are getting yourself into.

Game tools for your game masters will need to be written using our Watcher API which gives apps access to game & system information using URL like identifiers. The provided web based server tools enable you to filter and 'zero in' on particular aspects of what is going on in your game, such as the health of a particular character or the position of a monster in the world, but they are not really designed for Game Masters. You would need to write scripts in Python to enable your GMs to resurrect, teleport, drop money on particular characters etc as required by your game.

You would need to create these features in Python script, using the BigWorld Technology API. We provide examples of gui, chat, combat and trading all written in Python to help you get started.

We provide exporters for 3ds Max and Maya. Once a model has been exported it can be placed directly in the world using the World Editor, or customised with our Model Editor.

The BigWorld Server has been designed to use a consistent data rate, as specified by the client. Although anything can be specified, sensible data rates would be 5kbps at the low end (suitable for slow paced RPG), and 50kbps at the high end (fast paced shooter). If we compare ourselves to market leading MMOs the BigWorld server can smoothly move more players and monsters in a scene at lower bandwidth utilisation.

The Commercial Edition of BWT uses a combination of SQLite and MySQL, the Indie Edition uses XML.

The BigWorld server has different methods to preserve functionality when servers fail. Each of the following processes usually run on a separate machine in a production environment (during development fault tolerance is disabled).

CellApp: CellApps backup copies of entities randomly distributed to all BaseApp machines at a configurable rate (set to 10 seconds by default). If a CellApp machine fails, the entities on the failed machine are reinstated on remaining CellApps. If a game player is observing entities on a machine that failed, they may see a pause in movement while the entities are restored (typically less than a few seconds). Their own playing is not affected. If a game player is on a server that fails then all entities around them will disappear and then reappear as they are restored for their client. A few seconds of non-secured game-play will have been lost (eg the player health may change back to what it was 5 seconds ago). How long it takes for visible entities to be restored depends on bandwidth and number of visible entities. In FantasyDemo 300 visible entities can be restored in about 3 seconds. Typically you'd run the server at 70% capacity of peak usage. This leave headroom for unexpected server utilisation and failures. So if you need 10 CellApps for a theoretical 100% utilisation at peak, you'd specify 14 machines to allow for spare capacity. Note: secured gameplay refers to the principle of working directly to the database for important events. It is important to minimise these as too many database transactions will impact server performance.

BaseApp: BaseApps backup copies of entities randomly distributed to other BaseApps machines at a configurable period. If a BaseApp fails then the player will be logged out. The entity will be restored on the BaseApp that backed it up. Non-secured gameplay information may have been lost. Note: important operations such as picking up an item can write directly to the database to prevent data loss. As long as there is still at least one BaseApp the player can log in again straight away. Typically you'd want to have about 1 spare BaseApp machine per 10 BaseApps (and a minimum of two).

Login: This process is monitored by a watchdog process and on failure it is restarted on a spare machine (which can be shared with other manager backup machines). You can run multiple Login machines depending on load requirements. If there are no Login processes left then new players cannot join the game, but nothing else is affected. The Login process can be restarted starts in a few seconds, so this should not be noticed by players, except for players that were attempting a login when the Login process failed. In this case they will have to login again.

CellAppMgr/BaseAppMgr: These processes are monitored by a watchdog process and on failure they are restarted. No state information is lost if these processes fail. During the time that they are not available new CellApps and BaseApps cannot be added or removed from the cluster. This should have no impact on players.

DBMgr: This process is also monitored by a watchdog. On failure a new process is started. Any pending transactions will timeout, and have to be retried by script code. From a player perspective operations involving the database (eg: trading items) will take longer to complete.

At least one. This server can be shared by multiple team members. Each team member runs their own BigWorld server instance without conflicting with other users on the shared server. We have experience of teams of four developers sharing a single server, but this is dependant on memory and CPU usage by the individual game. We recommend a dual core with 2G of RAM per BigWorld server instance.

Yes. The tools have a Python API that allowing creating custom functionality.