How sevinatenine/fusion works
Fusion is a server for a CLI trading-card game, with separate chat and trading services and a browser-side terminal proxy. The main workflow is a client connecting to the game’s TCP server, which dispatches commands; startup also loads the database and launches HTTP, authentication, and admin services. Chat authenticates tokens through the auth service before relaying messages, while trading uses the game server for collection lookups. The tree and excerpts establish these entry points and some links; internal command, shop, and HTTP routing are not fully shown, so uncertain wiring is omitted.
Main entry points: src/main.js Service startup · server.js Game TCP server · src/main.js Web terminal proxy · authServer.js Token authentication
Components 16
Game Server
- Service startup
src/main.js - Game TCP server
src/server.js - Command dispatcher
src/commandHandler.js - Shop and auctions
src/shop.js - Card operations
src/cards.js
Supporting Services
- Database loader
src/dbLoader.js - MySQL access
src/mysql.js - HTTP service
src/httpServer.js - Token authentication
src/authServer.js - Admin panel
src/adminPanel.js
Chat and Trading
- Chat service
chat_server/src/main.js - Trading service
trading_server/src/main.js
Browser Access
- Web terminal proxy
web_client/src/main.js - Terminal emulator
web_client/public/modules/xterm/src/browser/Terminal.ts
Other components
- CLI client
- Browser user
Connections 12
- CLI client → Game TCP server: connects
- Game TCP server → Command dispatcher: dispatches
- Service startup → Database loader: loads data
- Service startup → Game TCP server: starts
- Service startup → HTTP service: starts
- Service startup → Token authentication: starts
- Service startup → Admin panel: starts
- Trading service → Game TCP server: connects
- Chat service → Token authentication: checks tokens
- Browser user → Web terminal proxy: opens session
- Web terminal proxy → Game TCP server: forwards terminal I/O
- Browser user → Terminal emulator: uses terminal