Author Topic: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line  (Read 143562 times)

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #25 on: November 09, 2015, 10:25:26 AM »
This is something I've considered at it makes sense. While the current UI and placement code looks at them as separate objects, the internal code sees it as a single structure with just a specific type of direction.

Adding this in would be fairly simple and would actually reduce the complexity of the connectedness algorithm (instead of checking for tube direction, it just checks to see if a tube is present).

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1013
Re: OutpostHD - An Outpost Redesign
« Reply #26 on: November 11, 2015, 04:54:24 AM »
Leeor,

This is a great project!. I really enjoyed Outpost back in the day, despite the difficult user interface. Curious on a couple of graphics related questions since you are planning to move away from the original game's graphics. I gathered 2D graphics, 32bit PNG arranged on sprite sheets.

Are you planning to stick with ISO view?

Are you planning on drawing multiple textures per tile (IE a ground texture with a building texture on top), or only drawing one texture per tile?

Are you planning on having any animated tiles? If so, will the animation just sequence through several PNG tiles from a sprite sheet?

-Brett

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: OutpostHD - An Outpost Redesign
« Reply #27 on: November 11, 2015, 02:25:02 PM »
For simulating the population as a whole, rather than every individual, you can use the model from Outpost 2 as a reference:
Population Model

Your population takes 3 values (number of workers, kids, and scientists).
Population growth takes 3 values (growth progress of workers, kids, and scientists).
Population death takes 3 values (death progress of workers, kids, and scientists).

When growth or death progress reaches a certain threshold, you gain or lose a colonist, with the remainder being saved for the next round. The threshold is affected by med centers and morale.

There are a few rules added to the mix, which adds some interesting asymmetry. Kids have double the death rate, you don't get new kids if they outnumber the adults, and scientists contribute half as much to procreation. A single active nursery is required for kids to grow, and also acts like a med center with a capacity of 40 for kids only (same as an unupgraded med center, which helps all population components), a single active university is required for kids to be trained into workers, and workers require manual training to become scientists.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #28 on: November 11, 2015, 03:33:26 PM »
@Hooman

That actually breaks things down much more easily for me and I now have the forumlation for a simple mathmatical approach. My math isn't particularly strong so I imagine it would be very easy to figure out a pattern and develop strategies to take advantage of any weaknesses in the math.

I suppose over time it can be improved but it would certainly work better (I think) than my initial thinking.

@Vagabond

Quote from: Vagabond
Are you planning to stick with ISO view?

Yes.

Quote from: Vagabond
Are you planning on drawing multiple textures per tile (IE a ground texture with a building texture on top), or only drawing one texture per tile?

?

It's already being drawn as separate 'textures'. As the engine loops through each tile its' drawing, it first draws the ground 'tile' and then any structures or visible elements on top. Next tile, rinse, repeat.

Doing it any other way seems awfully inefficient.

Quote from: Vagabond
Are you planning on having any animated tiles? If so, will the animation just sequence through several PNG tiles from a sprite sheet?

Already using the animations from the original game. It's kind of a pain to convert from the resource files and placement to a more modern format. My sprite implementation is a little naive and perhaps a bit wasteful (each frame shows the entire sprite vs. having the sprite with any changes drawn on top).

And yes, that's basically what it does. The sprites just grab chunks off a sprite sheet and draw that. The animation is laid out from right to left, top to bottom in the sprite sheets but it's not required to be done that way. Sprites are defined as XML files with tags and sections specifically for working with multiple sheets and frames of animation. Frames can be defined in any order and from any section of a given sprite sheet. Each frame also has a time/delay definition as well so you can have a single frame displayed for several milliseconds of for several minutes.

Following is one of the sprite XML definitions currently in use:

Code: xml [Select]

<sprite version="0.99">
<imagesheet id="construction" src="construction_01.png" />
<imagesheet id="main" src="command_center.png" />

<action name="construction">
<frame sheetid="construction" delay="800" x="0" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="321" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="0" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="321" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="0" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="321" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="500" x="0" y="192" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="321" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="128" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="0" y="128" width="107" height="64" anchorx="0" anchory="18" />

