Jump to content
XCOMUFO & Xenocide

People


dteviot

Recommended Posts

I think I've had this discussion before, but here's my thoughts on the matter.

 

There are two obvious ways of handling scientists (and engineeers.) One option is the X-COM 1 method, where they're identical and interchangable, and represented as nothing more than a counter in the base. e.g. Number of scientists. The other is the X-COM 3 way, where each scientist is a unique individual, like the soldiers.

 

My preference is the X-COM 3 way, for the following reasons.

  • Less work overall. As the individual person handing needs to be done for soldiers anyway, treating scientists as just a counter in the base would require different code from soldiers.
  • More flexible in the future, if we wish to give scientists different skill levels, or even want to send them on missions. (e.g. Deactivate the self destruct charge in a UFO, or pull the navigational/drive system from a crashed UFO.)

Note, while the scientists would be individuals, initially they would all have the same skill level. Variable skill levels is v1.0+ feature.

 

However, this approach does have one minor problem, in that assigning 100's of unique scientists to a project will be a bit of a pain, from a UI situation. My proposed solution to this would be copy X-COM 3, specifically we make scientists 10 times better, so you need (and can have) less of them. e.g.

  • Labs only hold 10 scientists, not 100.
  • Scientists cost 10 times as much (500k each instead of 50k)
  • Time to research projects is cut by 10.

I plan on starting work on this this weekend, so you have until then to give me feedback, or forever hold your piece.

Link to comment
Share on other sites

A scientist getting 500k a month? Man, I picked the right job... :D

 

Let me propose a different approach, just imagining, I have no clue if this would involve (too much) extra work or not. We keep the scientists as in UFO1 and 2. Adding them to a project can work in two ways: either add a certain number of random picked individuals, or add scientists via mark multiple scientists and drag&drop them to the project.

 

Another solution, which would (mainly) be a CT solution, (but I like it anyway... ;) ) would be putting together and assigning research teams with a special lead scientist - this would require an extra screen, so probably involves a lot of work, but would give a wonderful explanation for the wide bandwidth of the researchers skills, would minimize micromanagement and would still allow handling as individuals.

A v1 solution (if you don't want to invest a lot of work intoo this right now, but like the idea) for this could be that you buy already assembled research teams (10 scientists each), which are represented by their lead scientist. That would be pretty close to your idea, just giving it an explanation, and with the idea in mind to transform this into the proposed model later.

Link to comment
Share on other sites

A scientist getting 500k a month? Man, I picked the right job... :D

I doubt many would object to $50k/month either

Seriously, the funding numbers in X-Com are totally unrealistic. Aircraft missiles are in the hundreds of $k each.

I'm just trying to maintain the game balance.

Link to comment
Share on other sites

The only problem that I can think is that now adding an extra scientist can have a serious impact into the gameplay as you are adding in increments of 10... sometimes you cant handle 10 scientists but you can 5 (at least at the start of the game).

 

Greetings

Red Knight

Link to comment
Share on other sites

My opinion:

 

The counter idea is definitely the simplest one (Quote: Keep the design as simple as possible). BUT, this really kills modularity and the ability to add V1+ features, so... If you can think that a basic counter does the trick for now and change it in the future (maybe just before adding the Battlescape), I think it would be nice. I believe though that it will definitely lead to a case of development heck, so I think it should be scraped.

 

Having 100 individual scientists is a big no-no, management heck and kills the gameplay.

 

The idea of having "packs" of scientists (either 5 or 10, 5 sounds better) is far better. Just think of that (V1+): The "scientist teams" are generic research agents, they provide moderate research capabilities in any field. But, you can hire individual scientists who are more productive in a specific (or even more) fields, producing faster progress in those fields and lower in the other (in comparison with the individual members of the research team). Hire costs and salaries would also varry.

 

 

Conclusion: A 5-pack scientist group with a research head works best imo :)

In addition, monetary-wise, balance should be prefered to realism. Anyway, when you see an alien threat coming, would you "provide" a super-secret, super-advanced corporation only the pitiful sum of 500k?! Or 20k for the most advanced missile? xD

Link to comment
Share on other sites

My opinion:

 

The counter idea is definitely the simplest one (Quote: Keep the design as simple as possible). BUT, this really kills modularity and the ability to add V1+ features, so... If you can think that a basic counter does the trick for now and change it in the future (maybe just before adding the Battlescape), I think it would be nice. I believe though that it will definitely lead to a case of development heck, so I think it should be scraped.

The issue is, having a counter ISN'T the simplest approach from a coding viewpoint.

The simplest approach is having individual scientists. The reason being, we HAVE to have individual soldiers. So if we also have individual scientists, I can use the same code to manage purchase, sale, transfer, in use, etc.

If we use a counter, then I have to write one set of code for scientists, then a whole new set of code for soldiers later on.

 

Having 100 individual scientists is a big no-no, management heck and kills the gameplay.

 

The idea of having "packs" of scientists (either 5 or 10, 5 sounds better) is far better. Just think of that (V1+): The "scientist teams" are generic research agents, they provide moderate research capabilities in any field. But, you can hire individual scientists who are more productive in a specific (or even more) fields, producing faster progress in those fields and lower in the other (in comparison with the individual members of the research team). Hire costs and salaries would also varry.

 

 

