No limit tech tree?

No limit tech tree?

Discuss game development here, from a distinct game project to an accessible third-party mutator, down to the interaction and design of individual units if you like.

Moderator: Moderators

Post Reply
User avatar
bobthedinosaur
Blood & Steel Developer
Posts: 2700
Joined: 25 Aug 2004, 13:31

No limit tech tree?

Post by bobthedinosaur »

I'm kind of floating around the idea of a little concept game that uses scripts to create tech levels that have no upward limit. The idea being that units in each higher tech level becoming exponentially more expensive, as they get more DPS, HP, range etc. While resource gathering units would also get exponentially more resources.

Setting up a simple place holder game with only a few units that visually don't appear to change with each tech level while the unit stats do will not be as hard as trying to figure out balance of input vs output or cost/ reward.

I'm thinking maybe at x3 per level cost (assuming leveling up is controlled by price of the factory EG TA style) you would get anywhere from a 1.25 to 2.5 return on particular characteristics (ie manuverability increase less than weapon range increases, which less than DPS, which is less than HP). For resources maybe x2.5 mex or energy production increase, which allows for an increased difficulty in tech stepping as it is slower than the cost of the next level.

I'm wondering if anyone else has input on strategies or cost reward ratios for a ridiculous tech ladder system?


Obviously with a script controlled tech level you wont have alot of variety or unique units for niche roles, but this is more of a plan to see how such a game would play out.

On another note I'm thinking such a game would have no stationary defensive units, and require mobile units to fufill that role, so that tech turtling does become a black hole. maybe that is not necessary if other mechanics could discourage it?
User avatar
Silentwings
Posts: 3720
Joined: 25 Oct 2008, 00:23

Re: No limit tech tree?

Post by Silentwings »

You'd need the number of available unit types to be finite, but it could be made large enough that in practice no one would ever reach the top of your tech tree.

It wouldn't be hard to generate unit defs iteratively with unitdefs_post, although I'm not sure how you'd procedurally generate different models (if you wanted them as well).

Could be fun to add a bit of randomness into how the tech levels develop - reminds me of a half baked mutator I once wrote that hacks into defs.lua, reads in the unit/weapon defs of a game, fits a simple statistical model to them, and then resamples them randomly on each run...
User avatar
bobthedinosaur
Blood & Steel Developer
Posts: 2700
Joined: 25 Aug 2004, 13:31

Re: No limit tech tree?

Post by bobthedinosaur »

Ah yes. The unitdef limit would indeed require an upper end. okay maybe instead of open it would have an upper limit, and since the cost increase exponentially than a practical tech level maximum could be calculated. Players wont be running up a tech tree for more than a couple hours. How long do some of the really long games last?

Anyways, this mutator you mentioned randomized weapons and unit characteristics per each game?? That's sounds similar to what godde was asking for some time ago, about a game where unit characteristics are not consistent from game to game so simple counters and tactics would not be universal and would have to be learned with each new game.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: No limit tech tree?

Post by gajop »

You don't *have* to rely on unitdefs, as you can still change unit properties via LuaRules and adjust the UI to accommodate.
The spaceship in Area17 that we made had just one unitdef, but you could still upgrade its properties (hp, shields, anti missile lasers, weapons, drones, etc.). Easily enough you can make higher tier units contain the appropriate properties.
User avatar
bobthedinosaur
Blood & Steel Developer
Posts: 2700
Joined: 25 Aug 2004, 13:31

Re: No limit tech tree?

Post by bobthedinosaur »

right. But if you are modifying the unitdef via lua rules to simulate upper tier units, would that affect all units with that unit def or only specific ones?

for example player 1 and 3 both have the same race so if player 1 builder an upper tier version of on units that require modification would that also affect player 3's? or if player 1 has a ton of older lower tier units lying around would building a new tier force the older lower tier 1 to become upgraded when the lua rules adjusts the unitdefs for the new upper tier (which may not be part of the game design)?
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: No limit tech tree?

Post by gajop »