<frame sheetid="construction" delay="145" x="321" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="0" y="64" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="321" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="214" y="0" width="107" height="64" anchorx="0" anchory="18" />
<frame sheetid="construction" delay="145" x="107" y="0" width="107" height="64" anchorx="0" anchory="18" />
</action>

<action name="operational">
<frame sheetid="main" delay="125" x="0" y="0" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="107" y="0" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="214" y="0" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="321" y="0" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="0" y="55" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="107" y="55" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="214" y="55" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="321" y="55" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="0" y="110" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="107" y="110" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="214" y="110" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="321" y="110" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="0" y="165" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="107" y="165" width="107" height="55" anchorx="0" anchory="9" />
<frame sheetid="main" delay="125" x="214" y="165" width="107" height="55" anchorx="0" anchory="9" />
</action>
</sprite>

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: OutpostHD - An Outpost Redesign
« Reply #29 on: November 12, 2015, 06:56:09 AM »
Quote
That actually breaks things down much more easily for me and I now have the forumlation for a simple mathmatical approach. My math isn't particularly strong so I imagine it would be very easy to figure out a pattern and develop strategies to take advantage of any weaknesses in the math.

One weakness is the way morale affects the denominator. You only need good morale as the remainder grows to meet the denominator. Having high morale means more progress before a death occurs, and less remainder after it occurs. If your morale suddenly drops while there is a lot of growth, it can trigger a death, and lead to a lot of remainder to contribute towards the next death. Granted, morale is capped to only move 5 units max at a time. On the other hand, if you have low morale, but it's slowly rising to stay ahead of the growth, no death will occur until the growth catches up, and there will be little remainder to contribute towards the next death if the denominator is large.

In a sense, the effects of morale are forgotten between the death points. Morale does affect when those points will happen, but it's a moving target, and doesn't matter until that target is hit. You can potentially game the system by moving resources away from morale structures until the death point is getting close. Same for med centers. Save on workers and scientists until someone is almost ready to die, then gradually activate them to keep the denominator larger than the accumulating progress.

Ideally, I think things like med centers or morale should affect the numerator, so it can properly accumulate over time. That would totally change the math around though. Plus, it is hard to game the current system, particularly since those growth accumulators are hidden. But of course a clever little trainer, or an AI could make use of the way things work.

Offline vomov

  • Newbie
  • *
  • Posts: 25
Re: OutpostHD - An Outpost Redesign
« Reply #30 on: November 13, 2015, 05:43:32 AM »
Your population takes 3 values (number of workers, kids, and scientists).
Population growth takes 3 values (growth progress of workers, kids, and scientists).
Population death takes 3 values (death progress of workers, kids, and scientists).

Now I understand. I thought primarily from a coding standpoint: individuals in a matrix vs individuals in objects, which is why I didn't get it.

While this does reduce realism and immersion, and potentially introduces odd abstractions in population management, this does reduce the amount of data processed to practically nil.
Furthermore, this is a lot simpler to implement. At the start of a turn:
1) Calculate the changes in the population pool.
2) Loop through the jobs at the start of a turn (based on job priority, I guess), keep 'filling' them until we run out of people.

