Hope you find them as funny as I did. CC-BY if any one is curious.

I just updated my fork to the master ProjectPorcupine branch and now when I try to load the project in Unity, it doesn't load and I get NullReferenceException errors. Before I updated my Fork, it loaded just fine. I'm on Unity 5.4

I didnt watch any of video series about this game, but i want to contribute anyway. This requires more info what should be done, what is done ( i would rather do some coding than watch entire series ). I think this would be useful to a lot of people that want to contribute outside of quil18's channel.

The version of unity that contributors are using should be standardised and listed in the documentation. This is currently a non-issue but will be come important in the future when updates and new version of unity are released.

Later we will hit lots of issues when 2 or even more people were working on the same issue. Maybe we should also use some kind of real time chat? IRC is a bit archaic now, I personally hate Discord so maybe Gitter? It has a great integration with git (even in the name!) https://gitter.im I haven't ever maintained an opensource project so I don't know how the organization of this should go, and how this will really impact our community.

This came up in PR #19 and should probably go in CONTRIBUTING.md

KR is a government-based currency that you get for completing missions, however this is useless for anything other than trading with the government. You use a furniture (called KR Exchange?) to buy stuff (You can't sell stuff for KR--That's like being a freeloader!)

This could also evolve into some sort of Diplomacy system with SETI and stuff like that.

I would like to implement technology and science. I am asking here if you would like to see it in the game or if working on it would be pointless 😄 . My idea is that it would work similary to technology trees in KSP or Civ, where you have to unlock technologies one by one. On start player would have basic technology that would unlock few other technologies and so on. Here is my plan.

1.1 - Job priority system (There would be few different categories of jobs and plazer will be able to specify the priority of each one like you can in RimWorld)
1.2 - Custom science job
2 - Implementing furniture unlocking
2.1 - Technology definition file
2.2 - Linking furniture definition files to technology definition files (Every furniture would need to specify the name of technology that unlocks it)
3 - TechTree rendering

What do you think about it?

In the lua code for furniture the code is trying to access the value stacksize in invetory. This is a property and moonSharp does not like that.

Below I have included a screenshot of where and what error this creates.

Discussion was moved to #86 as we decided to use GOAP instead of this proposal

Proposal to rewrite parts of the Job API

Motivation

While discussing the current codebase with other members of the community today we stumbled upon the current jobsystem many a time as a System that needed tweaking. Throughout the day we were discussing ways to improve on the current system, and it became increasingly clear, that the current system would need some work. We Proposed a partial rewrite in #63. This proposal is an attempt to write a more formal outline of what we think must be done, what should optionally be done and the reasons for doing so. It also describes a proposed Solution we should then talk about.

The Problems

1. Only one global job queue. This leads to dirty hacks like local jobs for a character (fetching of materials) that never even hit the global queue and are difficult for a newcomer to understand.
2. No division of jobs. a worker could have his friend move the materials in place and then just has to come up and build them, rather than doing the whole job himself
3. No good way of doing priorities on a per-character level. This would allow for professions for characters, as well as designated workers.
4. No easy way to compose new Jobs. Currently it is a whole mess of callbacks, subjobs, nested ifs and more.
5. The scope/meaning of a job is too macroscopic. A simple "Build" job might entail several moves, pickups, works and more. This makes it difficult to reason about and debug.
6. Jobs don't expose any real metadata, neither for UI nor programming purposes.
7. No way to react to events. New jobs are only ever taken from the queue when an old one finishes.
8. No way to reserve resources for a job, which might lead to resource contention.
9. No good way to queue jobs from Lua and thus mods.

What must be done

• Characters have their own job queue. When deciding on a job they look at the best candidate from their local and the global queue and decide on one

• Jobs need to be divided into many smaller jobs. At the least the following should be separate Jobs:

  • Moving
  • Waiting
  • Picking/Placing items
  • Interacting with appropriate Objects (We suggest a new IInteractable interface)
  • Deciding on a Followup Job

  This should make composing complex jobs easier.

• Jobs need to be interruptible at any point. They should then be added back to the respecitve queue

• Jobs need to be taggable with metadata. We suggest an IMetadata Interface. This interface should also specify if the job can be executed out of order, concurrently and/or by a different character.

• A extensible priority system needs to be in place. We suggest a global table of weighting functions a job can call against, based on a number of tags the job might posess in its metadata.

What should be done

We suggest a Linq - Like API based on the changes above, that makes composing jobs easy. This API should partly be exposed to Lua as well.

Needed Functions

All the below functions are just an initial proposal i came up with. I might not have thought about every use case we might want to cover so feel free to append to it.

