Block Requests - Discussion

[Gealrüable]

Currently, there are 114 pending block requests, stretching back over 2 years, most posts getting basically no feedback.
The process might best be modeled by a big lootbox of random ideas, waiting in everlasting damnation. And every odd solar eclipse a beaming wizard reads the stars so a few may be deemed worthy for greatness, rising proud and shining from beneath their weathered gravestones to be used by some lanky nerd for his newest shed in minecraft.
Having left a few of my own ugly children rotting in this graveyard, I cannot help but feel for their horrid fate, and propose to alieviate their pain:

1. Uncertainty
Most posts disappear into obscurity, leaving anyone interested to wonder whereever if ever it is going anywhere.
To solve this we could introduce more tangible feedback both by the community and the staff.
Every request could be paired with a poll where builders could express how strongly they feel about the idea, from roaring enthusiasm to indifference or vomit inducing disgust.
This could give both poster and staff members a hint on general opinion.
Secondly mods might find use in stating more clearly their own opinion, outright rejecting bad ideas (several of my own are exceedingly deserving), and indicating their priority of implementation to the public.

2. Priority
Block requests vary in their usefulness to the general building public, I believe it to be constructive to concentrate on the most useful.
Which in my opinion are those that add to the general colour spectrum.
As an example: Azul's suggestion for a red dorne palette in contrast with my own idea of iron railings.
While the glorified wattle fences might prove useful in isolated cases, an expansion of red bricks would be critical for entire projects (and the potential of finally building sunspear is reason alone). New colours are the most effective way of creating new unique builds while maintaining the general aesthetic and avoiding outdating older builds.

To avoid hundreds of block suggestions in the future, it might help if we narrow our requests more on that line - that's not to say more specific requests have no place, but builders might want to reflect more if an iron railing really can't be substituted by a wattle fence.


This is meant to be a discussion, so please feel free to bring in your thoughts!

 

[Emoticone11]

Since I've basically been the main person responsible for working on the texture pack for the last several years, I'll give my input here, though of course I don't mean to stifle discussion around how we can improve the development process.

The elephant in the room

