Modding

From Software Inc.
Jump to navigation Jump to search
Furniture Modding is a separate page
Material Modding is a separate page
Code Modding is a separate page

Modding in Software Inc. is completely data driven. Software Inc. loads TyD files found in the "Mods" folder of the root of the game when it launches.

A mod should be placed in its own folder in the "Mods" folder and can optionally contain each of the following folders: "CompanyTypes", "NameGenerators" and "SoftwareTypes".

The root of your mod can additionally include a Personalities.tyd file to add new personalities to the game.

Debugging console

The debugging console is enabled by binding the console key at the bottom of the key binding menu in the options window.

Helpful commands

  • INSTA_DEVELOP_DESIGN - Instantly releases whatever is in the design document window, skipping design and dev phases (Only works for modded software)
  • RELOAD_MOD X - Reloads mod named X. Note that this does not affect the currently running game, if there is any
  • CHECK_SPEC_REP X - Checks whether all specialization levels are used across all software when mod named X is loaded, which would otherwise make some education worthless
  • TEST_DEV_MOD X Y Z - Prints out balancing information for Software Category Z in Software Y in mod X. This tells you if the player can reach 100% interest with any submarket targeting
  • LIST_SCOPE_MEMBERS X - Prints out all functions and variables available for the type X, to use when making level 3 feature scripts
  • COMPARE_LOCALIZATION X Y - Compares what has changed between between localization X and Y, Y should almost always be "English"
  • CONVERT_LOCALIZATION_TYD X - Converts localization named X from XML to TyD
  • RELOAD_LOCALIZATION - Reloads all localizations, but does not update UI instantly when in-game

In-game content

These are zip files of the software types, company types, name generators and personality types currently in the game:

Alpha 8.6.1 data - 23 KB

Alpha 9.7.6 data - 35 KB

Alpha 10.1.4 data - 23 KB

Alpha 11.4.1 data - 22 KB

Alpha 11 changes

If you're coming from pre-Alpha 11 modding, this section will probably be relevant, as the design philosophy of software in Alpha 11 is incompatible with previous versions.

Feature evolution

Features can no longer depend on each other. You can't design your software in a way that relies on features evolving or deprecating old features. Features are more abstract in Alpha 11 and rely instead on Tech levels to control their evolution. An example would be PC speaker, 8-bit audio and HD audio from Alpha 10. In Alpha 11 you just have "Audio" and its tech level determines its perceived complexity.

Why?

On a surface level this might seem like a step back in terms of gameplay depth, but it actually opens up a new layer of complexity. The old system wasn't really deep in any meaningful way to begin with, since the player would always end up just pressing "Select all" and none of the intricacies of the feature dependencies were very obvious or satisfying. Some benefits of the new system include:

  • The player will never run out of new features
  • The player will never run out of things to research and there will always be research available
  • The complexity has been moved from obscure interdependencies to several new systems the player can actively engage with
  • The tech level system is a steppingstone to adding the updates/expansion mechanic, which would not have been possible with the old feature system

Moving forward

Features should be a lot more abstract than before. They should represent aspects of a product that appeals to different submarkets to various degrees, rather than very time period specific add-ons. The game is balanced towards the player deciding on which markets they want to target and selecting features that fit that goal. Ideally you would have features that doesn't always fit in a product, which the player would want to leave out. Features that should always be present, like Audio playback, are represented as "SpecFeatures" or specialization features, which can be specified as mandatory and work as containers for other features with the same specialization.

Software types

Software types are the types of software you can choose to develop in Software Inc. in the design document window. Software types can be added to the game by creating an TyD file in the "SoftwareTypes" folder.

Overview

The elements of a software mod
Same elements as represented in-game

Elements

A software type TyD table should contain the following elements:

Name The name of the software as it will appear in dropdown lists, etc.
Override If this is set to True all elements are optional and will override the content of a software type by the same name. You can use this to override some values of the built-in software types. Note that if you override the Features list, you will delete all features from the software type. If it is set to Delete, it will delete the softwaretype of the same name, from the game. This should be omitted if you are just adding a new software type.
Category How the field of the software will be referred to in articles, e.g. games are categorized as "Gaming"
Categories The categories for the software type. This can be omitted to make the game create a Default category.
Description The contents of the tooltip that will appear when hovering over the software type in the dropdown menu in the design document window.
Unlock Which year this software type will unlock, e.g. Unlock 1995
Random How much sales will vary. When a product is released, a random number is chosen and it is weighted using this number, and it will be multiplied for all sales. As an example, for games it is 0.5, since you can't count on good sales for a game, but for operating systems, it is 0, since they are generally in demand and necessary for a computer to work, so sales won't vary that much. Note that the effect of this value is very small as of Alpha 11.
IdealPrice How much products of this type should ideally cost at 100% quality and interest. This should be omitted if you want to control the ideal pricing per category.
OptimalDevTime How many months this product should ideally take to make (This is in 1 employee months, meaning the value is not scaled by having a team working on it). This also controls how many features the player needs to select to satisfy a submarket. This is 40 for games and 75 for operating systems.
Popularity How popular a software type is, which limits the maximum amount of potential consumers. Computer operating systems have 1 and Role Playing Games have 0.6. (Ignored if software type has categories defined)
Retention How long products keep their interest after release and how long people will use the product in months. Computer operating systems have 72 and Role Playing Games have 24. (Ignored if software type has categories defined)
Iterative How likely AI companies are to develop sequels for this type of software, between 0 and 1. (Ignored if software type has categories defined)
OSSupport Set to True if this product requires support by an operating system. If you only want support by specific operating system categories you can write it out like Computer or in list form like [ Computer; Console ]. If your software is not operating system dependent just omit this record.
OneClient Whether this software is for contract work.
InHouse Whether you can lock this software to your own company. This makes sense for tool dependencies, like Audio and 3D tools, but not for customer facing products such as games for example.
NameGenerator The name generator to use for simulated companies or for when the player clicks the name button in the design document. (Will be used for all software categories which don't have one defined)
SubmarketNames A list of three submarket names, e.g. [ Gameplay; Graphics; Story ]. Submarket ratios you define in categories and features should be in the same order you define the names in.
Features All features that this software can implement.

Example

Note that this product will have a maximum devtime of 12, but the optimal is set to 25, so the player won't have enough features to reach 100% submarket satisfaction, especially since the features doesn't cover all submarkets properly. You can use the TEST_DEV_MOD console command to make sure your software type can satisfying its submarkets. 

SoftwareType
	{
	Name			"Test Software"
	Category		Testing
	Description		"This is part of a test mod. If you develop a perfect version, 50% of the population will want it for about $50, but less than 10% might randomly not want it."
	Random			0.1
	IdealPrice		50
	OptimalDevTime		25
	OSSupport		Computer
	OneClient		False
	InHouse			False
	SubmarketNames		[ TestMarket1; TestMarket2; TestMarket3 ]
	Categories
		[
			{
			Name			"Test category"
			Description		"This is a test category"
			Popularity		0.5
			Submarkets		[ 1; 3; 1 ]#20%, 60%, 20%
			Retention		24
			TimeScale		1
			Iterative		0.75
			NameGenerator		testgen
			}
		]
	Features
		[
			{
			Name 		"Test feat 1"
			Spec		System
			Description	"This feature represents the system aspect of the product and cannot be deselected"
			DevTime		3
			CodeArt		1
			Submarkets	[ 1; 0; 1 ]#50%, 0%, 50%
			Features
				[
					{
					Name		"Test subfeat 1"
					Description	"This feature requires a level 1 System designer/programmer to be finished"
					DevTime		3
					Level		1
					CodeArt		1
					Submarkets	[ 0; 1; 0 ]
					}
					{
					Name		"Test subfeat 2"
					Description	"This feature will cost the owner $1000 per day when it is released"
					DevTime		2
					Level		3
					CodeArt		1
					Submarkets	0 #No submarkets needed for level 3 features
					Script_EndOfDay "Product.DevCompany.MakeTransaction(-1000, Bills, \"Owned\");"
					}
				]
			}
			{
			Name 		"Test feat 2"
			Spec		Audio
			Dependencies	"Audio Tool"
			Optional	True
			Description	"This feature can be deselected, completely removing Audio features and Audio Tool dependencies from the product"
			DevTime		4
			CodeArt		1
			Submarkets	[ 0; 1; 3 ]#0%, 25%, 75%
			}
		]
	}

SpecFeatures

SpecFeatures or Specialization Features are features that map to a specialization (3D, 2D, Audio, etc.), which employees can specialize in. You can only have 1 SpecFeature per specialization, but you don’t need to have one for each specialization. You can make up your own specializations and the game will add them automatically.

SpecFeatures are the foundation that smaller features (SubFeatures) build on. All features have a level which determines employee education requirements. SpecFeatures are level 0, meaning everyone can work on them, but they are not as effective as level 1 or 2 features for satisfying the submarkets.

Values

Feature This is the root tag, which all tags should be a child to. Add any attribute explained above to this tag.
Name The name of the feature as it will appear in feature panel in the design document window
Category A tag that controls which specialization a product belongs to. The employees' specialization skill will control how well, if at all, they work with this feature. This can be 2D, 3D, Network, etc. You can add new specializations to the game using this tag by simply writing whatever you want.
ArtCategory You can use this optional tag if you want the art part of a feature to belong to a different category than the code part. This is not relevant if your CodeArt ratio (details below) is equal to 0 or 1.
Description The contents of the tooltip that will appear when hovering over the feature in the design document window.
Unlock Which year this feature will unlock, e.g. <Unlock>1995</Unlock>. Specializations will unlock, when the first feature which uses it unlocks.
DevTime How many months it takes to develop this feature
Innovation, Usability, Stability These three tags are normalized, so you can put in any number. 3, 4 and 5 would result in 3/12, 4/12 and 5/12. Innovation controls how long the product will stay interesting to customers. Usability controls how well customers will like the product and in extension, your company. Stability controls bugs and how much skill your employees will gain from working on the feature.
CodeArt The coding to art balancing of the feature. 1 will mean this feature only requires programmers whereas 0 will mean it only requires artists, and 0.5 means a little bit of both.
Server How many mbps this feature will need per active user. It is scaled with time using the formula 1+log10(year-1969). MMO uses 0.002, which would be around 5 gbps at any given time for a 1 million user game in 2010, which might change in the future.
Dependency What features this feature depends on to be available, this can be features in the current product, features in other products or features in supported operating system. Note that operating system feature dependencies are taken as an intersection, so if a features relies on 3D in an operating system, ALL chosen operating systems must support 3D. A dependency should be defined as <Dependency Software="Operating System">3D</Dependency>. You can have multiple of these tags per feature
SoftwareCategory Optional tag that limits the feature to a certain software category of its parent software type. You need to specificy an unlock year here, which will override the other unlock tag. You can set the unlock year to 0 to not have an unlock date. You can add multiple of these tags per feature.

SubFeatures

SubFeature are addons to the main SpecFeatures, they fit in the same specialization as the SpecFeature they belong to, but they satisfy submarkets more effectively, meaning they need less devtime to add more satisfaction.

Level 3 features

Level 3 features do not satisfy submarkets at all, but they have custom scripts attached that change how the game works in some way. Scripting works using a programming language developed specifically for Software Inc.

You add scripts to features by adding a Script record, which consists of Script_ and then the name of entry point where you want your script to be executed, and then your script. Each entry point has a different scope, which determines which variables you can interact with. These entry points currently exist:

Entry point Description Scope
Script_EndOfDay Executes after the market has finished simulating every day after the product is released. ProductScope
Script_AfterSales Executes right after a products sales units have been calculated. SaleScope
Script_OnRelease Executes when the product has been created, before it is actually registered in the market. ProductScope
Script_NewCopies Executes when new physical copies have been shipped for a product. (i.e. not sold yet) CopyScope
Script_WorkItemChange Executed whenever a task has been created or stopped, that is related to the product. You can use the is keyword to figure out what kind of task you're dealing with, e.g. if (WorkItem is MarketingPlan). DevScope

To figure out which variables you have access to, you can use the LIST_SCOPE_MEMBERS console command with the name of the scope you want to check out, e.g. LIST_SCOPE_MEMBERS CopyScope. Note that you can use dot notation to drill down into a scope, e.g. LIST_SCOPE_MEMBERS CopyScope.Product.

You can either write your scripts directly in your TyD file as such: 

Script_EndOfDay "if (Product.GetCashflow(false).Last() > 100) { Product.DevCompany.MakeTransaction(-Product.GetCashflow(false).Last() * 0.1, Bills); } #Pay 10% of last days income if it is more than $100"

Or you can put your script in separate files and refer to them relative to your mod root folder, by starting with a forward slash: 

Script_EndOfDay "/Scripts/MyScript.txt"

Software categories

Software categories are defined in the Categories list of the SoftwareType table. Categories enable software specialization, e.g. OS/Console/Phone Operating systems. It is completely optional and a "Default" category will be used in case it is omitted from the software definition.

Values

Name This is the name of the category
Description What will be shown when hovering over the category in the design document
Unlock Which year this software category will unlock, e.g. <Unlock>1995</Unlock>
Popularity How popular a software category is, which limits the maximum amount of income. Computer operating systems have 1 and Role Playing Games have 0.6.
Submarkets The ratio of submarkets for this category. E.g. [ 1; 3; 4 ] will result in the third submarket making up 4 / (1 + 3 + 4) = 50% of the consumer population for this product, while the first only makes up 12.5%.
TimeScale How long it will take to make a product in this category compared to the base software type, should be between 0 and 1. This scale is also applied to the optimal dev time parameter.
Retention How long products keep their interest after release and how long people will use the product in months. Computer operating systems have 72 and Role Playing Games have 24.
IdealPrice How much products of this type should ideally cost at 100% quality and interest. This is ignored if the software type already defines it.
Iterative How likely AI companies are to develop sequels for this type of software.
NameGenerator The name generator to use for simulated companies or for when the player clicks the name button in the design document.

Name generators

The random name generator uses a tree like structure to generate random strings of words. Generators will be loaded from txt files located in the "NameGenerators" folder and their name will match their file names, minus ".txt". If you name a name generator the same thing as one of the built-in name generators, they will merge their nodes and words, you can use this to expand the words of a built-in name generator.

Writing [REPLACE] as the first line will replace an existing name generator from the game, based on it's file name.

Example

Here is an example of how a name generator can be structured in the text file: 

-start(base)
-base(base2,end,stop)
Hello
Hi
-base2(end,stop)
, you
-end(stop)
.

This would create a generator that can generate the strings:

  1. Hello
  2. Hi
  3. Hello.
  4. Hi.
  5. Hello, you
  6. Hi, you
  7. Hello, you.
  8. Hi, you.

It works by starting from the first node "start" (nodes are the ones with a hyphen in front of the name), it appends a random string from the list of strings below it (in this case there’s nothing to pick), it then picks a random node from the parenthesis of the current node (which can only be "base" in this case), and then it continues until it reaches the node stop. There is a limit to how far it will go, depending on how many nodes there are, to avoid an infinite loop.

Company types

THIS SECTION IS NOT UPDATED TO ALPHA 11 YET!

Company types are the types of company that the game will simulate. If you don't define company types for your new software types, the software will not be released by the AI.

Removing companies

You can remove AI company types by adding a "delete.xml" file in the CompanyTypes folder, which includes a root tag containing a tags with the company types you want to remove, eg. 

<CompanyTypes>
	<Type>Web CMS</Type>
	<Type>Financial CMS</Type>
	<Type>Workflow CMS</Type>
</CompanyTypes>

Tags

CompanyType This is the root tag, which all tags should be a child to.
Specialization The name/tag of the company type. If you pick a name of one of the built-in company types, you can override it. Note that this only works for Alpha 4.5+
Force Whether a company of this type should be created on the first day and be forced to launch software on the first day. It is currently only used to launch a Computer Operating System on day one: <Force>Operating System,Computer</Force>. Just omit the tag if you don't need it.
PerYear The chance of a company of this type being founded every year. All company types in Software Inc. has this set to 0.2, as it seems to work pretty well.
Min The minimum amount of companies of this type there has to be on the market at any given point in time. 1 for computer OS, 2 for games.
Max The maximum amount of companies of this type there has to be on the market at any given point in time. 3 for computer OS, 6 for games.
Types The types of products the company will release and how much effort they take. 1 means they can only work one product of that software type at any given time, 0.25 means they would be able to work on 4 of it at a time. Currently this is set to 1 for all company types in Software Inc. as going lower seems to spam the market. You can define a category for each type, otherwise a random will be chosen from the categories available from the software type.
NameGen Optional name generator to use, will use "Company" by default. Only available in alpha 9.7+

Examples

<CompanyType>
	<Specialization>Tools</Specialization>
	<PerYear>0.2</PerYear>
	<Min>1</Min>
	<Max>4</Max>
	<Types>
		<Type Software="Audio Tool">1</Type>
		<Type Software="Visual Tool">1</Type>
		<Type Software="Antivirus">1</Type>
	</Types>
</CompanyType>
<CompanyType>
	<Specialization>Computer Operating Systems</Specialization>
	<Force>Operating System,Computer</Force>
	<PerYear>0.2</PerYear>
	<Min>1</Min>
	<Max>3</Max>
	<Types>
		<Type Software="Operating System" Category="Computer">1</Type>
	</Types>
</CompanyType>

Personalities

Personalities control employee traits an inter office relationships. All employees have exactly 2 personality traits. All personalities will be merged with the pre-existing personalities in the game.

Elements

PersonalityGraph This is the root table. If the mod has more than 2 new personalities, you can add a Replace True record to this table, to replace the base personalities of the game.
Personalities This list should contain the personalities
Incompatibilities This list should contain a list of personalities which cannot be mixed when picking employee personality.

Personalities and incompatibilities

Personality values include:

Personality This is the root table
Name The personality's name as it appears in the game.
WorkLearn Between -1 and 1, where -1 is hard working and 1 is easy learner.
Social Between -1 and 1, where -1 is independent and 1 is social.
LazyStress Between -1 and 1, where -1 is lazy and 1 is stressed.
Relationships This table should contain a list of records, defining how people with this personality feels about another personality, between -1 for bad, 0 for okay and 1 for great. You only need to define this one-way, so if you already have a relationship with Stubborn defined for Short-tempered, you shouldn't also define it other way around. You can define relationships with personalities already in the game.

The Incompatibilities list should contain a list of personality pairs that are incompatible, meaning they cannot exist in the same person.

Example

PersonalityGraph
	{
	Personalities
		[
			{
			Name		TestPersonality
			WorkLearn	1
			Social		-1
			LazyStress	0.3
			Relationships
				{
				Extrovert		-0.5
				TestPersonality2	1
				}
			}
			{
			Name		TestPersonality2
			WorkLearn	-0.5
			Social		0
			LazyStress	0.25
			}
		]
	Incompatibilities
		[
			[ TestPersonality; TestPersonality2 ]
			[ TestPersonality2; Introvert ]
		]
	}
Retrieved from "https://softwareinc.coredumping.com/wiki/index.php?title=Modding&oldid=600"