Outpost Universe Forums

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

Title: OutpostHD - An Outpost Redesign
Post by: leeor_net on September 27, 2015, 05:22:40 PM
OutpostHD (Formerly known as Outpost:MIA)

Welp, it's been a decade (or so) and itís been a long time coming but Iím finally ready to say something about a project Iíve been working on for a while. I wanted to wait until I had something substantial to show and I think Iíve finally reached that point. So here it is -- I'm officially announcing OutpostHD. It's a remake of Outpost; Outpost the way I think it should have been done.

Itís still in an early stage of development but Iíve got a lot to show for myself and I think everybody will agree that itís further along than most OPU projects tend to be.

SoÖ here it is:

v0.6.x Builds
(http://leeor.outpostuniverse.org/ophd/screenshots/0.6.0/ss_02_thumb.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.6.0/ss_02.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.6.0/ss_03_thumb.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.6.0/ss_03.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.6.0/ss_04_thumb.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.6.0/ss_04.png)

v0.7.x Builds
(http://leeor.outpostuniverse.org/ophd/screenshots/0.7.0/ss_01_thumb.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.7.0/ss_01.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.7.0/ss_02_thumb.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.7.0/ss_02.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.7.0/ss_03_thumb.png) (http://leeor.outpostuniverse.org/ophd/screenshots/0.7.0/ss_03.png)


YouTube Video:


What's done:

What Needs to be Done

Current Build
You can download the current build here: Current Build (http://leeor.outpostuniverse.org/ophd/ophd_v0.7.0_windows_x86.zip)

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

Change Log
Chang Log for v0.7.0 (https://svn.outpostuniverse.org:8443/!/#outposthd/view/r190/CHANGELOG.md)

Following link is for the most current, unrelease build: https://svn.outpostuniverse.org:8443/!/#outposthd/view/head/CHANGELOG.md

Issue Tracking & Task Management
I really really really like to use issue and task tracking software for projects like these. It helps to get everything laid out and also allows users to file bug reports, etc. Leviathan set up a Redmine installation for OPU. If you're interested in helping out, hop on over and get yourself registered. PM me your username and I'll get you added to the project.

http://redmine.outpostuniverse.org/projects/outposthd

WIKI Page

http://wiki.outpost2.net/doku.php?id=opu_projects:active_projects:outposthd

Pretty much just restates what's here but formatted a bit better.

Older Versions

Opted to clear out some of the older links in this thread -- all of the older stuff can be found here: http://leeor.outpostuniverse.org/ophd/

Goals
I want OutpostHD to be freely available to everybody, so itís open source. The code is available via OPUís public Subversion Repository.

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.



How You Can Help
This isnít a small project but I intend to complete it. Iíve already made a lot of progress but I could really use some help if this project is to be completed in a short amount of time. If youíre interested, reply to this post with what youíre able to help with and what you want to contribute.

Where to get the Code
The code is on its own OPU Subversion Repository. Code can be checked out from the following link:

https://svn.outpostuniverse.org:8443/svn/outposthd/

Building from Source
OutpostHD is written in C++ and takes advantage of several well-known libraries and my own 2D game development framework called NAS2D (http://nas2d.lairworks.com).

To build from source you will need Visual Studio 2015 (any version) with C++ language support installed. After checking out the current SVN repository, you will have everything you need to build and run OutpostHD including all of the necessary dependencies and their binary files (DLLís). The original project was only set up to build in 32Bit mode but the compiler and dependencies are available to build in 64Bit.

OutpostHD currently only has a Windows build... I do not have a mac and will not use Linux so I personally won't be maintaining these ports but the code should be buildable as-is on MacOS X. Linux builds will need to make a few modifications to NAS2D (specifically in the Filesystem code, maybe 10 lines total) in order to build and run properly. I haven't maintained the Linux code since I built it on Fedora and Ubuntu maybe 5 years ago but the Filesystem code hasn't changed a whole lot. Contact me if you want to help out but fixing the few bits of code needed to make NAS2D work on Linux.

NAS2D Source code can be found on GitHub: https://github.com/lairworks/nas2d-core

Graphics
Currently Iím using the original Outpost graphics as created in the early 90ís. They are old and primitive with no support for transparency and are in an 8-bit color depth. Iíve been converting them to modern PNG formats and optimizing the sprite sheets for use in a modern graphics engine.

However, I donít want to keep using the old graphics. One of the goals of this project is to supply a new set of visuals designed for modern graphics hardware in 32Bit color depths.

There are two reasons behind this. 1) It will provide a fresh new look to the game and 2) will help to prevent any potential CNDís which are always fun

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.

Programming
Iíve developed OutpostHD thus far using C++ and several well known libraries and a 2D game development framework of my own design called NAS2D. All of the boiler plate code is handled. What I need help with is developing the logic for the game.

Research Tree & Research Management
This one is the biggie. I have no idea where to start with this one. Should I use the original Outpost research tree or develop a new one? In either case, it would need to be developed and a good interface provided.

Which leads me to topic #2. I hated the way the original game handled research. There were games where Iíd have dozens of labs working on a research project but I never knew if having more labs on a particular subject actually made progress move faster. It appeared to. But even more importantly, it was TEDIOUS. If you had a dozen labs, you needed to click on each lab individually and set its research topic.

So there it is -- the research tree needs to be defined and implemented and lab management needs to be developed.

Truck Routes
We've talked about this one a lot in this thread and a bit on IRC as well. The consensus is that routes will be automatically generated by mines once they activate. They will find the Smelter nearest them that is able to handle the resource income from the mine. The user's job is to manage the number of trucks on a particular route and possibly also to manage which mines are routing to which smelters.

See the redmine task (http://redmine.outpostuniverse.org/issues/3) describing this issue and the related discussion surrounding it.

Changes to the Design

See OutpostHD's Wiki article (http://wiki.outpost2.net/doku.php?id=opu_projects:active_projects:outposthd) for details.
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.

https://youtu.be/PqqDt88pCCY
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.