Planning 0.2 Milestone

[koosemose]

We're coming close to the 0.1 milestone deadline, and while we don't quite have everything in place yet, I would like to go ahead and get the ball rolling on what we want to aim for in 0.2.

That being the case, I'll start with Listing things that either currently have open issues and no (known to me) current implementation plans. Not all may be appropriate for 0.2, but it's somewhere to get started. Feel free to suggest other things that I may have missed. Also note, I would prefer to focus this issue on deciding what is actually appropriate for 0.2, and what should be pushed to later milestones, rather than discussion the specifics of each feature. We can nail down specifics further once we have a more fully formed preliminary list.

0.2

Small

• [ ] Save/Load Jobs #177 #1590
• [x] Localize our localization (displaying US English as opposed to en_US, for example) #358
• [x] Save Load Logic for power system #602
• I'm not sure exactly what needs saved, other than the stored power on Accumulators
• [x] Asynchronous Saving #1459
• Any system which prevents PP from being reported as not responding would be acceptable
• Any speed ups in saving aren't necessary, but would be useful.

  Large

• [x] Integrate Power System and Utilities
• Rather than being universal, a power network should be anything that is connected to a given set of Power Cables.
• This requires utilities to intelligently build a network with all connected utilities of the same type.
• Should properly handle two power networks joining, or a single power network being split (by adding or removing cables)
• [x] Gas/Liquids/Fluids System @koosemose
• While there are currently gases that are kept track of in a dictionary in each room, some form of "Gas Network" would be desirable, in preparation for having gases transported by Utility pipes.
• Liquids should have a generally similar implementation.
• Liquid and Gas networks may be able to be implemented as a single fluid network due to the many similarities in how they would function within a network.
• Should roughly mimic how power is implemented, to ease future integration with utilities (Some of the parts of the power system may need altered to be more generic to allow them to be also used by fluids, most notably Grid and PowerConnection)
• Integration into Utilities is not required at this time, but is considered desirable if achievable at this stage.
• [ ] Metastockpiles
• Allow Stockpiles to be grouped together, and request items and handle where they go as a whole rather than each stockpile individually
• May require Job system having distinct haul jobs, rather than hauling stuff to a stockpile implemented as a job that requires material.
• [x] Main Menu (Initial PR in #1461 )
• Should have New Game, Load Game, Settings, and Exit at a minimum.
• [ ] Core Game as Mod #772
• Once the core game (or at least portions of it) are implemented as a mod this should help pave the way for proper mod loading logic.
• [ ] Further improvements to Job System #726 #1590
• [x] Path-finding logic to handle differentiating between inside and outside (Only exit the airlock when required)
• I'm not sure this is required as a distinct thing, but rather will end up as a side effect of other improvements (such as airlocks reporting a proper cost to pathfinding to account for difficulties in going outside)
• [ ] Gear #268
• Should have multiple gear slots (head, torso, hands, feet, for example)
• Should have at least one piece of gear
• [ ] Decouple World and WorldController as discussed in #353
• WorldController currently handles many things that are applicable to the play session as a whole (and in some cases the entirety of the game, that don't need recreated between games).
• We want some amount of separation between things that should exist in the scope of "You are currently playing PP" and things that exist only in the current playthrough. (Possibly also separation between what exists for the current world and the playthrough if we still want multiple "areas" we can send our crew)
• [x] Room Spanning Multiple Levels? Discussion @ #1491
• This may require more base work before being ready to implement.
• Currently rooms only care about their floor on room creation, if a floor tile is removed, the room stays intact.
• Optimally a hole in the floor should either expose the room to space, or join it to the lower room.
• What about going up? Having some type of separate "roof" tile seems needless tedium, and having to build a floor on the next level up feels awkward (In addition to problems on the top level, either enclosed rooms can't be built on top level or the top level is special and doesn't require roofs built with floor, which seems inconsistent)
• [ ] Effects #1487
• Fire as an initial implementation, others implemented as needed.
• [x] Pathfinding Optimization
• Now that pathfinding searches all levels, there is typically a momentary hang when a character needs to pathfind anything distant (particularly outside of the base).
• We need some optimizations in pathfinding code, using the Room_Graph would be one way, but will still have a fair amount of slowness when pathfinding outside of the base.
• I would like us to achieve enough optimizations that characters don't teleport a full tile on their first movement from pathfinding.
• Alternatively, perhaps this could be achieved by doing the pathfinding asynchronously, so they would just take a bit longer to get the path, and would just stand around for a moment before moving, rather than having the obvious frame drop.
• [x] 64 px base character sprite

  Ongoing tasks

Bugfixing, always Bugfixing Component System

• Elements of Furnitures (and possibly later other Buildables) that are not common to all furnitures but potentially shared among many should be implemented as Components that can be used for what furnitures need them without each implementing them from scratch, but not polluting class files with things that other furnitures may not need.

Continuing UI improvements (discussed many places)

• Continue moving more of our UI to code based creation, optimally we should never have to directly create prefabs to implement any new UI system, and a mod should be capable of creating UI that exactly mimics anything we've implemented in the core game.
• This is likely an ongoing goal, and may not be completed in a single milestone.

  Future Milestones/Optional tasks for ambitious folk

Storyline #431 (likely best for a much later milestone) Lighting, Lights and Darkness #533 (Possible library for 2d lighting: https://github.com/f15gdsy/2D-Light-of-Sight-Unity )

• [x] Health system #544 Minimap #566
• [x] C# Modding Improved Map Generation #306 Gravity

[UnknownDude1]

I just wanted to add, it might be a good idea to finally make at least a basic main menu. I know over here #1461 @Ohda has already started with this but maybe we should get something a bit bigger (with options, load etc.) in place.

[Tranberry]

The question for me is still: are we past concept stage / are we at alpha stages - or not?

And my answer is that we are still in proof of concept stage - meaning that ambitious features are not needed to achieve the next milestone.

I like most if not all of the suggestions as of now.

[bjubes]

I agree with being in a concept stage. We cant be in an alpha until all the furniture is balanced against each other and general gameplay progression makes sense. right now that is not the case.

[sboigelot]

Concept stage 👍

[mikejbrown]

What he said ^^^ :+1:

[pderuiter77]

• Gravivty
• Move code to separate components (to continue what dusho has started:) )

[mikejbrown]

726 and #772 have been bumped from v0.1, so make good candidates for v0.2. The same will probably happen to #602 since it's 80% there but seemingly inactive.

EDIT: Bumped #602.

[mikejbrown]

Bumping "Job logic to handle bringing material for multiple constructions (Don't bring stuff for only one floor tile on each trip outside." from v0.1 to v0.2. Also bumping "Path-finding logic to handle differentiating between inside and outside (Only exit the airlock when required)".

[koosemose]

Updated original post to include additional suggestions, and sorted things into what I thought was reasonable goals for 0.2.

Once something approaching a consensus is reached, I will begin to get discussion going on nailing down exactly what we want for each of these features, or at least more specific ideas than we had for several for 0.1.

[dusho]

maybe also C# modding as alternative ? useful for 'heavy' mods and also more handy when it comes to refactoring that is happening a lot in early stages

[Tranberry]

@dusho how would that differ from how it is now?

[mikejbrown]

@Tranberry I assumed @dusho was talking about allowing a modder to, say, drop a dll in the mod folder and have it work. Not sure what would be involved in practice to make that work. Maybe he meant something different?

[dusho]

yes.. either .dll could be compiled, or game will compile all mod .cs at startup, produce .dll and load it so instead of .lua files, there can be .cs files containing methods that will be hooked from .xml

[Tranberry]

sounds good to me, but I wouldn't know if it creates another hurdle on the path to actually achieve something close to a alpha game or not.

[mikejbrown]

I'd consider dll loading to be a feature that could be implemented at any time. Don't see why it has to come pre-alpha. Lua modding should be enough to get people started. Only when popular mods get big/complex enough to warrant the speed boost do we really have to start worry about the possibility.

(That said if it turns out to be an easy thing to do, and do without breaking things catastrophically, make a PR whenever you want!)

[koosemose]

Adding more details on most elements of the milestone, trying to get a more clearcut "here's what we want to achieve" for this milestone.

And due to the nature of this project, I think anything on the "future milestone" list can likely be considered as "We're not aiming for it right now, but if someone can do it within the current milestone, that's fine".

[TomMalbran]

We could add to the list: Trading and Mining improvements/updates. Those are 2 systems being worked on that will continue to be improved. Might not get done in the next milestone, but they might get improvements.

Also inside the UI updates, we can add the redesign that is slowly happening. Maybe construction menu improvements, and other UI enhancements.

[vogonistic]

Most of these improvements are great core system tasks, but the list is a bit long and we might want to add some purely gameplay tasks too.

We should take this list and split it based on if there is a proposal and implementer to fix the issues and only include the ones that have a plan.

I prefer shorter release cycles over long ones. Especially when we still let people work on tasks that aren't on this list.

[koosemose]

There've been several times when I've seen people looking for a "something to do" having open tasks looking for an implementer allows that.

And to a degree this is still a list of everything I could find that has been talked about, the only things that I moved to "future" are things that I was fairly sure would require more framework in place.

[mikejbrown]

What about a due date? Quill gave 1 month for 0.1 and we almost made it. Considering the current slower pace of development, might I suggest the (completely arbitrary but nice and round) Dec 31?

[mikejbrown]

I've added all the issues/PRs currently linked in the OP to v0.2. Feel free to disagree if you disagree. :grinning:

[Tritaris]

I currently have a start on the world generation. #1269

[koosemose]

I personally prefer Jan 1 for a due date (due to New Years Eve), but something around that time frame is good in my opinion.

[mikejbrown]

Gone ahead and set it to Jan 1. It can always be bumped.

[Ohda]

2 points i think we need to add here somewhere :

• Improve Player Inputs Management : For now it's really difficult to have the same key to do differant actions depending of the context. Handle Mouse Actions and Keyboard Action with same system ... Mabye not 0.2 but the sooner the better, we need at least a system that can extend well.
• Mabye an ambitious task for ambitious dev but i think we need to add some features so players can fail. And the more obvious way to do that is to add some ennemies that can kill characters so player can start thinking for a strategy to fight against that. I think this is need as proof of concept stage

[koosemose]

At this point, 0.2 is pretty much set, start new Issues for these, and they will at some point end up in a milestone.

Regarding enemies, and failure states in general, I would prefer to put that sort of thing off until the game is at some sort of "Playable level" with fewer core features still being worked on, just due to the difficulties in testing having failure states such as enemies can bring.

[Geoffrotism]

can you update the OP, i think

Room Spanning Multiple Levels? Discussion @ #1491

and

Main Menu (Initial PR in #1461 )

have been accomplished.

Also, shouldnt we move Gear to a new milestone if we plan on changing how character sprites work?

[koosemose]

Multiple level rooms is still in PR because due to the weird way TileTypes functions it breaks loading saves, and I'm not sure I can find a workaround.

And a gear system doesn't initially have to have sprites or interact with the sprite system, just have a way for a character to know they have a given piece of gear and it do what it should do (add some kind of armor, or allow them to fly in space or whatever)

[koosemose]

We didn't quite hit the milestone, but we got a lot done, closing this as we begin our journey to the next milestone.