> For the complete documentation index, see [llms.txt](https://hellstreet.gitbook.io/hellstreet-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hellstreet.gitbook.io/hellstreet-docs/insightful-investment-intelligence/developers.md).
# 👨‍💻 Developers
*HellStreet’s development process is designed around one central idea: the platform must support both a playable urban world and a creator ecosystem at the same time. That means the development stack has to handle game design, social systems, live events, asset workflows, marketplace logic, and publishing infrastructure all together. Unlike a traditional game where development ends at release, HellStreet is a continuously evolving platform, so development has to be modular, testable, and built for iteration.*
***
At the core of development is **HellStreet Create**, the internal and community-facing world-building environment. This is where scenes are assembled, gameplay logic is configured, assets are imported, and experiences are prepared for publishing. Development workflows inside HellStreet Create usually start with blockout and prototyping, followed by asset integration, gameplay scripting, lighting, optimization, and final testing. The goal is to make it possible for creators to move from concept to playable world without needing to build everything from scratch.
***
The platform uses a modern **asset pipeline** that supports structured imports, preview generation, versioning, and packaging for deployment. In practice, this means models, textures, audio, and interactive elements can be managed in a way that keeps worlds performant and organized. For a world like HellStreet, that matters because visual identity is important, but so is load time, stability, and compatibility across different client setups. Development teams need to balance detail with performance, especially in social hubs and event-heavy scenes where many players may be present at once.
***
A major part of the development process is **systems integration**. HellStreet is not just a collection of static environments; it includes features like user accounts, avatar persistence, inventory, marketplace flows, access passes, land ownership, event ticketing, and creator monetization. These systems require coordinated backend and frontend development, along with careful API design. In a practical setup, this usually means REST or GraphQL endpoints for metadata and inventory, WebSocket or realtime event channels for live gameplay states, and signed transaction flows for any on-chain operations. Development teams also need to maintain clear boundaries between gameplay state, commerce state, and creator publishing data so that the platform remains reliable.
***
***
HellStreet development also depends heavily on **testing and staging**. Because the project includes both gameplay and economic features, it is not enough to simply test whether a world loads. Teams need to verify interactions, permissions, item behavior, marketplace listings, event entry rules, and the publishing pipeline itself. Internal staging environments are used to test new worlds, creator submissions, balance changes, and feature updates before anything reaches the live environment. This helps reduce bugs, protect user assets, and avoid breaking the economy with unintended changes.
***
Another important part of development is **performance optimization**. HellStreet worlds are designed to feel lively and detailed, but that has to be balanced against rendering cost, network overhead, and client hardware variation. Development teams therefore work with profiling tools, telemetry, and optimization passes to tune draw distance, asset complexity, animation cost, and stream behavior. In a platform like HellStreet, optimization is not a final cleanup step — it is part of the development cycle from the beginning.
***
Security and reliability are also built into the development workflow. Source control, environment separation, code review, dependency management, and automated build pipelines are essential. A typical setup would include Git-based version control, CI/CD automation, issue tracking, logging, crash reporting, and runtime monitoring. For live platform features, this is especially important because a small bug in publishing or marketplace logic can have a much larger impact than a visual glitch in a map.
***
**Finally, development in HellStreet is collaborative by design. Internal teams, external creators, and community contributors all need different levels of access, documentation, and support. That is why documentation, templates, starter kits, and publish guidelines matter so much. The stronger the development workflow, the easier it is for creators to ship polished worlds and for the platform to keep growing without losing quality.**
{% hint style="info" %}
In short, HellStreet development is about building a living platform, not just a game. It combines content creation, live systems, digital ownership, and social interaction into one development framework — and that requires real structure, real tooling, and a constant focus on iteration. 🛠️🌆
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://hellstreet.gitbook.io/hellstreet-docs/insightful-investment-intelligence/developers.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.