However, from a coding standpoint, I do have a question: how complicated and abstract will the formulas get (assuming the Outpost 2 method isn't copied to the letter)?
If population death works based on a number, and every turn this number increases: numDeath = numDeath + 0.01 * numPop. Then we add general medical research, which leads to numDeath = numDeath + 0.001 * numPop. An negative event happens, so numDeath instantly increases by 0.05 * numPop. numDeath > 1 means killing floor(numDeath) individual(s), and numDeath = numDeath - floor(numDeath). I'm not sure I understand the effects of morale; does a high morale increase progression towards a death-event? That does not feel proper. It's been a long time since I played Outpost 2, so I might not get it.

Morale itself, however, can become very complex very quickly, since there are a lot of factors that can be taken into account. Furthermore, if the formulas incorporate a lot of other factors, they will potentially reach a level of abstraction that makes bug-hunting difficult. I remember a game with a similar approach for a worker pool, that would roll over zero at some point, leading to an infinite worker pool and a crash. Also, due to the formulas being abstract, it would be quite difficult to get them to approach something believable (although this might be less of an issue here).

On the other hand, this does feel quite similar to what Outpost originally did. Also, the other method (population as object-individuals) does have some drawbacks. On the computational side, it is slower. Of course, the amount of operations per individual should be relatively low (a small 'does it change?' operation should take care of most of it), and steps can be taken to reduce this (infants and children in a pool as a single number would be a VERY good idea, possibly ignore retirees as well), but it'll always require more computing power than the population-as-a-number-approach. Second, all supporting functions would be inherited from the 'person' class, and should be very easy to understand, but would still take up a bit of time to code. Bug-hunting should be easy, though, since the level of abstraction is a lot lower.

Some stuff can certainly be improved from the original, and I do like immersion and storytelling, but it does deviate from the original. I think I'll mount the fence for this issue.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: OutpostHD - An Outpost Redesign
« Reply #31 on: November 13, 2015, 06:06:06 AM »
From the thread I linked, the death fraction is:
workerDeathRemainder / (totalMedCenterCapacity + M_DIE_RATE)

Note that M_DIE_RATE is actually an inverse rate. A higher number means slower death rate. By increasing the med center capacting, or increasing the die "rate" (having higher morale), you slow the rate at which workers die.

There's a problem with this approach. If you have say 70 workers, so workerDeathRemainder increases by 70 each cycle, and your med center capacity is 70 (upgraded), then as long as you can activate an additional med center each turn, nobody dies. Once a person dies, idle all the med centers and repeat. That should give you extra workers and scientists to play with meanwhile. Granted, idling all the med centers affects morale, which is the other part of that fraction.


There are possibly other formulas that may work better. This was just an example. It's not overly complicated, and doesn't need to be.

Offline vomov

  • Newbie
  • *
  • Posts: 25
Re: OutpostHD - An Outpost Redesign
« Reply #32 on: November 13, 2015, 07:07:38 AM »
Get it now, thanks. Not sure if morale should actually influence death rate, though. Perhaps only below a certain level?

There are possibly other formulas that may work better. This was just an example. It's not overly complicated, and doesn't need to be.

There are problems with all approaches, but I'm a big fan of the simple ones. What's simple for us (easy to read/implement) is not always simple for the computer, or sometimes comes back to bite us in the tushy with unexpected complexity or weird border-cases (I created a solution for a data-problem four months ago, and I have been regretting it for the past four bug-hunting days). Here, the simplest solution seems to be to define population as a single number, and add modifiers to the 'progression to death' - variable. Morale would be similar, albeit a bit more complicated (i.e.: more modifiers).

Concerning possible exploits, I think not allowing certain buildings to shut down (was that in the original?) would be a good start on that.

On feedback: like in Outpost, there should be a 'master report' showing food, morale, population, and several other things, which should also show the 'percentage busy' for the medical centres and possibly also for the parcs/resevoirs and rec' centres, like the original did for the residential structures. A high 'percentage busy' should give some kind of feedback, like a news message, as well.

I had a question: the original had the news-button, which became active if there was a bit of news present. Perhaps a scrolling news ticker, news box with clickable items, or popup news messages might be better. I did a bit of a playthrough two days ago and only looked at the news around turn 100.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #33 on: November 13, 2015, 11:35:36 PM »
Quote from: vomov
I had a question: the original had the news-button, which became active if there was a bit of news present. Perhaps a scrolling news ticker, news box with clickable items, or popup news messages might be better. I did a bit of a playthrough two days ago and only looked at the news around turn 100.

The news items in the original game were... cute. Honestly, the more I analyze the game the more it's apparent that there was a breathtaking amount of hubris when developing the game. They spent more time with witty headlines for a virtual newspaper than they did programming the game. It's really quite amazing how much time the spent on little things.

Anyway, a news ticker is an interesting idea but it reminds me of SimCity 3000. I had thought about a news system similar to the original Outpost but with 'notifications' of some sort. Ultimately I think it's a lower priority and something to start thinking about later on during development.

Offline vomov

  • Newbie
  • *
  • Posts: 25
Re: OutpostHD - An Outpost Redesign
« Reply #34 on: November 14, 2015, 01:35:13 AM »
The original Outpost news system did give popups, but only sporadically give useful information (somebody dies every two turns in my 500+ colony; who cares?).
The news button tends to be ignored, but a notification might draw attention to it. Perhaps a simple blinking button for low-priority articles, while high-priority stuff uses a popup?

I've been doing a playthrough, and I agree on the news items. 'Funny' news articles about time travel on every load aside, I was mainly thinking about setting up a small system that watches out for certain situations occurring, like food dwindling, or power being insufficient. Of course, it can't do anything if the systems it's supposed to watch are not yet implemented :)

On another note; I've been exploring the research tree on my playthrough, and it feels that about 80% is either not implemented at all, or implemented in some weird hidden fashion, while the actual tree doesn't make sense at all. I'm not the only one thinking a severe revision would be appropriate, right?

Offline dave_erald

  • Sr. Member
  • ****
  • Posts: 262
Re: OutpostHD - An Outpost Redesign
« Reply #35 on: November 14, 2015, 09:02:44 AM »
I wonder why maybe morale couldn't be used in more aspects of the game? Say for instance that at the extremes of the morale scale it starts to affect production times by a small percentage? And I wonder if there couldn't be a specific point at which morale stops trending to the extreme low, that once you have enough residential and medical centers that morale doesn't go to the lowest level, it could already be programmed that way I'm not sure, but that could be a tip or notification that pops up in your system once you start implementing things.

As far as the tech and research function of the game work, are you looking to reuse all the buildings the way they are and just rework how things work together or maybe start renaming buildings and starting from scratch?
-David R.V.

-GMT400 fan
-OPU Influencer

Offline dave_erald

  • Sr. Member
  • ****
  • Posts: 262
Re: OutpostHD - An Outpost Redesign
« Reply #36 on: November 14, 2015, 09:04:10 AM »
On a side note perhaps today or tomorrow I should download the game and play through to see how good or bad it is.
-David R.V.

-GMT400 fan
-OPU Influencer

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #37 on: November 15, 2015, 08:09:20 PM »
I intend for morale to affect a lot of things including production efficiency, procreation, health levels, research speed,etc.

Offline dave_erald

  • Sr. Member
  • ****
  • Posts: 262
Re: OutpostHD - An Outpost Redesign
« Reply #38 on: November 19, 2015, 03:31:12 PM »
Sweet, functioning UI means playable?

And you were talking about updated graphics, so does that mean you need someone with graphics design experience?
-David R.V.

-GMT400 fan
-OPU Influencer

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #39 on: November 20, 2015, 12:06:21 AM »
It had a functional UI before, it just couldn't do much. The production UI now works so it adds gameplay to the game in addition to just plopping down buildings you can now also construct robots and use up all your resources in the process!

Work kind of got in the way the last few days so 0.5.0 hasn't been touched since Monday but after my 8 hour car trip tomorrow I'll be relaxing a lot during the weekend far, far away from work and during the evenings will have time to work on development.

Offline vomov

  • Newbie
  • *
  • Posts: 25
Re: OutpostHD - An Outpost Redesign
« Reply #40 on: November 20, 2015, 05:19:12 AM »
Nice!

Right now all resources are thrown into a single 'pool' right? How will you implement local (mine) vs. colony (storage tanks?) storage?

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #41 on: November 23, 2015, 12:05:23 PM »
Yes, they're just added/subtracted from a 'pool'.

I've been giving that some thought and I think that it should be simple enough to continue with a 'pool' paradigm only with capacities and locations.

So the short answer is:

Some special case code.

The long answer:

Basically, mines would have their own caps on what they can store. Say a mine can store 500 units of ore, once it reaches 500 units it goes into an Idle state until something comes and takes units of ore out of its 'pool'. If ore is being pulled by a truck, the truck has so much capacity, say 25 units. It then dumps that off at a Smelter which has a fixed rate of processing so the Smelter would have two pools -- the raw ore and the processed ore. Though in reality we can probably just have the refined ore just be automagically added to regular storage.

The number of active storage tank structures would determine the capacity of storage for all of the processed materials. Like mines, I would say that this should just be X number of slots, say 500 units per storage tanks (or maybe in harder difficults 250 units). What's stored in them can be any combination of the common/rare ores. Food storage would probably stay within the Agridome's themselves so they would have enough room for say 100 units of food each.

Energy doesn't accumulate, it's just sum of all energy output from energy producing structures so that should be simple enough.

Offline vomov

  • Newbie
  • *
  • Posts: 25
Re: OutpostHD - An Outpost Redesign
« Reply #42 on: November 23, 2015, 02:08:31 PM »
Food and energy as colony-wide pools would be best, I agree.

In the original, storage tanks had their own pools, which is odd, now that I think about it.
A generalized pool would be good, but there is a potential issue: if mine yield is randomized per resource, then there is a risk of storage filling with materials of one kind, while there is not enough of another kind. Based on the exact handling and balancing of production and mining, this can get ugly fast. At some point there's going to be 80% filled with common ores, and 20% with common minerals, and no rare anything unless we throw some stuff away... The SPEW took care of that originally, by creating MPG (also known as Torgo's Ground Executive Powder).

Simply 'throwing away' resources above a certain threshold (Rare ore low, common mineral highest, so replace common mineral with rare ore?) is something I've seen before, but I'm not sure if that's a good idea... On the other hand, weird micro-management with the risk of building huge storage parcs is also not desirable.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #43 on: December 19, 2015, 11:59:47 AM »
Quote
A generalized pool would be good, but there is a potential issue: if mine yield is randomized per resource, then there is a risk of storage filling with materials of one kind, while there is not enough of another kind.

This is where balancing comes into play. Running the numbers through my head, I don't think this sort of situation would come up. At present, mines are randomly dispersed across the landing area and can have one of three yields: High, Medium and Low. These yields are not randomized (though difficulty ratings should have an effect on actual yields). The yeild determines the amount of resources produced by the mine per turn. I will be taking a page out of Outpost's book on this one and the digging depth determines how long a mine produces good results (after which it continues to produce at a very, very low yield).

In the current code a single medium yield mine produces enough ores of all types to operate a tiny colony. Expand that to two medium yield mines and you will have enough resources produced each turn to develop a colony at a relatively slow pace. It will need more balancing in the future but the numbers at the moment are working out okay.

Quote
Simply 'throwing away' resources above a certain threshold (Rare ore low, common mineral highest, so replace common mineral with rare ore?) is something I've seen before, but I'm not sure if that's a good idea...

