Crtl Z/Undo

[Bill Nye]

I just started playing the game, so maybe its not working for me. Is there a way to undo? Please for the love of all that is holy there better be.

[Captain Pothead]

No. No undo feature. Its has been a subject since the game came out.

[Phoenixflieger]

So far you cannot undo build items. You can bulldoze them and get a (full) refund (if not having spent too much time since placing)

But there is dlc coming Nov 20 which promises a lot of small features that so far aren't all revealed yet!

[Exilyth]

Undo has been requested a lot.

Building something and misclicking and suddenly having a wall or something stuck/duplicated in the middle of a build or deleting that one rock you know you won't be able to place exactly like that again hurts.

What helps in the absence of undo is saving often.


The perspective camera mod can help with placed stuff - the ability to fly into a build and remove that one misplaced item is nice to have (also makes painting/coloring stuff easier).

[Bill Nye]

I don't care if i get charged if I undo. It should not be hard to keep a short history record of actions that can be undone. The only reason why they wouldn't add it is because they are lazy. Super lazy if they don't even acknowledge it.

[Sebioff]

Originally posted by Space Cat:

I don't care if i get charged if I undo. It should not be hard to keep a short history record of actions that can be undone. The only reason why they wouldn't add it is because they are lazy. Super lazy if they don't even acknowledge it.

It has been asked and acknowledged many times, for example here. It's harder than you think.

[Exilyth]

