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

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line
« on: September 27, 2015, 07:22:40 PM »
What is OutpostHD?
OutpostHD is a remake of OUTPOST by Sierra On-line from 1994. It's not a clone of OUTPOST -- it's an entirely new game inspired by OUTPOST's core mechanics while providing a more complete and satisfying experience than the original ever could.

YouTube Video


Screen Shots

Current Build
You can download the current build here: Current Build

The Windows release of OutpostHD is developed using Visual Studio 2019. You will need to download the Microsoft Visual C++ 2019 Redistributable. Use the x64 version as OutpostHD is now distributed as a 64bit binary.

How to Play
A "How to Play" guide has been started on the OPU Wiki:

OutpostHD Wiki: How to Play

Change Log
Change Log for v0.8.7

Change Log for the current development build.


Roadmap
OutpostHD is hosted on GitHub -- you can see its current and future progress here: OPHD Milestones


WIKI Page
Basically restates what's here but goes into more details on a number of subjects. Also, as the game is beginning to be fleshed out now it's a good resource for understanding how parts of the game work.


Older Versions
Older versions of OutpostHD, if you're interested in seeing the changes over time, can be found in the files directory of the OPU website: http://outpost2.net/files/ophd/



Goals
I want OutpostHD to be freely available to everybody, so it's open source. The code is available on GitHub under the BSD-3-Clause license.

I also want OutpostHD to have its own new art and audio assets so as not to infringe on the original copyrights and to be able to take advantage of modern graphics hardware and 32bit Color Depths.

Finally, I want OutpostHD to be what Outpost should have been. Outpost was a great idea. Its implementation, however, was terrible. OutpostHD is an attempt at making the game that Outpost could have been.


Changes to the Design
OutpostHD isn't a clone of OUTPOST but instead a re-implementation of the core mechanics and ideas in a more refined and finished product. See OutpostHD's Wiki article for details.





How You Can Help
I'm often asked how one can contribute without being a programmer -- there are lots of ways!


Graphics
One of the goals of OPHD is to replace all of the visuals with unencumbered assets. Most of the structures have been replaced, all of the tilesets, planets and landing maps are new and the GUI Skin is new. There's still plenty left to do though -- check out the Graphics Update subforum to see where efforts are being focused and where you might be able to help.


User Interface
I've never been very good at UI design and thankfully several community members have been able to step up and help me develop a much better user interface. But, it still needs further work. The best way to help with the UI is to offer designs or to just use the interface and report back any issues you find (something is unclear, something doesn't work right, etc.)

See the User Interface subforum for discussions about improving the UI.


Writing
I know, not exactly a story driven game but writing is becoming a thing that's going to need some TLC. Specifically, the flavor text for the Research Tree, product descriptions for the Factory UI Panel, the individual structures and the Wiki Page. If you're up to the challenge, let me know!


Programming
The best way to get involved is to just jump in, clone a copy of the git repository and start poking around in the code. You can get instructions for cloning the git repository from the GitHub project page: https://github.com/OutpostUniverse/OPHD

I started putting together a Building from Source wiki page. It should be fairly complete. If you run into trouble you can post here or get ahold of me or Hooman on Discord (see chat link at the top of the page).

The latest commits on github use Visual Studio 2022 project/solution files and vcpkg for dependency management. See https://github.com/microsoft/vcpkg for instructions on installing vcpkg and Building from Source (linked earlier) for vcpkg commands.

Please ask if you have questions. A lot of effort went into making this as painless as possible and questions help me to see where instructions can be improved.

Poke around the code, see what issues/tasks are still open and don't be afraid to ask questions or make suggestions! I'm very open to assistance and without the help and experience of several other developers OPHD would not be nearly as far along as it is. Even if it's just a small patch, go ahead and submit a pull request -- it's a great way to get my attention on GitHub!

Can I help in some other way?
Yes!

As the developer, I have intimate knowledge of how every part of the game works. I know how I intend the game to work so I often don't think of ways that users may try to play the game.

