Author Topic: OutpostHD - An Outpost Redesign  (Read 9863 times)

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1441
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #50 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.


Offline Galactic

  • Administrator
  • Full Member
  • *****
  • Posts: 140
    • http://www.konker.net
Re: OutpostHD - An Outpost Redesign
« Reply #51 on: January 20, 2016, 12:50:33 PM »
Looking good so far, keep up the good work.
Take me to your leader! I bare the claws of a corndog.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1441
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #52 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

Offline Vagabond

  • Sr. Member
  • ****
  • Posts: 336
Re: OutpostHD - An Outpost Redesign
« Reply #53 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.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1441
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #54 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.

Offline Charles_Bronson

  • Newbie
  • *
  • Posts: 5
Re: OutpostHD - An Outpost Redesign
« Reply #55 on: December 14, 2016, 12:58:22 PM »
thats good progress! Really nice work done!

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1441
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #56 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!

Offline lhark

  • Newbie
  • *
  • Posts: 4
Re: OutpostHD - An Outpost Redesign
« Reply #57 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 :)

Offline Vagabond

  • Sr. Member
  • ****
  • Posts: 336
Re: OutpostHD - An Outpost Redesign
« Reply #58 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

Offline lhark

  • Newbie
  • *
  • Posts: 4
Re: OutpostHD - An Outpost Redesign
« Reply #59 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
« Last Edit: June 11, 2017, 10:01:10 PM by lhark »

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1441
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #60 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 -_-
« Last Edit: June 13, 2017, 08:24:54 PM by leeor_net »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3775
Re: OutpostHD - An Outpost Redesign
« Reply #61 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.

Offline lhark

  • Newbie
  • *
  • Posts: 4
Re: OutpostHD - An Outpost Redesign
« Reply #62 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.
« Last Edit: June 25, 2017, 09:01:13 PM by lhark »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3775
Re: OutpostHD - An Outpost Redesign
« Reply #63 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.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1441
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #64 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.

Offline lhark

  • Newbie
  • *
  • Posts: 4
Re: OutpostHD - An Outpost Redesign
« Reply #65 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 ?