Add a pixel art-friendly setting preset when creating a new project

[rafaelcastrocouto]

Describe the project you are working on

Shotcaller - https://github.com/spicylobstergames/shotcaller-godot

Describe the problem or limitation you are having in your project

After 3 years of development we are still changing rendering settings for our pixelart style. Here's a list of settings that could be auto configured with a simple "Pixelart game" checkbox:

• [ ] Disabling import filter
• [ ] Lossless Compression Mode
• [ ] GPU pixel snap
• [ ] Fix Alpha Border
• [ ] Base window size options (256×224, 640×480, etc)
• [ ] Are there others?

Extras (optional):

• [ ] Change the game font family to a default pixelart (eg. Press Start 2P)
• [ ] Change the game theme from round edges to a pixel art perfect default theme.
• [ ] Auto set most common 2d screen stretch options
• [ ] Add a link to screen resolution docs
• [ ] More?

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Simple check box option on the project creation dialog (same place where godot asks for OpenGL ES version) to be checked when it's a pixelart game.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

User creates a new project, marks the check box creates a simple pixelart game with proper pixel perfect configuration while avoid wasting a lot of time on godot rendering details.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It makes little sense to use a script to configure the game editor settings.

Is there a reason why this should be core and not an add-on in the asset library?

It's not an asset.

[lenscas]

Change the game font family to a default pixelart (eg. Press Start 2P)

I know at least one dev that I've seen go on war paths when it comes to pixel art fonts and I kinda agree with him. Just use normal fonts for your pixel art games, it is fine and actually readable.

[Calinou]

I think this is best done by distributing a project template, which can then be uploaded to the asset library. This can be done for both 3.x and 4.0 (with separate templates) :slightly_smiling_face:

[clayjohn]

We have plans to add something like this to the new project creation menu!

[TheDuriel]

I don't think there is any consensus on what a pixel art game actually is and requires, beyond "visible pixels". Every project will want its own settings and preferences on how to handle various resources.

I do personally think that for textures at least, the default settings should be with filtering off, and to enable filtering only if they are used in 3D. (This detection already exists, but 2D textures are filtered by default.) As in the majority of cases in 2D: A filtered texture will simply not display as expected.

[golddotasksquestions]

@TheDuriel

There is very clear consensus that 2D pixelart projects generally

• don't need texture filtering,
• do need GPU pixel snap
• do need lossless compression

Other sensible defaults would be:

• a smaller project resolution but an integer multiple (like 3x for example) of that project resolution for Window Width and Height Override
• Viewport stretch mode
• Icon.svg size reimported in a pixel art friendly resolution like 32x32

These are all things we already have and all it would take is to set these defaults. I also wish we would have a built-in automatic integer viewport stretch mode which is very important for fullscreen (so how most games are commonly played nowadays), but that's something we don't have right now.

[TheDuriel]

This is absolutely not true. And many of these settings can not be set as defaults.

Filtering being disabled is a safe and detectable use case that yes, holds true for the supermajority of 2D games. But not for all of them.

The other settings you propose can not be safely set as defaults, as they will produce undesired side effects. GPU pixel snap for example is not required for 2D games, unless the specific art direction of the project causes artefacts to occur. Similarily, we can not assume lossless compression, as many assets will be just fine with it. And maybe the user wants to push to mobile?

Your "other sensible defaults" are even more project specific. You are basically deciding for people what a 2D game is supposed to look and behave like.

This will inevitably lead to just as many cases of people asking about weird behavior they do not understand, just to be directed to just as many obscure to a newcommer settings to change.

[lenscas]

This is absolutely not true. And many of these settings can not be set as defaults.

Filtering being disabled is a safe and detectable use case that yes, holds true for the supermajority of 2D games. But not for all of them.

The other settings you propose can not be safely set as defaults, as they will produce undesired side effects. GPU pixel snap for example is not required for 2D games, unless the specific art direction of the project causes artefacts to occur. Similarily, we can not assume lossless compression, as many assets will be just fine with it. And maybe the user wants to push to mobile?

Your "other sensible defaults" are even more project specific. You are basically deciding for people what a 2D game is supposed to look and behave like.