Selectors
Callable On: Initial Method
Returned Interface: IActorCollection
Those select one or more characters that will be appropriate for the job. Selection should expose the following Selections:

• GetNearestCharacter(Tile t) => selects the nearest character
• GetNearestCharacters(Tile t, int count) => selects the nearest characters
• GetNearestCharacters(Tile t, float distance) => selects the nearest characters withind
• GetAll(Profession p) => Selects all characters of profession p
• GetAll(Predicate selector) => Selects all characters where the passed predicate returns true.

Functions
Callable On: IActorCollection, IJobFunction
Returned Interface: IJobFunction
Functions should be the main method of composing jobs. They are chainable and should allow for easy Syntax. The following are the proposed initial Functions:

• MoveTo(Tile t) => The selected actor(s) move to this tile
• MoveRelative(int deltaX, deltaY) => The selected actor(s) move relative to their current tile
• PickUp (Item desiredItem, int desiredAmount) => The selected actor(s) try to pick up the provided item at their current location
• PlaceDown(int desiredAmount) => The selected actor(s) place the desired amount of their currently held items on the floor at their current position
• Interact() => The selected actor(s) call the IInteractable.Interact() method on the Tile in front of them, if possible
• Build (Template t) => The selected actor(s) try to build the template at their current position. The required materials must be in place.
• Repeat(int amount) => The selected actor(s) repeat all commands chained before this one times
  • RepeatUntil(Predicate prdicate) => The selected actor(s) repeat all commands chained until returns true
• Trigger (IEvent event) => The selected actor(s) trigger the provided event when they reach this function.

Triggers
Callable On: IJobFunction
Returned Interface: ITriggeredAction => can be used to revoke an active.
They might react to events or just server as a final call to a composition.

• OnEvent (IEvent event) => Triggers when the event occurs
• OnTimer (int milliseconds) => Triggers cyclically after the amount of
• Queue () => Triggers instantly thus queueing the job

Modifiers
Callable On: ITriggeredAction
Returned Interface: IJobDefinition
This allows us to tag a job with metadata. This is the function that will cause the actual queueing of the job.

• WithMetadata(IMetadata meta) => Decorates the job with the appropriate metadata

Sample

A sample snippet for the Proposed API would be

Character.NearestCharacter(trashcan).MoveTo(trashcan).PickUp("Trash", -1).MoveTo("AirLock").Drop("Trash", -1).Interact().RepeatUntil(m => trashcan.IsEmpty).Queue().WithMetadata(meta)

which would queue a job on the nearest character to jettison the trash from the trashcan.

Final Thoughts

I think the proposed API would server really well for composing jobs on the Fly and especially from Lua code. It should also be intuitive for anyone that worked with Linq before and will also be really extensible.
However this is a version 0.1 of the proposal that i just quickly typed down. Any feedback and criticism would be apprciated.

Regards,
Jan

There should be more resources.
Copper for electronics
Steel for general stuff
Plasteel is more durable steel.

Certain features will need to care about the general type of a furniture, such as the recently committed replaceable furniture, as it stands it requires each specific furniture to be named, which works for now, but in the future, particularly for modding, it can become overly complex, if not completely unworkable. As an example, if a mod implements a new wall type, and a second mod adds a new door type, the new door would presumably list the current wall as something it can replace, but would be unable to replace the modded wall.

Now if there were a generalized type for furnitures, such as "Wall" or "Door" rather than "Steel Wall' or "Basic Door", then each new wall and door could simply be told that it is a wall or a door, and if one mod adds a wall, it will be typed as a "Wall", and a mod adding a door (or even the vanilla doors) would simply be told that they can replace any furniture that is a "Wall", and it would just work.

It could also be of potential use for other features as well, if one were to implement a feature akin to Rimworld with raiders breaking down doors to get in or possibly even walls, they could be told to break any objects of types "Door" or "Wall" rather than either breaking any furniture in their way, or having to base the decision on the movement cost/passability of a given furniture.

Every time i start unity it seams to make these changes:

The question is it is something that should be added to .gitignore or do someone just need to push this to the master once and problem solved.

I have so far been unchecking them from my commits. Are you all seeing the same? And what are you guys doing with them?

I've found some issues with pathfinding and jobs systems (i.e. https://youtu.be/AIhuLfB-9F0 and https://youtu.be/W_M4i7eHz6w?t=32m36s) - will try to document and fix that soon.