It's not a good idea. In fact I'd go so far as to call it a terrible idea. With the way it's working presently and the way I intend to have resources handled at each Mine (which has its own pool), there will never be a need to 'throw away resources'. While a mine can store up to 500 units of whatever ores are produced, if the mine's resources are at say, 498, and in a turn more than this would be produced, the mine simply shuts itself down and stops production. Basically, if a resource pool is too small to handle incoming resources, the resources are outright rejected. In this way there is no loss of resources and a mine simply stops production.

Conversely, if a Smelter has too many raw resources in its resource pool and a truck has more resources than can fit in the Smelter's resource pool, the truck is forced to simply wait for enough room to be made. If storage tanks are at their capacity, then the whole resource production cycle effectively gets halted as the mines fill up and shut down and the Smelter has more resources than it can handle.

It's a somewhat complex process internally that I need to really map out well but I at least have the general idea of how it should work.

Offline vomov

  • Newbie
  • *
  • Posts: 25
Re: OutpostHD - An Outpost Redesign
« Reply #44 on: December 21, 2015, 04:39:43 AM »
You mean that the yields will be randomized to make people search for a mine with proper ratios, but not too randomized so people won't get stuck building huge storage parcs? Some minor balancing aside, that should work well.

To help people find out which resources they need, perhaps a simple 'balance sheet' showing input, storage, and usage would be very helpful. Perhaps also a small spreadsheet showing all mines and their yield? If something is wrong (mine produces more than trucks can carry, smelter full, etc.), a small exclamation mark to draw attention to it should be enough. I don't remember which game, but there was one that had several buttons related to certain parts of a production flow, and if there was something wrong, the button itself would blink with an exclamation mark.