I'm saying that you should have only one set of constant unitdefs, and simply change the actual unit (instance) properties via Spring.SetUnit* functions. You can do almost anything with it.
Changing the unitdefs directly while the game is running is not supported (it *might* work but I've no idea if or how it would sync).
Google_Frog
Moderator
Posts: 2464
Joined: 12 Oct 2007, 09:24

Re: No limit tech tree?

Post by Google_Frog »

Make a base unitDef for each type of unit and then scale its stats based on its level. All units of the same type would have the same underlying unitDefID but be scaled ingame individually in UnitCreated.

I know for certain that you can change:
  • Health
  • Speed
  • Reload Time
  • Build Speed
  • Metal extraction rate (at least, you could a few years ago, I have not used extraction in a while)
  • Sensor range (los, aLOS, sonar, jamming)
  • Unit costs
ZK has a gadget which can change a lot of the above in a fairly generic way. It handles a bunch of weird behaviour and edge cases to do with reload time and speed. These edge cases are mostly to do with 0 speed or reload speed though so you probably don't need them.

Since 101.0 you can change:
  • Weapon Damages
  • Mass
You can modify basically anything on the fly if you reimplement it in lua. I recommend against using Spring.SetUnitResourcing to change the resource drain/production of a unit because I recall getting weird behaviour out of it. I think the lua function sets resourcing in addition to the unitDef derived resourcing. Perhaps you would be able to get it to work but I just ended up reimplementing resource production in lua.
gajop
Moderator
Posts: 3051
Joined: 05 Aug 2009, 20:42

Re: No limit tech tree?

Post by gajop »

Just so you're not confused, I was saying the same thing that GoogleFrog explained in much finer detail.
To add on that, you can represent different unit tiers via unit rule params, so luaui can see it too.
I'm not sure if you can use different models, but unit shaders might allow you to do custom appearance as well. There are probably limits to this though and might require drastic changes to the shader framework if you were to use it (which I think should be done anyway, regardless of this project).


Lastly, some useful ways of modifying unit attributes can be found in a ZK's gadget: https://github.com/ZeroK-RTS/Zero-K/blo ... ibutes.lua
User avatar
bobthedinosaur
Blood & Steel Developer
Posts: 2700
Joined: 25 Aug 2004, 13:31

Re: No limit tech tree?

Post by bobthedinosaur »

you can control metal, energy cost, and build time also on the fly?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: No limit tech tree?

Post by smoth »

Concerns:
  • People who split their upgrades could be fucked over
  • If you upgrade the wrong type of unit
  • if you can hide back upgrade unharrassed and then roll out with massively OP units that few things can touch
  • once people figure out the unit that upgrades to be the best with minimal skill to use your game will be over. no variety same thing over and over.
  • slippery slope.
these are concerns off the top of my head.
bobthedinosaur wrote:you can control metal, energy cost, and build time also on the fly?
I have my own economy. your economy can be whatever you want with unit costs being controlled by lua
8611z
Posts: 169
Joined: 08 Jul 2015, 20:20

Re: No limit tech tree?

Post by 8611z »

Stuff done in the def files or def's _post.lua file = the changes are applied to all units of that unittype
Functions like Spring.SetUnitMaxHealth() = change is only applied to that one unit
bobthedinosaur wrote:you can control metal, energy cost, and build time also on the fly?
Spring.SetUnitCosts of https://springrts.com/wiki/Lua_SyncedCtrl#Unit_Control looks promising.

Beside the properties of units that can be changed by calling a function (like Spring.SetUnitMaxHealth() etc) one should not forget the properties of whatever new stuff a script added.
If there is cluster-weapon-script then you could upgrade the amount of submunition-projectiles that comes out of the main-bomb.
If there is a units-on-fire-script then you could have an upgrade that makes units immune to burning.
If there is a units-can-jump script you could make an upgrade that gives longer jump-range or allows to double-jump. (jump again mid-jump in air)
If there is terraform then that could require unlocking.
(...)
Setting up a simple place holder game with only a few units that visually don't appear to change with each tech level while the unit stats do will not be as hard as trying to figure out balance of input vs output or cost/ reward.
I feel when upgrades and changing stats play such an important role, then having them reflected visually would be important to understand what is going on.
a game where unit characteristics are not consistent from game to game so simple counters and tactics would not be universal and would have to be learned with each new game
Many games are 'figured out' but are still fun to play.
RTS games contain lots of numbers and numbers are boring. Luckily after a while one does not need to look at the resource numbers anymore or check how much hitpoints a unit has - You get a feel for it.
Discovering a new game is fun but only if it is really something new to discover. Randomly changed numbers do not seem fun, more cumbersome and it might not even change the playstyle that much. If a game is decided because "Oh, I did not notice today those tanks can shot so far" is not interesting.

What might be fun is maybe a bit the opposite: Randomly removing units from the game. zero-K had a "raider weekend" with turrets disabled.
There are the popular "no-metal" maps that basically remove the metal-extractor and play totally different. That could be taken some step further, TA-mods have hundreds of units. Even with random selection of 50% units disabled the game would stil be playable. The units are still the same (so there is no boring comparing of numbers) but it would still give the challenge that each match you have to totally re-think how to play.
User avatar
PicassoCT
Journeywar Developer & Mapper
Posts: 10450
Joined: 24 Jan 2006, 21:12

Re: No limit tech tree?

Post by PicassoCT »

Silentwings wrote:
It wouldn't be hard to generate unit defs iteratively with unitdefs_post, although I'm not sure how you'd procedurally generate different models (if you wanted them as well).
PieceLego? SetPieceHierarchy?
User avatar
bobthedinosaur
Blood & Steel Developer
Posts: 2700
Joined: 25 Aug 2004, 13:31

Re: No limit tech tree?

Post by bobthedinosaur »

Alright guys now aside from the technical aspect which I see is very open, so lets get back to design philosophy.

Smoth expressed concern with an unbalanced OP in leveling. could there be a way to balance leveling? Smoth, are you implying that a sinle tech level game has the best balance system? Leveling doesn't have to be a krogoth at level 3. maybe krogoths are level 8 and there is much between the pewee/AK and the krogoth?


Also the randomly generated stats thing would be absurdly difficult to pull off. but a system that allowed for players to recognize quickly and not be completely randomized, (maybe more of a set number of predefined planned out balanced state that could rotate?) may be better. for example recognize maybe a dozen differnt unit groups that could be randomly remoze from a list but still allow game play to occur with out major missing unit counters balances.

bed time
Post Reply

Return to “Game Development”