BitHunter

_{Um RPG 2D top-down em Java (AWT/Swing) — engine “na unha”, com foco em sistemas, legibilidade e iteração rápida.}

Source-available / Proprietary — Este repositório é público, mas não é open-source.
O código e os assets são protegidos (All Rights Reserved). Contribuições via PR são bem-vindas.
Reutilização fora deste repositório é proibida. Veja LICENSE e CONTRIBUTING.md.

🧭 O que você encontra aqui
- Loop de jogo + render 2D (Swing)
- Tiles/mapas via resources
- Entidades (player/NPC/monstros/itens) + colisão
- Save/Load (serialização)
- UI modular (HUD, trade, opções, pet yard…)
- i18n com .properties

🎮
_{Jogo 2D top-down} ☕
_{Java SE + AWT/Swing} 🗺️
_{Mapas em resource/maps/*.txt} 🌍
_{i18n via resource/lang} 💾
_{Save/Load em save.dat}

TL;DR (honesto): o repositório documenta e implementa boa parte da “engine” e dos sistemas (UI, entidades, mapas, eventos, pets, save/load…), mas os assets binários não estão presentes. O README abaixo explica como navegar, entender a arquitetura e o que é necessário para rodar localmente com o que existe hoje.

Navegação

BitHunter
Um RPG 2D top-down em Java (AWT/Swing) — engine “na unha”, com foco em sistemas, legibilidade e iteração rápida.

O que é

BitHunter é um projeto de jogo (RPG 2D top-down) implementado em Java, com renderização 2D e UI via AWT/Swing, organizado como uma “mini engine” com:

Loop de jogo em thread dedicada (main.GamePanel)
Entidades e gameplay (player/NPC/monstros/itens) via herança de entity.Entity
Mapas em texto (resource/maps/*.txt) e tiles carregados por tile.TileManager
UI modular por estados (HUD, inventário, trade, opções, pet yard, etc.) em ui.*
Save/Load por serialização de um data.DataStorage em save.dat
Traduções via resource/lang/messages_*.properties + main.LanguageManager

O repo também inclui um documento de design: gdd.md (Game Design Document) que descreve visão, loop central, controles e backlog.

Para quem é

Quem estuda engenharia de jogos em Java: arquitetura de sistemas (UI, entidades, mapas, eventos) em um projeto “real”.
Quem quer um playground de gameplay-systems: inventário, trade, progressão, eventos/teleportes, IA simples com pathfinding.
Quem quer evoluir o projeto: adicionar pipeline de build, empacotamento, assets, testes e automações.

Destaques confirmados no código

🎛️ Estados e UI por módulos Estados como Title/Play/Pause/Dialogue/Options/Trade/Pet Yard/Map estão declarados em `main.GamePanel` e desenhados via `ui.UI` + sub-UIs.	🌍 i18n (multi-idioma) Textos via `main.LanguageManager` e arquivos `resource/lang/messages_*.properties` (com menu de idioma em Opções).
💾 Save/Load Persistência em `save.dat` com `ObjectOutputStream`/`ObjectInputStream` (classe `data.SaveLoad`).	🗺️ Mapa + mini-mapa Tela de mapa e mini-mapa (toggle) implementados em `tile.Map` e acionados por teclas (ver Controles).
🤖 IA e pathfinding A* em `ai.PathFinder` com máscara de sólidos incluindo `InteractiveTile`.	🐾 Pets e incubação de ovos Coleção de pets, pet ativo, XP do pet e incubadora (`pets.PetIncubator` + `ui.PetYardUi`).
⚔️ Combate + guarda Ataque corpo-a-corpo (ENTER), projétil/magia (F) e sistema de guarda (SPACE) com stamina (em `entity.Player` + `entity.Entity`).	🌗 Iluminação e ciclo dia/noite Overlay com `RadialGradientPaint` e fases do dia em `environment.Lighting`.
📖 Bestiário Sistema de enciclopédia de criaturas com progressão por abates, 3 estágios de revelação, categorias e pontos de recompensa (`bestiary.*` + `ui.BestiaryUi`).	🔧 Ferramentas de validação Validador i18n (`tools/I18nValidator.java`) para garantir paridade de chaves entre todos os idiomas.

Demonstração

Este repositório (no estado atual) não contém imagens/screencasts versionados em public/, docs/ ou assets/.

Como gerar uma demo a partir do repo (sem prometer output)

Capturas de tela: rode o jogo localmente e capture as telas mais “explicativas”:
- Title Screen
- HUD em gameplay (barras HP/MP/Guarda + XP no topo)
- Inventário / tela de personagem
- Trade com o comerciante
- Pet Yard + painel de incubação
- Mapa / mini-mapa
Onde versionar: crie uma pasta docs/img/ e adicione as imagens lá (o README já está pronto para incorporar assets locais quando existirem).

Stack e tecnologias (detectadas no repo)

Linguagem: Java (código em src/).
UI / render: Swing/AWT (JFrame, JPanel, Graphics2D) — entrypoint em main.Main.
Áudio: javax.sound.sampled (Clip, AudioSystem) em main.Sound.
Imagens: ImageIO + carga via classpath em entity.Entity.setup(...) e tile.TileManager.
i18n: java.util.Properties + arquivos .properties em resource/lang (main.LanguageManager).
Persistência: serialização Java em data.SaveLoad (save.dat).
Editor tooling: configurações de VS Code em .vscode/ (debug/launch/tasks + formatter).

Build (com resources)

Requisito para rodar: ter o Java instalado (JRE/JDK) e o comando java disponível no PATH. Requisito para buildar: ter o JDK instalado (com javac disponível).

rm -rf build && mkdir -p build/classes

# 1) Compila
javac --release 24 -d build/classes $(find src -name "*.java")

# 2) Copia resources para a raiz do classpath
# (isso cria build/classes/maps e build/classes/tiles, etc.)
cp -r resource/* build/classes/

# 3) Empacota
jar --create --file build/app.jar --main-class main.Main -C build/classes .

# 4) Confirma que entrou
jar tf build/app.jar | grep -E '^(maps|tiles)/' | head -n 50

# 5) Roda
java -jar build/app.jar

Gerar executável (.exe) com runtime embutido

Requisito: JDK 14+ com o comando jpackage disponível no PATH.

O jpackage empacota o .jar junto com um runtime Java, gerando um .exe standalone que não exige Java instalado na máquina do usuário.

1) Gere o JAR (se ainda não gerou)

Siga os passos da seção Build (com resources) para produzir o build/app.jar.

2) Prepare a pasta de input

O jpackage exige que o --main-jar seja apenas o nome do arquivo (sem caminho), e que esse .jar esteja dentro da pasta informada em --input.

Crie a estrutura de packaging e copie o JAR para dentro dela:

cd D:\Workspace\BitHunter\build

mkdir .\package\input -Force | Out-Null
mkdir .\package\out   -Force | Out-Null

Copy-Item .\app.jar .\package\input\ -Force

Se o seu JAR tiver outro nome (ex.: BitHunter-v1.0.0.jar), ajuste o nome nos comandos abaixo.

3) Gere o executável

jpackage `
  --type app-image `
  --dest .\package\out `
  --name BitHunter `
  --input .\package\input `
  --main-jar app.jar

Parâmetro	O que faz
`--type`	`app-image` gera uma pasta com o `.exe` (sem instalador)
`--dest`	Pasta de destino onde o pacote será criado
`--name`	Nome do executável gerado
`--input`	Pasta que contém o `.jar` e quaisquer arquivos extras
`--main-jar`	Apenas o nome do JAR (sem caminho) — deve estar dentro de `--input`

4) Resultado

Após a execução, o executável estará em:

build\package\out\BitHunter\BitHunter.exe

A pasta BitHunter\ conterá o runtime Java embutido (subpasta runtime\) e tudo que estava em --input. Basta distribuir essa pasta inteira — o usuário final não precisa ter Java instalado.

Incluindo arquivos extras no pacote

Se o jogo precisar de arquivos externos ao JAR em tempo de execução (como config.txt ou pastas de assets), basta copiá-los para a pasta --input antes de rodar o jpackage. Tudo que estiver dentro de --input será incluído no pacote final junto ao .exe.

Copy-Item ..\config.txt .\package\input\ -Force

Como rodar localmente

Via VS Code (config já no repo)

O repositório inclui uma configuração de execução para Java:

.vscode/launch.json define o launch “Run BitHunter” com mainClass: "main.Main".
.vscode/settings.json define java.project.sourcePaths como ["src", "resource"] (ou seja, a pasta resource/ é tratada como source/resource path).
.vscode/extensions.json recomenda o ecossistema de Java para VS Code (RedHat Java + Java Pack + Debug/Test/Dependency).

Fluxo recomendado (sem depender de comandos):

Abra o workspace no VS Code.
Garanta que você tem um JDK configurado (o projeto é Java).
Selecione a configuração Run BitHunter e execute a classe main.Main.

Se você estiver com problemas já na abertura do jogo (ícone, fontes, sprites, sons), pule para Troubleshooting e para Recursos (assets) e classpath.

Task utilitária existente no repo

Em .vscode/tasks.json existe a task “Clean build” que remove a pasta bin/ e imprime “limpo.”. Observação: o comando configurado usa rm -rf, que é típico de ambientes Unix/macOS; em Windows pode não funcionar sem um shell compatível.

Config persistida (config.txt)

O jogo salva/carrega preferências em config.txt (no diretório de trabalho).

O formato atual, linha a linha (main.Config), é:

Linha	Conteúdo	Exemplo	Efeito
1	Fullscreen (`On`/`Off`)	`Off`	Liga/desliga tela cheia (efeito completo após reiniciar — ver UI)
2	Volume música (0..5)	`3`	Ajusta `music.volumeScale`
3	Volume efeitos (0..5)	`3`	Ajusta `se.volumeScale`
4	Idioma (ex. `pt_BR`)	`pt_BR`	Define idioma via `LanguageManager`

Save/Load (save.dat)

O jogo usa save.dat como arquivo de save (data.SaveLoad).
O .gitignore do repo ignora *.dat, então saves locais não entram em commit por padrão.

Estrutura do projeto

Abaixo está uma visão fiel ao que existe hoje (sem assumir build system ou monorepo).

.
├─ src/
│  ├─ ai/                 # Pathfinding (A*)
│  ├─ bestiary/           # Bestiário (registros, serviço, progressão)
│  ├─ data/               # Save/Load + estruturas serializáveis
│  ├─ entity/             # Entity base + Player + NPCs
│  ├─ environment/        # Iluminação / ambiente
│  ├─ main/               # Entry e “núcleo” (GamePanel, input, config, etc.)
│  ├─ monster/            # Monstros (inclui boss)
│  ├─ object/             # Itens/objetos do mundo (coin, chest, door...)
│  ├─ pets/               # Pets, ovos, incubadora
│  ├─ tile/               # Tiles, mapas e minimapa
│  ├─ tile_interactive/   # Tiles interativos/destrutíveis
│  └─ ui/                 # UI modular por telas/estados
│
├─ resource/
│  ├─ bestiary/           # dados do bestiário (creatures.properties)
│  ├─ lang/               # i18n: messages_*.properties
│  └─ maps/               # mapas em texto + tiledata.txt
│
├─ tools/
│  └─ I18nValidator.java  # validador de chaves de tradução
│
├─ .vscode/               # debug/launch/tasks + formatter + recomendações
├─ config.txt             # preferências (fullscreen/volumes/idioma)
├─ gdd.md                 # Game Design Document (visão + backlog)
└─ LICENSE                # licença do código e dos assets

Arquitetura e fluxos

Visão “de cima” (sistemas)

Bootstrap `main.Main` cria a janela (`JFrame`), adiciona `GamePanel`, carrega config e inicia a thread do jogo.	Loop `GamePanel.run()` atualiza + desenha a ~60 FPS (delta timing).
Update `GamePanel.update()` delega por estado (principalmente `PLAY_STATE`) e atualiza player/NPCs/monstros/projéteis/partículas/tiles interativos + ambiente + incubadora.	Render Desenha tiles → tiles interativos → entidades (ordenadas por `worldY`) → ambiente → mini-mapa → cutscene → UI.

Estados do jogo

Os estados são centralizados em main.GamePanel e consumidos por main.KeyHandler (input) e ui.UI (render UI):

TITLE_STATE, PLAY_STATE, PAUSE_STATE, DIALOGUE_STATE, CHARACTER_STATE
OPTIONS_STATE, GAME_OVER_STATE, TRANSITION_STATE, TRADE_STATE, SLEEP_STATE
MAP_STATE, CUTSCENE_STATE, PET_YARD_STATE, BESTIARY_STATE

Controles

Baseado em main.KeyHandler e nos textos em resource/lang/messages_*.properties:

Contexto	Tecla	Ação
Gameplay	`W/A/S/D`	mover
Gameplay	`ENTER`	confirmar / atacar / interagir (dependendo do contexto)
Gameplay	`F`	atirar/conjurar (projétil/habilidade)
Gameplay	`SPACE`	guarda (se houver stamina/escudo)
Gameplay	`B`	bestiário
Gameplay	`C`	tela do personagem
Gameplay	`P`	pausar
Gameplay	`ESC`	opções
Gameplay	`M`	mapa (tela cheia)
Gameplay	`X`	liga/desliga mini-mapa
Dev (gameplay)	`T`	alterna debug (e desenha path)
Dev (gameplay)	`R`	recarrega mapa atual (atalho)
Dev (gameplay)	`G`	alterna “god mode”
Menus	`W/S`	navegar
Menus	`ENTER`	confirmar
Menus	`ESC`	voltar (onde aplicável)

Nota: o atalho R chama loadMap("/maps/interior01.txt", 1) em KeyHandler, mas o repo contém resource/maps/indoor01.txt. Isso sugere um mismatch de nome de mapa no atalho (ver Troubleshooting).

Mapas e tiles

Mapas: resource/maps/world01.txt, indoor01.txt, dungeon01.txt, dungeon02.txt.
Metadados de tiles: resource/maps/tiledata.txt (lista + flag de colisão por tile).
Carregamento/desenho: tile.TileManager mantém mapTileNum e desenha apenas o “view” visível baseado na posição do player.
Mini-mapa e mapa: tile.Map herda TileManager e pré-renderiza um BufferedImage por mapa para desenhar:
- o mapa inteiro em MAP_STATE
- um mini-mapa com alpha em PLAY_STATE quando habilitado

Entidades, combate e progressão

Base: entity.Entity define direção, sprites, áreas de colisão/ataque, inventário, atributos, flags de estado e helpers (incluindo setup(...) para sprites).
Player: entity.Player
- atributos (level/HP/MP/STR/DEX/EXP/coins)
- inventário (até 20)
- ataque corpo-a-corpo + projétil (Fireball)
- guarda com stamina (se houver escudo/guard capacity)
- integração com pets (pet ativo, XP, etc.)
Monstros: monster.* inclui inimigos comuns e MonSkeletonLord (boss) com fase 2 (rage) e sprites específicos.
Objetos/itens: object.* (coin, key, chest, doors, potion, lantern, armas, etc.)
Interativos: tile_interactive.* (árvores/parede destrutível/placa metálica/tronco…)

Pets + incubadora

Registry/factory: pets.PetFactory define IDs estáveis e criação de instâncias.
Incubação: pets.PetIncubator gerencia 1 ovo por vez, tickando apenas em PLAY_STATE.
UI: ui.PetYardUi oferece:
- gerenciar/equipar pet
- escolher ovo no inventário e iniciar incubação (com custo em moedas)
- painel de status com progresso e tempo restante

Eventos, teleporte e cutscenes

main.EventHandler centraliza eventos por tile (com EventRect):

dano em “pit”
“healing pool” que restaura vida/mana, respawna monstros e salva
teleporte entre mapas (outside/indoor/dungeon/boss)
trigger de boss (Skeleton Lord) iniciando cutscene

UI modular (HUD, inventário, trade, opções…)

ui.UI é o orquestrador e instancia sub-módulos:

HudUi: barras de HP/MP/Guarda, XP top bar, HP de monstros, mensagens, HUD do pet
TitleUi: título + menu e seleção de classe
OptionsUi: tela cheia, volume música/efeitos, controles (paginado), idioma (lista scrollável), sair para title
TradeUi: compra/venda (com validações de moedas/inventário)
PetYardUi: gerenciamento e incubação
além de Pause/Dialogue/Character/Transition/GameOver etc.

i18n (traduções)

Arquivos disponíveis: resource/lang/messages_{pt_BR,en_US,es_ES,fr_FR,it_IT,de_DE,ru_RU,ja_JP,ko_KR,zh_CN}.properties
Idiomas expostos no menu (hoje): definidos em LanguageManager.getAvailableLanguages().
Estratégia: LanguageManager.text(key) retorna ??key?? quando não encontra (com fallback para pt_BR quando aplicável).

Validador de chaves i18n (tools/I18nValidator.java)

O projeto inclui um utilitário em tools/I18nValidator.java que compara todos os arquivos de idioma com o idioma base (en_US) e aponta chaves faltantes ou sobrando. Sem dependências externas — Java puro.

Como usar:

# A partir da raiz do projeto
javac tools/I18nValidator.java -d tools
java -cp tools I18nValidator

Saída esperada (quando tudo está OK):

=============================================================
 i18n Key Validator
=============================================================
Idioma base: messages_en_US.properties (245 chaves)
-------------------------------------------------------------

[OK] messages_de_DE.properties (245 chaves)
  Todas as chaves estão presentes.
...
=============================================================
RESULTADO: TODOS OS IDIOMAS ESTÃO COMPLETOS!

Exit codes:

0 — todos os idiomas estão completos
1 — erro de configuração (diretório/arquivo base não encontrado)
2 — inconsistências detectadas (chaves faltantes ou sobrando)

Dica: rode o validador sempre que adicionar novas chaves de tradução para garantir que todos os idiomas ficaram sincronizados.

Áudio

main.Sound mapeia sons por índice carregando .wav via getResource("/sounds/..."), com volume ajustável por volumeScale (0..5).

Iluminação / ciclo dia-noite

environment.Lighting cria um overlay (darknessFilter) com gradiente radial baseado na luz equipada do player (quando existe) e alterna fases do dia (DAY/DUSK/NIGHT/DAWN) ajustando filterAlpha.

Recursos (assets) e classpath

O projeto carrega recursos via classpath (ex.: getResourceAsStream("/maps/world01.txt"), setup("/objects/coin_bronze", ...), getResource("/sounds/coin.wav")).

O que existe versionado hoje em resource/:

resource/maps/*.txt + tiledata.txt
resource/lang/messages_*.properties

O que o código referencia (paths típicos) — mas que não está presente no repositório no estado atual (sem .png/.wav/.ttf):

"/tiles/" (tileset)
"/tiles_interactive/" (tiles interativos)
"/objects/" (itens/ícones/objetos)
"/player/Walking sprites/", "/player/Attacking sprites/", "/player/Guarding sprites/" (sprites do player)
"/npc/" (sprites de NPCs)
"/monster/" (sprites de monstros/boss)
"/projectile/" (sprites de projétil)
"/pets/", "/eggs/" (sprites de pets e ovos)
"/sounds/" (áudios .wav)
"/font/" (fontes .ttf)

Como encaixar assets corretamente (modelo mental)

Como .vscode/settings.json define resource em java.project.sourcePaths, a pasta resource/ entra no classpath do projeto quando você roda pelo VS Code.
Portanto, um path como "/maps/world01.txt" deve existir como resource/maps/world01.txt.
Um path como "/objects/coin_bronze.png" deve existir como resource/objects/coin_bronze.png.
E assim por diante, respeitando maiúsculas/minúsculas e espaços no nome da pasta (por exemplo: "/player/Walking sprites/...").

Padrões e convenções do repo

.editorconfig: LF, UTF-8, trim de trailing whitespace, indentação de 2 espaços.
VS Code: .vscode/settings.json ativa format on save/paste e organiza imports em Java, usando um formatter XML em .vscode/eclipse-formatter.xml.

Testes e qualidade

No estado atual, o repositório não contém suíte de testes automatizados (não há evidência de JUnit/Gradle/Maven nem diretório de testes). Ainda assim, alguns pontos que já ajudam a manter qualidade:

UI e gameplay separam responsabilidades por pacotes (ui/, entity/, tile/, data/, main/, bestiary/, etc.).
LanguageManager e Config são módulos bem isolados.
O projeto registra e ignora artefatos locais (ex.: save.dat) via .gitignore.
Validador i18n: tools/I18nValidator.java verifica paridade de chaves entre todos os idiomas (ver seção i18n).

Troubleshooting (baseado no que o repo mostra)

1) Jogo abre “quebrado”, sem sprites/sons/fontes, ou crasha ao carregar recursos

Causa provável: o código referencia recursos (.png, .wav, .ttf) via classpath, mas o repo não contém esses arquivos. Como confirmar: procure pelos paths em entity.Entity.setup(...), main.Sound, ui.UI, tile.TileManager e compare com a estrutura existente em resource/.

Ação: adicione os assets em resource/ seguindo os paths esperados (ver Recursos (assets) e classpath).

2) Atalho de dev “R” não recarrega o mapa indoor

KeyHandler chama loadMap("/maps/interior01.txt", 1), mas o repositório contém resource/maps/indoor01.txt (sem “interior”). Sintoma: recarregar o mapa pode falhar/silenciar erro (dependendo de logging/exception). Ação: alinhar o nome do arquivo (código vs resource).

3) “Clean build” no Windows não funciona

A task do VS Code usa rm -rf bin. Em Windows, isso depende do shell. Ação: rodar a task em ambiente compatível ou ajustar o comando na task para o seu shell.

4) Tela cheia só aplica após reiniciar

A UI exibe um aviso específico: ui.options.fullscreenNotice (“A alteração terá efeito após reiniciar o jogo.”). Isso é consistente com main.Main, que decide setUndecorated(true) no boot baseado na flag carregada.

5) "The import [pacote] cannot be resolved" / "Unresolved compilation problems" (cache do JDT)

Sintoma: ao rodar o jogo pelo VS Code/Cursor, o erro aparece como:

Exception in thread "main" java.lang.Error: Unresolved compilation problems:
    The import bestiary cannot be resolved
    BestiaryService cannot be resolved to a type
    ...

O código-fonte está correto e compila normalmente via javac no terminal, mas o Java Language Server (RedHat JDT) não reconhece pacotes ou classes — geralmente após adicionar novos pacotes/arquivos ao projeto.

Causa: o workspace cache do JDT (armazenado em %APPDATA%\Code\User\workspaceStorage\...\redhat.java\jdt_ws\) ficou desatualizado e os .class gerados contêm erros embutidos.

Solução (recomendada):

Abra a Command Palette (Ctrl+Shift+P)
Execute "Java: Clean Java Language Server Workspace"
Confirme clicando em "Restart and delete"

Isso limpa todo o cache de compilação e força uma reindexação completa do projeto.

Solução alternativa (manual):

# Feche o Cursor/VS Code primeiro, depois execute:
Remove-Item -Recurse -Force "$env:APPDATA\Code\User\workspaceStorage\*\redhat.java\jdt_ws"

Reabra o editor em seguida — o JDT vai recompilar tudo do zero.

Como confirmar que o problema é cache (e não código):

# Compilar direto pelo terminal (a partir da raiz do projeto):
& "caminho\para\javac.exe" --enable-preview --source 25 -d out -sourcepath src src\main\GamePanel.java

Se compilar sem erros, o problema é exclusivamente do cache do JDT.

Automação / CI/CD

O repositório não contém .github/workflows/ nem pipelines de CI detectáveis. Também não há Dockerfile/docker-compose/Makefile.

Se você quiser evoluir isso, uma direção segura (sem “assumir stack”) é:

adicionar um build system Java (Maven/Gradle) para padronizar build/run/test
adicionar workflow de CI para build + lint + testes (quando existirem)
criar release empacotado (JAR) + instruções de distribuição

Roadmap

Backlog existente (GDD)

O arquivo gdd.md contém uma seção “Conteúdo Futuro / Backlog” e vários pontos marcados como Planejado, incluindo ideias como:

expansão de sistemas (crafting/imbuements, contratos de caça, seeds de mapa)
UX/acessibilidade extra
evolução de progressão/endgame

Importante: o GDD descreve visão e planejamento; este README separa explicitamente o que é “implementado no código” do que está “planejado”.

Próximos passos sugeridos (observando lacunas do repo)

Sem inventar escopo, estas são melhorias naturalmente sugeridas pelo estado atual:

Adicionar/commitar assets (ou documentar onde obtê-los): hoje o código referencia muitos recursos que não estão no repo.
Padronizar build/run (Maven/Gradle) para facilitar onboarding fora do VS Code.
Documentar uma “matriz de recursos” (quais arquivos existem para cada path) para reduzir troubleshooting.
Criar screenshots e um docs/ com guias curtos (por exemplo, “como adicionar um novo item/monstro/tile”).
Testes unitários para módulos puros (ex.: i18n, save/load, regras de progressão).

Contribuição

Contribuições (issues e pull requests) são bem-vindas! Consulte CONTRIBUTING.md para as regras completas.

Resumo rápido:

Abra uma Issue antes de grandes mudanças.
PRs focados por subsistema (ui/, entity/, tile/, data/…).
Ao submeter um PR, você declara ter direito sobre o que enviou e concorda em licenciar a contribuição sob os mesmos termos do LICENSE.
Contribuições devem ser originais ou compatíveis com a política do projeto.

Licença

Source-available / Proprietary — All Rights Reserved

Este projeto é público e aceita contribuições, mas não é open-source.

Permitido: visualizar, clonar, rodar localmente para estudo/avaliação e contribuir via PR para este repositório.
Proibido: reutilizar código ou assets em outros projetos, publicar forks como projetos próprios, redistribuir builds/binários, empacotar bibliotecas, ou criar derivados fora do fluxo de contribuição deste repositório.

Consulte LICENSE para os termos completos e CONTRIBUTING.md para as regras de contribuição.

Name		Name	Last commit message	Last commit date
.claude		.claude
.github/workflows		.github/workflows
.vscode		.vscode
docs		docs
resource		resource
src		src
tools		tools
.editorconfig		.editorconfig
.gitignore		.gitignore
CLAUDE.md		CLAUDE.md
CONTRIBUTING.md		CONTRIBUTING.md
LICENSE		LICENSE
README.md		README.md
config.txt		config.txt
controls.properties		controls.properties
weather.properties		weather.properties

Latest commit

History

Folders and files

Repository files navigation