Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP : Add screenshots to save games #364

Open
wants to merge 5 commits into
base: develop
Choose a base branch
from

Conversation

balloonpopper
Copy link
Contributor

@balloonpopper balloonpopper commented Dec 14, 2024

Proposal to add screenshots to save games. It works at the moment, but I'd like the project maintainers to review the code for feedback.

The interface gets very buggy if I don't pre-resize the screenshot prior to trying to show it on the load/save screen. The resolution of the resized image, and the filename to save games to should be exported to project settings. Currently it's hard coded in the file but I'll hold off on moving it until the project maintainers advise if at the top of the file or in project settings would be preferred.

This is how the load interface looks with this change currently - I made the screenshots 100x65 for proof of concept.

image

@balloonpopper
Copy link
Contributor Author

balloonpopper commented Dec 21, 2024

Changed "New Save" to be "Empty Slot" so the picture works for both save and loading screens, and also added a "Missing Image" image in case you have a save game file but not its related image.

@balloonpopper
Copy link
Contributor Author

I tried doing further updates to the interface (like drawing a box around the save game entry on mouse-over) but I gave up as I found it too inconsistent with the current popochiu_popup class, and Godot's control nodes are painful to use.

@stickgrinder
Copy link
Collaborator

Hi @balloonpopper.

Me and @mapedorr just reviewed your implementation. It's working code but there are some corner cases that makes a proper solution pretty hard to complete.

To start with, this implementations should not overwrite the save/load component we have in place. A new one should be created instead.
Saving screenshot in a file may be a problem with web builds of the games, and this have to be checked better.
Also, your comment about Godot controls being a bit finnicky is not far from truth.

Considering all of that, the best option may be for @mapedorr to implement this feature. He has thorough knowledge of Godot controls, plus he knows the GUI system ins and outs.

I think we can work this out under the umbrella of #365 if we want to broaden its scope.
Are you ok with this?

@balloonpopper
Copy link
Contributor Author

If @mapedorr wants to implement this feature then that's fine.
You mentioned above that you don't want to modify the existing load/save functionality. In order to implement that I assume that you therefore would set up something similar to the GUI selection so you can select the save file type that you like? I have concerns about using the same setup tool for this - if I want to change my save game style, I don't want to overwrite my GUI type in case I have code customisations in there. The setup tool would need to be overhauled so that it only impacts the components you want to change.

@stickgrinder
Copy link
Collaborator

The setup tool would need to be overhauled so that it only impacts the components you want to change.

Yes, there is draft work by @mapedorr on that that we decided to remove from 2.0, but will make its way into future versions, to allow people to pick up components à-la carte. The plugin UI to "compose" your game UI was too green and still requires proper design.

In the meantime, you are right: customizations need to be managed by hand. But this is true for every GUI component that gets customized. The best option we have right now is writing more documentation on how to incorporate new or updated components into the game UI if you upgrade Popochiu in your project.

Please, note that there has been a lot of discussion on how to support devs creating game UIs. It's not an easy deed, because GUIs are the most prominent elements that change a lot between adventure games (much more than characters, props, rooms or dialogues, which behaviors are 90% the same across different games).

Contributions in the GUI area will probably need a good amount of upfront design to be considered for inclusion. If you want to take this over, of course, the best option can be to detail the solution architecture in an issue before getting to the implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants