Opened 12 years ago
Last modified 8 years ago
#1358 closed enhancement
Extend technology manager for template data — at Version 5
Reported by: | historic_bruno | Owned by: | |
---|---|---|---|
Priority: | Must Have | Milestone: | Alpha 11 |
Component: | UI & Simulation | Keywords: | patch |
Cc: | Jonathan Waller | Patch: |
Description (last modified by )
The new tech system currently supports applying stat modifications to existing entities. But we often need the stats prior to creating the entity, for information/UI or e.g. using costs to calculate if we have sufficient resources to create the entity.
See below for discussion.
Change History (5)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
Milestone: | Alpha 10 → Alpha 11 |
---|
Had some discussion about this in IRC today. To summarize what is by no means a consensus:
- There are three separate areas that need access to tech-related data: simulation, GUI, and AIs:
- simulation just needs to use modified entity stats after techs are applied, the current design allows for this
- the GUI needs to reflect which techs are researchable and when things are unlocked, the current design achieves this
- the GUI also needs to know updated stats for trainable and buildable templates, which is currently lacking
- the AI also needs to know about techs, unlocking, and modified stats, but unlike the GUI, it doesn't have GUIInterface (only a simulation state proxy updated each turn)
- We shouldn't arbitrarily limit which stats GUI and AI have access to, that complicates modding
Proposed design:
- Factor out the actual tech modification code from TechnologyManager into a new global script accessible by simulation, GUI, and AI
- The GUI and AI get a list of all entity and tech template data at the start of the game
- Each turn they get an updated list of researched techs for each(?) player. The AI might also have use for
TechnologyModification
and/orTechnologyResearched
events. - In the global tech script will be some logic that takes as input:
- all tech template data
- a list of techs researched by each(?) player
- a player id (who would own the entity)
- an entity template (of the entity to be affected)
- a property name (of the modification type to look for)
- It returns the possibly modified value of the property given those inputs
- The function call might look like:
var healHP = GetModifiedAttribute(g_Templates, g_TechData, techsForCurrentTurn, playerID, templateName, "Heal/HP");
- The simulation may handle it slightly differently
That design helps to minimize the amount of data computed each turn and tech modifications are only accessed on demand, instead of being "pushed" into the GUI/AIs. It also naturally preserves the original template data, so we don't need separate functions to access base vs. bonused stats.
I think we can make due without this until Alpha 11. More discussion is warranted.
comment:3 by , 12 years ago
Description: | modified (diff) |
---|
comment:4 by , 12 years ago
Priority: | Should Have → Must Have |
---|
comment:5 by , 12 years ago
Description: | modified (diff) |
---|
Agreed. The current system, while working, is limited. By default, accessing something like
this.entity.template.max_health
should already be stat modified.I think the following names would make the most sense:
The other thing too... the tech engine doesn't support entities with an ID of -1. So when you contruct a farm, the entity id is -1 for some reason. As a result, when the farm finishes constructing, you can't add techs to it or it'll barf, so any max health increases won't work as intended :-( I found this out trying to increase farms max produce.