Torn Stars Meta Game

This topic is to discuss the design of the Torn Stars Meta game.

There are a few assumptions in the document (not linked here), that I should make clearer.

Hidden Operations exist because we need a stealth component for pirates and rebels. And because pirates and rebels are poor and cannot afford to build stations (that the Navy just pounds into dust in a few turns anyway).

There are hidden operations in the current Torn Stars release. All the fences and black markets exist because there is a hidden operation inside the station. When the player flys near the station, the hidden operation "wakes up" and creates the ships.


Fleet operations exist because tracking 2000+ warships in the game is just totally crazy. Instead, whole battle fleets get abstracted down to one Operation. If we had the source to Flux, we would model the ships. But we don't, so Fleet Operations are the easiest simplification.

You can already see what a fleet operation looks like. The customs patrols on the Lpoints are implemented as a fleet operation. The only difference, is that the current implementation is permanant. And the meta-game version could be destroyed.

I point these items out, so you can get a feel for what currently exists, and a little more of the why behind them.

Feel to offer comment on the document here. And offer changes or post questions.

I've begun some more formal design specification of the meta game and would like to give a brief, general idea of how I understand the design document along with some inital thoughts on implementation. Any and all comments are welcome.

Meta Game
The meta game is played out on an abstract game board. The smallest unit is a location, corresponding to a "square" (or maybe hexagon) on a physical game board. The actors are all AI and the game-pieces are Operations. Each type of actor has a set of pieces with unique rules for every piece. When an AI decides to move a particular piece, the likelyhood of certain traffic scripts, at the location the piece is moved into, is increased. The interaction between traffic, player and meta game is primarily through missions and resource expenditure (I'm assuming that if the Fleet Operation is generated using a traffic script, the corresponding resources will be deducted from the Fleet if a ship is destroyed).

Each actor has specified goals, sometimes conflicting with other actors' goals. This leads to conflict and the AI must decide if the potential benefits of a certain play outweigh the risks.

Thoughts
I would suggest that Operations are more like cards in a typical CCG (collectible card-game for the uninitiated), some generate resources, some are used to attack opponents, some have special effects and so forth. I'm working along a slightly different design path where the differences are mainly conceptual but more directly correspond to the implementation I'm considering. The first and main difference I'm suggesting is using segment-based time. A certain action takes a particular number of abstract time segments, and during this time a certain number of sub-actions are completed every few segments. This means the position and current state of any particular operation can be easily extrapolated. I'm suggesting a lazy approach, where the details of a particular operation aren't generated at all until the player actually interacts with it. Once something is generated, however, it is persistent. So, if the player sees the cruiser "Agamemnon", or whatever, in a particular fleet that ship will be present the next time the player encounters that fleet. Note that we do not have to track that cruiser, we can extrapolate where it went the next time the same faction has a fleet that the player sees. With a not-too-complex mathematical model this can be very fast. This approach also allows for specific resources to be linked to an actual trade-route (if we later want a much more dynamic and pervasive environment and real-time, in-game economic interaction between actors through trade etc, ie full alife).

Edit
The purpose of segmenting time is synchronization between meta game tasks. The standard game day of 4 hours is too long, but the four hour cycle of a day is a very good timespan for larger scale events (particularily campaign events). Doing synchronization on entry/exit is too irregular, since the player can be sitting ontop of an asteroid in an almost empty system, waiting for a smuggler etc. However, the AI will be reactive, since I'm keeping the door open for full alife, meaning that it selects new actions only after recieving feedback from previous actions. Only a fixed number of actions will be active at once (simulating the administrative capacity of a faction--which a faction might even be able to spend resources to increase). So the synchronization isn't done at regular intervals, but at predictable intervals! (A simpler example is the old Amiga game Battletech/Mechforce, with only two actions and more limited types of actions)
End.

All this will require a certain degree of mathematical modelling. I want to use two particular approaches; systems of linear equations (for the extrapolation bit) and boosted ensamble learning (specifically, boosted ID3 decision-tree stumps, which is a modern approach to GOFAI expert systems). Both are very fast on any computer with a fpu (ie 386DX and up). Also, a lazy approach means that the calculations only have to be completed at periodic intervals. However, POG may place additional limitations on what is fast or not. Note that I said learning, although initially the actual experience the AI will gain will be limited. Future developments might enable a much more complete learning implementation (I have some experience with learning intelligent agents, although limited to non-commercial applications).

I'm using a sort of classical design principle that at least I call an Abstract State Model, something they hammered into my head during my days studying computing science. I realise this might sound overly ambitious, but what are your thoughts?

Hmmm. I might have given some misleading information. Let’s make sure our game model is the same before going too far into the design.

A Location (which is called a “Center� in the code) is a Sim of type T_Station or T_Lpoint.

Stations are the same as operations, they just happen to have a Sim that is also a Location.

Operations come in two flavors: Hidden Operation that exist inside stations. And Fleet operations that exist in orbit around stations.

Stations and Operations are built by factions. They earn and spend money. And they have an inventory of ships and supplies to use in fighting.

If thinking about this as a RTS then the Stations and Operations are the buildings. They get purchased by the faction. They repair themselves. Some earn funds. Some can build and launch units.

Traffic Scripts such as those seen flying around in the PS game are closely related to the meta-game concept Actions.

Actions are purchased by Stations and Operations and draw fleet resources from those Stations and Operations. An Action can travel between stations. This is how stations attack each other.

(So a Traffic Script would never spawn a fleet operation. It would always be the other way around. Operations launch actions).

An Action does not have to be combat oriented. An Action might be diplomatic in nature. Or be the moving of a station component to help build a station.

An Action is the smallest thing modeled. The meta-game does not envision modeling individual ships. A smuggler or trade ship would not get modeled (we don’t go down to that level of detail). But an Action that happens near a player might get turned into a fleet of ships.

Simplicity is the primary reason for this structure.

A very simple AI can exist for a station (or operation) that chooses actions based on nearby friendly/hostile stations. A faction AI does not need to pick actions (done at the station level) it can focus instead on selecting which stations and operations to build, and where (essentially doing the strategic planning).

Let me describe what was done prior for Actions, since I have not sent over any of that code.

Actions are persistent state tasks. Each Action has a target location. They get placed into a List at that location. If the player arrives, the Action is woken. It checks to see if it needs to do anything (like create a battle fleet and attack that station that day). If not, it goes back to sleep. If it does, then it creates the ships or items needed and (typically) starts a traffic script.

Actions also have an update function. If the player never shows up, the Action times out and just executes a “background� version of itself. It might compare fleet strengths and then destroy some ships or something like that.

Traffic Scripts that just represent “busyness� don’t need actions behind them. Standard trade and taxis and flitters can all just float around stations without needing to represent AI entities. They can just be created based on the current health of the station (or operation).

Hopefully this helps make the meta-game as envisioned clearer. Is this making more sense? Is this how you were reading the document?

Are you still thinking of Operations as cards, or would it be Actions as cards? Or maybe we could switch to a RTS analogy?

Ah, yes, I certainly had interpreted some things differently. Most of the terms Operation, Location, Action and Station I had mixed up.

From an advanced AI perspective, the semantics of these non-atomic entities (ie stations being operations and coincidentally locations, operations containing operations) will be a complication, although certainly not an insurmountable one.

Actions are atomic, then, not operations. That makes more sense, don't know why I read it the other way.

So Actions increase the likelyhood of a particular traffic script. I formulated the bit about traffic-scripts really poorly, what it should have said was "if an attack action is rendered by a traffic script". And since the Operation resources are already spent I realise that entire paragraph was kind of irrelevant....

What I'm after is modelling Actions moving through systems with a minimum of continous computation--or at least writing code that is easily reused in such an implementation. Ie, the player can intercept a station part moving from one system to another in a third system that is just a waypoint--even if the fleet wasn't rendered in the originating system so that the player can pursue it. All without having to actually create and destroy the Actions in the list as it passes each system (esp if the player isn't even close). Like this: At time X, Operation A launches an action, with target B. Reaching B takes a certain amount of time, Y. A new event is scheduled for time X+Y. Meanwhile, nothing happens. If the player passes the path of the action, an interrupt event is scheduled and the details of the action are extrapolated. If the player never sees any part of the action, it's resolved schematically in some fashion (probabilities of some kind, whatever we want). That's the lazy bit I ranted about. This means that maybe not the only, but at least one of few continously running parts of the meta-game is the interrupt scheduler. Again, I'm trying to keep future developments in mind and write reusable code--all this would certainly not be present in a first implementation!

What I'm suggesting, at least for a future implementation, is a scheme where actual ships (traders, smugglers) aren't explicitly modelled, they are calculated only when the player have an interest in them. Esentially, it could be only a name for a pilot or ship, or a particular cargo canister etc. It would only be created if the player targets a vessel or subsystem and waits for the hud-display to actually display that information. The only use for it, initially, is immersiveness and pervasiveness. However, it's only really viable if all traffic results from actions, since that's where we would extrapolate information about the particular feature.

I was thinking that the standard mode would be to do the "background" versions of actions, and only render the actions if the player is close by (this is really a matter of semantics, the implementation would be essentially the same, unless we use my proposed segmentation scheme in which case the Action wouldn't be waiting at all).

Have I understood it correctly, then, that jumping random traders close to L-Points won't actually have an impact on the faction that owns the ship and the cargo? I mean economically--they might still get mad at me since my faction standing is reduced, but they won't lose those resources? Standard trade and taxis have no connection to the AI and meta game, other than as a rendition of the faction's current state, etc? I had envisioned that ALL traffic was the result of actions of some type (trade actions, etc). If all ships have a purpose, the game would seem much more alive, IMO.

Hopefully this helps make the meta-game as envisioned clearer. Is this making more sense? Is this how you were reading the document?

Are you still thinking of Operations as cards, or would it be Actions as cards? Or maybe we could switch to a RTS analogy?

Certainly, I understand much better now. As for the analogies, I don't really have a preference, as long as we're using the same analogy. A good analogy can cross-fertilise (that's an HCI expression, I think it sounds plain weird in this context) the project, and I think RTS games contain many interesting features that when envisioned as an abstraction can lead to surprising new concepts.

(The Card analogy was my attempt to sort out the operation-location-station thing, had completely misunderstood Actions)

I think we are, more or less, working on the same idea. Actions represent “ships in motion� and are only rendered when the player is nearby or somehow interacts. They are rendered by creating Traffic Scripts to represent them. Or, if no player ends up near, they resolve schematically.

Please explain more about the segmentation scheme and interpolating the actions position. I though I understood, but now I am sure I don’t understand at all. Where are the actions stored? How can you calculate the position? Must every action be examined by the interrupt handler over and over?

Trade, Taxis, Station guards. The main reason these are not actions is that we would need many, many actions. There are as many as a 1000 stations. Add operations. And then you start needing +10,000 actions. I believe this would be outside of our resource capacity. StarShatter does this, but uses native code not a byte language. And it has real objects.

I was still planning on linking the traffic into the meta-game. If you wipe out station guards, they will need to grow back. If you destroy freighters leaving a station, the station inventory profits take a hit. This allows us to let the player have the same impact that the background running actions do. But without nearly so much over head. The actions never even get generated if the player is not nearby.

In the long term, it would be fun to have a true ALife simulation, where each ship (or fleet group or something) was unique and modeled. I think it could be done in POG. But it would require totally changing the economy and all other aspects of Torn Stars.

So what I think we should do is just enough work to get the meta-game running. By then another year will have passed and perhaps some other 3D engine will exist that allows C++ extensions. Given that Jasper has created the tools to allow Iwar models to be taken out of the game, it is possible Vega strike or something could be converted. But that is talk for another winter.

Oh, one last bit worth discussing: Real time versus Dramatic time. One issue that is not clear during design, but is clear when playing is that nothing ever happens near the player. A combat in Iwar is very quick – far less than a four hour day. And so conflicts are almost never visible. And the rates of traffic the player currently sees in the game, will never happen. So I think actions should run on Dramatic Time. The idea is an Action gets scheduled to happen sometime during a week. And if the player arrives on any day that week, the Action is resolved.

This plays total hell with real time movement and so forth, but it makes for a much more interesting world. Now, the game SpaceRangers solved this a different way. Movement and combat are super slow in SpaceRangers. Shooting your weapon once takes a whole day. Battles last for months. But Real Time is preserved. I like Dramatic Time better. But glad to discuss the idea.

During the coding of Unstable Space I have been pondering the Meta Game design. I think the meta game can be made simpler and at the same time get richer in effect.

The prior idea, in short, had Factions building Stations and Operations (Producers). Those producers took Actions (basically weapon shots) at each other.

Actions were meant to be missions that the player could perform. They would let the player “get involved� in the conflict between factions.

But if the player can attack and destroy stations and operations, then the player can be involved in the conflict. And Actions just add a whole layer of complexity.

A simplification is to get rid of actions completely. In the new design Factions build Stations. Stations build Operations. Operations move around the cluster.

Here is an example. The Gargoyle Pirate Clan builds a new station. Once that station is built, the station starts to build Operations. It first builds a Protection Racket operation to extort nearby commercial stations.

The Protection Racket Operation can move from station to station. It moves to one station for a month or so. Then it moves to another station. If the player visits a station with the Protection Racket, the player gets charged a fee to visit the station. In this way, the Operation is impacting the player. If the player owns a mining station nearby, the Protection Racket might settle on the players station and start charging him money not to destroy things.

The player can impact the Operation by destroying the command ship that is the center of the operation. An operation might be made of one ship, or several ships. But if the command ship is destroyed, the operation stops existing. (this is a trivial few lines of code in the command ships Death Script)

So this is how the player can change the nature and makeup of the cluster that is around him, by destroying the operations, and possibly stations.

At first, it seemed like this would be giving up support for missions. But instead, missions can now involve attacking or protecting operations and stations. Because operations can spawn fairly often (as opposed to stations) they make a rich set of targets for missions.

And because we have tossed Actions and all the resources they consume, we might be able to code a fair amount of detail into Operations. They could essentially become real fleets. They move to shipyards to repair. They can find fuel depots to refuel. They flee when damaged. They move to nearby lpoints to extort shipping.

Joco has some really great code that creates lists of ships out of a simple force value. Since most Operations will never encounter the player, they will never become a resource hogging ship model. They will live and die as a few virtual bytes. But when a player does show up, they can be quickly turned into a fleet of real life ships. Almost exactly what happens in the game now, when the player encounters a Pirate Toll at an Lpoint.

More examples, just to get down these thoughts. If the Navy wanted to take out a pirate base, in the prior design it would have moved a Fleet Attack Operation into the same system as the pirates. The Fleet Attack Operation would have generated Actions to send ships to attack the pirate base. And the player could take those missions.

In the new design, the Fleet Attack Operation would be a fleet of ships. It would move into orbit around the pirate base. For the next few days, it would “attack� the pirate base. If the player shows up during that week, they get to help out with the fighting. (on any side they pick).

If the player does show up, joins the fight, and the command ship is destroyed, the Fleet Attack Operation would be destroyed. If the command ship flees to another station, the Operation is moved to that station (and would be there when the player visits later).

Hooking into missions might work like this: During the week the Attack Operation is near the pirate base, the player could get a pirate mission to defend the base. The player could also take a navy mission to destroy the station. A mission generator would have a fairly easy time noticing the hostile operation in orbit around the station and generating the missions.