If you place the door first, then the walls, the door is never properly rotated.
I think placing a piece of furniture should always call update on surrounding furnite, regardless if the furniture has LinksToNeighbours set to true.
That way, a door can re-orient, if walls are placed adjacent.
I've started working on a pull request on for this.

The standard way to document the workflow to contribute to a project is a CONTRIBUTING file as described in [0]. Going forward this would probably be the best way to let new developers know how to
contribute to this project and also help them learn where this information can be found in other projects.

[0] https://github.com/blog/1184-contributing-guidelines

@lameox - There is something wrong with your Character refactor #45 , I've downloaded a fresh zip from upstream and still this is happening: https://youtu.be/N05saPPNmPo

So this is what we came up with after a long discussion in #75 and #63.

The plan for the new job system and really the new AI system is to use GOAP (Goal Oriented Action Planning).

I won't go into the finer workings of GOAP but there are some great resources out there:
A GOAP rescource website
TheHappieCats video
Quill18s video
A paper on applying GOAP in practice

The general gist is to not worry about dependencies and special/edge cases and only worry about the end goal.

So all the programmer has to do is just specify the desired end result and the system will figure out what needs to be done for the goal to be reached.

This is done by defining actions that a character can take. A action contains what dependencies that action takes (e.g Building a wall requires building materials) and what outcome that action results in (e.g the wall being built). In addition to this a action contains a cost function that is used to calculate what the cost of a action is. This can be in either in respects to resources or time (Efficiency vs. time).

So when a goal is specified it goes through all the available actions that result in the desired result and chooses the least costly solution.

This is a good solution because it allows modders to easily create cross mod support. For example consider the following scenario:

Modder x creates a mod that creates a machine that creates steel plates super efficiently.
And modder y creates a mod that requires steel plates to craft a really cool weapon.

Using some kind of other system, a specific case for the other mods machine might be needed.
But with GOAP this is a non issue. The machine in modder xs mod would just specify an action to create steel plates and modder ys mod would specify a goal that requires steel pates. The system would then figure out that crafting the steel plates is the cheapest way to create steel plates and create the steel plates that way.
And just like that, Done!

Goals that should be solved (please add more):

• Ensure that close jobs are picked first, unless there is something urgent, so that what the character does makes sense to the player.

I think, there should be some kind of TODO list, or list that anyone working on some feture can write down what is he working on, so when somebody else wants to start woking on something, he will no that nobody else is working on it already.

Im not sure if this is necessary, but usually a project of this scale has a "develop" branch that we can submit pull requests to. This way, when you want to release a new version (ie. 0.1.1), then you can merge the develop branch into the master branch.

Okay, this is me being very nitpicky, but oh well...

I noticed that again after having seen the changes in PR #24. Why does our interface end with "Interface"? Interfaces in C# start with a capital I and generally are an adjective ending with -able. There should be no need to write "Interface" at the end of the interface, right?

This is is an outline of what i view is the set of features that is logical for us to move development towards right now and a road map for how i think we should go about getting there. This should all be uncontroversial stuff i line with what @quill18 has already talked about in videos. All feedback is greatly appreciated so we can all move towards a common vision of at least the next few steps in development.

Features to aim for

• Everything is constructed by a character (no magical floor)
• An enclosed with an atmosphere is required for normal functioning of most things
• Characters can go through an airlock to access outside areas (for construction new rooms)
• Game starts with a bare minimum construction (One small room and airlock?) and some materials
• System for generating, maintain and requiring an atmosphere(For now just oxygen)

Roadmap

What needs to be implemented in the engine to accomplish this in rough order that it has to be done. Some things might need to be broken up into several steps.