This will inevitably lead to just as many cases of people asking about weird behavior they do not understand, just to be directed to just as many obscure to a newcommer settings to change.

Are you using "2D games" as a shorthand for pixel art games? I agree that these settings shouldn't be used for 2D games but they sound sane to me when going for 2D pixel art style games. I don't think anyone here wants these defauts for every 2D game. Instead just for 2D pixel art games.

[TheDuriel]

Are you using "2D games" as a shorthand for pixel art games?

I am disqualifying "pixel art games" as a category. Because pixel art is not a universal constant. There are many kinds of games that employ pixel art, and they do so with a variety of preferences towards resolution scaling, filtering, and other settings. That is my point.

goldot's proposed settings can work fine for retro inspired, low resolution games. Can. But each project will have its own needs unless you are dictating a particular art style under the "pixel art" umbrella.

[rafaelcastrocouto]

The wiki definition looks good enough https://en.wikipedia.org/wiki/Pixel_art

The precise definition of pixel art is a subject of debate, but an artwork is usually considered as such if deliberate thought was put into each individual pixel of the image. Standard digital artworks or low resolution photographs are also composed of pixels, but they would only be considered pixel art if the individual pixels were placed with artistic intent, even if the pixels are clearly visible or prominent

[TheDuriel]

It boils down to: Does it have Visible Pixels.

But visible pixels can be achieved in many many many ways depending on the needs of the project. Hence why:

We can detect and enable a setting that disables filtering for assets that don't require filtering. Because they are used in 2D at their native size without being scaled.

We can not prescribe to users scaling or resolution modes through presets. One project will want canvas scaling, another will want 2D. Yet another project will want to run at 480p (horrible idea imho) another will want to run at 1080p and upscale their assets. Some projects will want to run the gameplay at a specific resolution and display the UI at another resolution. Some projects will be deployed to mobile. Often times asset compression will be impossible to be noticed by the user.

We could create a comprehensive tutorial or list of presets for various window and canvas management modes. Maybe.

[rafaelcastrocouto]

I see your point @TheDuriel but I think most people will agree that for each of those options we have a most common one for traditional 2d pixel art games (based on the wiki definition and on the previous famous games from old consoles).

