Author Topic: Galactic Puzzle Pieces: The Challenge of Making a Modable Game  (Read 1662 times)

Firgof

  • BMS Administrator
  • Delusional
  • *
  • Posts: 1531
  • Karma: +175/-4
    • View Profile
Galactic Puzzle Pieces: The Challenge of Making a Modable Game
« on: November 21, 2009, 12:30:12 PM »

From the beginning, Star Ruler was designed to be accessible to modders. In this article, we'll explore the impact of that choice from two perspectives: impact of modability on development, and the advantages modability brings to the end users.

It was an early choice to design Star Ruler with support for modifications, as that's how I personally got most interested in game design and development, and I wanted to give that opportunity to people that are just becoming exposed to game development. This choice has had significant impact on the rest of the design process, both positively and negatively, although the positives vastly outweigh the negatives.

Starting with the negative side of mod support, everything in our engine will be exposed to circumstances far beyond what any of us can envision, requiring code which is resilient to all sorts of input errors as well as other strange things that modding may cause. We don't know that ships will always leave a system under their own power, or that planets always need people, or that stars will be stationary. Many of the shortcuts that could have become available without support for modding simply aren't options.

Additionally, we have extra difficulty in designing the user interface as we try to balance design complexity on our end with support for things modders (or even we) may make use of, thereby saving time for modders whom won't have the same difficulty during their development.

On the other hand, these design requirements have also benefited us as we got farther along in the development, because the engine already supports things we didn't even know we would eventually be adding, and allows us to very rapidly code things that had already been planned, as well as quickly and easily change many elements of the game.

Looking back at the decision to support modification, I'd make the same choice. While supporting that decision has made development more difficult, the extra difficulty truly comes from programming the engine in a way that is far easier to maintain as time passes, and the design requirements limit the times where a quick solution wins out over a long term solution.

Star Ruler from a Modder's Perspective
Star Ruler's modding starts with its data files. These files are in a plain text format, so any text editor with the ability to export plain text works. Data files consist of Key:Value pairs as an attempt to maximize both human and machine readability. Each data file specifies base data, or a relationship between the base data and the mechanics of the game. Here's an example of a Sub System definition.

System: MediumHull
              Name: "Standard Hull"
              Description: "Standard hulls provide the necessary support structure to equip components, and some moderate damage resistance. They provide a middle ground between strength and speed."
              Appearance: MediumHull
              Tags: IgnoresScale, Hull
              Available: Techs.ShipConstruction.Level > 0
              Level: floor(Techs.ShipConstruction.Level)
              Size: Object.Size
              Durability: Size * progress(20,0.5,Level)
              Mass: Size * 20
              Costs: Metals[100 + 50 * Size], Electronics[50 + 10 * Size], AdvParts[20 + 4 * Size]
              Provides: DestructsShip

All the blue text is the keys, and the remainder of a line is interpreted based on the key. All the mathematical expressions are evaluated via algebraic order of operations whenever an instance of the Sub System is created. The Provides line adds gameplay effects, specified elsewhere, to the Sub System, optionally with variables that define the effect's behavior. Also of importance is the costs, which can be named anything – adding a new resource is as simple as referencing one that doesn't already exist – which ties into the more general system of object states.

For non-data files, we use the C++ style scripting language AngelScript. This language is used for the GUI, custom effects system, and AI, and it may be expanded elsewhere in the future. A great deal of the engine is exposed in this language, and very little is impossible to do. While learning this language gives a modder far more power to create his or her vision, plenty of modding can still take place in the data files, or by editing clearly described variables within the code files.

To make mod creation as easy as possible, mods can make use of as much of the base game – or any mod – as they chose, overriding parts as the creator sees fit. We also plan to support meta-mods, which could function independent of the base mod (e.g. a new GUI window), or act as options or small modifications to larger mods.



All images are "Works In Progress" and are not representative of the final product. All ship models, images, and in-game screenshots used in this news article are the property of Blind Mind Studios and the team members and contracted individuals who created them (listed on the About page); they may not be redistributed without permission. To seek permission, contact us; if you are a member of the press, please indicate as such!
"Now it will punish you"