• Character able to walk on empty tiles
• Character build floor incl. job creation for floor building
• Airlocks, (different door from internal doors or a small room with two doors that we frequently depressurise?)
• Atmosphere requirement for some buildings
• Prevent deconstruction of outer walls and floor in a pressurised zone
• Path-finding logic to handle differentiating between inside and outside (Only exit the airlock when required)
• Job logic to handle bringing material for multiple constructions (Don't bring stuff for only one floor tile on each trip outside.
• Generate initial construction
• Expand atmosphere system. (Flow air between rooms)

Is there any posibility to enable unity cloud build for this project. A up to date build status and a built package to download would be great!

When you place a Mining Drone Station and Deconstruct it the Job remains on the workable tile and the AI is stuck on it.
Trying to figure out where the furniture job may be cancelled or if the job queue should be reset.

Since this was created as a Unity tutorial, it'd be great for beginners (of Unity, programming or otherwise) if we created a set of tasks, labelled them "Beginner" and discouraged people with experience from just solving them. It would serve as an easy way for someone to get introduced to the pull requests, doing something that helps and finding something that they can work on.

I've seen it on many other projects and it seems to be a good way to get people involved.

There might not be any right now, but this can serve as a place to discuss it.

Github has a wiki built in. Might be a good place to consolidate design decisions, code conventions and so on.

Quill has to start it and give out permissions. I think Quill should delegate the job of moderating the wiki to someone he trusts. And that only use the wiki for presenting made decisions.

Thoughts?

Hi guys,

Don't know if you tried the same...

1 - Start the game
2 - Pathfinding Test
3 - Create Mining Drone
4 - Wait for the first 10 steel plates
5 - Create a stock pile
6 - When character moves towards the stock pile delete the Mining Drone

And you will see the unity freezes like hell! !

Anyone had the same issue ?

I think we should add some kind of contribution guideline that says that you should include screenshots if its a visual change.

Yes, I belive a form of A* should be used, but it looks wierd how characters move when going diagonally. A* should be used when, for some reason, you have a maze. Moving in straight lines should be used when moving to something in the same room with NO walls in between.

Right now the localization code fails to load any data. This results in furniture buttons not being created. This is a problem.

I was wondering if there was a way to see what jobs are queued up for the player to complete. If there isn't already, it would be useful to see what jobs they are working on and will work on in future. Also, it would be useful to see what a character is currently holding, resource wise.

As quill often said, we should probably have objectTypes like "furn_steelWall" and separate displayed names for these objects (in this case "Steel Wall"), maybe even with possible localisation dictionaries that get read from XML. Quill himself partly began that effort with the steel walls when he moved from C# to XML/Lua for the furniture and their custom code.

The earlier we do this switch, the less refactoring is necessary when we actually do this, so I'd personally do that before we add any more new furniture or inventory types.

When structuring a stockpile in any size bigger than 2x2 the ai is building from bottom to the top, meaning he is first building the first row then goes back to the bottom to start the second row. A more effective way would be to either build the nearest tiles first or otherwise in a s type manner such as when the ai gets to the end of a row he starts on the top of the next, eliminating the walking time to the bottom of the row.

This will allow for inputs to be dynamically changed and remapped.

currently some files (such as tile.cs) have copyright statements that obviously don't agree with the license file. //================================================================ // Copyright Martin "quill18" Glaude 2015-2016. // http://quill18.com //=================================================================
These should be removed, probably by quill for legal reasons

There would be value in writing an XML file to set up a scenario. It could include the world size, required life support settings, etc. It could allow for scenarios, or just be a foundation for setting certain items to be included.

It might be worth having a separate settings file, for things that aren't likely to change from run to run. Cursor icon would be one such example, I'm sure that others could be derived as well.

I realise that this early... But... This just might work..
So pirates come (when everyone is sleeping?) and steal stuff from stockpiles.

While it is very much encouraged to spam the log to your hearts content while testing, there should be some general guidelines on what debug messages should be allowed to be kept in a final PR. I am currently removing the more spammy ones to prevent lag and to find my own messages in the mix, but there should definitely be some written rules about this in either the CONTRIBUTING file or somewhere more fitting.

As it is currently the game has to generate the entire A*graph every time a floor tile or a piece of furniture is constructed. On my computer this causes very visible slowdown. As shown below my computer uses almost 3 full seconds regenerating the graph.

I am not really sure how to go about improving this so any suggestions would be greatly appreciated

When building or removing floors, there is no 'overlay' to show which floor tiles have been selected, like when you add or remove walls and furniture. This means that it's unclear whether or not you have actually selected the floor. Also, when removing furniture, there is not 'overlay' to see what you have selected to delete. When deleting, the overlay should be red, not green I think.

Where do we get resources in space, outside of internal mining drones?

• Asteroids: Metals, Stone
• Comets: Water
• Planets: Anything
• Traders: Anything
• Pirates: Cannibal food

Where else can you get raw resources? There is also a big question on how that would work. Does asteroid mining involve sending a drone that tosses resources at you in intervals, do you send people and drones on missions that bring back bulk items, or do we just stick to how the internal mining drone work?

The event keyword exists for a reason.

Hello everyone! I guess we're all excited for adding our custom content for this project. Right now almost everything is moddable thanks to quill but... not the UI! It's fine, but we know it could be better. So around episodes 67-68 of the series I took time to make a generic class to load UI sprites and change the actual ones in the UI system.

However, Unity's UI System is a bit funky (because of the way UI elements snap to the screen), so loading sprites and matching element's with their corresponding width and height is a bit a pain in the a**. That's why I wanted to kind of suggest a "convention" or a series of rules that the UI should follow in order to make modding it a bit easier, as well as naming the sprites correctly so everyone can upload their custom mod and add the corresponding UI reference easily.

So, what you think?

Building the stockpile is fine, but at the second the player adds to it the game freezes.

Example

No Idea if this is something on my end, And honnesly propably is.
Any confirmation would be great.

In the current master branch the build menu doesn't add the furniture name to its corresponding UI button.

Some people me included have expressed concern that the job system needs reworking. Both to allow more features, better performance and api. I have a idea about the implementation already. Will make a more detail description in a fem minutes.

If you have a stock pile area with a resource of a non-maximum amount (i.e. 15), when a mining droid have gathered max resources (50) the character will first move to the stock pile and carry the non-max resource (however it will still lie there) then he goes and get the max resource exchange it with what he has in his hand and go back to the stock pile and pile it on the old non-max resource which then dissappears. Then he goes back to fetch the non-max amount which he left at the mining drone.

Proposal for a System to handle inventory dumping

The Problem

I just finished a first refactoring pass over the Character's Job handling functions and in doing so also stumbled over a few places where inventory had to be discarded.

As of now, the Inventory just gets dumped to the floor, and if that does not work, it is just deleted and thus leaked.

I already laid the foundation for any kind of new system in my first refactoring pass (see #45) by implementing a stubbed out function DumpExcessInventory() and replacing the old discard snippets with it.

However i did not implement any functionality other than null-ing the inventory, as i feel this is an issue that needs to be discussed first. I have some approaches in mind, that i would like to talk about.

Approaches

The simple one

The naive approach, in my oppinion, is looking for the nearest empty tile, going there and dumping the currently held inventory.

Advantages

• Easy to implement
• Easy to understand for new contributors

Disadvantages

• Not really flexible/extensible at all
• Clutters the ground with items thus making it visually unappealing
• there needs to be some logic to check, weather the tile we want to dump in is a tile where, i.e. a job is queued. This would lead to suboptimal behaviour of our workers where they would rearrange items on the floor repeatedly in the worst case.

Integration with the inventory manager

The solution I would like quite a bit more would be some form of integration with the InventoryManager we already have. I would like to have all furnitures and jobs to register at the InventoryManager for items they accept. Then, when a character has inventory to dump, he/she can bring those items to the nearest inventory that accepts those items and only if it cant find any revert to dumping on the floor.

Advantages
What i really like about this method, is that quite a few features can be implemented this way:

• Stockpiles that only accept certain items
• Separation of carrying jobs and building jobs. Currently we have no way of letting one character bring ressources for a job and another executing said job, even though that might be quite a bit more efficient
• Designated Carriers and Builders. The carriers would go about and ensure the requested items list stays empty
• Priority system for requesting. An oxygen generator might need batteries more urgently than a stockpile trying to fill up
• Pooling of regionally close requests for the same items (i.e. when building a wall). Carriers could then bring i.e. 20 steel plates at a time and then move about in the destination area, thus fulfilling multiple carrying jobs at once
• Multiple item accepting Systems. There might not always be the need for items to be visible to every other entity on the map. Rather there could be a system the working characters see, one that a automated factories robots can see and so on. This would help relieve cpu stress and also serve to divide up a complex system into smaller manageable ones. This could also be nice for some factorio style logistic robots.
• Based on a system like this there might also be cool interactions for stuff like different maps/regions (maybe we can land on a planet in the future) and easy item transfer between them (a spaceship can see two such systems and thus "link" them)

Disadvantages

• Quite a bit more initial work to implement
• Harder to understand as it is more complex
• More edge cases we will have to test when changing something in the future. This should be unit-testable though.

Final Thoughts

I think the second approach would give us a really solid foundation for future expansions on the inventory system. It also should be less complex in the long run, as we dont have to program each and every new behaviour in by hand but can let the priority and callback system handle them for us.

I also think, that in doing this, it will be easier to integrate with our lua/xml resources as it mostly comes down to a priority field and one or two scripts.

However the decision to implement such a system should not be made by me but rather the community. Let me know what you think and also if we can find another system that is even better for the problem at hand ;)

Regards,
Jan

As the game will evolve we will need a system for requesting graphics, these any person artist or none artist can contribute to and the best graphic will be selected by the requestor. This can probably be accomplished by opening issues explaining the graphic needed, I would suggest a naming scheme of something along the lines of 'Graphic Request: [graphic name]' or 'Graphic Needed: [graphic name]' or 'Graphic Missing: [graphic name]'