Data Modding

A lot of the modding features in Software Inc. are 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, Read more here.
GENERATE_LOCALIZATION X - Generates localization files based on the mod named X
CHECK_ADDON_MARKET X Y Z - Checks whether all markets are fulfilled by the add-on Z in a software type Y in mod X, which would otherwise make it impossible to sell the add-on to 100% of the market

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.7.1 data - 22 KB

Beta 1.1.1 data - 34 KB

Beta 1.3.19 data - 35 KB

Beta 1.7.15 data - 35 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 don'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	Deprecated as of Beta 1 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

Name	The name of the feature as it will appear in feature panel in the design document window
Spec	Which specialization this feature maps to. This can be 2D, 3D, Network, etc. You can add new specializations to the game using this record by simply writing whatever you want.
Description	The contents of the tooltip that will appear when hovering over the feature in the design document window.
Dependencies	Optional record to specify whether this feature depends on other software tools. This can be either the name of a software type, like Dependencies "2D Editor" or a list: Dependencies [ "2D Editor"; "3D Editor"]
Unlock	Which year this feature will unlock, e.g. Unlock 1995. Specializations will unlock, when the first feature which uses it unlocks.
DevTime	How many months it takes to develop this feature
Submarkets	A list of 3 values determining the submarket ratio, i.e. how this feature satisfies the submarkets. These three values are normalized, so you can put in any number. 3, 4 and 5 would result in 3/12, 4/12 and 5/12.
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.
Optional	If you want the player to be able to toggle this feature off, just add the record Optional True, otherwise you can omit this record.
SoftwareCategories	Optional record that limits the feature to a certain software category of its parent software type. You can specify a year with each category you list, e.g. [ [Computer; 1995]; [ Console; 2000 ] ], however if you just want the feature to only be available for some categories, you can write them out in a list like so: [ Computer; Console], which is equivalent to unlocking at year 0. Having this record will override it in all its subfeatures.
Features	This is the list of SubFeatures that belongs to this SpecFeature.

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.

Values

Name	The name of the feature as it will appear in feature panel in the design document window
Description	The contents of the tooltip that will appear when hovering over the feature in the design document window.
Level	The level of the feature, which controls who can work on it. Level 2 features give more submarket satisfaction than level 1 features. Level 3 features don't satisfy submarkets at all, but they have custom scripts.
Unlock	Which year this feature will unlock, e.g. Unlock 1995.
DevTime	How many months it takes to develop this feature
Submarkets	A list of 3 values determining the submarket ratio, i.e. how this feature satisfies the submarkets. These three values are normalized, so you can put in any number. 3, 4 and 5 would result in 3/12, 4/12 and 5/12.
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.
SoftwareCategories	Optional record that limits the feature to a certain software category of its parent software type. You can specify a year with each category you list, e.g. [ [Computer; 1995]; [ Console; 2000 ] ], however if you just want the feature to only be available for some categories, you can write them out in a list like so: [ Computer; Console], which is equivalent to unlocking at year 0. This record will be ignored if the parent SpecFeature has it defined.
Script_EntryPoint	Scripts for level 3 features, read below.

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.

Please note that level 3 features will never be selected by the AI, to avoid unpredictable behaviour and since scripts aren't very performant, it would slow the game down a lot if all products had scripts to execute. So you can think of level 3 features as small bonuses for the player to pick. If you want more advanced behaviour, you should look at writing code mods.

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 use parentheses to get info on specific parameters or generic types, e.g. LIST_SCOPE_MEMBERS CopyScope.Product.RunScripts(0) will print out info for the first parameter of the function RunScripts, which is ScriptSystem.EntryPoint, i.e. the available list of entry points.

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"

Finally, all SoftwareProduct's have their own local variables that you can read and write to for your scripts, just use Product.GetVar(VariableName, DefaultValue) and Product.PutVar(VariableName, Value).

Scope members

These are the variables and methods each scope has access to. Note that you should use the LIST_SCOPE_MEMBERS console command, as described above, to get details.

All scopes

SDateTime Now (Current in-game time)
int DaysPerMonth
Company PlayerCompany
MarketSimulation MarketSimulation
string Localize(string input, optional string arguments) (Localizes a string)
void LaunchLawsuit(string subject, float amount, float difficulty) (subject should be an unlocalized string and the mod should include the localization. Difficulty is float between 0 and 1, 1 being very hard to defeat)
SDateTime CreateDate(int year, int month, int day, int hour, int minute) (Create a new date to use where needed or for date arithmetic, e.g. Now + CreateDate(0,1,0,0,0) to add 1 month to the current date. Note that "year" is defined as years since 1900)
void AddPopUp(string text, float importance = 0.5, string icon = "Info", NotificationSound sfx = Neutral) (Adds a popup message in the top left, input string should be pre-localized, icons include "Exclamation", "Money", "Server", etc. Sfx includes Issue, Warning, Good, Neutral)

