Independent project / Palworld 1.0 / Server & community

ASCENDANT

A gaming hobby that grew into custom software, connected services, and a community to look after.

Overview · What I built

I started Ascendant because I wanted to try running my own Palworld server and gaming community. I acquired game hosting, configured the dedicated server, and set up Discord channels for rules, announcements, support, and events.

As I ran the server, I built the tools I wanted: custom runtime extensions, PalMap web administration, Discord commands, and automated boss events and rewards. My work covered requirements, AI-assisted development, systems integration, testing, deployment, and day-to-day community concerns.

Back to projects

Inside the project

Real screenshots from the server, my custom tools, and Discord workflows. Player identifiers and private connection details have been removed.

Actual Palworld gameplay showing the Ascendant arena. — **In-game arena.** The game environment behind the event and administration work.

PalMap Give interface with item search, quantities, and a confirmation basket. Player names are redacted. — **PalMap administration.** My web interface for selecting items, setting quantities, and confirming server grants.

PalMap zone editor with safe/PVE, PVP, no-build, boss arena, and restricted-zone controls. — **Custom zone management.** Map boundaries, rule controls, and runtime status in PalMap. The interface manages configuration for the custom runtime extensions.

Ascendant Discord channels and a Grizzbolt bot announcement explaining boss event timing, rounds, rewards, and teleportation. — **Discord event workflow.** A bot announcement explains schedule and mechanic changes in English and Tagalog.

Game Host Bros hosting panel for Ascendant, showing settings and resource monitoring with private connection details redacted. — **Hosted-server operations.** The third-party Game Host Bros panel I used for the dedicated server. This is separate from my custom tools and NAS supporting services.

Why I built it

The standard server and individual tools provided useful administration and integration features. My requirements called for connecting those capabilities with custom rules, event coordination, and records that an administrator could act on.

Operational needs and the extensions I built
Operational need	Existing setup	My extension
Custom area rules	Server settings and runtime tooling	Configurable no-build zones, administrator exceptions, restricted-area handling, and structure protection.
Central administration	Hosting panel and separate server/API views	PalMap combines map, player, server, and zone workflows in a browser interface.
Multi-wave encounters	Game runtime and encounter mechanisms	Controllers coordinate generation, wave state, runtime commands, and result handling.
Reward reconciliation	Grant commands and server responses	Per-reward records track expected, confirmed, missing, and uncertain deliveries.
Discord operations	Discord applications and RCON/API connectivity	Role-gated commands, bilingual announcement relays, and scheduled reminders.
Operational review	Separate logs and service events	Monitoring adapters, structured history, and configured notification destinations.

Administration capabilities

The administration layer turns information and commands into repeatable tasks. Web administration and Discord provide complementary entry points.

Inspect players and server state: Open PalMap → backend requests server and supported PalDefender player views → inspect location, state, and authorized inventory/progression information.
Configure map zones: Edit zone geometry and supported rules → save JSON configuration for the deployment workflow → align a visible map boundary with runtime enforcement settings.
Prepare and manage events: Preview encounter scaling or start an authorized event → services generate parameters and coordinate lifecycle/waves → manage a repeatable encounter rather than a collection of manual steps.
Review rewards: Inspect delivery records → distinguish confirmed amounts, known missing amounts, and UNKNOWN responses → reconcile incomplete delivery without blindly replaying every grant.
Send announcements: Publish an approved message or schedule a reminder → relay to configured destinations and supported in-game paths → communicate consistently across channels.
Review monitoring and audit records: Inspect service transitions, configured log feeds, and command records → investigate supported evidence → make an informed administrative decision.

Existing zone reference map — Supporting zone reference: communicates approximate no-build areas around event locations. The editable zone configuration is managed separately.

Running the community

Keeping the server online was only part of the work. I answered player concerns, handled feedback and community issues, maintained rules and Discord channels, and organized events.

When schedules or mechanics changed, I explained what was changing and what players needed to know. Those conversations helped me decide which tools and workflows to build next.

Discord as an operational interface

Authorized commands

/worldboss dryrun, /worldboss start, and /worldboss status pass an owner-role check before the event controller acts and returns a response. A dry run previews generator output without spawning an encounter. Server-facing actions use the relevant RCON or runtime-file path; local event operations do not all require RCON.

/event create, /event score, and /event close are owner-gated service workflows for registration, scoring, and eligibility. This distinguishes interactive Discord API commands from outbound notifications.

Announcements and reminders

/event announce checks the owner role and publishes the approved schedule through the Discord API. The announcement relay sends messages to configured English and Tagalog destinations, records processing, and retries failed destinations. Guide reminders retain their processed slots. Supported in-game announcement paths use the server integration rather than a Discord webhook.

Operational notifications

A service transition or configured monitored log produces a notification → a bot/API adapter or outbound webhook sends it to the configured channel → an administrator reviews the event. Interactive bots receive commands and return responses; webhooks deliver outbound messages.

System architecture

Runtime components run with the hosted game server. Outside that process, Node.js services coordinate administration and Discord, and Python generates encounters. Administrators use PalMap’s browser interface and backend to inspect state and edit configuration.

Component responsibilities and communication paths

Players ↔ Palworld Dedicated ServerGame client/server connection