I like the 'very very low yield', as it prevents a colony from locking up completely.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2350
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #45 on: December 24, 2015, 12:05:51 AM »
Quote
To help people find out which resources they need, perhaps a simple 'balance sheet' showing input, storage, and usage would be very helpful.

Agreed. I planned on something like this which is pulled up via the GUI. I haven't decided if it's through a 'master report' like interface like the original game had (I don't like this) or via the resource UI which I started to add. One thing I liked in Civ5 is that resources show you exactly what you're getting (+/- each turn). I want to do something like that with the UI so the user can have a general feel for what they're looking at and then they can click on it or right click on it to bring up a UI window with much more detailed results (including what raw resources they're getting, from where, and additional information including the production at individual mines and smelters).

At the moment it's overly simplified and it results in some weird numbers showing up. I need to clean up the resource processing each turn but I haven't yet come up with a good solution. Means I don't have a good grasp of the problem itself so it's time to go back to the drawing board so I can reimplement a cleaner solution.

Offline vomov

  • Newbie
  • *
  • Posts: 25
Re: OutpostHD - An Outpost Redesign
« Reply #46 on: January 11, 2016, 05:12:35 AM »
I saw you were working on the resource management, and I'm curious on your current plan. The 'Update the way the player's usable resources are handled'-task denotes a problem with complexity, but no preferred solution.

Some questions:
- As I understand it, Agridomes store their own food, which means every Agridome - object has its own counter and behaviour. This is similar to the original, but I'm not sure why this isn't done with a global counter.
- On storage of resources (and later items in warehouses); the original did that per object. That is the plan, I gather, but I wouldn't have the faintest on how an implementation would look like.
- In the original, I would build a tokamak and forget about my energy needs. Energy was implemented, right?

The master report was a bit odd, but it could be made useful. General stuff can be put in a single small window (mini report) that shows the bare basics. Energy, food, and air shouldn't need te be monitored during the game; three dots saying 'enough air', 'enough power', and 'we're producing more food than we need' should be enough. If we're near the limits, those dot could become orange, suggesting a need for something to change.

Clicking on the mini report can open up a bigger version (master report), or bring up separate windows. For example, clicking on the population number can open up a window showing the ages and jobs, and clicking on the energy counter tells us we're getting 10% from solar, and 90% from a Tokamak. The original was heavily limited by the screen resolution of the time, nowadays it's not that much of an issue anymore. Putting all resources somewhere might create quite a bit of clutter, though.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: OutpostHD - An Outpost Redesign
« Reply #47 on: January 11, 2016, 08:29:51 AM »
Quote
I saw you were working on the resource management, and I'm curious on your current plan. The 'Update the way the player's usable resources are handled'-task denotes a problem with complexity, but no preferred solution.
I really like how you brought that up.

Quote
- As I understand it, Agridomes store their own food, which means every Agridome - object has its own counter and behaviour. This is similar to the original, but I'm not sure why this isn't done with a global counter.
I'm used to the Outpost 2 way of storing food using a global counter. I never even considered it this way. In a way it almost makes more sense to have food stored at agridomes, and potentially losing it if the agridome is destroyed. That may be why it wasn't implemented that way though, since Outpost 2 needed to support land rush games where there is no agridome.

Offline vomov

  • Newbie
  • *
  • Posts: 25
Re: OutpostHD - An Outpost Redesign
« Reply #48 on: January 11, 2016, 09:17:38 AM »
I really like how you brought that up.
Not good?

... potentially losing it if the agridome is destroyed.
Ah, that's what I was missing! Implementing disasters would mean you'd need to put the hot lab and tokamak away from everything else.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4954
Re: OutpostHD - An Outpost Redesign
« Reply #49 on: January 11, 2016, 12:46:14 PM »
Quote
Not good?
It was good. It was basically: hey, you said you were going to work on something vague. What are the specifics?