Functionality
A resource should be dependable before it is decorative. Features should have a clear purpose, configuration should be understandable, and integrations should expose the controls developers actually need. Where practical, we also keep resources self-contained rather than adding third-party dependencies purely for convenience.Presentation
Player-facing resources should look and feel intentional. Menus, prompts and interactions are designed as part of the resource rather than treated as an afterthought. That includes consistent navigation, clear feedback and input behaviour that makes sense across supported control methods.Integration
Different FiveM servers use different stacks, so individual FzD resources may support standalone operation, frameworks such as Qbox/QBCore/ESX, or compatibility layers for common ecosystem resources. The exact support is documented per script instead of assuming every FzD resource has identical requirements.Controls
Controller support is a major part of the FzD approach. When a resource has player interaction or NUI, we consider gamepad navigation and input alongside keyboard and mouse from the design stage.FiveM and individual framework/resource APIs can impose limitations. Where complete controller parity is not possible, the relevant script documentation will call that out rather than silently assuming keyboard and mouse.