Conclusion: A 5-pack scientist group with a research head works best imo :)

In addition, monetary-wise, balance should be prefered to realism. Anyway, when you see an alien threat coming, would you "provide" a super-secret, super-advanced corporation only the pitiful sum of 500k?! Or 20k for the most advanced missile? xD

 

Having "teams" might work. You could buy teams of 1, 5 or 10 scientists. With a different cost and productivity. And you assign in teams.

 

Thinking about it a bit more, we have "Scientist skill", and "Wage", so you can have:

1. lab technician: $50k month, 1 point/day output

2. scientist: $250k month, 5 points/day output

3. genius: $500k, 10 points/day output.

 

Not quite sure what the engineer ranks would be:

1. mechanic:

2. engineer

3. Scotty

4. McGyver?

 

So, phase one would be individual scientists, with a phase 2 of different skill levels/cost (if need is found.)

Link to comment
Share on other sites

I don't know what we would call the different levels of engineers as they have different groups, civil, chemical, computer etc etc.. maybe in the future we will need different types to build certain things..

 

levels of apprenticeship sound a little weird

 

apprentice engineer

journeyman engineer

master engineer

Link to comment
Share on other sites

Managing 100 entities that are sort of static is almost free except for the 1Kb of memory ;) ... with today machines and where that management is gonna take place, go for it... make them cloned individuals as the same algorithms will apply for management of all entities. More code = more complexity... go the simple route (individual entities) if we measure and the approach do not work... then we optimize in an optimization pass.

 

Greetings

Red Knight

Link to comment
Share on other sites

Not quite sure what the engineer ranks would be:

1. mechanic:

2. engineer

3. Scotty

4. McGyver?

 

So, phase one would be individual scientists, with a phase 2 of different skill levels/cost (if need is found.)

 

McGyver is better than Scotty? Heresy says I! Set your phasers on kill Mr. Spock! Engineers aren't just better mechanics anyway. You need both in the right ratio to make a (real) project work.

 

Here is another approach. Why treat sceintists as people? Why not treat them as items? We will have code to purchase, transfer and mark as in-use (assigned to a transport that is) for items as well. In fact leased planes effectively have a salary. So it seems like we could just treat them similarly to transports as easily as we could treat them as a type of soldier. That's the simplest method to my mind.

 

Perhaps items and people should stem from the same base class? Even soldiers?

 

 

On the other hand I am drawn towards the idea of adding more RPG type stats to the people in the game. There is a danger of making the geoscape a little too "fiddly" if we add to many stats though.

 

 

 

-D

Link to comment
Share on other sites

Managing 100 entities that are sort of static is almost free except for the 1Kb of memory ;) ... with today machines and where that management is gonna take place, go for it... make them cloned individuals as the same algorithms will apply for management of all entities. More code = more complexity... go the simple route (individual entities) if we measure and the approach do not work... then we optimize in an optimization pass.

 

Greetings

Red Knight

Huh? I'm not worried about the memory required having 100s of scientists. I'm worried about the UI for the player, if he wants to assign 200 scientists to a project, and he has to assign them individually to do so.

 

Here is another approach. Why treat sceintists as people? Why not treat them as items? We will have code to purchase, transfer and mark as in-use (assigned to a transport that is) for items as well. In fact leased planes effectively have a salary. So it seems like we could just treat them similarly to transports as easily as we could treat them as a type of soldier. That's the simplest method to my mind.

 

Perhaps items and people should stem from the same base class? Even soldiers?

That is exactly my plan. I use the item root for handing buy/sell/transfer/storage.

The issue is, I don't currently have to worry about "in use" items. They're not going to be in an outpost's inventory.

At current time, there's special case handling for craft, and all other items. I'm going to have to write special case for people. I don't want to write two sets of special case, one for scientists (and engineers) and another for soldiers.

Link to comment
Share on other sites

Managing 100 entities that are sort of static is almost free except for the 1Kb of memory ;) ... with today machines and where that management is gonna take place, go for it... make them cloned individuals as the same algorithms will apply for management of all entities. More code = more complexity... go the simple route (individual entities) if we measure and the approach do not work... then we optimize in an optimization pass.

 

Greetings

Red Knight

Huh? I'm not worried about the memory required having 100s of scientists. I'm worried about the UI for the player, if he wants to assign 200 scientists to a project, and he has to assign them individually to do so.

So why not have the scientists/engineers stored as individual entities internally, but the UI still show a counter like in X-Com 1? After all, if they're all gonna have the same skill in the beginning, I don't see the point in having the player select them individually. It's easier to rewrite the UI in the future than the underlying code. Edited by SupSuper
Link to comment
Share on other sites

So why not have the scientists/engineers stored as individual entities internally, but the UI still show a counter like in X-Com 1? After all, if they're all gonna have the same skill in the beginning, I don't see the point in having the player select them individually. It's easier to rewrite the UI in the future than the underlying code.

Excellent suggestion.

Link to comment
Share on other sites

×
×
  • Create New...