Provider-managed hosting · Bropanel for operational controls

Custom runtimeUE4SS · C++ zones
Lua Alpha watcherIntegrated systemsPalDefender security/tools
TowerBound progression

PalMap web administration↔ HTTP/REST ↔Palworld state + PalDefender player views

Node.js administration bots↔ RCON ↔Server commands + grant responses

Node.js event workflows→ subprocess / JSON →Python encounter generator → runtime JSON files

Runtime observation + services↔ SFTP / file exchange ↔Event records, runtime commands and logs

PalMap zone editor→ JSON configuration →Zone files → deployment workflow → C++ runtime

Bots + notification services↔ Discord API · outbound webhooks →Administration, announcements and review channels

Configuration, logs & reward recordsJSON state · NDJSON history · per-reward confirmation records

RCON: Remote server administration commands.
HTTP/API: Requests between services; PalMap uses documented REST-style routes for server and player information.
Webhooks: Event-triggered notifications sent to configured destinations.
UE4SS: A third-party runtime extension framework for interacting with the running game.

Development, release & NAS migration

Development began on my laptop, with code maintained in private GitHub repositories. I validated the components and packaged a stable release baseline. Selected supporting services were migrated to my NAS, while the dedicated game server remained with its hosting provider.

Development and delivery workflow

LaptopDevelopment and integration
Private GitHubVersion control
Validation & release freezeStable baseline
Selected NAS servicesSupporting-service operation

Separate hosted game runtimeSupporting services ↔ RCON / HTTP/API / SFTP and runtime files ↔ provider-hosted server

Local tests, dry runs, and configuration checks supported development; server-connected checks covered runtime behavior and integration paths. Release packaging preserved a stable baseline for deployment. The NAS provided a separate home for selected supporting services, with service configuration and persistent state kept distinct from the hosted game runtime.

My engineering contribution

Runtime development

C++ / Lua — configurable no-build rules, administrator exceptions, and restricted-area handling; Lua scripts observe encounters and write runtime status files.

Web and service development

PalMap / Node.js / Python — interactive map and zone administration, backend player views, and encounter controllers that call Python to generate runtime parameters.

Systems integration

RCON / APIs / Discord / webhooks / file exchange — role-gated event commands connect to supporting services; JSON and SFTP carry configuration, observations, and raid HUD commands between services and the hosted runtime.

Delivery and operations

Version control / validation / release packaging — private source history, local and server-connected checks, stable deployment baselines, selected-service NAS migration, and configuration troubleshooting.

Handling uncertain reward responses: per-reward records retain expected and confirmed quantities. Retries request only known missing amounts; an ambiguous response stays UNKNOWN for explicit review instead of automatic replay. This reduces duplicate delivery risk without promising exactly-once delivery.

Existing Boss Raid arena layout — Supporting arena reference: boss spawn positions, player placement slots, and the counted event area. Numbered slots identify positions, not individual players.

Deployment requirements

This is a custom integrated deployment, not a ready-to-install public product. Compatibility depends on the selected game, runtime, and integration versions.

Core platform

A compatible Palworld Dedicated Server and hosting that permits the required runtime extensions and file access.
Compatible UE4SS plus the custom C++ modules and Lua scripts used by the selected features.
Node.js and the relevant service dependencies for the web backend and bots.
Private configuration and secrets, writable persistent records/logs, and backup workflows.

Feature-specific dependencies

Python for encounter generation and access to the runtime files used by event workflows.
RCON and HTTP/API connectivity with authorized credentials for the relevant administration features.
SFTP access for the implemented remote file workflows.
A Discord application/bot, role permissions, and configured channels; webhooks only for notification paths that use them.
PalDefender for supported player views/security integrations and TowerBound for the integrated progression/observation workflow.

Infrastructure used in my deployment

The laptop served development and local supporting-service execution. Private GitHub supported source control. The NAS hosted selected supporting services, with runtime dependencies, configuration, persistent storage, and connectivity to the hosted server. Game Host Bros/Bropanel was my hosting arrangement, not the only possible provider.

Technology stack

Runtime: C++ · Lua · UE4SS
Services: Node.js · Python · PowerShell
Web: HTML · CSS · JavaScript · Express · Leaflet
Integration: RCON · HTTP/REST · Discord API · webhooks · JSON · SFTP
Development Tools: Git · GitHub · Claude · OpenAI Codex
Development & delivery: Git · private GitHub · local validation · release freeze · partial NAS migration
Operations: Structured logs · configuration · backup workflows · hosting control panel
Third-party integrations: Palworld Dedicated Server · PalDefender · TowerBound

Used Claude and OpenAI Codex to assist with implementation, debugging, code review, and documentation. I defined requirements, reviewed changes, validated behavior, and managed deployment.

Outcome & current status

I brought custom runtime rules, web administration, Discord operations, encounter coordination, and reward reconciliation into one connected environment. The work combined software development with deployment, configuration, monitoring, and operational troubleshooting.

Status: Selected supporting services were migrated to the NAS; broader migration remained in progress. Current server availability and enabled features have not been rechecked.

The project demonstrates how I turn operational requirements into targeted software, connect independent systems, and manage the path from development to a maintainable deployment.

Discuss a similar project

Connect on LinkedIn ↗ Send an email