Then maybe it’s the vehicles that are the problem?
Ovens and fridges could be converted to a vehicle style system without much hassle. This is probably the best choice because the vehicle system already has a system in place to handle wiring, power transfer, power consumption, recharging, and all those other fine things. Smaller powered furniture like lamps and whatnot could, in theory, be implemented as foldable vehicle parts, where they have to be “unfolded” (really just converted from an inventory item to an in game vehicle) to deploy, then they just be connected like other vehicles.
A system like this has been discussed for powered machinery and other tools, possibly with special part flags that ensure that certain parts can’t be removed without complete disassembly, or that those parts can’t be installed on other vehicles.
I still think that a unified map object system can be made to work. Furniture and vehicles just have too much in common to be so different code-wise. They could exist in such a state that the game can track both as either. A vehicle that is not moving may just as well be furniture and accessed as such. A furniture object that is being moved may as well be referred to as a vehicle. It makes a lot of potential things far less complicated. Wiring, working stationary refrigerators/ovens/forges/etc, folding chairs/tables/etc. Moving sofas/beds/tables/shelves as connected entities, using furniture as frames for vehicles, building furniture into vehicles as-is, unified dragging/collision/interaction mechanics, proper weight for furniture… lots of things can be done or made simpler to use and expand on.
Generally speaking, there is a lot more furniture than there are vehicles. Tracking all the information currently being tracked for every vehicle for every piece of furniture as well is unrealistic.
True, but that speaks more of how needlessly complex the vehicle tracking is. Vehicles could well be tracked as furniture-like objects when not moving. The point is a unified code base for them, not literally handling furniture the same way vehicles are now. So that they both descend from the same class and can use the same code when it comes to (the increasingly numerous) overlapping functions.
I see them more like this:
[ul][li]Have lamps be items[/li]
[li]Store “attached to” value similar to jumper cables[/li]
[li]Move jumper cable tracking code (breaking off when too far etc.) to a common function[/li]
[li]When consuming power, have them consume it from the targeted vehicle instead[/li][/ul]
This code could be later on change to a tool mod, to allow using tools by connecting them to vehicle power source. This would be really useful.
Vehicles are complex multi-part structures that fulfill multiple functions at once, track a lot of stats, perform updates per turn, are processed on load, are relatively slow to access in the code and require more complex access methods.
Furniture is a secondary terrain type, where all instances are totally identical and don’t actively perform any function.
Honestly, vehicles are more similar to monsters than to furniture.
I don’t see how would you achieve this merge.
There are few functions vehicles and furniture could share, but those would be mostly “has_flag”.
The unification is simply unfeasible on the basis of vehicles being instanced as objects and furniture being instanced as ID.
What do they even have in common? That they fall, can be dragged and have flags?
It’s simple. Base the vehicle class on the furniture class. You keep thinking of vehicles as whole entities first, whereas that only counts when the vehicle is moved. As far as most features go, vehicles are just blobs of static objects with flags, parented to a single entity. You can duplicate the furniture-tracking code in vehicles, and change the “vehicle” entities so that they only handle movement and construction. As an added bonus, furniture will finally have more states than “fully intact” and “smashed into constituent parts”, because as far as code they can be single-item vehicles (like a single placed frame) and will have durability and mass. As an additional added bonus, with proper handling of static vehicles you will increase performance in cities if current vehicles are as resource-intensive as you lead me to believe. Just flag all static vehicles like you would furniture, and you’ll be able to process them regardless of whether they’re actually furniture - and when a player interacts with one you can read which vehicle it belongs to (via flag and UID), scan the surroundings for “furniture” belonging to the same vehicle, and call the constructor for your “vehicle” class with the results.
As an extra additional added bonus, there’s your implementation for “dockable” vehicles. Make vehicle go idle, flip adjacent idle vehicle’s tiles’ “parent flag” to same vehicle, activate vehicle again.
Furniture isn’t even a class.
Each instance is literally just a single ID.
As far as most features go, vehicles are just blobs of static objects with flags, parented to a single entity.
Flags, stats, tracked passenger ids, targets, contained items and configuration info.
Overall enough data to be stored in a separately addressed structure rather than a submap-sized square array.
change the "vehicle" entities so that they only handle movement and construction.
And per-vehicle cache calculations that can’t be expressed in terms of individual components, per-turn updates, charge counting, configuration of the whole vehicle, turrets, folding, scoops, rotations…
As an additional added bonus, with proper handling of static vehicles you will increase performance in cities if current vehicles are as resource-intensive as you lead me to believe.
The problem isn’t vehicles being expensive to process (they aren’t perfect, but aren’t bad), the problem is keeping the track of all of them.
The issue is mostly about caching. Could become about memory size if handled badly.
Current implementation of vehicles is that they are “floating” in space, their position described by coordinates. This means that before processing them, they all have to be checked. Advantage of that is that they can store a lot of data which can be “moved” just by changing the coordinate.
Furniture is a 3D block of IDs.
Changing the coord option to ID option would require dumbing down vehicles so much they wouldn’t be able to perform their functions. So the only option left is IDs to objects.
And changing ID blocks to objects would slow down all of:
[ul][li]Fire processing[/li]
[li]Movement calculations[/li]
[li]Mapgen, saving and loading (counting as one because it doesn’t happen per-turn)[/li]
[li]Cache regeneration on map shifting[/li]
[li]Pathfinding[/li][/ul]
And that is assuming they would either get a cache like vehicle one or share cache with the vehicle one.
The only real performance gain from merging furniture and vehicles would come from unified check of furniture_or_vehicle, which would most likely be quite minimal.
So the idea is to make it so you can convert household appliances to being able to run off of a generator using a jumper cable? How about using an UPS? It’s wireless power isn’t it?
We could always have this as an additional world option until the performance is ironed out.
For people with mid-high gaming PC’s like me, performance really isn’t an issue.