That's where you, the user, come in. Your feedback is extremely helpful in knowing where to focus my development efforts. Is something not clear? Say so! Did the game explode on you? Tell me!

I love getting bug reports especially when the game breaks in weird and unexpected ways. I've already been able to iron out a lot of bugs just from the feedback of users like you. So download the game, play it, explore it, find ways to break it horribly and then let me know about your experience!
« Last Edit: June 17, 2023, 03:39:17 PM by leeor_net »

Offline Eddy-B

  • Hero Member
  • *****
  • Posts: 1186
    • http://www.eddy-b.com
Re: OutpostHD - An Outpost Redesign
« Reply #1 on: September 28, 2015, 03:48:33 PM »
::ThumbsUp::

I never got this far, although i did toy with the idea once...
Rule #1:  Eddy is always right
Rule #2: If you think he's wrong, see rule #1
--------------------

Outpost : Renegades - Eddy-B.com - Electronics Pit[/siz

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
Re: OutpostHD - An Outpost Redesign
« Reply #2 on: September 29, 2015, 08:10:12 PM »
Fantastic news! The project is coming along nicely, its looking great!

I did play Outpost 1 a bit when I was a kid.. I will have to revisit it and then I can actually comment on your questions and discuss the projects direction properly. Simplifying things is good and getting rid of pre-game stuff makes sense to just get into the game, it could always be added later, I do remember liking it. Most important thing is the main game.

I hope you find the time to work on the project, I know work is hetic for you!

:D

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: OutpostHD - An Outpost Redesign
« Reply #3 on: October 05, 2015, 11:12:05 PM »
Very nice. Will have to take a more detailed look at this.

I love that you posted the repository link. (Although I currently get a security warning when I click the link in the browser because the certificate is not trusted).

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #4 on: October 09, 2015, 01:38:09 AM »
I was originally going to keep a record of the changelog here on the Forums but I realized it would make much more sense to simply link to the 'CHANGELOG.md' file I just committed to the repository so I'll be linking to it instead. The SVN server does a decent job of rendering the log but Google has a few Markdown Viewer plugins that work better so feel free to install one of those and view it that way.
« Last Edit: October 09, 2015, 02:39:03 AM by leeor_net »

Offline Leviathan

  • Hero Member
  • *****
  • Posts: 4055
Re: OutpostHD - An Outpost Redesign
« Reply #5 on: October 09, 2015, 05:51:44 AM »
Yeah changelog is best on the SVN or website/wiki page.

Glad to see you are making progress :)

I just tried out Outpost 1 lately.. OutpostHD already looking better, being able to see so many more tiles on screen is great.

I forgot about the underground view in Outpost 1, I remember loving that, and in other games like SimCity.
« Last Edit: October 09, 2015, 06:09:17 AM by Leviathan »

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #6 on: October 09, 2015, 05:53:08 PM »
The game also scales down to 640x480 pretty well. Not that anybody would really want to play it in that resolution but for nostalgia's sake!

I do need to add some sanity checks for screen resolutions and eventually I'll need to have the screen resolution configurable from within the game. I had a proof-of-concept of doing that on the fly with The Legend of Mazzeroth -- we were switching between resolutions and at the time between a software and OpenGL renderer.

Anyway, the fullscreen mode works well I think. I was wondering about the background of the game though... I know it's a small detail but should I have it auto generated like the original game with a blue gradient and green lines? Or should I shy away from that and go with something else entirely?

Offline rmiddle

  • Newbie
  • *
  • Posts: 9
Re: OutpostHD - An Outpost Redesign
« Reply #7 on: October 09, 2015, 11:22:14 PM »
Is the game actually playable at this point or is it still more a proof of concept.

Thanks
Robert

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #8 on: October 10, 2015, 12:32:46 AM »
It's less a proof of concept and more a WIP.

It's almost playable. I need to get resource management and factory production working, difficulty selection and save/loading working before I would call it 'playable'. After that it would be a matter of adding in research trees, resource trucking routes and polishing up the UI to make it intuitive to use and look half way decent, then we can call it a truly playable game.

Offline BinaryMan

  • Newbie
  • *
  • Posts: 35
Re: OutpostHD - An Outpost Redesign
« Reply #9 on: October 12, 2015, 06:27:01 PM »
For both factory production and research, it could be more user-friendly to use a queue approach. So the factory can make several items (possibly in a loop), and several pre-requisite technologies can be done in a row and all labs can work on the same thing without having to open each one.

Offline rmiddle

  • Newbie
  • *
  • Posts: 9
Re: OutpostHD - An Outpost Redesign
« Reply #10 on: October 13, 2015, 11:55:58 AM »
For both factory production and research, it could be more user-friendly to use a queue approach. So the factory can make several items (possibly in a loop), and several pre-requisite technologies can be done in a row and all labs can work on the same thing without having to open each one.

That would be great.  The interface in OP2 especially tended to leave your research labs idle doing nothing.

Thanks
Robert

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #11 on: October 13, 2015, 12:52:27 PM »
That's not a bad idea... kind of take a page from Civilization's book in that case. I was actually thinking about how to handle the UI when selecting factories, labs and manufacturing/research parks. Could use a similar approach where it just covers the whole screen.

Research makes a lot more sense to queue up but I'm wondering if I should again take a page from Civ5's book and every time a research topic is completed it lets you know "Hey! Listen! You can do more research!". In this case research labs would be assigned all together. Or again, go with the research parks where several labs are directly connected to an administration building and they are treated together.

Going to have to think about it.

Offline rmiddle

  • Newbie
  • *
  • Posts: 9
Re: OutpostHD - An Outpost Redesign
« Reply #12 on: October 13, 2015, 07:06:28 PM »
That's not a bad idea... kind of take a page from Civilization's book in that case. I was actually thinking about how to handle the UI when selecting factories, labs and manufacturing/research parks. Could use a similar approach where it just covers the whole screen.

Research makes a lot more sense to queue up but I'm wondering if I should again take a page from Civ5's book and every time a research topic is completed it lets you know "Hey! Listen! You can do more research!". In this case research labs would be assigned all together. Or again, go with the research parks where several labs are directly connected to an administration building and they are treated together.

Going to have to think about it.

In Outpost 1 how do you add additional Command Center to create additional Colonies?

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #13 on: October 13, 2015, 10:45:17 PM »
You don't. The game was never finished.

Offline Sirbomber

  • Hero Member
  • *****
  • Posts: 3238
Re: OutpostHD - An Outpost Redesign
« Reply #14 on: October 14, 2015, 03:15:45 PM »
In Outpost 1 how do you add additional Command Center to create additional Colonies?

You don't. The game was never finished.

Wrong.  I forget what tech you need, but you can actually build new Command Centers and start new colonies.  It needs to be placed at least 30 tiles (I think) away from any existing Command Center on terrain that hasn't been cleared by a Robo-Dozer.
"As usual, colonist opinion is split between those who think the plague is a good idea, and those who are dying from it." - Outpost Evening Star

Outpost 2 Coding 101 Tutorials

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #15 on: October 14, 2015, 05:34:00 PM »
Okay, great. Let's stick to the topic at hand, questions about how to play Sierra's OP1 can be brought up in the appropriate forum.

Offline nolongerinuse

  • Newbie
  • *
  • Posts: 25
Re: OutpostHD - An Outpost Redesign
« Reply #16 on: October 16, 2015, 06:50:32 AM »
Played around with it, and I must say: it's already quite an accomplishment!