DevScope

WorkItem WorkItem
bool Ended, Cancelled (these will be true if the event was triggered by the workitem being ended or cancelled, otherwise it was triggered by being created)

SaleScope

SDateTime Time (Same as Now)
SoftwareProduct Product
int PhysicalSales, DigitalSales, Refunds (These can be changed to alter the result of the current day's market simulation)

ProductScope

SoftwareProduct Product
SDateTime Time (Release date)

CopyScope

SoftwareProduct Product
uint NewCopies (How many new copies were added to stock, this is read-only)

Networking

Level 3 features can also use the RunType value to control which computer will execute the code. The value can be either of the following:

Local, which means the script will only run on the computer for the player who owns the product (This is the default). Example: You want something to happen to the affected player's game, like launching a lawsuit or firing an employee. This needs to be done locally for the affected player, or someone else might be sued for no reason.
Host, which means the script will only run on the current hosting player's computer. Example: You are only calling methods which are synchronized between players, like adding bugs or money. These can be run locally, but any online synchronized methods will be faster to run for the host machine. If you are unsure, using Local will be fine, but if you run a synchronized method using the Everyone RunType, the method will get called multiple times. E.g. if you are adding money to a company, then that money will be added again to the same company for each player connected.
Everyone, which means the script will run for every player connected. Example: You are directly changing aspects of the product (like the price) or a company, by altering the value of local variables, which will not be synchronized by default, so you want the script to run for all players in the game, so everyone is on the same page.

Note that the RunType value is only valid for the EndOfDay, OnRelease and NewCopies entry points. AfterSales is only ever executed for the host and WorkItemChange is only ever executed for the local player.

Script example

This script is used in the microphone surveillance feature of the Operating System SoftwareType:

if (Product.GetVar("MicMining", true)) //Check if player has been caught
	{
	Product.Bugs = Max(0, Product.Bugs - Product.Userbase * 0.01); //Remove 1 bug from product for each 100th active user
	if (Random() * Product.Userbase > 1000000 * Product.Category.Popularity)  //Random chance of getting caught
		{
		LaunchLawsuit("SpyingOnUsers", Product.Sum, 1);  //Create anonymous lawsuit
		Product.DevCompany.AddFans(-Product.Userbase, Product.Category);  //Remove fans and market recognition from player in category
		Product.Userbase = Product.Userbase * 0.05;  //Remove 95% of active users
		Product.KillAwareness();  //Remove all marketing
		Product.PutVar("MicMining", false);  //Mark player as caught for this product
		}
	}

You should download the mod data zip and check out examples of other scripts in the other vanilla SoftwareTypes.

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
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.

Add-ons

Add-ons are defined in the software root table as an AddOns node with a list of add-on tables. Add-ons are either software or hardware based, which depends on the categories that support it. Software categories that uses a specific add-on should all either be hardware or software based. Add-ons can be limited to certain categories of the main software type.

Hardware based add-ons are peripherals and function differently than software add-ons in that other companies can make them for each other's hardware and a single customer can buy the same peripheral several times.

Values

Name	This is the name of the add-on
Description	Currently not shown anywhere
Unlock	Which year this add-on will unlock, e.g. Unlock 1995
Categories	Optional list of software categories that supports this add-on
OptimalDevTime	This optimal amount of time it takes to develop, to maximize interest, works the same as for software types
Retention	How long products keep their interest after release and how long people will use the product in months.
Forced	Whether you have to develop this add-on when develop the main product, e.g. joysticks for consoles. Only valid for peripheral add-ons. This should be a number between 0 and 1 that controls how big of an impact the quality of an add-on has on the main product's reception.
PerUser	How many times a single customer can buy this product. Only valid for peripheral add-ons
IdealPrice	How much products of this type should ideally cost at 100% quality and interest.
BaseFeature	Optional feature that is always selected, which makes it so this add-on can be developed without needing to pick any features at all. Also forces a baseline development timeline.
Features	A list of features, as with the main software type. Each feature also additionally has an optional MaxFactor number that works like a multiplier for the player, e.g. setting it to 3, means the player can multiply this features effect from 1 to 3. If MaxFactor is used, you can also use AmountScript to write a SIPL script that formats the number, e.g. x + " bunnies", will write "3 bunnies" if the player picks 3 as the factor. LocalizePlural('Employee', x) will use the plural enabled localization key based on the factor, e.g. 3 would write "3 employees". and Switch(x, clampBool, localizeBool, 'one', 'two', 'three') will pick one of the strings based on the factor value, e.g. 4 would be 'three' if clampBool is true and 'one' if it is false. Finally features can optionally define DependsOn, which is a feature in the main product that needs to be present to use this feature in an add-on.
Manufacturing	The manufacturing process for peripheral add-ons
NameGenerator	The name generator to use for simulated companies or for when the player clicks the name button in the add-on design document.

Hardware

To turn a software type into hardware you need to add the value Hardware True, which will disable digital sales and make the product easier to sell. When you toggle hardware for a software type, you should also add a manufacturing process, that defines the components that make up a product.

The Hardware toggle and Manufacturing table can be added directly to the root Softwaretype table to affect all categories, or individually on categories.

Manufacturing process

The manufacturing table should include the following items:

Components	The possible components that will make up the final product.
Processes	The assembly processes that define how components are put together
FinalTime	The time it takes to assemble the final product in minutes. That is the last step in assembly, not the entire process.

Components

Name	The name of the component (This will work as an ID and key for the localization system, you should use the GENERATE_LOCALIZATION console command on your mod to generate the localization files that will be used in the UI)
Thumbnail	The path to a 128x128 pixel png file containing a "sticker". The path should be relative to the root folder of your mod. The thumbnail will not be loaded if it is not exactly 128x128 pixels. All stickers in the game use a 4 pixel white border, you are free to not add it, however it is recommended, by me, I guess.
BuiltInThumbnail	Optional thumbnail to fall back on in case the game fails loading your png file. Defaults to Unknown, but can be Camera, Console, Fingerprint, Gyroscope, Harddrive, Joystick, LCD, Microchip, PCB, Phone, Plastic, PlasticCase, Speaker, Thermostat, Touch, USB, Battery, Antenna, LED or Vibration.
DependsOn	Optional name of a feature in the software this component depends on, to be added to the manufacturing process. If the player does not select this feature, the component will be removed from the manufacturing process. The game will collapse any processes that are completely removed by this process. Note that all features that a component depends on will have its submarket satisfaction scaled by 6 (This can be overridden by adding a HardwareFactor value to the feature with the scale you want to use), to incentivize the player to use them, so you should keep the DevTime low for these features. You should have at least one component that doesn't depend on any feature.
DependencyFactor	This can be used for peripheral add-ons to control which factor(s) are required to use this component, e.g. [1;6], means factors 1 through 6 are needed, but just writing 2 means the exact factor '2' is needed.
Price	The price of the component. Only components that are printed will actually have a cost, e.g. components that are inputs in a process, but not an output in any process. If all inputs in an assembly are removed due to feature dependencies, the price of the output in that assembly will then be used, as it is now being printed.
Time	How long it takes to print or assemble this component in minutes. You should pick a base multiplier and use that for all times, e.g. picking 4 minutes and then making all components either 4, 8, 12, 16, 20, etc. minutes, as it will make the game's optimal machine count more precise.

Processes

Inputs	A list of component inputs to this process. Note that you can only use a component as an input in one process.
Output	The output component. Again only use a component as an output once. Exactly 1 process should have "Final" as its output, as this will be the final assembly step.

Hardware Designs

You can add a Design record to reference one or more hardware designs to be used for products of this type. You either specify a single hardware design, a list of designs, a list of designs with an unlock year or anything in between, e.g. Design [ "CellPhone"; [ "SmartPhone" ; 2000 ] ]

You can also limit which MeshObjects can be used in a HardwareDesign based on which features the product has. Just add one or more FeatureBinding records, containing a list formatted as [HardwareDesign, MeshObject, Feature].

Check out more here: Hardware Design

Example

Hardware	True
Manufacturing
	{
	Components
		[
			{
			Name 			Gyroscope
			Thumbnail		"AThumbnail.png"
			BuiltInThumbnail	Gyroscope
			Price			15
			Time			4
			DependsOn		"Motion detection"
			}
			{
			Name 			"Rumble unit"
			BuiltInThumbnail	Vibration
			Price			10
			Time			2
			DependsOn		"Vibration"
			}
			{
			Name 			Plastic
			BuiltInThumbnail	Plastic
			Price			5
			Time			2
			}
			{
			Name 			Board
			BuiltInThumbnail	PCB
			Price			5
			Time			4
			}
			{
			Name 			Joystick
			BuiltInThumbnail	Joystick
			Price			5
			Time			4
			}
			{
			Name 			"Drive bay"
			BuiltInThumbnail	Harddrive
			Price			10
			Time			4
			DependsOn		"External drive"
			}
			{
			Name 			Controller
			BuiltInThumbnail	Microchip
			Price			100
			Time			8
			}
			{
			Name 			Console
			BuiltInThumbnail	Console
			Price			50
			Time			8
			}
		]
	Processes
		[
			{
			Inputs	[ "Gyroscope"; "Rumble unit"; "Plastic" ]
			Output	Joystick
			}
			{
			Inputs	[ "Board"; "Drive bay"; "Controller" ]
			Output	Console
			}
			{
			Inputs	[ "Joystick"; "Console" ]
			Output	Final
			}
		]
	FinalTime	2
	Design		[ "CellPhone"; [ "SmartPhone" ; 2000 ] ]
	FeatureBinding	[ "CellPhone"; "Antenna"; "Networking" ]
	}

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:

Hello
Hi
Hello.
Hi.
Hello, you
Hi, you
Hello, you.
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

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.txt" file in the CompanyTypes folder, with a list of the company types you want to remove, separated by new line, eg.

Antivirus
Games
Office

Values

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.
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. 2 for computer OS, 3 for games.
Max	The maximum amount of companies of this type there has to be on the market at any given point in time. 2 for computer OS, 6 for games.
Frameworks	Whether this company will develop frameworks for their products, which can be licensed by the player and other companies.
Types	The types of products the company will release and how much effort they take(Chance). 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. You can define a category for each type, otherwise a random will be chosen from the categories available from the software type. You can also add the record Force True which will make the game force a product out immediately when the game starts, if possible, which is currently used to make sure there is an OS available on day 1.
Addons	Optional list of tables with Software, Addon and Chance records, which is this companies chance of developing the specified hardware add-on of the software type for another company's hardware product. Companies will by default create add-ons for their own products.
NameGen	Optional name generator to use, will use "Company" by default.

Examples

CompanyType
	{
	Specialization		"Creative tools"
	PerYear			0.2
	Min			4
	Max			8
	Types
		[
			{
			Software	"Audio Tool"
			Chance		1
			}
			{
			Software	"2D Editor"
			Chance		1
			}
			{
			Software	"3D Editor"
			Chance		1
			}
		]
	Addons
		[
			{
			Software	"Operating System"
			Addon		"Joystick"
			Chance		0.05
			}
		]
	}

CompanyType
	{
	Specialization		"Computer Operating Systems"
	PerYear			0.2
	Min			2
	Max			2
	Frameworks		False
	Types
		[
			{
			Software	"Operating System"
			Category	Computer
			Chance		1
			Force		True
			}
		]
	}

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:

Name	The personality's name as it appears in the game.
Traits	Should be either a good and a bad trait or a neutral trait. See traits below. E.g. [ WalkItOff ; SlowEater ] or [ Detached ]
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.

Traits

Good traits: FastLearner, Independant, BigBrain, Humble, Capacitor, WalkItOff, ThisIsFine, Skyscraper, Sunshine, RGBThumb
Bad traits: Stressed, Hypochondriac, SlowEater, NervousBladder, BumLeg, Forgetful, Cupholder, NeatFreak, SilentButDeadly, WalkInstead, UnderTheWeather, OldSole
Neutral traits: NightOwl, BornLeader, FirmwareInc, SuperFocus, Unphased, JustTheFlu, Detached, Watch
Traits that also work for the founder: FastLearner, BigBrain, RGBThumb, BornLeader, FirmwareInc, SuperFocus, BumLeg, Forgetful, Cupholder, Watch, SilentButDeadly, WalkInstead, OldSole, Capacitor, ThisIsFine, Sunshine, Skyscraper, Detached, NeatFreak, UnderTheWeather

Example

PersonalityGraph
	{
	Personalities
		[
			{
			Name		TestPersonality
			Traits		[ WalkItOff ; SlowEater ]
			Relationships
				{
				Extrovert		-0.5
				TestPersonality2	1
				}
			}
			{
			Name		TestPersonality2
			Traits		[ Detached ]
			}
		]
	Incompatibilities
		[
			[ TestPersonality; TestPersonality2 ]
			[ TestPersonality2; Introvert ]
		]
	}

Data Modding

Debugging console

Helpful commands

In-game content

Alpha 11 changes

Feature evolution

Why?

Moving forward

Software types

Overview

Elements

Example

SpecFeatures

Values

SubFeatures

Values

Level 3 features

Scope members

Networking

Script example

Software categories

Values

Add-ons

Values

Hardware

Manufacturing process

Components

Processes

Hardware Designs

Example

Name generators

Example

Company types

Removing companies

Values

Examples

Personalities

Elements

Personalities and incompatibilities

Traits

Example

Navigation menu

Search