Outpost Universe Forums

Projects & Development => Projects => OutpostHD => Topic started by: leeor_net on September 27, 2015, 05:22:40 PM

Title: OutpostHD - An Outpost Remake
Post by: leeor_net on September 27, 2015, 05:22:40 PM
OutpostHD
OutpostHD is a remake of Outpost; Outpost the way I think it should have been done. Simply put, OPHD is an attempt to build an entirely new Outpost game based on the core concepts and gameplay mechanics of the original while providing a more complete and satisfying experience than the original ever could.

YouTube Video


Current Build
You can download the current build here: Current Build (https://outpost2.net/files/ophd/ophd_v0.7.6_windows_x86.zip)

If you don't already have it installed, you may need to download and install the Microsoft Visual C++ 2015 Redistributable (https://www.microsoft.com/en-us/download/details.aspx?id=48145).


Change Log
Change Log for v0.7.6 (https://github.com/ldicker83/OPHD/blob/6d45c47b7998b3b69e6ebfa13194199146fe4f19/CHANGELOG.md)

Change Log for the current development build (https://github.com/ldicker83/OPHD/blob/master/CHANGELOG.md).


Roadmap
OutpostHD is hosted on GitHub -- you can see its current and future progress here: https://github.com/ldicker83/OPHD/milestones (https://github.com/ldicker83/OPHD/milestones)


WIKI Page (http://wiki.outpost2.net/doku.php?id=opu_projects:active_projects:outposthd)
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 resources 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 good 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 (http://wiki.outpost2.net/doku.php?id=opu_projects:active_projects:outposthd) 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. Many 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 (https://forum.outpost2.net/index.php/board,109.0.html) 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 (https://forum.outpost2.net/index.php/topic,6111.0.html). 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 (https://forum.outpost2.net/index.php/board,111.0.html) for discussions about improving the UI.


Writing
I know, not exactly a story driven game but writing is becoing a thing that's going to need some TLC. Specifically, the flavor text for the Research Tree (https://forum.outpost2.net/index.php/topic,6142.0.html), product descriptions for the Factory UI Panel (https://forum.outpost2.net/index.php/topic,6111.0.html), the individual structures and the Wiki Page (https://wiki.outpost2.net/doku.php?id=outposthd:how_to_play). If you're up to the challenge, let me know!


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

There are also some dependencies that you'll need to download in addition to the code in order to compile it (and run the game). I don't have a perfect place for these ATM so hopefully these FileDropper links work:

Build Dependencies (http://www.filedropper.com/api_6) Data Assets (http://www.filedropper.com/data_61) Win32 DLL Dependencies (http://www.filedropper.com/win32dlls_1)

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!
Title: Re: OutpostHD - An Outpost Redesign
Post by: Eddy-B on September 28, 2015, 01:48:33 PM
::ThumbsUp::

I never got this far, although i did toy with the idea once...
Title: Re: OutpostHD - An Outpost Redesign
Post by: Leviathan on September 29, 2015, 06: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
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on October 05, 2015, 09: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).
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 08, 2015, 11:38:09 PM
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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Leviathan on October 09, 2015, 03: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 09, 2015, 03: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?
Title: Re: OutpostHD - An Outpost Redesign
Post by: rmiddle on October 09, 2015, 09:22:14 PM
Is the game actually playable at this point or is it still more a proof of concept.

Thanks
Robert
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 09, 2015, 10:32:46 PM
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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: BinaryMan on October 12, 2015, 04: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: rmiddle on October 13, 2015, 09: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
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 13, 2015, 10:52:27 AM
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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: rmiddle on October 13, 2015, 05: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?
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 13, 2015, 08:45:17 PM
You don't. The game was never finished.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Sirbomber on October 14, 2015, 01: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 14, 2015, 03: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on October 16, 2015, 04: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:I'd like to propose the following as proper resources as well: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 16, 2015, 10:48:14 AM
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:


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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Mordithrahl on October 16, 2015, 06:12:45 PM
This is incredibly exciting, and your project looks great so far! So happy to see this alive.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on October 17, 2015, 02: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 20, 2015, 09: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.

(http://leeor.outpostuniverse.org/ophd/screenshots/0.5.0/ss_01_thumb.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.5.0/ss_01.png)
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 01, 2015, 09: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. :)
Title: Re: OutpostHD - An Outpost Redesign
Post by: dave_erald on November 07, 2015, 11:19:11 PM
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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 08, 2015, 11:02:54 AM
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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 09, 2015, 08: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 09, 2015, 09: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).
Title: Re: OutpostHD - An Outpost Redesign
Post by: Vagabond on November 11, 2015, 03: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
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on November 11, 2015, 01: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 (http://forum.outpost2.net/index.php/topic,2147.msg38753.html#msg38753)

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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 11, 2015, 02: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>
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on November 12, 2015, 05: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 13, 2015, 04: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on November 13, 2015, 05: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 13, 2015, 06: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 13, 2015, 10: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 14, 2015, 12: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?
Title: Re: OutpostHD - An Outpost Redesign
Post by: dave_erald on November 14, 2015, 08: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?
Title: Re: OutpostHD - An Outpost Redesign
Post by: dave_erald on November 14, 2015, 08: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 15, 2015, 07:09:20 PM
I intend for morale to affect a lot of things including production efficiency, procreation, health levels, research speed,etc.
Title: Re: OutpostHD - An Outpost Redesign
Post by: dave_erald on November 19, 2015, 02: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?
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 19, 2015, 11:06:21 PM
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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 20, 2015, 04: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?
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on November 23, 2015, 11:05:23 AM
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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on November 23, 2015, 01: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on December 19, 2015, 10: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on December 21, 2015, 03: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on December 23, 2015, 11:05:51 PM
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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on January 11, 2016, 04: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on January 11, 2016, 07: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: vomov on January 11, 2016, 08: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.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on January 11, 2016, 11:46:14 AM
Quote
Not good?
It was good. It was basically: hey, you said you were going to work on something vague. What are the specifics?
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on January 11, 2016, 09:34:07 PM
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.

Note this in the task description:

Quote
TODO:

Finish fleshing out this thought and create tasks revolving around this problem.

Basically, I started defining the task and ran out of time and steam and had to get to bed for work in the morning.

Part of the problem is that I don't have a good grasp of the actual problem. I haven't fully worked it out in my head but it comes down to one thing; my current implementation is far too simple and worked while I was just starting the game development but it's time to provide a more sophisticated approach to it. I'm too tired tonight to finish 'fleshing out my thoughts' so I probably won't be updating it until tomorrow sometime in the afternoon.

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.

Because it's easier to use the internally built objects to manage all of this instead of global counters. I never liked global counters and it doesn't fit the simulation model specified by the original game. Hooman touches on one of the reasons I went with this approach:

Quote from: Hooman
In a way it almost makes more sense to have food stored at agridomes, and potentially losing it if the agridome is destroyed.

Bingo. This is why I went with this design. If you don't manage your structures properly and a structure that contains perishable storage goes inactive for one reason or another, you very well could lose all of that resource. You could even consider regular storage tanks to have 'perishable storage' such that if one was disabled the seals on the containers could leak leading to corrosion and deterioration of the stored resources.

Bulldozing a structure would be handled a little differently (this is where a global counter would make sense); Resources stored within the structure would be pushed into other like structures and whatever remains would effectively be lost. Kinda sucks but that's the way it works in real-life too.

*** Quick though while it's on my mind, if a Storage Tanks structure was destroyed during a disaster, bulldozing its remains should probably provide a higher level of resources than an empty Storage Tanks due to whatever remains of its stored resources could be scavenged. ***

Quote
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.

This is the plan. Without going into too much detail, suffice it to say that at least for resources, I use an object that defines a number of resource types. This object can act as either a simple container (e.g., to pass along construction, manufacturing and recycling values as well as required input resources) and can act as a storage container with push/pull functions (e.g., pushing resources into the container and pulling resources from it). These storage management function check the given capacity of said container and will only allow so many resource in.

By using these resource objects within certain structures, implementation is fairly trivial. The logic is contained within the structure itself on what resources get pushed/pulled from storage and the resource objects themselves handle push/pull requests.

Quote
In the original, I would build a tokamak and forget about my energy needs. Energy was implemented, right?

Pretty much. At this point the only energy provided is the meager 50 units by the SEED Power Facility. I haven't yet implemented the Tokamak. I'm not sure exactly when I will but probably after I get the storage situation finished and cleaned up.

Quote
The master report was a bit odd, but it could be made useful.

This is true, but simply cloning it and improving it to me is a waste of time. Why fix something that's badly designed when you can redesign something superior? I'm not a great UI designer by any stretch so any thoughts on this front would be helpful especially any mockups. Keeping in mind that I want to kind of stray away from the modified Windows 3.1 GUI approach.

Title: Re: OutpostHD - An Outpost Redesign
Post by: Galactic on January 20, 2016, 12:50:33 PM
Looking good so far, keep up the good work.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on January 22, 2016, 07:38:47 AM
For those of you who don't want to download the game yet because it's technically not 'playable', here's a short video demonstrating some of the various aspects of the game.

Title: Re: OutpostHD - An Outpost Redesign
Post by: Vagabond on January 22, 2016, 11:43:46 AM
Leeor,

I'm excited about this project. I enjoyed playing through Outpost 1.5 a few times years ago.

Glad to see the progress and nice video.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on January 22, 2016, 04:01:48 PM
Thank ya!

I'm not sure how to upload in higher resolution... perhaps I just need to set it to full screen and record it that way.

Still pushing a long. The last few weeks have been exhausting at work so I've pushed it to the back burner because of how tired I've been but I have a weekend coming up and then 6 days off from work so I hope to have storage and resource management figured out and probably saving/loading figured out by next the end of next week.

After that it's truck routing and research trees!

Hooman, if you're up for it maybe you could help me figure out some math for the population model? I keep going back to a full-blown population simulation and that seems like total overkill for this game.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Charles_Bronson on December 14, 2016, 12:58:22 PM
thats good progress! Really nice work done!
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on December 14, 2016, 01:45:37 PM
Thanks! Been at it for a year and have a lot to show for myself. Goof has been super helpful too especially with developing a lot of the structures. Would feel very bare without his help.

BTW, I see it's been what, almost 8 years since you posted last? Welcome back!
Title: Re: OutpostHD - An Outpost Redesign
Post by: lhark on June 10, 2017, 09:23:45 PM
Hello everyone, i just discovered this forum and the outpostHD project.
Outpost has a big place in my childhood memories and it warms my heart to see people are still passionate about it :)

Anyways, being a big free software supporter, i tried (and succeeded) building OutpostHD and it's underlying API NAS2D on linux.
It runs reasonably well after a few bugfixes.

I've already submitted a pull-request on github for NAS2D, but i don't know to do the same with the OutpostHD svn repo :/
Do i need to provide a patchfile ? do i get push access to the repo ? to a feature branch ?
I must confess i'm not that familiar with svn.

Once again, thank you for the great work you put into this project :)
Title: Re: OutpostHD - An Outpost Redesign
Post by: Vagabond on June 10, 2017, 10:40:35 PM
Ihark,

The repository is read only until an admin like leeor_net gives you write access. Just keeps people from making a mess of it. It sounds like you already found the repo location to download the source code.

We have some limited, basic info on Subversion in the wiki here: http://wiki.outpost2.net/doku.php?id=opu:repository.

I'm glad to hear the code compiled without too much difficulty on Linux.

-Brett
Title: Re: OutpostHD - An Outpost Redesign
Post by: lhark on June 11, 2017, 09:53:57 PM
Thankks for the answer :)

I guess I'll wait for an answer by leeor_net then.

By the way I also updated OutpostHD to NAS2D v1.4.2 (that had absolutely nothing to do with me not realising
that outposthd was not using the last release when I started ^^).

EDIT : In fact the only part that wasn't already v1.4.2-compatible was ui_builder which is not really part of the game
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on June 13, 2017, 08:22:57 PM
I actually don't have admin access to the SVN -- that's something Leviathan handles (can get a hold of him via IRC).

If you'd like you can submit a patch file for OutpostHD via PM (or send me a message if it won't allow you to attach the file(s) and I'll give you my e-mail address).

Will look at the pull request for NAS2D -- I've been visiting my parents in NJ for the last few days so I've been unable to do a whole lot with it.

And thank you for taking care of the Linux parts! I don't have a linux installation but when I was building The Legend of Mazzeroth (LoM, as in the code base for the file system) the base code worked well.

Once you get write access to the SVN from Leviathan, if you're interested in poking around the OutpostHD code, by all means! I could use a bit of help -- I was starting to work on it again last week but ended up being contracted to build some tooling for a new project so I had to put it down.

Anyway, plan over the next couple of weeks is to implement population requirements check and then move on to the product production and storage implentation. See the Redmine roadmap for the general plan.

Thanks for updating to the latest version of NAS2D! I never got around to it.

I kinda forgot about UI_Builder after I realized I'd have to build a lot more than really cared to do at the time. I should pick that project back up and just build the layout interpreter file and just make my life a lot easier. UI coding can be miserable -_-
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on June 25, 2017, 11:17:49 AM
I just tried compiling the source on Linux and got the following errors:
Code: [Select]
outposthd$ make
/bin/sh: 2: [: src/Map/: unexpected operator
/bin/sh: 2: [: src/Map/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/Things/Structures/: unexpected operator
/bin/sh: 2: [: src/Things/Structures/: unexpected operator
/bin/sh: 2: [: src/Things/Robots/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/Population/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
make: *** No rule to make target 'API/NAS2D/lib/libnas2d.a', needed by 'bin/OPHD'.  Stop.
Title: Re: OutpostHD - An Outpost Redesign
Post by: lhark on June 25, 2017, 08:59:25 PM
Ok, that's weird, I can only reproduce half of your problem. On the last line it complains about a missing library and is right about it : leeor_net forgot to include it with the rest of my patch.

If you want, you can compile the missing library yourself leeor_net accepted my pull request for https://github.com/lhark/nas2d-core.

As for the other problems, I can only that my shell scripting wasn't fully POSIX compliant :/

Maybe try the following fix on line 24 of the Makefile

-   if [ "$${dirs#*ui_builder/}" == "$$dirs" ]; \
+   if [ "$${dirs#*ui_builder/}" = "$$dirs" ]; \

Also, leeor_net, you should have a look at line 436 in src/States/GameState.cpp, I think you have a bug : the string sLevel becomes SLevels at one point without any new declaration.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on June 26, 2017, 01:17:03 AM
Thanks, removing one of the equal signs solved that problem.

I needed to install the SDL2 dependency (using Ubuntu):
Code: [Select]
sudo apt install libsdl2-dev

I also needed to add the "-std=c++11" flag to CFLAGS in the Makefile:
Code: [Select]
-CFLAGS         =       -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
+CFLAGS         =       -std=c++11 -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
That removed a ton of errors and warnings about "nullptr".

I see a few errors about "sLevels", as stated above. I renamed the occurrences to "sLevel" just to see if it would compile. No other compile errors, though lots of warnings about non-void functions having no return statement (they are dummy stubs), and a few typedefs being locally defined but unused.

And of course the error stated above was still present:
Code: [Select]
make: *** No rule to make target 'API/NAS2D/lib/libnas2d.a', needed by 'bin/OPHD'.  Stop.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on June 26, 2017, 11:23:52 AM
Also, leeor_net, you should have a look at line 436 in src/States/GameState.cpp, I think you have a bug : the string sLevel becomes SLevels at one point without any new declaration.

Seems to be an artifact of merging some changes. Have to admit, I'm finding Git to be far better at merging than SVN.

I'm also seeing that the code itself is wrong, again probably due to changes made between several commits between me and Goof.
Title: Re: OutpostHD - An Outpost Redesign
Post by: lhark on June 27, 2017, 11:14:25 PM
I would also be in favor of a migration from SVN to git, but I don't think my voice is worth anything yet^^

About the makefile, I completly rewrote it in order to have some dependency management: before, if you where to change just one header file,
the whole project would basically need to be rebuilt. I did a single test with GameState.h and got a five fold improvement on the build speed :

Code: [Select]
new makefile: make                  6.31s  user 0.44s system 99% cpu 6.747 total
old makefile: make -f Makefile.old  32.60s user 2.31s system 99% cpu 34.920 total

I also needed to add the "-std=c++11" flag to CFLAGS in the Makefile:
Code: [Select]
-CFLAGS         =       -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
+CFLAGS         =       -std=c++11 -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
That removed a ton of errors and warnings about "nullptr".
Thank you for the tip, I didn't really focus on reducing the volume of warnings ^^

By the way, is there an easier way for me to push this modification now that I have access to the redmine ?
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on June 29, 2017, 11:20:25 AM
Nice job on the compile time improvements. That's a huge win for iterative development.

I think the "nullptr" issue led to actual errors since they were showing up as undefined identifiers before. Though some messages were warnings. Different systems might have different default language standards.


Slightly unrelated, but I use git-svn so I can download the changes into a git repository and work with the code using git. Using git at the source could simplify that slightly.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Goof on July 08, 2017, 05:06:53 AM
Also, leeor_net, you should have a look at line 436 in src/States/GameState.cpp, I think you have a bug : the string sLevel becomes SLevels at one point without any new declaration.

Seems to be an artifact of merging some changes. Have to admit, I'm finding Git to be far better at merging than SVN.

I'm also seeing that the code itself is wrong, again probably due to changes made between several commits between me and Goof.

Yes it seems to be a merge mistake.
R228 was good with the new code and R229 was messy with part of the old code.
It should be right on live SVN version now.

I also add the navigation thru depth levels with First / End / Page Up / Page Down  keys.
Since, for me, it seems to be obvious shortcuts.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on July 09, 2017, 10:39:27 PM
I made another attempt to compile things on Ubuntu. Seems a few more updates are needed.

I pushed the changes to the Makefile for the = versus == POSIX compliance thing, and added the -std=c++11 flag.

I found additional dependencies needed to be installed outside of just the core SDL2 library. The core SDL library (libsdl2-dev) is needed for the sdl-config utility used in the Makefile. Additionally, other libraries are needed by the compiler. The full install set for OutpostHD is:
Code: [Select]
sudo apt install libsdl2-dev libsdl2-image-dev libsdl2-mixer-dev libsdl2-ttf-dev libphysfs-dev libglew-dev

I'm thinking a rule could be added to the Makefile to install these.

I looked into removing some of the warnings. It looks like there are attempts at compile time errors within templates using the familiar negative array index hack. I'm thinking this should be changed to the new static_assert introduced in c++11. Here's an example:
Code: [Select]
-       typedef int ERROR_CantUseHorrible_cast[sizeof(InputClass) == sizeof(u) && sizeof(InputClass) == sizeof(OutputClass) ? 1 : -1];
+       static_assert(sizeof(InputClass) != sizeof(u) || sizeof(InputClass) != sizeof(OutputClass), "Can't use horrible cast");
Note the negated condition. The code with the negative array index hack gives the condition for passing the check, rather than failing the check. The conditions would need to be rewritten as if the "1 : -1" was reversed to "-1 : 1".

There was one odd example I'm not so sure about:
Code: [Select]
-               typedef char ERROR_Unsupported_member_function_pointer_on_this_compiler[N-100];
+               static_assert(N < 100, "Unsupported member function pointer on this compiler");
What is going on with that check against 100? Seems like a hack. What is it doing, and is there a better way to do that?

I noticed a few sections of code similar to the following:
Code: [Select]
	AiVoiceNotifier() {}; // Explicitely Declared Private
AiVoiceNotifier(const AiVoiceNotifier&) {}; // Explicitely Declared Private
AiVoiceNotifier& operator=(const AiVoiceNotifier&) {}; // Explicitely Declared Private
The operator= caused warnings due to no return value from a non-void function. Removing the "{}" removed the warning. It's not called, so not having a body won't produce an error. But this gets more to the heart of the idiom used here. As the function is explicitly being declared private to prevent its use, it would be more clear to use the "= deleted;" syntax introduced in c++11. This would apply to all 3 methods as well, and would give more clear intent.

Another missing return from a non-void function was:
Code: [Select]
int incrementFuelCellAge() { mFuelCellAge++; }
I'm thinking just change the return type to void. I don't think it needs to return a value. I also noticed it's not called anywhere. Another thought, should the return value actually be desired, it might make more sense to use the pre-increment operator: "return ++mFuelCellAge;". That would return the value after the increment, rather than what the value was before the increment.


It took me a while to realize NAS2D was a separate download. The folder in OutpostHD is really just the development headers. This of course means a new set of challenges.

The Makefile for NAS2D also needed to have the "-std=c++11" flag set.

I needed to install another library:
Code: [Select]
sudo apt install glee-dev

There was one include I needed to update in src/Renderer/OGL_Renderer.cpp:
Code: [Select]
-#include "SDL_image.h"
+#include "SDL2/SDL_image.h"

I still get some errors with NAS2D in src/Renderer/OGL_Renderer.cpp:
Code: [Select]
src/Renderer/OGL_Renderer.cpp: In member function ‘virtual void NAS2D::OGL_Renderer::fullscreen(bool, bool)’:
src/Renderer/OGL_Renderer.cpp:494:44: error: ‘SDL_SetWindowResizable’ was not declared in this scope
   SDL_SetWindowResizable(_WINDOW, SDL_FALSE);
                                            ^
src/Renderer/OGL_Renderer.cpp: In member function ‘virtual void NAS2D::OGL_Renderer::resizeable(bool)’:
src/Renderer/OGL_Renderer.cpp:518:59: error: ‘SDL_SetWindowResizable’ was not declared in this scope
  SDL_SetWindowResizable(_WINDOW, static_cast<SDL_bool>(_r));
                                                           ^
Makefile:22: recipe for target 'obj/Renderer/OGL_Renderer.o' failed

According to the SDL docs:
Quote
This function is available since SDL 2.0.5.

According to the output of apt install:
Code: [Select]
libsdl2-dev is already the newest version (2.0.4+dfsg1-2ubuntu2).

Looks like the packages available for Ubuntu are too old to contain this function.

I'm stopping here for now.
Title: Re: OutpostHD - An Outpost Redesign
Post by: lhark on July 09, 2017, 11:38:43 PM
Wow, very nice and in depth test.

Sorry about the dependency, I didn't write them down anywhere, and it wouldn't have been usefull to you anyway as I'm running archlinux.
However, I don't think that adding the dependency install to the makefile is a good practice or even a good idea. You would need to support
all the different packet managers that are out there (apt, pacman, yum to cite just a few of them).

I reckon a better idea would be mentionning that in the README.

About NAS2D, theorically, if we ship libnas2d.a with the rest of the windows libraries, it should work. But seeing as it's only compiled for
amd64 right now, that wouldn't be really portable.

As for the include in NAS2D/src/Renderer/OGL_Renderer.cpp, I didn't get any issue with it.
It might have something to do with the fact I have both versions of the SDL installed on my machine though.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on July 10, 2017, 01:31:24 AM
Quote
As for the include in NAS2D/src/Renderer/OGL_Renderer.cpp, I didn't get any issue with it.
It might have something to do with the fact I have both versions of the SDL installed on my machine though.

Ahh, that could be it. Interesting, if there is a mixed version compile happening. I mentioned it precisely because I thought it was odd nobody else had a problem. I figured there must be some configuration where that header file worked, and if I changed it, I might break someone else's setup on another platform.

Well, I suppose one way to find out, is to "fix" it, and see if anybody complains. ;)

Though now that I check, I also have libsdl-dev installed, which is version 1.2.15. Perhaps one of the other packages is involved, or it is a platform difference.

Quote
Sorry about the dependency, I didn't write them down anywhere, and it wouldn't have been usefull to you anyway as I'm running archlinux.
However, I don't think that adding the dependency install to the makefile is a good practice or even a good idea. You would need to support
all the different packet managers that are out there (apt, pacman, yum to cite just a few of them).

I reckon a better idea would be mentionning that in the README.
I was wondering what version of Linux you used.

I was also thinking the package names will differ by platform, as will the package manager. Still, I think dependency installation can still make sense in a Makefile as an independent rule, similar to the .PHONY rule for "clean". Perhaps a rule name "install-deps-ubuntu". Could throw in a rule for Arch Linux too.

The rules might not work for everyone, but I figure it's just as easy to add a Makefile rule as it is to document that in a readme, and for the few people that it helps, it's quite a convenience.

Might even be possible to have a generic "install-deps" rule that detects the distro and passes control to the right place.


Hey leeor_net, how come NAS2D is up on GitHub, while OutpostHD is hosted on the OPU SVN server?
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on July 13, 2017, 08:46:27 PM
Why does NAD2D use both GLee and Glew? From what I understand, they are both OpenGL extension loader libraries. They seem to do the same thing. Indeed, I've read that although you can use both in the same project, you can't include both headers from the same compilation unit.

I've also found a few places that suggest GLee is no longer maintained, and hasn't been in years. Of note is the open bug on the GLee SourceForge project page (https://sourceforge.net/p/glee/bugs/5/), which never got a reply:
Quote
We're going to be restructuring the SDK area of www.opengl.org and, since glee is listed there, wanted to ask what the current state of the project is, and if it should continue to be listed as a current resource. The sourceforge project seems pretty dead by casual inspection.

The use of GLee seems to be restricted to: src/Resources/Shader.cpp
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on July 18, 2017, 08:37:21 AM
It's not supposed to. I originally used GLEE but after that was discontinued I switched to GLEW. Anything from GLEE can be considered legacy and removed.

As a note, Shader.cpp contains... very old code that hasn't been updated in a long time. But, since I've learned a lot more about shaders I'm probably going to start updating that again soon.

Anyway, in the mean time GLEE references can be killed.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on July 21, 2017, 01:53:19 AM
Question for lhark:
How come you used .PRECIOUS in the makefile? Is there a reason to use this over .SECONDARY?
Code: [Select]
$(DEPDIR)/%.d: ;
.PRECIOUS: $(DEPDIR)/%.d

I read the GNU Make special targets (https://www.gnu.org/software/make/manual/html_node/Special-Targets.html) page:
Quote
.PRECIOUS
The targets which .PRECIOUS depends on are given the following special treatment: if make is killed or interrupted during the execution of their recipes, the target is not deleted. See Interrupting or Killing make. Also, if the target is an intermediate file, it will not be deleted after it is no longer needed, as is normally done. See Chains of Implicit Rules. In this latter respect it overlaps with the .SECONDARY special target.

You can also list the target pattern of an implicit rule (such as ‘%.o’) as a prerequisite file of the special target .PRECIOUS to preserve intermediate files created by rules whose target patterns match that file’s name.

...

.SECONDARY
The targets which .SECONDARY depends on are treated as intermediate files, except that they are never automatically deleted. See Chains of Implicit Rules.

.SECONDARY with no prerequisites causes all targets to be treated as secondary (i.e., no target is removed because it is considered intermediate).


On another topic, I read somewhere that #include lines should omit the "SDL2" directory, and instead add a -I flag to include the SDL2 directory in the include search path. The main reasoning seems to be different install paths and hierarchies on different platforms, or with different setups, such as using a local install rather than a system install. By keeping that out of the source, and in the makefile, it's supposed to make it easier to compile in different environments.

Personally I feel the suggestion to omit directory names is a bit backwards from most other languages. Most other languages have a defined directory layout for packages, and a mapping between package imports and their directory. Having the package/directory in the source makes it very clear what version you're expecting, and makes sure you don't accidentally grab the wrong import.

In this case, specifying "SDL2/SDL.h" rather than just "SDL.h" ensures you're compiling against version 2, and not against version 1. However, there seems to be a lack of a well defined standard in C++ about where package header files go. Indeed, the current source files have a number of platform specific defines to include the right header files. Perhaps the includes should be normalized to not include the directory name, and the build scripts updated to include the necessary include directories? If done correctly, a lot of the platform specific checks could be eliminated.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on July 21, 2017, 04:47:12 AM
As a side note, I've since updated NAS2D -- fixed a bug in one function that Goof pointed out and I've also commented out all of the shader code.
Title: Re: OutpostHD - An Outpost Redesign
Post by: havkyp on July 29, 2017, 05:14:21 PM
Just wanted to say a huge THANK YOU to you for developing OutpostHD!!! I signed up for this forum specifically to express this. :D

I played the original Outpost 1.5 to death back in the day trying to find all of those missing features thinking they were there somewhere... :p

I'm especially glad that you're making OutpostHD fully open source, this is essential for ensuring its historical heritage and for others to learn from and build on it. BTW what's its license? GPLv3?

Anyway, in addition to the huge thank you, what are some ways to support OutpostHD's development? Unfortunately I'm not a programmer. Do you accept donations or have other ways to help? Let's make this work. Thanks!!
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on July 29, 2017, 06:14:41 PM
Just wanted to say a huge THANK YOU to you for developing OutpostHD!!! I signed up for this forum specifically to express this. :D

Thanks for stopping by! It's good to know people are as excited about this project as I and the other developers are. :)

I'm especially glad that you're making OutpostHD fully open source, this is essential for ensuring its historical heritage and for others to learn from and build on it. BTW what's its license? GPLv3?

No, no no no! I do not like the GPL! I have it under a much more permissive BSD 3-Clause license. See LICENSE.txt in the distributions.

And that's why I made it open source. I could have kept it closed source but the only projects along these lines that seem to survive and progress into anything (OpenTTD, CorsixTH, Caesaria and many others) are all open source. The closed source ones seem to fizzle out and die over time.

Anyway, in addition to the huge thank you, what are some ways to support OutpostHD's development? Unfortunately I'm not a programmer. Do you accept donations or have other ways to help? Let's make this work. Thanks!!

Donations would be nice but I'm not sure I'd feel comfortable accepting them as I'm not the only developer.

Non-programmers can be extremely helpful. On the first post I have this section:

Quote
User Interface
I’m terrible at UI design. I can do the programming but the design itself is not my strong suit. I really need help designing a good UI that’s functional, looks good and is intuitive. Any help here would be much appreciated.

Effectively what I need are UI mockups with details about how the different elements work. The basic UI in the game right now is functional but pretty bare.

If you're up for some wireframing I'd be grateful. I'm just genuinely bad when it comes to UI design -- the few windows you see in game are mostly my doing though Goof and others have helped in developing other parts of the UI (e.g., the bottom ribbon). So any thoughts there are most welcome -- though in a separate thread! :D

Other ways to help:

Play the releases, find issues, spread the word.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on July 30, 2017, 10:03:05 PM
Quote
Donations would be nice but I'm not sure I'd feel comfortable accepting them as I'm not the only developer.

Leeor, you're too nice.

He could probably use a donation :p
Title: Re: OutpostHD - An Outpost Redesign
Post by: havkyp on July 31, 2017, 11:38:56 AM
No, no no no! I do not like the GPL! I have it under a much more permissive BSD 3-Clause license. See LICENSE.txt in the distributions.

Great!! BSD license is good, too. Sorry I didn't see the LICENSE.txt during my initial short look.

And that's why I made it open source. I could have kept it closed source but the only projects along these lines that seem to survive and progress into anything (OpenTTD, CorsixTH, Caesaria and many others) are all open source. The closed source ones seem to fizzle out and die over time.

I agree. For the sake of history and continuation of culture I strongly believe efforts like this should be free (as in freedom). And even if one wanted to make money, it is still possible with open source anyway.

Donations would be nice but I'm not sure I'd feel comfortable accepting them as I'm not the only developer.

I agree with @Hooman that you should still get some donations. So let me know if and how I can donate, and I'll be happy to donate to other developers, too if that will mean the game getting to 1.0 sooner! :)

Quote
User Interface
I’m terrible at UI design. I can do the programming but the design itself is not my strong suit. I really need help designing a good UI that’s functional, looks good and is intuitive. Any help here would be much appreciated.

Effectively what I need are UI mockups with details about how the different elements work. The basic UI in the game right now is functional but pretty bare.

If you're up for some wireframing I'd be grateful. I'm just genuinely bad when it comes to UI design -- the few windows you see in game are mostly my doing though Goof and others have helped in developing other parts of the UI (e.g., the bottom ribbon). So any thoughts there are most welcome -- though in a separate thread! :D

Good point. I'll download and try to play around a bit more. I already have some thoughts on UI so will make a list and let you know with suggestions! And I'll do my best to mock up some things though I only know Inkscape and not professional wireframing... Is that still useful????

Thanks a lot again for making this game. I'll do my best to give constructive feedback, and please keep up the amazing work!! :D
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on July 31, 2017, 08:07:59 PM
Good point. I'll download and try to play around a bit more. I already have some thoughts on UI so will make a list and let you know with suggestions! And I'll do my best to mock up some things though I only know Inkscape and not professional wireframing... Is that still useful????

Inkscape drawings would be very useful. There are free online tools that can be used as well including Moqups (https://moqups.com/) and draw.io (https://www.draw.io/). Draw.io tends to be more suited toward flowchart design but it can be used for wireframing as well... plus it has excellent integration with Google Docs which means easy sharing of documents.

Moqups is tailored specifically toward UI wireframing but it's technically not free. It has a 'trial' mode but I don't know exactly what the limitations are. Something along the lines of 1 project, 300 layouts and 5mbs of storage or some such. I've used it without signing in, coming up with whatever and then saving an image. With a free account you can save but I don't know where else it goes from there.

There may be other good online wireframing tools as well but these are the two I've actually used and have had good experiences with.

Thanks a lot again for making this game. I'll do my best to give constructive feedback, and please keep up the amazing work!! :D

Thanks for your feedback! Knowing that end users are finding and getting excited about this project helps me to continue development.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on August 03, 2017, 02:13:43 AM
Quote
Good point. I'll download and try to play around a bit more. I already have some thoughts on UI so will make a list and let you know with suggestions! And I'll do my best to mock up some things though I only know Inkscape and not professional wireframing... Is that still useful?

There are many times where I wished I had some Inkscape skills. Those sorts of tools could be very useful.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Goof on August 03, 2017, 04:55:58 AM
I do use Inkscape a lot for technical stuffs.
I'm not an artist, so i use it basicly at work to re/make clients logos, some layout, sketches, ....
But as SVG is basically XML files I used that to generate raffle tickets with a small program to add the counter on the SVG base file and print them.

Last time it was for the Slider control skin for OPHD.
I figured out how to make Inkscape Slice a picture like in Photoshop.
(one file for each part of the skin, named directly out of Inkscape).
It's a very easy in fact but you have to know the trick.
Title: Re: OutpostHD - An Outpost Redesign
Post by: JetMech1999 on October 15, 2017, 03:45:13 PM
I was looking through the posts for the answers to my questions, but couldn't find anything.  So, if I'm bringing these items up that have already been addressed, my apologies.

1. Multiple colonies on the same planet.  Is this something that will be put into the new rendition?  That would really kind of make the "Trade" idea work.

2. Upon development of a space program, will the launch of a colony ship end the game?  Or will it continue?  Any chance of multiple interplanetary colonies?  As if trying to manage one colony wasn't enough, managing colonies on other planets would make life really interesting.  Since the initial research would have been accomplished on the first colony, research on other colonies would primarily focus on making their new home more habitable.  Or maybe have another "rebel" group make off with some people and equipment and have to start from scratch themselves.

3.  Would research move into theoretical physics, such as Faster-than-light travel (I'm a Star Trek geek, too!)?

4. What about extraterrestrial visitors(invaders)?

I know that some of these are going WAY beyond the original thoughts for Outpost.  It's just that, in addition to the less-than-polished design of the game, it always struck me as an unfinished product. It would be great to see this game done the way it should have been done from the beginning.  I'd also love to see it move forward, be the jumping-off point into a bigger universe!  I know that every game has to have an end-game point.  It just seems to me that this could be carried forward so much further...
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 17, 2017, 06:46:11 PM
Hello and welcome!

To answer your questions:

Title: Re: OutpostHD - An Outpost Redesign
Post by: JetMech1999 on October 19, 2017, 05:17:24 PM
That's cool.  That gives me more of an idea where this version of Outpost is headed.  Still sounds like it's going to be a lot of fun.  I knew some of what I put was really out there.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 19, 2017, 07:59:05 PM
It's all about discussion. That's the only way to make a game fun if you ask me. :)

Also, forgive my curtness. I've been dealing with flu this week on top of work and a load of other stuff. I'm usually more articulate.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on October 20, 2017, 02:37:43 AM
I could see multiple colonies on the same planet working. The other ideas sound fun, though I suspect the implementation would be hard, and the result ... probably not so fun.

Leeor_net, it's good to hear from you. I was wondering how the job was going. Figured you must be pretty busy with it. Hope you get over the flu soon.
Title: Re: OutpostHD - An Outpost Redesign
Post by: singthemuse on October 20, 2017, 08:07:12 AM
I think theoretical physics would be a fun end game research tier. Not necessarily for new technology gains or anything but as a mile marker. My thinking is that if a person's colony has the time/resources to support the study of theoretical sciences, then the colony is likely VERY stable and has enough extra supplies and colonists to support that, rather than something more immediately necessary to survival like housing, mining, morale, etc..

Perhaps "theoretical physics" could be an option that would continuously study thus tying up the facility forever unless it is canceled. It could be a large drain on resources too meaning that if players choose it too soon, they would endanger the colony. It could open the door for creating the new starship maybe (after enough cycles of it being studied)? Or perhaps just gives bonuses to other facilities (universities??) while it is being studied.

Just a thought!
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on October 20, 2017, 09:02:26 AM
Ahh, sounds kind of like the "Future Tech" in the Civilization series of games. Once you've researched the entire tech tree, you just continue researching numbered "future techs", with each one adding to your overall score. There was no actual in game benefit to doing it though. It just affected the high score rankings.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 22, 2017, 03:03:22 PM
I think that's what Basic Research was supposed to do. It sped up current research by a few turns... ultimately not that useful.

I was thinking of something similar which would provide some sort of random buff. Like small efficiency upgrades, cost cutting, etc.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Goof on October 22, 2017, 04:34:24 PM
Moral is a big thing in the game.
So just add moral to balance other issues could be sufficient ?
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 25, 2017, 06:02:52 PM
That could work. I still need to fully flesh it out but it currently works with the population model and the birth/death rates of the colonists. Need to get it to work with production and decay rates as well.
Title: Re: OutpostHD - An Outpost Redesign
Post by: JetMech1999 on January 04, 2018, 12:06:08 PM
It's all about discussion. That's the only way to make a game fun if you ask me. :)

Also, forgive my curtness. I've been dealing with flu this week on top of work and a load of other stuff. I'm usually more articulate.
I get it.  No feelings hurt here, it sucks being sick.  Besides, redesigning a game from the ground up is enough of a challenge without trying to incorporate crazy new ideas into the version 1.0 of said rewrite.  Since it's been a while from my last postings, I hope that the new job is going well and that you're feeling better.  Can't wait to see the newest data and graphics. 
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on January 07, 2018, 08:34:38 PM
Glad OPHD is still generating interest even though I've kinda put it on the back burner for awhile.

On that note, I've made a few commits today and am getting the feel to get back into coding. I've settled into my new job, have been offered a permanent position with pay increase and health benefits so I'm far less stressed on that end.

Basically, boils down to I'm starting to pick it back up again.

I don't want to make any promises in terms of time frames... but you can check the SVN/Redmine projects for updates. :D
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on January 08, 2018, 12:29:25 AM
Yeah! And there was much rejoicing.

Checking out the changes now.


Also, congratulations on the job success.
Title: Re: OutpostHD - An Outpost Redesign
Post by: White Claw on January 08, 2018, 06:18:19 PM
Welcome back, Leeor! Looking forward to updates, and congrats on the job. :)
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on January 08, 2018, 07:03:40 PM
Thanks, everybody! :D

Hooman, I saw your change to the initializer -- I didn't realize I had it wrong. Looks like Microsoft added their own non-standard flare once again. Either that or VS2015 doesn't fully implement the standard. Maybe I should just upgrade to 2017?
Title: Re: OutpostHD - An Outpost Redesign
Post by: JetMech1999 on March 25, 2018, 09:32:24 AM
Haven't seen anything new posted for a couple of months.  Just wanted to make sure things are still good.  I know that jobs, family, life, etc. happens and figured that something like that has put the brakes on things for a while.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on March 26, 2018, 03:25:55 AM
Yes, kind of curious if there are any updates to this. I've sort of let my contributions to this slide as well.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on March 26, 2018, 10:15:43 AM
Was thinking about posting a status update. I know it's been awhile and things sort fell the wayside. Suffice it to say my own personal brand of insanity has made it difficult to do much of anything. But I'm starting to feel better again and started poking around the code again. I've started by updating the project to allow for PVS-Studio to analyse it (it's a static code analyzer that's pretty good at what it does). With it I've already fixed a few glaring bugs.

Beyond that, I've almost got the warehouse and production systems in place. It's further developed than I remember (shows you how lost I was for awhile) so I hope to start ramping development back up again.
Title: Re: OutpostHD - An Outpost Redesign
Post by: White Claw on March 27, 2018, 09:58:50 PM
I'm still around also, checking the forums periodically. Things were a bit crazy for me the last couple months, but I'm hoping all that will stay settled. I've not made any new buildings in a while, though I did start some 3D modeling again just a couple weeks ago (not Outpost related). Going to try to finish that project over the next couple weeks (if work doesn't stop me), then perhaps back over to remaking the buildings.

Cheers!
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on March 28, 2018, 02:23:52 AM
Cool, great to hear from both of you.

I just checked out the PVS-Studio Analyzer website. Neat little tool. Looks to do the same sort of thing as Coverity Scan.

White Claw, what's your other project? Anything worth starting a new thread about?
Title: Re: OutpostHD - An Outpost Redesign
Post by: White Claw on March 28, 2018, 08:13:09 PM
White Claw, what's your other project? Anything worth starting a new thread about?

Probably nothing worth an entire new thread, but I went ahead and added it to the other 3D modeling thread since it's completely off topic here.

http://forum.outpost2.net/index.php/topic,5951.msg86223.html#msg86223
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on March 28, 2018, 09:24:14 PM
I just checked out the PVS-Studio Analyzer website. Neat little tool. Looks to do the same sort of thing as Coverity Scan.

It basically is but it integrates well with Visual Studio and its code analysis has helped me find many bugs in my other project Rogue Arena (https://github.com/ldicker83/rogue-arena). I didn't realize how useful static code analysis was. It also turns out that Visual Studio has static code analysis built into it even in the free community edition though it missed a lot of what PVS-Studio flagged (and found things PVS-Studio missed).
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on March 29, 2018, 08:03:13 AM
I love static code analysis.  :)

Which is also one of the reasons why I like compiled languages. They generally do at least some basic syntax and semantic checking up front during the compile stage, so you can catch a whole wide range of errors easily and quickly.

Then there are other software packages (I think one culprit was MatLab), where a program can run for an hour before aborting with a syntax error.  >:(

When I first moved to Ruby, I sorely missed the syntax check from a compile phase. Automated tests become a lot more important in a language like that. Which unfortunately have to be manually written.

It is impressive though what some of those C++ static analysis tools can catch, which a compiler typically won't check for. Glad you got that working.  :)
Title: Re: OutpostHD - An Outpost Redesign
Post by: JetMech1999 on March 30, 2018, 05:15:46 PM
Glad to hear everyone is doing well and that none of you fell off the planet.  Looking forward to the status updates (when life gives you a few moments to post them) as well as any new graphics (test or otherwise).
Title: Re: OutpostHD - An Outpost Redesign
Post by: macksting on May 13, 2018, 03:50:24 AM
Every now and then I scratch the itch to play Outpost, or look for something else that will scratch it.
This is probably the first time I've ever seen a post about a remake within the same year it was last spoken of.
I was gonna say "I'll try not to get too optimistic," but then I checked the other topics, and it looks like this is surprisingly far along.

I wonder if there's some way I can help. I doubt it, but if there's simple scripting or bug testing, you might be able to shove some grunt work off on somebody else.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on May 13, 2018, 05:36:31 AM
In my experience, the most effective way to contribute to a project, any project, is to poke around until you find something you can do, and then just do it. You know your own skills and interests the best. Plus, the majority of projects are generally not organized enough to know where they might need help.

Though I noticed you suggested a few possible ways you could help, which is a better start than most offers to help.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on May 13, 2018, 08:57:54 AM
Hey, macksting! Welcome to the forums!

Yes, I just recently released the newest versions -- see first post for download link.

I'm going to assume you're not a developer... which is great because it means you're a user! Users are some of the most helpful contributors to a project like this. I could use your feedback on any of the topics in this thread (especially the UI discussions). Play the current build, see if you find any issues, if you do, report them. Finding and squashing bugs is an ongoing process and as the lead developer I may not think to go through a series of actions that a user may follow -- e.g., I know how you're 'supposed' to do things so I tend not to deviate from that but that often leads to logic paths I hadn't considered which is where you, the user, comes in. :D

Anyway, keep checking back! It's been awhile since I posted a major update (last one was july last year) but I want to avoid a long development cycle like that.
Title: Re: OutpostHD - An Outpost Redesign
Post by: macksting on May 26, 2018, 03:29:37 PM
Let's see if I'm wakeful enough to wrestle with this today.

Probably not. I'm not entirely accustomed to the process of compiling from source in Linux, so I'm having a little trouble remembering the process and not seeing anything that looks familiar enough to latch onto other than makefile, which eventually I tried, knowing full well I was jumping the gun. (Sure enough, it didn't yield much of use on its own.) I'll go start a topic for this, I think.
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on May 27, 2018, 12:33:33 PM
Huh, that's much more of an attempt than I expected. Indeed, there is a makefile, though there are 2 projects that need to be compiled together, NAS2D and OutpostHD. I'll have to dig up some of my old notes.
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on May 27, 2018, 05:10:46 PM
I set up an Ubuntu VM and tried building from source but I'm getting hung up compiling SDL 2.0.5 (Apt is still using 2.0.4 annoyingly enough). It's a linker error regarding some functions it can't find, I dunno. I suspect after I compile SDL2.0.5 NAS2D will build which will let me build OutpostHD.

Today's been a super lazy day -- been in bed watching star trek all day. Yeah, one of those. :D

I'll see what I can figure out from there maybe with your assistance. I've got all the instructions required for downloading and installing the dependencies to build all of the projects.
Title: Re: OutpostHD - An Outpost Redesign
Post by: macksting on May 27, 2018, 09:38:58 PM
Huh, that's much more of an attempt than I expected. Indeed, there is a makefile, though there are 2 projects that need to be compiled together, NAS2D and OutpostHD. I'll have to dig up some of my old notes.

If you've been waiting to see a unicorn as long as I have... - Molly Grue

I've helped out with a couple things, very much a layman in such matters but willing to learn something long enough to apply it (and then, due to disuse, promptly forget about it.)
Title: Re: OutpostHD - An Outpost Redesign
Post by: Hooman on May 28, 2018, 05:28:35 AM
Ubuntu 18.04 is now out. I just checked the download page. The new version of Ubuntu should have up-to-date Apt packages, that will be sufficient for building OutpostHD.

You can also try the stuff in that docker thread from a couple months back, which was using a Docker image for Ubuntu 18.04.

I think my SDL2 source install script was not complete, in that it only compiled the modules it needed up to date versions of, not all modules used. I'm not sure mixed Apt and source install versions play well together. With all the things I've done locally on my machine, it's possible I missed the mixed version issue in my earlier attempts.


I've had Star Trek binge days. Awesome.  :)

Though I've never seen The Last Unicorn.
Title: Re: OutpostHD - An Outpost Redesign
Post by: macksting on June 15, 2018, 09:54:41 AM
It's probably one of my top favorite books. In some ways it reminds me of some of the more peculiar new wave science fiction stories I've read; if Beagle wrote a science fiction story, I'd eat it right up. The movie's good, too, great actors, kept most of the important parts of the book, music's nice, etc. But I feel it's a rare case where reading the book first would improve watching the film, since it's close enough to the book to not have the film insult the reader's intelligence, and the book gives the events in the movie more context.

Uh, anyway, I'll consider upgrading soon. It's gonna be a busy summer, though.
Title: Re: OutpostHD - An Outpost Redesign
Post by: chris2222 on September 08, 2018, 03:52:25 PM
Hi!  It's been a long time since I last visited this forum.  Every once and a while I think about digging out OP1 and playing it but short on time and busy family life, you all know how it is.  Didn't really get into Outpost2 wasn't as beautiful a game as the original Outpost.  Anyways, I can't recall ever knowing about this Outpost remake, OutpostHD is looking quite awesome!  Just googled "games like outpost" and happened to be reading a forum that led me to OupostHD, this is awesome!
I don't know that I can help but I certainly appreciate all the work that has been done on this project.  I have the original boxed outpost still in great condition with it's manual and a rather large Outpost strategy guide I had bought after a few weeks of playing OP1.  Just wondering if you all have access to these manuals?  I'm pretty sure you do, but if you don't I could provide information from these that could help? 

I realize OPHD is almost ready to release version 0.7.9.  I'm sure everything has mostly been thought about. 
CRTL F12 was a way to force a choice of a natural disaster on your colony.  Monorails I think was never properly implemented in OP1.  I'll have to do some digging, but this looks fun! 

Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on September 08, 2018, 07:37:06 PM
Very glad you decided to pop in and say something! It helps to know that there's a bit of buzz (even if it's just a tiny amount) for OutpostHD.

I also have the manual and the 'official strategy guide' (which is more of the witty quips of Bruce Balfour in book form more than anything else).

The best way to help is to play the game as it is and let me know if you find any mistakes, any bugs, any usability issues and present any ideas you may have. You might think of something I haven't though of or (as in the case with another user (https://forum.outpost2.net/index.php/topic,6164.0.html)) come across a usability issue that isn't obvious to me as the developer. Feedback from users is extremely important and helps me to know where to focus development efforts.

Thanks for stopping by! Hope to see you around more often!
Title: Re: OutpostHD - An Outpost Redesign
Post by: leeor_net on October 06, 2018, 09:27:25 PM
Thought I'd provide a bit of an update for the main OPHD thread. :D

As the various (https://forum.outpost2.net/index.php/topic,6167.0.html) other (https://forum.outpost2.net/index.php/topic,6179.0.html) threads (https://forum.outpost2.net/index.php/topic,5990.0.html) in this subforum suggest, OPHD has seen a huge amount of progress over the last few years. It's really beginning to look and feel like a finished game. To that end, I've been keeping the first post updated to the best of my ability.

That stated, I'm really bad at writing 'flavor text' and the UI panels are beginning to need that. Additionally, the research tree (https://forum.outpost2.net/index.php/topic,6142.0.html) is going to need some help writing the flavor text for the individual research topics. If anybody is up to the challenge, please let me know and we can get something going.

I also wanted to reiterate my appreciation for the support and contributions from everybody here on the forums. Thanks for making this such a great process! I know it's taken a lot of time to become a thing (kind of the nature of a hobby programming project) but I really do appreciate all of the feedback I've gotten!

2018 is drawing to a close and I look forward to pushing development even further in 2019!