If we know the game will be a 2d pixel art game, starting with those options will most likely require less tinkering to get to the desired result (even if it's one of the special cases you mentioned)

[TheDuriel]

Intense desire to have usage data collection intensifies

Or how about we simply: Do not guess. And only act based on observable facts.

Disable filtering on textures by default, enable it if the texture is loaded into 3D (This already happens, textures used in 3D materials are reimported using the 3D preset.). Let people notice how filtering looks bad if they implement a zooming camera or scale their assets, and then let them reenable it if they need it.

The other settings like compression and pixel snap can not be predicted and sensible defaults are already enabled.

Window scaling and resolution settings can be expanded upon here: https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html to account for different common use cases. With several options for 2D games, and examples comparing retro games, pixel games, 2d games, of various forms.

[rafaelcastrocouto]

Thanks for the link ... I'll add the suggestions in there to the list

Pixel art:

Set the base window size to the viewport size you intend to use. Most pixel art games use viewport sizes between 256×224 and 640×480. Higher viewport sizes will require using higher resolution artwork, unless you intend to show more of the game world at a given time.

Set the stretch mode to viewport.

Set the stretch aspect to keep to enforce a single aspect ratio (with black bars). As an alternative, you can set the stretch aspect to expand to support multiple aspect ratios.

If using the expand stretch aspect, Configure Control nodes' anchors to snap to the correct corners using the Layout menu.

Maybe we should include a link to this doc as well!

[golddotasksquestions]

You don't need telemetry or be a data scientist to figure this out. If anyone watches one or more of the Godot community channels regularly (r/Godot, Godot Discord server, Twitter, Youtube, ...) every day you can see people posting footage of their projects or asking about how to achieve the looks of games which fall into the category of "2D pixelart" as it is described here in OPs post.

The advice on how to set up Godot for 2D pixelart is one of the most common advice I give out, if not THE most common. And I'm not the only one who does that. Godot by default is not dialed in for pixelart and the settings you have to change are spread around the editor in various places. This is even worse if you want pixel perfect pixel art.

Given how common this desire is, it would make perfectly sense to have a "2D pixelart" clickable thing which would set up Godots defaults so it's ready for an average pixelart game (low res, no filtering, gpu snap, viewport stretch mode ...).

I do very much assume if we would have such a clickable thing in the new project dialog (in form of templates or whatever), there would be other options for different presets too, as well as the current "general" default.

So @TheDuriel I really don't understand your opposition here. If this gets implemented, you loose nothing. But all those people who do need this would be helped a lot and their workflow would be sped up tremendously.

[TheDuriel]

You don't need facts. You need personal anecdotes!

I am not going to argue this.

---

I really don't understand your opposition here.

I am opposing the creation and labelling of a single "2D Pixel Art" project template. When everyone here appears to agree that: Pixel Art is not defined by a set of project settings. But by the visible appearance of pixels in an aesthetic. But by the usage of visible pixels for Aesthetic purposes.

Problem:

If you create a template with all the settings as proposed by the OP and you Golddot, then we will be missleading users down the wrong path based on the assumption that Pixel Art is one singular thing and has one singular way of implementing this.

Solution:

Offer reasonable defaults that do not prescribe a particular workflow which is not universally suited to all projects.

Avoid using names and labels for describing a specific implementation of a concept. When those names describe an aesthetic that can and must be accomplished using different methodologies.

Furthermore:

If a desire to create project templates exists, which set many obscure/hidden settings. Then create a serviceably broad set of these.

"2D Pixel Art" is not one thing. And thus can not be represented with one template.

As an example of how to better describe templates and avoid the naming problem:

Template Name -> Rough Qualifying Description

"Canvas Scaling with Filtering Disabled and Pixel Snap Enabled -> Suitable for Retro inspired games rendering at a low resolution with a pixelated look."

"2D Scaling with Filtering and Pixel Snap Disabled -> Suitable for General purpose 2D games, including most Pixel Art Aesthetics."

"2D Scaling with Filtering Enabled and Pixel Snap Enabled -> Suitable for General Purpose 2D games where Zooming and Scaling is expected."

[golddotasksquestions]

Duriel I wish you would sometimes put yourself in the mindset of someone who comes new to this.

For most people who know nothing about Godot or game dev, "2D Pixel Art" is pretty clear: It's not 3D and its likely low res. Templates are not about something specific. A template just allows you to do less initial customization steps, as it does the very commonly first few customization steps for you. Most people understand this since this is how templates and presets work in countless other software.

"Canvas Scaling with Filtering Disabled and Pixel Snap Enabled" might mean something to a veteran Godot user, but is totally useless for anyone else. The general direction of what can be expected from "2D Pixel Art" is instantly clear to a beginner as well as veteran Godot user without the need to add lengthy explanations (an explanation which you can still add. The explanation is where the details belong, not in the template name).

If you create a template with all the settings as proposed by the OP and you Golddot, then we will be missleading users down the wrong path based on the assumption that Pixel Art is one singular thing and has one singular way of implementing this.

I communicate about 2D pixelart games all the time online and IRL. People say "pixelart games" everywhere and never once did I have the impression those people would think of "pixelart games" as only one particular thing. Anyone who has seen or played more than one pixelart game in their life will know they can differ quite a bit. If you have a game engine template or preset of that name, it means this will set up your project with project settings suitable for this general type of game. Once you clicked on the "create" button, you can then further customize your project just like you would with the default vanilla project template ... Nothing is set in stone. It's just some project setting after all.

[TheDuriel]

Duriel I wish you would sometimes put yourself in the mindset of someone who comes new to this.

This is precisely why I am arguing against prescriptive language. Because of the famed new user that doesn't know.

If we create a template labelled "Pixel Art". That is misleading.

It creates the impression in this new user, that this setting. This preset. Is the correct and only way to go about things. When in reality, there are a multitude of configurations that could serve them. When their particular goal might not align with any of the settings of this preset.

Terraria. Loop Hero. Shovel knight. Binding of Isaac. None of these games use one unified template. But they are all pixel art.

This is why, if there is to be templates. There there must not be a template. But there must be many. And that these templates should be explained clearly, using language that can be useful to experienced users, users capable of research, and users looking for a quick starting point.

That is why, you quoting me in the beginning of your post ""Canvas Scaling with Filtering Disabled and Pixel Snap Enabled" is itself, misleading. Because you have not quoted the expanded description. Which should be used to provide a helpful pointer for these users.

I communicate about 2D

We agree on that then.

Once you clicked on the "create" button, you can then further customize your project just like you would with the default vanilla project template ... Nothing is set in stone. It's just some project setting after all.

It is not.

Defaults and templates matter. They matter because it is well proven that users have a tendency to stick to the default settings. That they will not dig into menus and deep documentation about subjects.

If we provide a 2D Pixel Art template. Then you will have new users and professional users open the engine, choose this template. And conclude: This is the way Godot wants me to do pixel art.

If we provide multiple templates for various use cases, and which do not attempt to prescribe a method to a style. Then you will have new users and professionals consider and inform themselves about their use case.

And yes, they might still not get it right the first time. But there will be an increased likelihood of the resulting reaction being a beneficial one of: "I should have chosen differently." or "I should change this one aspect of my choice." once they gain a deeper understanding of the engine and the needs of their own project. Instead of: "The way Godot wants me to do this thing, isn't suited for what I want to make."

---

And finally to reiterate:

Yes. Disable filtering of textures by default. That just makes sense.

[golddotasksquestions]

I think I understand your perspective now (thanks for your detailed explanation), but I still fundamentally disagree for already mentioned reasons.

[Zireael07]

Duriel, I don't think giving a preset a short name that is understandable to newcomers communicates "that this is the only way to do things".

As golddot said, the template could be further customized to anyone's specific needs, but it will at least stop/mitigate the endless questions on the community channels. Godot already has an edge over competitor engines in how it handles 2D (being easy to setup), let's capitalize on that.

[TheDuriel]

And yet, the addition of the "Add new node" field to the ScenTree dock, did lead to a flood of people needing help because they put a Node2D as the root of their scene before their KinematicBody.

Defaults. Matter.

Naming. Matters.

It should be obvious that they do, given that we all here are part of an industry obsessing over what to name functions and variables. Why does that not apply to UX and the software we make with those?

2D Pixel Art, or anything like it. Is misleading.

Change the defaults which truly make sense.

And if you want to add templates. Then clearly communicate what those templates do. And do not hide behind generalized names that will create a bias towards one specific approach. Tutorials already do that. The engine can really do without it.

the template could be further customized to anyone's specific needs

The people these templates are for. Don't. Do. That. Not unless you explicitly spell out the fact that they can, and why that might be useful. And then some might still click past it, but at least you tried.

I can make the exact same argument here as Golddot did. Think of the newbies.

---

Why do I even need to argue in favor of:

Don't do:

"This is the 2D Pixel Art Template."

Do:

"This template is often suitable for 2D Pixel Art. But these other templates could also serve your needs."

[Zireael07]

"This template is often suitable for 2D Pixel Art. But these other templates could also serve your needs."

No one, afaict, said anything about this being THE template, just A template. So the first sentence is just a rephrasing, just a bit long.

The main problem is how much screen space do we have for template names/descriptions? If a lot, then I see no reason for not including the whole thing I quoted, if not enough, then the "other templates" part could go in a header or something?

[TheDuriel]

This proposal is about adding a template with a definitive name that is highly misleading, and settings which lend themselves only to specific use cases. (In case someone lost track.)

If a new proposal was made for adding templates (multiple), and said proposal did not try to apply a single methodology to an entire artstyle. I would not be arguing for caution nearly as much.

The main problem is how much screen space do we have for template names/descriptions?

An entire repositories readme.md file, within the asset library, from the looks of OPs proposal.

Or, an entirely new menu in the launcher.

This isn't a quick and simple thing in either case.

[rafaelcastrocouto]

Maybe we could edit the "Create new project" popup window by adding a button for "Custom Settings" where we would have more space.

There we could make available not only 2d pixelart, but all kind of important settings that might require scenes to be ajusted later (like the renderer). Maybe on the top of this custom window we could have an option list with quick presets with proper explanation (like duriel mentioned).

[Zireael07]

@TheDuriel OP says

Simple check box option on the project creation dialog (same place where godot asks for OpenGL ES version) to be checked when it's a pixelart game.

so I don't see how it's "an entire README in the repo" - not to mention newbies usually don't read READMEs, unfortunately...

Hm, if we were to put it in this popup, then yeah, we can go wild with the description for the template(s) and any other settings we might like to put there. Or forgo the idea of "A template" entirely and just have an adjustable list of settings...? Thoughts?

[YuriSizov]

I don't think we should complicate things for the project creation dialog and maintain various arbitrary presets (note that people would argue about their sensibility and create an unnecessary load on maintainers to sort this out).

A better solution would be to have a better onboarding experience with custom project templates. We already offer them from the asset lib, but it's pretty barebones and there are many things that those could better solve. A community-maintained pixel art project template, whatever that entails, would fit there just right.

[Zireael07]

Project templates have been "in the works" since forever and don't look likely to materialize forever. Secondly, I think the idea is NOT to have a template, but a toggleable list of settings with newbie-friendly descriptions (what is gpu snap? what is filtering off?)

[YuriSizov]

Project templates have been "in the works" since forever and don't look likely to materialize forever.

Huh? This is an existing feature. I'm talking about making the onboarding experience better. What's been discussed on top of the existing feature is having local project templates instead of downloading one from the asset library, but that is irrelevant here as it doesn't help new users. As for the asset library ones, we need to communicate better that this feature exists, that there are templates, and for each template — what it's for. Currently this UI is a bit hidden and a bit heavy.

Secondly, I think the idea is NOT to have a template, but a toggleable list of settings with newbie-friendly descriptions (what is gpu snap? what is filtering off?)

Right, and I'm saying this is a poor idea, because, as stated, it would be a subject of constant complaints and corrections and would introduce unnecessary burden for maintainers, who would have to arbiter these complaints and their validity. If you think this won't happen, I present to you this thread itself, which has been going for days over what is or isn't a 2d pixel art game. Same will happen with presets, or with the list of settings that we'd have to expose.

We already have two levels for projects settings, basic and advanced, and even deciding what goes where can cause problems and hide useful properties from users. Maintaining another list, or several, of settings for a particular style of game to be configured at the project creation is not that great of an idea.

So, again, project templates shared over the asset library would cover this functionality better. And if tinkering with specific project settings is a necessity, then we could find a way to make it a feature of installing project templates.

[golddotasksquestions]

Users already have the option to download and install templates from the Asset Library.

This option existed for years and does not solve anything, because it is a random collection of user content, and not an officially sanctioned dialog of a hand full of presets "Here is a selection of useful common defaults for common needs."

The type of pre-select project settings or templates (as discussed in https://github.com/godotengine/godot-proposals/issues/3029) we are discussing here needs to be official in order to instill confidence to be used and useful. See Unreal.

[YuriSizov]

This still is better outsourced to the community, via a rating system that will be a part of the new asset store. We can't be sole judges over what is a good and what is not. It's just not our place to do that.

[Zireael07]

A rating system for the assets would be LOVELY but it won't solve the problem.

Exactly because the engine devs can't be sole judges it needs to be not a template but a set of settings.

RE: templates... ah, a word. I used a wrong one - I was referring to a proposal that would make it easier to share files between the projects, but I can't remember the keyword they used...

[golddotasksquestions]

We can't be sole judges over what is a good and what is not. It's just not our place to do that.

You realize Godots Nodes are nothing but a collection of sensible presets for common usecases judged by Godot developers, right?

[glennDittmann]

@clayjohn Yes, please make that a pre-project settings as mentioned above. Would be highly appreciated.

Otherwise I am currently creating a github template repository as a workaround, for anyone wanting to use it or adding something missing please feel free.