Laboratories

[MadRat]

It's a regular monthly topic to do some sort research tree, and prerequisites to build one unit before others are possible. But perhaps these two ideas should be separated to make each one possible.

As it sits there are three types of units; factories, mobiles units, and buildings. To set prereqs right now you need a needlessly complex and thorough knowledge of calls in the cob file strucutre, something few people understand at the moment. It would almost make more sense to create a fourth dimension to units, and that would be to add laboratories, in order to make this more user freindly.

Like factories, the laboratories would need a menu. Instead of having units to build the laboratories should instead offer technologies. A simple build pic of the technology would represent the possible tech to research. Energy and/or metals could be consumed, along with buildtime, in order to complete research. Heck, even a research rate variable using existing buildtime and buildrate variables would keep it simple enough.

The advantage to this setup is that it doesn't require extensive rewrites of existing code, but rather only requires a new laboratory branch in the slow update loop. A single monolithic file, like the sidedata.tdf for unit creation, would be necessary to control the technology trees. So in effect, code used for factories could be recycled for laboratories. The proverbial techdata.tdf so to speak would contain data in a simple format:

Code: Select all

[%LaboratoryName%]
{
Techname1=%TechnologyName7%;
          {
          Buildtime=1000; //in tradition buildtime units format
          Prerequisite1=%TechnologyName1%;
          Prerequisite2=%TechnologyName2%;
          Prerequisite3=%TechnologyName3%;
          }
Techname2=%TechnologyName8%;
          {
          Buildtime=1000; //in tradition buildtime units format
          Prerequisite1=%TechnologyName4%;
          Prerequisite2=%TechnologyName5%;
          Prerequisite3=%TechnologyName6%;
          }
}

You shouldn't need more than four or eight prerequisites per technology. In game the cob files could be used to detect technology changes. This way you would script new weapons, abilities, etc. for a unit depending on the tech changes. Your biggest change in the code then would be to read technology variables using a call from a cob file. A cob file could look like this:

Code: Select all

[techtree]
     If (%TechnologyName% = TRUE)
          {
          //Do this
          }

No huge rewrites of code for doing research junk. No massive reorgs of current mods would be needed. But this system would make mod writing for unit upgrades more straightforward.

The end game would be to eventually allow build menues to also use the technologies in order to set prerequisites for unit production. But because it could be done separate to this the two ideas do not need to happen simultaneously. If someone got ambitious to do the second step then they would already have the avenue open to them to eventually tie tech improvement in with both factory build menues and sidedata.tdf, giving everyone what they've been asking for on the whole 'research' idea.

Just my 2 cent compromise on the topic.

[KDR_11k]

You can be pretty damn sure people will want that functionality to be combinable with factories within five minutes so better plan for it right away.

The other problem is that COB files CANNOT say if (%TECHNAME% == TRUE) because they don't know strings beyond function names. There's no sane way to map those strings to get constants unless you want to give each research an id number and check that. At that point I'd rather say abandon the separate lab idea and just give us our frigging shared variables for COB scripts and possibly UI script hooks and we'll implement our own system that doesn't involve introducing new unit classes.

[Pxtl]

You can be pretty damn sure people will want that functionality to be combinable with factories within five minutes so better plan for it right away.

The other problem is that COB files CANNOT say if (%TECHNAME% == TRUE) because they don't know strings beyond function names. There's no sane way to map those strings to get constants unless you want to give each research an id number and check that. At that point I'd rather say abandon the separate lab idea and just give us our frigging shared variables for COB scripts and possibly UI script hooks and we'll implement our own system that doesn't involve introducing new unit classes.

There are no strings in COB? Seriously? None?

The problem is that every solution runs into the limitations of COB and the unit-centric nature of the programming. In a modern language, you'd simply have a hashtable of objects attached to the player/team object, and have changes to these objects fire events. On an upgrade, a change would be made to that hashtable, which would fire an event on the individual units (or unit-classes) that are have subscribed to that upgrade (factories, etc.). I can definitely see the appeal of OSSRTS using a DotNet solution.

[KDR_11k]

That's the reason they're working on a Lua interface. I don't think .Net would be a good idea for an opensource multiplatform game.

[zwzsg]

The only BOS/COB command that uses string is the play-sound one. Would be nice to extend the BOS/COB language a bit, to add a couple new commands, but then we'd need to have a new BOS->COB compiler, and so far no one wants to modify Scriptor source, (nor write a new one from scratch).


As for the initial post, well, I'd rather have mobile units, factories, and buildings (?? I'd though buildings and factories were the same) merged into a single type than having a fourth (third?) kind created. I don't see why the upgrade needs to be hard coded to be only builable by a special kind of unit called "laboratories", what's wrong with letting upgrade be built by regular factories and mobile construction units? I mean, it's the upgrade that needs to be a special kind of category, but what builds the upgrade doesn't matter. Also, you forgot the metal and energy cost.

[Dragon45]

Mono if you really are looking for something in that vein.

But really, a suitable, powerful scripting language doesn't have to be a fully featured programming anything like .NET or Java or Mono or something... as long as its Turing complete, it should be fine to do stuff in.