As I think most people know (and as I've tried to be transparent about), the block development cycle has been effectively gridlocked by the 1.18 migration process (which we have been making consistent progress on, as you can follow in the #118-development discord channel). The challenge is twofold: pushing a new block update while we're in the middle of migrating the WesterosBlocks mod and WesterosCraftRP greatly disrupts the migration process and requires a ton of additional man-hours to convert those changes to the 1.18 format as well. On the other hand, it's difficult to develop a 1.18 block update in parallel because the assets and organization of the 1.18 pack are themselves a moving target. The jump past 1.12 has necessitated redeveloping the entire pack from its bones, including moving from Optifine to a new ConnectedTexturesMod.

Consequently, I've decided to suspend work on block development so that we (particularly mikeprimm and geeberry) can focus solely on making the 1.18 migration happen as quickly as is feasible. All this to say: the reason that the block development cycle has been in stasis for a bit over a year now is not because of a lack of feedback or interest in block requests, but rather because of a deliberate decision to postpone work on this front due to more pressing tasks.

On workflow

For a variety of reasons, I've found it most effective to approach block development using an Agile development framework, in which work happens in periodic short-term "sprints" that each encompass the full planning -> design -> development -> testing -> deployment cycle. This means that, rather than "time-sharing" block suggestion reviews like I do with other server tasks (like builder apps, project apps, etc.) and IRL work, I find it most productive to review block suggestions in batch, including assessment of priority, at the beginning of a sprint where I'm actually prepared to begin active development in the following weeks.

Due to this, I view the "Pending Block Requests" subforum as basically a "wishlist" for anything they feel they might want, regardless of feasibility -- or, as you said, "a big lootbox of random ideas". In contrast, the "In Progress Block Requests" subforum is used for requests that are in an active development phase (or were, and are currently suspended). I don't really see any particular issue with having hundreds of pending block requests; at this point, whenever I'm ready to start a new development sprint, it's still feasible enough for me to iterate through all of them and select a subset for development. If it gets to the point where there are thousands, then we might want to reconsider.

Accepting requests prior to beginning a sprint would be tantamount to making an empty promise and letting suggestions pile up in the "In Progress" subforum rather than the "Pending" subforum, which I don't think really solves anything, and actually considerably complicates the development process since I mostly use the "In Progress" subforum as an easy checklist for development.

While I could reject requests that I think are clearly infeasible at the moment, I don't really see any particular reason to. It's helpful to keep these suggestions around even if there's no chance of them being implemented at the moment -- some day if we ever get to Essos, for instance, these suggestions can be taken into account when creating a new Essos block pack. Although one thing that might help organizationally is having a specific subforum for requests that are currently "archived", to be distinguished from active requests.

All that said, I encourage builders to help with tasks such as informally assessing priority and utility of suggestions, addressing and planning for possible implications of the suggestion that might impact willingness to add it (e.g., outdating existing builds), pointing out duplicate requests that can be merged, creating prototype textures, etc. All of this makes the initial stages of a development sprint (planning and design) much easier.

On feedback

I'm not entirely sure there's a need for a formal poll system here; looking at likes and replies to the initial post already gives a pretty good indication of enthusiasm. It's not clear to me what benefits a poll would bring.

One idea that might be somewhat useful though is automatically including a survey with several Likert-scale questions with each request, such as "on a scale of 1 to 5, how useful would you find this block for {general construction / a region-specific style}", "[...] how much do you think this block would contribute towards outdating existing projects", etc. It might be difficult to get a representative response sample from builders for every single request, but this would at least help prompt more specific feedback.

Regardless, one thing I want to emphasize is that community feedback is only one factor; ultimately the decision still comes down to the development team who triages community feedback, development considerations, and global project considerations.

 

[Margaery_Tyrell]

Also if you’re going to request a block it helps if you make/provide a texture for it, thats probably the hardest part.

 

[Wazgamer]

Im curious, what do you use to make the textures emot? And do you have any resources of how one would be able to better understand how to make a block texture?

 

[Emoticone11]

Im curious, what do you use to make the textures emot? And do you have any resources of how one would be able to better understand how to make a block texture?

Personally I use Photoshop, but GIMP is a good free alternative. Here's one resource I'm familiar with:

Minecraft Modelling & Texturing Tips - Minecraft Models

This is a guide written by @MasterianoX (with slight edits and additions by Esron/Fred) and is the go to guide for all beginners of Minecraft modelling & texturing using BlockBench. Use the navigation below or just scroll and see all of them. 1. UV Proportions Stretched/skewed UV Consisitent UV...

mcmodels.net

Going to ping Thamus_Knoward so he can share some of his resources (if he can find a bit of time ), since he's the real texture artist here!

 

[Thamus_Knoward]

Tools:
Asperite, Pro Motion, Pyxel Edit - I use Photoshop CS6 and Blockbench

Style:
If you wanna live up to the greatest examples of pixel art in the genre (e.g. Shovel Knight, Backbone, Celeste), you might wanna follow the classic pixel art style taught in these tutorials:

https://www.derekyu.com/makegames/pixelart.html

Pixel Joint Forum: The Pixel Art Tutorial

pixeljoint.com

While Docucraft and thus many old WesterosCraft textures used to follow that, I have tried to steer away from it in favour of a less restricted palette and a more "photorealistic" look. There's no good tutorial for that, but one advice is to step back often to see the texture in context and at scale. And another is to use CTM to introduce variation as much as possible!

Workflow:
We used to have one file per block following the CTM templates. I now use one large file cut into named tiles. I love the slice feature in Photoshop to export named tiles that match my CTM rules. I use layers, folders, blend modes, etc to create slight variants. Now, having worked with models a lot too, I'm thinking that I'd rather use the materials editor of a modern engine, but I haven't dared to make the transition yet because I'm not sure if that still let's me export everything so that minecraft is happy with it.
I keep a pretty barebones test resource pack around that I let overlay the production packs. When I work on textures, I have one instance of minecraft running, one window with the original resources from vanilla MC, one window with my test pack, and one with a temp folder to dump tiles into from photoshop.

 

[Wazgamer]

This is honestly kinda beautiful you guys! I dont think id ever be able to get this in depth into it. But was thinking of trying to create “mock” textures. Which would be a base for design, shape, and colour. So that then someone could integrate it into the pack.

Feel like most people on the server could do this too as we are all creatives at heart

me: starts making brick textures for days

 

[EStoop]

I personally think we need to review the texture pack as a whole rather than keep adding blocks to it with block requests.
This individual approach leads to a limited view to "needed" blocks, often missing opportunities to implement a wider variety of the same or similar blocks to be used over a broader region, resulting in other regions still needing to deal with the issues that led to the block request in the first place.

If we would take a moment to evaluate the texture pack, decide on what we want to represent with it and which blocks are needed to do that accurately and convincingly, we could solve the need to add new blocks once and for all.