I'd love to help, but I'm not good enough with coding (I'd love to help with testing and balancing, though, as well as most people here). Some thoughts:

UI can definitly benefit from some improvement, but I'd say to leave that for last. Base gameplay might go through several iterations, requiring tedious rewrites. Especially considering the original was quite broken, improvements would be made, changing the gameplay massively.
Question; didn't Outpost 1 under windows simply change the theme to some odd variant of the high-contrast theme?

In Outpost 1, I remember not paying attention to resources at all, unless something was wrong. I vaguely remember I'd just plop down mines, and keep the mining robot busy on new ones. This cannot be intended, so some form of resource management would be required. Separating metals and minerals into common and rare is good enough, I'd say. Could mining sites have differing proportions of these, though?

Mines automatically adding to the pool is odd, and trucks are defintely a solution. Truck routes with waypoints might not be ideal. How about this (example): mines automatically add truck routes from the mine to the command centre. The length of these routes is calculated using for A*, with every tile having a bit of resistance (rough tiles take longer). All trucks are shared between them. If a truck can traverse 100 tiles every turn, and we've got two mines at a distance of 25 tiles to the colony, then one truck can visit each mine twice every turn. Assuming mine production is balanced based on resource usage, then you'd only have to fiddle with the truck size until it feels right. Using mining robots to extend a mine would have it produce more resources, having insufficient trucks would cause resources to stock at the mine until the mine is full. A button showing the results of the search algorithm and a small window showing all truck routes with the used storage room at the mines would be enough for truck routes, then. Connecting a mine directly to the colony with a tube or monorail or whatever means trucks are no longer for that route, and then resources are added instantly (read: it's best to start near a mine).

MPG always reminds me of Soylent Green, so its universal use always felt wrong. I would also vote for the resource 'organic waste'. Food comes from agridomes, raw organic matter is fertilizer. Slag as a resource also feels realistic. Question: what did SPEW stand for (Sewage Processing ...)? It's kinda a nice acronym:)

As I read it, we've got several resources:
  • Common metals
  • Rare metals
  • Common minerals
  • Rare minerals
  • Organic matter/food
  • Organic waste (food for plants)
  • Slag (contains metals, need a lot of energy to get metals out)
I'd like to propose the following as proper resources as well:
  • Trash (contains metals and organics, based on number of people, education, luxury use, efficiency, etc.)
  • Bioplastics (since plastics are seeing HEAVY use in our society, and we don't expect oil on other planets)
On research, I'm not a huge fan of Civ's system; it feels like an annoyance. Queing might work quite well, but maybe a slider system, like Space Empires uses, would work better. This would be a parallel system, where you set up a couple of 'studies', which are then shared across labs. Making research parcs by coupling research labs would work very well, as long as you can set the task for the whole parc in one go. Multiple parcs, multiple tasks. Same for factories; certain tasks take quite a while, combining factories would reduce the time required. Separate factory parcs with separate tasks would be brilliant. As for the interface-part; show the separate parcs as a single 'factory' in a list, each with their own task/queue.

Modelling individuals would be a nice addition, and easy since it's a turn-based game. Also, this allows you to model birth, aging, and death. Relationships... would be complicated, but a simple marriage and procreation thing might be nice.

Question: didn't the original say something like 'people are frozen, and will be thawed if we've got the capacity'? If not; this might be a good addition, for the sake of realism. A genepool of twenty people is awefully small.

I feel medical issues are generally neglected, while they provide quite a bit of material for gameplay and storytelling. Perhaps medical issues could benefit from something similar, but simpler: everybody has a base chance to get a cold, break a leg, get cancer, andsoforth. However, somebody working in the agridomes might have an increased chance of needing treatment for allergies. A list of diseases/disorders with base chance, and modifiers based on job would do the trick (although this might stretch the idea a bit too far). Medical centres producing medicine would be good enough, so they'd need a bit of resources. Maybe this addition might go a bit too far, though...

I've seen other games use VERY simple formulas to model morale to good effect, so it doesn't have to be too complicated. Let's say morale goes from 0 to 100. The base state would be 20 (the only survivors, stuck on a inhospitable planet; not fun). And then you'd simply give additions per individual.
For example: let's say you've got one residential unit, which holds 16 people, and you've got a production of 10 cheap luxury items per turn. Randomize the colonist list, and start running through then one by one. For the first ten, you've got housing and cheap luxury items: +10 morale for housing, +5 for cheap luxury items. For the next six, you've only got housing: +10. The next four, you don't have anything; they'll sleep in the hallways and brush their teeth with the gravel found outside the airlock. Simple math then tells you you've got 10 colonists with 35, six with 25, and four with 20. Average would then be ((10*35)+(6*25)+(4*20))/20=29, which is not great.

The effect of food should work differently. Let's say 20 people, but only food for 10: nobody starves, but people aren't happy, so -10. Food for 40, and everybodycan pick and choose: +10, and slightly more organic waste (people simply eat more), which drains into the agridomes. Food for eighty, and a lot of food gets wasted, leading to unhappiness: +10 for the food, -5 for the inefficiency.

EDIT: sorry for the wall of text, I got carried away.
« Last Edit: October 16, 2015, 06:52:23 AM by vomov »

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #17 on: October 16, 2015, 12:48:14 PM »
Quote from: vomov
EDIT: sorry for the wall of text, I got carried away.

By all means, this is the kind of discussion I was hoping to see.

Quote from: vomov
I'd love to help with testing and balancing, though, as well as most people here

This is an area I could certainly use help. For the moment I've just used arbitrary values that help me just to see where things are going and test the resource consumption, etc. but none of it is set up well. Arbitrary values don't usually work well for these kinds of games so balancing will be needed.

Quote from: vomov
UI can definitly benefit from some improvement, but I'd say to leave that for last.

Naturally. This is why I called it a 'functional' UI but that doesn't make it good. Toward the 0.8/0.9 versions of the game I'll be looking at making a pretty UI that's as functional as it is good looking, but for now the basics do the job with simple buttons and pop up menus and the delightfully classic Windows 95 look.

Quote from: vomov
Question; didn't Outpost 1 under windows simply change the theme to some odd variant of the high-contrast theme?

Pretty much. They just changed it to black and green.

Quote from: vomov
Could mining sites have differing proportions of these, though?

They already do, though atm it's as simple as YIELD_HIGH, YIELD_MEDIUM and YIELD_LOW. Again, just threw in some arbitrary values there but it wouldn't be difficult to expand on that such as YIELD_HIGH_RARE_HEAVY, etc. or there could just be a randomized element to what kinds of resources a given mine will yield. I have mines randomly generated up to a set amount but the terrain difficult dictates the likelihood of getting a higher yield mine (e.g., tougher terrains will tend to favor medium and high yields, easy terrain will tend to favor low yields).

Quote from: vomov
these routes is calculated using for A*

There was another user that had PM'd me about exactly this. My thinking was that trucks had a certain range for which they could travel... say 30 tiles. So we could limit the A* search to that. Your other proposals of showing pathed trucks makes sense and is something I had considered as well and only makes too much sense. Highlighting truck routes is a natural progression.

Following that, once a route is established, the user would mostly be looking at assigning x number of trucks to particular routes. The UI for that would show if there are too many trucks, if resources are being left at the mine, etc.

I also thought about how often routes would need to be calculated and it should be fairly straight forward -- whenever a new mine is placed or an existing route becomes obstructed (colony expansion, etc.). The only issue then is whether or not the Smelther that it's being brought to is inaccessible and in a case like that the game can alert the player that there is a mine with no truck access to a Smelter.

Finally, when a mine becomes active, does the user have to initiate the routing? Or does it happen automatically? If it happens automatically, it will need to determine which smelter it needs to go to. Smelters are connected to the colony via tubes, but mines aren't, so a smelter could feasibly be built right next to a mine meaning trucks aren't taking much time to get back and forth and that the resources, once processed, are immediately available to the colony. I don't see this as an issue but it would mean that trucks would need to have a limit to how long they spend at each building. My thinking is once they arrive at a structure, it takes them 1 turn to load/unload.

Quote from: vomov
As I read it, we've got several resources:

These are the resources I'm currently considering:

  • Common Metals
  • Common Minerals
  • Rare Metals
  • Rare Minerals
  • Energy
  • Food
  • Organic Waste
  • Other Waste

I don't want to really break it down much farther than this and I may even consider combining the two waste's into just simply 'waste' which when processed produces a small amount of metals and minerals. I don't think making it any more complex than that is necessary or fun.

I am curious though -- if one does not have a recycling center, what happens to all of this waste? What do the colonists do with it? Organic in particular -- does it just get dumped out onto the surface somewhere where it gets to fester before being irradiated or frozen? I would think at the very, very least that all residential units and any structures with toilet facilities would have some sort of a sump well that separates the solids from the liquids with the liquids then being sent off to the CHAP (perhaps it should just be called the Life Support Facility considering it does more than just air) for cleaning and re-circulation. That being stated, the now dry solid waste is the concern... do they just throw it away? With a recycling facility that's my suggestion of where this waste, along with manufacturing waste, etc., would go to be broken down into their components for use where needed.

Quote from: vomov
This would be a parallel system, where you set up a couple of 'studies', which are then shared across labs.

This was the general idea. I liked how Civ5 just laid out their topics, it doesn't mean that we need to be limited to working on only a single research topic at a time. On the contrary, I would want different research projects to happen at the same time. But this is where I think the research parks come in. Unless you have an administration building of some sort directly connected to labs, you'd have to set each lab individually. With the administration set up, now you can set research for  up to four labs at a time, or maybe instead of having labs being required to be directly connected to the Admin building, the Admin building would instead have an area of effect, say any lab within 3 tiles of the admin building are under its control. This does bring up the problem of what about overlapping areas but that can be solved by just restricting administration buildings to having to be at least 6 tiles away from any other administration building.

I like your thoughts on the population and morale models. I haven't looked too deeply into it yet as I've been more focused on getting the basics done first so if you wanted to design the population model and morale model, by all means go right on ahead.

Offline Mordithrahl

  • Newbie
  • *
  • Posts: 2
Re: OutpostHD - An Outpost Redesign
« Reply #18 on: October 16, 2015, 08:12:45 PM »
This is incredibly exciting, and your project looks great so far! So happy to see this alive.

Offline nolongerinuse

  • Newbie
  • *
  • Posts: 25
Re: OutpostHD - An Outpost Redesign
« Reply #19 on: October 17, 2015, 04:33:06 AM »
Pretty much. They just changed it to black and green.
Ah, yes, now I remember. And after a crash the theme would 'stick'. Ew.

e.g., tougher terrains will tend to favor medium and high yields, easy terrain will tend to favor low yields
I like that; a clear incentive to go to the difficult-to-reach mines, yet at the same time it's possible to make a lot of easy mines.

Following that, once a route is established, the user would mostly be looking at assigning x number of trucks to particular routes. The UI for that would show if there are too many trucks, if resources are being left at the mine, etc.

That's a better idea; I thought about having a general 'truck pool' where all routes get their trucks, but this bit of micromanagement allows the player to fine-tune the influx of materials.

Then the whole stuff about routes and smelters has several possibilities, and is dependent on each other. I think about the steps involved, I end up roughly like this:
New mine is placed --> mine is unconnected --> mine makes automatic connection with the nearest/least busy smelter --> new route requisitions trucks until simple math shows all resources generated in a turn ends up at the smelter, or until the free trucks run out.
This has the advantage of triggers; if a mine expands, a smelter disappears, trucks get destroyed, or something else happens, it can simply run through some or all of these steps again.
Concerning the smelters; I think in Outpost 1 smelters had to be placed outside of the colony, without tube access. If we follow that route, perhaps we can do something like this:
Smelters do not require tube access, and automatically create a link with the colony. As in; they make a sort of 'minitube' (visible or not), or use small trucks that come with the smelter, or whatever. They'd have to be placed within five tiles of a colony-tile for the link to form, which would make the one turn to unload redundant too; the trucks have to travel quite a ways anyway. To make this work perfectly, and add a smidge of realism, perhaps introduce four extra resources: raw common metals, raw rare metals, raw common minerals, raw rare minerals. Mine ships bulky raw stuff to the smelter, smelter gets rid of most of the useless material, and a small transport drone is enough to ship all processed materials to the colony.

These are the resources I'm currently considering:
  • Common Metals
  • Common Minerals
  • Rare Metals
  • Rare Minerals
  • Energy
  • Food
  • Organic Waste
  • Other Waste
Noodles from a tin :o
Although; if we use the term 'bioplastics', then we can use either food or organic waste as a resource required by several industries. For example; while a colonist consumes 1 food per turn, 0.1 of this food is spent in making the packaging. Same for other things; making a truck requires a bit of organic matter for the upholstery, which comes from food or organic waste (organic waste would be the least odd, but you'd still end up with odd smelling tires). On the other hand; realism shouldn't stand in the way of good gameplay, so maybe this goes a bit far. Canned food would work just as well.

... with the liquids then being sent off to the CHAP ...
I think that's where the CHAP and the SPEW can work together; the SPEW eats up (organic, or all) waste, the CHAP gets rid of the smelly liquids, and produces air and potable water. For the CHAP a description should be enough, no extra resources would be needed. Concerning the circulation of matter; I read a Sci-fi book once that detailed (in excruciating detail) the flow of matter through a small colony. Generic 'trash' would be collected, separated into liquids, solid-ish organics, and non-organics. The liquids were used for air and water, same as here, the solid organics were made into fertilizer, and the non-organics were thrown into something that reminds me of the smelter. Perhaps a pseudo-resource could work here; the SPEW and CHAP simply get an amount of input based on the amount of people; more people, more organic waste. An overloaded SPEW or CHAP makes people unhappy. And then assume the CHAP produces as much air as required (until overloaded), and the SPEW has a direct line to the agridomes. In other words; organic waste disappears as a proper resource, and other (inorganic) waste can simply be thrown into the smelter for a small amount of random materials. No need for a big pile of poo outside the colony  ;D

With the administration set up, now you can set research for  up to four labs at a time, or maybe instead of having labs being required to be directly connected to the Admin building, the Admin building would instead have an area of effect, say any lab within 3 tiles of the admin building are under its control. This does bring up the problem of what about overlapping areas but that can be solved by just restricting administration buildings to having to be at least 6 tiles away from any other administration building.
That'd require an additional building, and I expect people will want to put multiple admin buildings to the same task. Why not make labs auto-connect into larger labs? For example:
Two separate labs, with separate tasks:
lab+lab
Two parcs, where the right one has twice the research points:
lab+lablab
Two parcs, with the right one five times the research points:
lab+lablab
       lablablab
It would provide some cosmetic benefits; no more 'grid of tubes' eating up half the space. The same could be done for factories and, now that I think about it; smelters! Also, in late-game; terraformers could also do something similar. Other buildings might also benefit from this; putting four universities together might change the description; "This university has a dedicated astronomy, geology, physics, and medicine faculty". Question; there were no multi-tile graphics in the original, except for some unused graphics of the terraformer and the defective mass driver, right?

Every parc (lab, factory, smelter) would behave as one single entitiy. No admin buildings needed, no additional micromanagment (linking labs to admin buildings), and easy expansion (overloaded smelter? Expand it!). Some form of limit would have to be imposed, like a max of nine combined labs, or four combined factories. If, for example, the CHAP is overloaded, and we build a second one half a colony away, then resources are shared between them. If we put them right next to each other, we end up with a single CHAP, with one window, one set of resources, etc.

Question: in Outpost there was an administrative building, but I don't know what it did. Did it have a use?

I like your thoughts on the population and morale models. I haven't looked too deeply into it yet as I've been more focused on getting the basics done first so if you wanted to design the population model and morale model, by all means go right on ahead.
I'll do some minor brainstorming, and I can set up a preliminary list with some seemingly arbitrary values.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #20 on: October 20, 2015, 11:49:51 PM »
@Vomov -- I will reply, I promise. Just haven't had the time to really respond.

Quick update -- not ready for release yet but this is what the current factory production interface is shaping up to look like. This will change in the future when you can update factory production in groups instead of individually but this interface will likely remain if you want to tweak a single factory without looking in the production window.


Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #21 on: November 01, 2015, 10:09:11 PM »
Quote from: lordpalandus
Humans don't die from old age. They die from organ failure

Who cares? I'm not trying to simulate true biology here.

Ultimately when I first started putting that class together, I just threw in values that I thought made sense. E.g., structures. They also have a 'maxAge' field. Do actual structures in the real world have a set number of years that they exist and then suddenly fail? No, not at all. All kinds of factors are involved in how long a structure lasts including exposure, maintenance and natural events (like storms and earthquakes). But, a maxAge field makes sense because that's how long a structure is expected to last. And some, for the sake of game play mechanics, will last only so long.

Perhaps a better way to represent both People and Structures is 'state of health' and 'state of repair'. Instead of counting up these values would count down. When either of these values hits '0' the person dies or the building collapses.

Regardless, the idea here is to be able to provide a reasonably good simulation of a population where values are used to approximate actual conditions. A 'maxAge' value for a Person would simply represent an average lifespan which is modified during the simulation based on stress, morale, working conditions, environment conditions (e.g., heavy radiation exposure or high gravity), medical technology and advancement and availability of life support.

I dunno -- this seems like we're beating a dead horse now. I'm going to proceed with what I had originally envisioned. If someone has a better idea, I'm open to a proposal which should include an actual model of how it would work vs. how it could be handled. Not being pissy here, just want to move forward with this. :)

Offline dave_erald

  • Sr. Member
  • ****
  • Posts: 262
Re: OutpostHD - An Outpost Redesign
« Reply #22 on: November 08, 2015, 12:19:11 AM »
Cool, new content. Awesome.

So my biggest beef with Outpost 2, (sorry never played the first Outpost game ) was replay-ability, as far as tech and research tree was concerned it really kind of requires more micro managing then I think it really needed. Trying to replay quickly in multiplayer would drive one nuts I believe. Also the the levels and separate upgrades for a particular upgrade of an upgrade made me scratch my head.

I seen the original post and was wondering if you had made any head way in this direction yet or still needed input?

I can't program but I can brain, if that makes any sense.
-David R.V.

-GMT400 fan
-OPU Influencer

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #23 on: November 08, 2015, 12:02:54 PM »
With the research trees? Not really. I've been focused more on the basics. Research trees are coming up soon though in terms of development so I will need to figure that out.

There have been a few suggestions as to how to improve the original research tree and research management. So far nothing concrete.

Offline nolongerinuse

  • Newbie
  • *
  • Posts: 25
Re: OutpostHD - An Outpost Redesign
« Reply #24 on: November 09, 2015, 09:10:30 AM »
Concerning research: I still have the outpost research tree from a FAQ, but it doesn't contain all the effects (although quite a few are obvious). A short playthrough should solve most of this, though :)

I had a question about the connector tubes; originally, we had straight tubes in the two directions, and an intersection. Would it be possible to replace this with 'tube', that simply connected to whatever was in the next tile? A tile would be a 'tube'-tile, which would get a different image based on its bordering tiles. I think I could even make some generic T-junctions for artwork (they're just BMP's, so...). This would be partially a aesthetic improvement, but also a UI improvement; a single generic 'tube'-button would be it for the user interface, perhaps with generic 'bulldoze' and 'dig' and 'mine' buttons next to it.