'undo' is a variation/extension of the command pattern (it's also the example used by most explanations of the command pattern). It's not hard to code, but there's loads of stuff to refactor if the code hasn't been coded with undo in mind. Also some state to remember.

Basically, a function gets replaced with a call to the execute method of a command object and what was done within the function before is now done in the execute method. All command objects inherit from an abstract base and need to implement an execute function which performs the command and an undo function which reverts the command.

For many actions, this should be easy as there is already functionality to e.g. add/remove objects which would 'just' need to be refactored into commands and paired, f.e. the undo of adding a deco item is removing that deco item, the undo of removing stuff is adding that stuff back.

Slightly different are actions which need to remember state: the undo of a color change is the restoring of the previous colors, the undo of changing a landscape texture/type is the restore of the previous type and so on. There are some special cases, e.g. upon placing an object so that it removes other objects, the objects replaced should be restored upon performing an undo - f.e. when a willow replaces a bunch of poplars, one would expect to get back the poplars upon doing an undo.

Once all actions have been identified and refactored into command objects (with execute and undo functions), one only needs to remember the last N actions performed and when undo is called, one needs to go through that list in reverse order and remove actions, calling their undo function before deleting them.

A special case are 'compound actions', e.g. placing a blueprint performs a combination of place attraction, place decoitem and place shop actions (and maybe even others). Such actions could be implemented as a container for actions: on execute, all actions within the container are executed and on undo all actions within are undo-ed.


Tbh, you could probably sit down with a piece of paper, read the code and write down all the actions in the game, then sort them into stateless and stateful actions, find any pairs (e.g. add/remove some object) and identify compound actions. With that list, you could then go through the code and refactor the action functions into command objects. Each of the steps isn't hard, they're just time consuming.


Ofc, this is speaking from my own experience - I don't know what the Parkitect code looks like and how much the unity sources would support such changes or make them more difficult. I'd still be inclined to say this is an easy task, but depending on program architecture with an excessive amount of code rewriting and thus quite time consuming.


TL;DR:
I oppose the notion that implementing undo is hard, but concede that it's a lot of work.

[Bill Nye]

Originally posted by Sebioff:

Originally posted by Space Cat:

I don't care if i get charged if I undo. It should not be hard to keep a short history record of actions that can be undone. The only reason why they wouldn't add it is because they are lazy. Super lazy if they don't even acknowledge it.

It has been asked and acknowledged many times, for example here. It's harder than you think.

We would be more than happy to fund a gofundme

[nannerpuss]

Originally posted by Exilyth:

'undo' is a variation/extension of the command pattern (it's also the example used by most explanations of the command pattern). It's not hard to code, but there's loads of stuff to refactor if the code hasn't been coded with undo in mind. Also some state to remember.

Basically, a function gets replaced with a call to the execute method of a command object and what was done within the function before is now done in the execute method. All command objects inherit from an abstract base and need to implement an execute function which performs the command and an undo function which reverts the command.

For many actions, this should be easy as there is already functionality to e.g. add/remove objects which would 'just' need to be refactored into commands and paired, f.e. the undo of adding a deco item is removing that deco item, the undo of removing stuff is adding that stuff back.

Slightly different are actions which need to remember state: the undo of a color change is the restoring of the previous colors, the undo of changing a landscape texture/type is the restore of the previous type and so on. There are some special cases, e.g. upon placing an object so that it removes other objects, the objects replaced should be restored upon performing an undo - f.e. when a willow replaces a bunch of poplars, one would expect to get back the poplars upon doing an undo.

Once all actions have been identified and refactored into command objects (with execute and undo functions), one only needs to remember the last N actions performed and when undo is called, one needs to go through that list in reverse order and remove actions, calling their undo function before deleting them.

A special case are 'compound actions', e.g. placing a blueprint performs a combination of place attraction, place decoitem and place shop actions (and maybe even others). Such actions could be implemented as a container for actions: on execute, all actions within the container are executed and on undo all actions within are undo-ed.


Tbh, you could probably sit down with a piece of paper, read the code and write down all the actions in the game, then sort them into stateless and stateful actions, find any pairs (e.g. add/remove some object) and identify compound actions. With that list, you could then go through the code and refactor the action functions into command objects. Each of the steps isn't hard, they're just time consuming.


Ofc, this is speaking from my own experience - I don't know what the Parkitect code looks like and how much the unity sources would support such changes or make them more difficult. I'd still be inclined to say this is an easy task, but depending on program architecture with an excessive amount of code rewriting and thus quite time consuming.


TL;DR:
I oppose the notion that implementing undo is hard, but concede that it's a lot of work.

I gotta be honest here though, you are trying very hard to explain why a command that has been a part of computing since DOS is unavailable in a video game made in 2019. It would be one thing if Ctrl + Z were a rarity in "builder" or sim games, but that's hard to find evidence of, although I'm sure if you go back to the Sim City games of the late 90's, early 2000's you might find a title or two that didn't support an Undo option. Anyone who has ever played a city builder at this point is accustomed to even the worst games having such a basic feature, so it's dumb-founding why such a well-made game like Parkitect doesn't support a command and concept as old as time. Add to that Planet Coaster being the Coke to this Pepsi and it has quite an advanced build mode, although that comparison is unfair considering the engines the games run on and the intent of the game design and mechanics. But just knowing the other game out there right now in the same sliver of market as Parkitect includes an Undo action the way any other game I have does (Cities: Skylines, Cities in Motion, Tropico 5, etc.) only confuses people/frustrates people more. If this were some kind of experimental feature or people were expecting non-isometic building with free rotation, that's one thing. But this is Ctrl +Z.

What I'm trying to say is that you may have the best logic in the world, but for 98% of people out there, it's mind-boggling why a brand new game with a build mode and a high probability of accidentally misplacing objects doesn't have something I used on text-based console games 35 years ago.

EDIT: Also, I completely understand your reasons and logic behind not implementing it now at the snap of a finger, because games do not work that way. But the thing I question is the design decision from day one to not include Undo. Was this intended to be a mobile title or maybe on console or something originally? Or was it a technical limitation of some kind?

[Bill Nye]

Originally posted by nannerpuss:

Originally posted by Exilyth:

'undo' is a variation/extension of the command pattern (it's also the example used by most explanations of the command pattern). It's not hard to code, but there's loads of stuff to refactor if the code hasn't been coded with undo in mind. Also some state to remember.

Basically, a function gets replaced with a call to the execute method of a command object and what was done within the function before is now done in the execute method. All command objects inherit from an abstract base and need to implement an execute function which performs the command and an undo function which reverts the command.

For many actions, this should be easy as there is already functionality to e.g. add/remove objects which would 'just' need to be refactored into commands and paired, f.e. the undo of adding a deco item is removing that deco item, the undo of removing stuff is adding that stuff back.

Slightly different are actions which need to remember state: the undo of a color change is the restoring of the previous colors, the undo of changing a landscape texture/type is the restore of the previous type and so on. There are some special cases, e.g. upon placing an object so that it removes other objects, the objects replaced should be restored upon performing an undo - f.e. when a willow replaces a bunch of poplars, one would expect to get back the poplars upon doing an undo.

Once all actions have been identified and refactored into command objects (with execute and undo functions), one only needs to remember the last N actions performed and when undo is called, one needs to go through that list in reverse order and remove actions, calling their undo function before deleting them.

A special case are 'compound actions', e.g. placing a blueprint performs a combination of place attraction, place decoitem and place shop actions (and maybe even others). Such actions could be implemented as a container for actions: on execute, all actions within the container are executed and on undo all actions within are undo-ed.


Tbh, you could probably sit down with a piece of paper, read the code and write down all the actions in the game, then sort them into stateless and stateful actions, find any pairs (e.g. add/remove some object) and identify compound actions. With that list, you could then go through the code and refactor the action functions into command objects. Each of the steps isn't hard, they're just time consuming.


Ofc, this is speaking from my own experience - I don't know what the Parkitect code looks like and how much the unity sources would support such changes or make them more difficult. I'd still be inclined to say this is an easy task, but depending on program architecture with an excessive amount of code rewriting and thus quite time consuming.


TL;DR:
I oppose the notion that implementing undo is hard, but concede that it's a lot of work.

I gotta be honest here though, you are trying very hard to explain why a command that has been a part of computing since DOS is unavailable in a video game made in 2019. It would be one thing if Ctrl + Z were a rarity in "builder" or sim games, but that's hard to find evidence of, although I'm sure if you go back to the Sim City games of the late 90's, early 2000's you might find a title or two that didn't support an Undo option. Anyone who has ever played a city builder at this point is accustomed to even the worst games having such a basic feature, so it's dumb-founding why such a well-made game like Parkitect doesn't support a command and concept as old as time. Add to that Planet Coaster being the Coke to this Pepsi and it has quite an advanced build mode, although that comparison is unfair considering the engines the games run on and the intent of the game design and mechanics. But just knowing the other game out there right now in the same sliver of market as Parkitect includes an Undo action the way any other game I have does (Cities: Skylines, Cities in Motion, Tropico 5, etc.) only confuses people/frustrates people more. If this were some kind of experimental feature or people were expecting non-isometic building with free rotation, that's one thing. But this is Ctrl +Z.

What I'm trying to say is that you may have the best logic in the world, but for 98% of people out there, it's mind-boggling why a brand new game with a build mode and a high probability of accidentally misplacing objects doesn't have something I used on text-based console games 35 years ago.

EDIT: Also, I completely understand your reasons and logic behind not implementing it now at the snap of a finger, because games do not work that way. But the thing I question is the design decision from day one to not include Undo. Was this intended to be a mobile title or maybe on console or something originally? Or was it a technical limitation of some kind?

I would of thought doing an undo command would be along the lines of:

-------------------------------------------------------------------------

place.instance:fry_stand ( "13" . "13" "5")
rotation ("180")

input "crtl" + "z"

remove.instance:fry_stand ( "13" . "13" "5")

-------------------------------------------------------------------------

but apparently its super complicated

[Sebioff]

Originally posted by nannerpuss:

But the thing I question is the design decision from day one to not include Undo.

Well, as I've explained, the reason is simply that it is really quite difficult and a ton of work, despite claims of the opposite ;)

If you want to take it from someone who actually worked on an undo feature in a game like this, and since you mentioned PC, they said about undo that it "required a massive development effort to implement" (Source[www.gamasutra.com]), and I recall someone who worked on it saying that it was one of the most difficult things they ever worked on.

Obviously yes, this is not rocket science. The difficulty isn't how to do it conceptually and more that it basically doubles the amount of code required for implementing any user action; and adding code paths that will get triggered relatively infrequently and new combinations of action sequences, which would be a pretty good source for bugs.
We had 1 programmer for a pretty big and technically challenging game, so we had to pick our fights or drop other features in return. I really appreciate the comparison with these AAA games, but it's no secret that we simply didn't have that budget.

[nannerpuss]

Originally posted by Sebioff:

Originally posted by nannerpuss:

But the thing I question is the design decision from day one to not include Undo.

We had 1 programmer for a pretty big and technically challenging game, so we had to pick our fights or drop other features in return. I really appreciate the comparison with these AAA games, but it's no secret that we simply didn't have that budget.

Hey I didn't want to sound like I was being a ♥♥♥♥ here, I kind of assumed this was the case and hearing you confirm that makes sense. I think most gamers actually (try to) understand the difficulty of being a smaller/indie dev and the costs involved as Steam and Kickstarter and other have given us a peek behind the curtain and, like we're doing here, even lets us talk to the guys and girls making the games we play. Totally on your side here, but I was trying to tell him how the average younger gamer is going to look at it.

[tr!star*]

Wtf, we dont need Undo in a realtime program game. It´s literally same as deleting the object.
And if you like a part but wanna try something different, make a blueprint before.

The only thing what I wanna mention to this is to get a Copy Pipet for a group of assets to replace. What would be game changing as hell.

[Bill Nye]

Originally posted by tr!star*:

Wtf, we dont need Undo in a realtime program game. It´s literally same as deleting the object.
And if you like a part but wanna try something different, make a blueprint before.

The only thing what I wanna mention to this is to get a Copy Pipet for a group of assets to replace. What would be game changing as hell.

Alright chief. You recreate all of Walt Disney World and then you can come back and tell me that you don't need an undo button.

[nannerpuss]

Originally posted by Space Cat:

Originally posted by tr!star*:

Wtf, we dont need Undo in a realtime program game. It´s literally same as deleting the object.
And if you like a part but wanna try something different, make a blueprint before.

The only thing what I wanna mention to this is to get a Copy Pipet for a group of assets to replace. What would be game changing as hell.

Alright chief. You recreate all of Walt Disney World and then you can come back and tell me that you don't need an undo button.

Yeah I don't know what this kid is smoking. How could an undo button possibly hurt? Just the convenience of not having to mouse down and click menus to remove something and hope it removes it how I hope is kind of a big unnecessary pain in the ass compared to left pinky, left ring finger Ctrl Z

[Bill Nye]

Originally posted by nannerpuss:

Originally posted by Space Cat:

Alright chief. You recreate all of Walt Disney World and then you can come back and tell me that you don't need an undo button.

Yeah I don't know what this kid is smoking. How could an undo button possibly hurt? Just the convenience of not having to mouse down and click menus to remove something and hope it removes it how I hope is kind of a big unnecessary pain in the ass compared to left pinky, left ring finger Ctrl Z

Apparently he doesnt care about placing scenery and whatnot