Ghostline Development Log

Following Arizona field reconnaissance and discussions about property-access and commercial photography permissions, The 9th Vessel has been repositioned in Calder, Arizona, an original fictional copper-mining town rather than a recreation of specific real-world venues.

• Rebuilt the public project page around Calder's twelve fictional main investigation spaces and ten secondary areas.
• Retired the former real-property photo comparisons, recognizable venue-based concept renders and venue-specific teaser footage from the website.
• Updated homepage, studio portfolio, metadata and social previews to describe an original fictional setting.
• Kept internal story mechanics and ending conditions private while original Calder-specific art, terrain and hotel environments are developed.

Next: produce and review original Calder architecture and media; the first Unity environment will focus on terrain and a fictional historic hotel.

Following the nationwide route audit and the first fleet-modeling milestone, RailLogic advanced its National Hub network and improved how passengers compare scheduled connections. The active work remains on a GitHub review branch; this update distinguishes verified GUI behavior from designs not yet implemented.

• Six-region National Hub review: staged Los Angeles as National Hub #5 in place of Albuquerque, while retaining Albuquerque as an important Direct and interregional interchange station. All twelve hubs and 66 unique hub-pair physical paths are present on the review branch. The static path-continuity review passed; wider compilation, timetable, fare, booking, and GUI regression checks for the realignment remain open.
• Journey choice correction: updated scheduled-trip discovery to preserve useful one-transfer itineraries alongside earlier-arriving alternatives with two transfers. The passenger results distinguish Fewest Transfers from Earliest Arrival, rather than hiding a convenient trip behind another result.
• Live validation: Phoenix ↔ Chicago was checked in both directions in the GUI. Each direction displayed an existing one-transfer itinerary via Cincinnati and a separate earlier-arrival two-transfer alternative. No additional train service was needed to correct the journey-choice presentation; seat, payment, and broader station-coverage checks are still outstanding.
• Passenger interface: planned a clearer WPF layout with trip inputs on the left, independently scrollable compact journey cards in the center, and the selected itinerary and transfer details on the right. Graphical seat selection and checkout will be separate steps, while the National Route Explorer remains available for network review.
• Group booking and passenger protection: defined a one-checkout group reservation workflow, per-leg seat inventory, and protection for paid seats even when a group member does not board. Confirmed passengers are not involuntarily displaced for standby or staff travel; any urgent active-duty military accommodation is based on verified need and customer volunteers.
• Fleet direction: continued the 12-car day-train design with one universal Comfort Class, accessible and companion accommodations, designated family/table seating, crew areas, and shared observation and café facilities. The earlier 472-position model remains a provisional engineering milestone, not a final sellable-capacity figure.

Result: the reviewed planner can show distinct transfer-versus-arrival tradeoffs in the tested Phoenix/Chicago journeys, and the next development stages have an explicit passenger-UI and booking design. The hub changes and future booking features are not being presented as a released system.

Next: complete remaining realignment and connection regressions; verify fare and seat behavior; then implement the passenger interface, group reservations, accessible seat inventory, and graphical seat selection in separately tested stages.

RailLogic completed the nationwide route-audit and Regional-consolidation phase and moved into fleet modeling. The current work turns the validated service network into a physical train configuration that can later drive capacity, scheduling, accessibility, and graphical seat selection.

• Completed and locked the remaining Regional consolidation work across the Midwest, Northeast, Central, Southeast, Northwest, and Southwest, retiring redundant short services where longer through-running Regionals now cover the same passenger markets.
• Locked a common 12-car single-deck day train for Regional, Direct, and National Day service so the operating pattern can change without requiring a different physical fleet for each service type.
• Set the standard day-train capacity at 472 assigned passenger positions, with full premium 2+2 seating cars using 15 rows of four seats and dedicated accessible capacity in Cars 2 and 11.
• Defined Car 5 as a dual-purpose observation / lounge / public dining area and Car 6 as the galley / cafe / beverage-service core, allowing hospitality to scale with actual trip duration rather than the Regional, Direct, or National service label.
• Added new C# fleet models for TrainSet, TrainCar, TrainCarType, TrainAccommodation, and TrainAccommodationType, then connected scheduled TrainRuns to the standard trainset configuration through RailNetwork.
• Verified the fleet model in the Visual Studio debugger at 12 cars and 472 passenger positions.
• Added the first seat-map generator for a standard premium car; Car 3 now creates 60 reservable accommodations from 1A through 15D, with window and aisle attributes stored on each accommodation.
• Kept seat availability separate from the physical seat definition so the same seat can later be sold on different journey segments as occupancy changes along a route.

Result: RailLogic has moved from a validated route-and-service catalog into a real fleet-and-capacity model. The network now knows what train configuration a scheduled run uses, and the first physical seat inventory is being generated in code.

Next: generate seats for the remaining premium cars, build wheelchair / PCA companion layouts for Cars 2 and 11, then continue into physical fleet assignment and timetable work before the later fare and graphical reservation-UI passes.

RailLogic completed its Southwest route-and-service audit and immediately moved into Northwest validation. The work focused on making the physical guideway, passenger-station catalog, service patterns, TrainRun schedules, and reservation screen agree with one another before each corridor is locked.

• Cleaned and consolidated RailNodeData, removed duplicate California node definitions, and added the missing Los Banos, Modesto, and Stockton passenger nodes required by the two California trunk alignments.
• Added matching passenger stations and updated the Central Valley physical path so the CA-99 side now runs Fresno → Modesto → Stockton → Sacramento.
• Built the western California Bay approach from Los Angeles → Burbank Airport → Santa Clarita → Los Banos → San Jose and linked it to the existing San Jose → San Francisco → Sacramento infrastructure.
• Locked the California Central Valley Direct as Los Angeles → Burbank → Bakersfield → Fresno → Stockton → Sacramento and the Regional as Los Angeles → Burbank → Santa Clarita → Bakersfield → Fresno → Modesto → Stockton → Sacramento.
• Validated the Central Valley service in both directions at 392 miles: Direct runs in 1 hr 58 min at a $86 fare, while Regional runs in 2 hr 17 min at a $74 fare.
• Extended the Bay service into a full California trunk. The California Bay Direct now runs Los Angeles → Burbank → Los Banos → San Jose → San Francisco → Sacramento, while the California Bay Regional adds Santa Clarita and continues through Sacramento to Redding.
• Found and corrected a reservation-data dependency: bookable stations are generated from scheduled passenger stops on actual TrainRuns. Los Banos, San Jose, and San Francisco did not appear until the new Bay Direct and Regional services received real repeating departures.
• Validated Los Angeles ↔ San Francisco in both directions at 408 miles: Direct runs in 1 hr 51 min for $90, while Regional runs in 2 hr 1 min for $77.
• With the California work complete, marked the Southwest Region complete and locked and began the Northwest audit without changing the already validated Bay service again.
• Locked NW-01 Northern Rockies Direct: Seattle → Spokane → Butte → Billings → Sheridan → Cheyenne. The 1,280-mile Direct runs in 4 hr 49 min for $282 versus the National Nonstop at 4 hr 10 min for $320, producing a clear service-tier tradeoff.
• Locked NW-02 Pacific Northwest Spine Direct: Seattle → Portland → Redding → Sacramento. Direct covers 755 miles in 2 hr 48 min for $166, while the 758-mile Regional takes 3 hr 48 min for $144. The Direct saves a full hour for a $22 premium.
• NW-03 is already represented by the California Bay service completed during the Southwest pass, so the next untouched Northwest Direct is NW-04 Portland ↔ Boise.

Result: Southwest is no longer an open-ended design pass; it is a tested, bidirectional passenger-service region with California’s Central Valley and Bay trunks operating through the same schedule and reservation model as the rest of RailLogic. Northwest validation has begun with its first two untouched Direct corridors already locked.

Next: resume with NW-04 Portland ↔ Boise, compare the Columbia–Idaho Direct against the Columbia–Snake Regional, continue the Northwest route-by-route audit, and defer fleet-size reconciliation until the full service catalog has been validated.

RailLogic made a major jump from route-catalog construction into a more complete passenger operating model. Recent work unified service timing, fare calculation, multi-train pathfinding, transfer presentation, and route auditing while the rail product name was finalized as RailLogic.

• Standardized the commercial maximum service speed at 311 mph (500 km/h) and added acceleration / cruise / deceleration timing so short segments no longer assume instant travel at maximum speed.
• Locked mileage-based passenger fares at $0.19 per mile for Regional, $0.22 per mile for Direct, and $0.25 per mile for National Hub Nonstop, with mixed-service trips priced from the actual mileage and service type of each leg rather than a transfer surcharge.
• Added unlimited multi-transfer rail pathfinding that can combine Regional, Direct, and National Nonstop services, uses real scheduled TrainRuns, respects minimum connection windows, handles time zones, and ranks viable itineraries by arrival time and transfer count.
• Improved connection ranking so repeated schedule choices on the same route combination are reduced to the best useful options instead of flooding the passenger with near-duplicate itineraries.
• Reworked the reservation presentation into a wide planning column and a continuous right-side timetable showing Station, Arrival, Departure, and Service / Action, with BOARD, TRANSFER, and EXIT behavior kept inside one readable journey table.
• Refined connection cards so each itinerary clearly exposes fare, departure / arrival timing, total duration, transfer count, service mix, and transfer cities before the passenger selects a departure.
• Expanded Southwest Direct service data, corrected time-zone and rail-node behavior, and continued aligning the reservation screen with the same service and schedule model used by the route catalog.
• Added the Western Intermountain Regional passenger service from Phoenix to Salt Lake City, serving Camp Verde, Flagstaff, Kingman, Henderson, Las Vegas, St. George, Cedar City, and Provo before reaching Salt Lake City.
• Audited and validated Phoenix ↔ Salt Lake City National Nonstop service at 828 miles and Phoenix ↔ Seattle National Nonstop service at 1,679 miles in both directions, including fares, elapsed time, daily departures, average speed, and time-zone behavior. The Phoenix ↔ Salt Lake City Direct overlay was also validated in both directions.
• Locked a new network-design rule for the Regional audit: a Regional service should normally connect meaningful major terminals, Direct stations, National Hubs, or inter-regional gateways along the same physical corridor rather than terminate at an arbitrary Regional station.
• Established a common national timetable pattern for implementation across all six regions: Nonstop → Direct → Regional → Direct → Regional → Direct → Nonstop between the four-hour National Nonstop anchors. This operating pattern is a planning standard and will be wired into the timetable generator next.

Result: RailLogic now behaves much more like an integrated passenger railway model rather than separate route, booking, and timetable demonstrations. Physical corridors, passenger services, real departures, fares, transfers, and the reservation UI are converging on one operating system.

Next: implement the national departure pattern in the timetable generator, continue the Southwest audit through Regional and Direct endpoint structure, rework corridors such as the Rio Grande Regional where an ordinary station currently acts as an artificial terminus, and keep validating every service in both directions before locking it.

RailLogic moved another step from network design into a passenger-facing operating prototype. The reservation interface is now being tied directly to the same service, timetable, and route data used by Route Explorer instead of treating booking as a separate demonstration layer.

• Expanded the National Hub route catalog through the Bismarck pairing set, adding long-distance combinations including Bismarck-to-New-York, Pittsburgh, Nashville, and Miami while continuing to use shared physical corridor segments rather than duplicating track logic.
• Refined several National Hub alignments so routes follow the preferred operating geography instead of simply passing through another National Hub when a cleaner bypass is available.
• Updated the passenger journey wrapper so National Hub and Regional journeys can point directly at a RailService; ordinary-station trips temporarily retain the legacy direct / one-transfer highway-route planner while the full service conversion continues.
• Connected the reservation screen to selected departures and train inventory so it can display the train name and live available-seat count for the chosen schedule.
• Moved seat selection into a dedicated, scrollable Choose a seat window with a four-column seat layout, disabled unavailable seats, highlighted current selection, and return-to-reservation behavior.
• Reworked the main reservation results area around readable journey details instead of a permanently visible seat grid, freeing the workspace for route, schedule, transfer, and trip information.
• Added a Copy trip action so the currently displayed itinerary can be copied directly from the reservation screen.
• Improved transfer handling so the selected itinerary can show the transfer station and calculated connection time between arrival and the next departure.
• Kept booking controls for passenger information, departure selection, payment method, fare display, reservation, and cancellation while integrating the newer journey-detail workflow.

Result: the reservation system is beginning to operate as a true front end for the RailLogic network model. Route Explorer, scheduled services, transfer timing, train capacity, and seat selection are converging on the same underlying data instead of being maintained as separate demonstrations.

Next: finish the remaining National Hub route pairs, continue replacing the legacy ordinary-station planner with service-based Regional journeys, validate transfer windows across longer itineraries, and keep tightening the reservation UI as the operating model becomes more complete.

RailLogic has moved from designing individual showcase corridors into a repeatable National Hub route-build process. The current pass applies the same physical-corridor, station, service, and scheduling rules across the full hub network instead of forcing every pair into an immediate route.

• Advanced the current National Hub route-build sequence to roughly 22 of 67 planned routes, with each route checked against available guideway, passenger geography, and practical transfer structure.
• Revised the active National Hub set so Albuquerque, New Mexico replaces Denver, Colorado; Albuquerque is now used for the remaining National Hub route generation unless the network plan is revised again.
• Locked the rule that alternate physical corridors serving meaningfully different geography are regular scheduled routes, not hidden contingency-only paths. The default alternate-corridor pattern is two trains per day in each direction—one morning and one evening—with additional service during holiday and high-demand periods.
• Prioritized routes that can be built from the guideway already represented by the Interstate-system corridor catalog. When the better primary path depends on a not-yet-built U.S.-highway corridor, that hub pair is deferred rather than routed through an unrealistic Interstate detour.
• Applied that rule to Cheyenne ↔ Houston, which remains deferred until the planned US-287 corridor is added during the corridor-expansion phase.
• Locked universal trip-planning behavior so reservation searches will eventually return all valid scheduled itineraries between approved passenger stations, including feeder or Regional legs into gateway stations, direct services, non-stop services, and valid transfer combinations.
• Standardized the passenger operating window around stations opening at 6:00 AM, first departures at 7:00 AM, Regional departures repeating every two hours, and no train departures after midnight; trains may still arrive after midnight when the booked itinerary requires it.
• Refined the guideway geometry rule: 375-mph mainline alignments should remain as straight and flat as practical with very large-radius curves, while tighter curves are permitted where necessary if trains slow before entering them. Very low-speed curves around 40–50 mph are reserved for terminals, junctions, urban constraints, and other special-use locations.

Result: route generation is now governed by a consistent network-wide operating model instead of one-off corridor decisions. That makes the remaining hub build more realistic, easier to audit, and better prepared for later timetable and reservation-system integration.

Next: complete the remaining National Hub routes that can use existing Interstate guideway, build the deferred U.S.-highway corridor expansions, return to deferred hub pairs such as Cheyenne–Houston, and connect the completed route catalog more deeply to scheduled journey planning.

RailLogic continued its move from a route-reference model into a scalable operating network by expanding permanent hub-to-hub travel routes, locking additional transcontinental corridor data, and adding logic for connected trips and alternate operating paths.

• Added TR-508 — Northern Tier Corridor, a direct Seattle-to-New-York transcontinental route using the I-90 spine through the Northwest, northern Plains, upper Midwest, Chicago, and the eastern approach into New York.
• Expanded the permanent route register with TR-506 Pioneer-Atlantic Line from Salt Lake City to New York, TR-507 Gem State Seaboard Line from Boise to New York, TR-509 Piedmont-Seaboard Express from Atlanta to New York, TR-510 Sunshine-Empire Express from Miami to New York, TR-511 Wasatch & Sound Express from Salt Lake City to Seattle, and TR-512 Intermountain-Texan Line from Salt Lake City to Dallas-Fort Worth.
• Completed the Phoenix-to-Seattle TR-109 Valley-Sound Route and its associated Valley-Sound link structure, extending direct National Hub coverage into the Pacific Northwest.
• Audited the I-90 station and node sequence across the western and northern transcontinental corridor, including coverage through Washington, Montana, Wyoming, South Dakota, Minnesota, Wisconsin, and Chicago.
• Kept passenger hubs distinct from track-only guideway junctions so technical routing points can support realistic path construction without appearing as bookable passenger stops.
• Added HubTripPlanner groundwork for finding a connected sequence of rail services between National Hubs when a trip requires more than one service.
• Added OperatingRouteSelector logic that evaluates a service's primary and alternate travel routes, excludes route IDs marked as congested, and selects the shortest available route by baseline mileage.

Result: RailLogic can now represent a much larger transcontinental hub network while separating passenger service, physical travel routes, transfer planning, and real-time operating-route choice into independent layers.

Next: continue building the remaining National Hub routes, connect the hub planner to scheduled services and transfer timing, and expand alternate-route data so congestion handling can move from route selection logic into full journey simulation.

RailLogic advanced from a highway-and-station reference model into the beginning of an operational rail network. The work now separates the physical route a train follows from the passenger service pattern and the individual scheduled train that operates it.

• Established the 12 National Hubs across the six planned rail regions, including station capacity, storage-yard, maintenance-facility, and local-time-zone data.
• Added the first permanent multi-corridor travel route: TR-101 — Intermountain Meridian, connecting Phoenix and Salt Lake City through I-17, I-40, I-11 / US-93, the Las Vegas connector, and I-15.
• Separated passenger-serving stations from track-only guideway junctions so the network can model real routing and mileage without exposing technical connectors in passenger searches.
• Created the Desert-Salt Arrow National Hub Nonstop Express and the Intermountain Meridian Regional service pattern on the same physical route.
• Defined both northbound and southbound service directions, with the Regional service scheduling every passenger station and 15-minute intermediate dwell times.
• Added individual daily train runs for the Desert-Salt Arrow at 7:00 AM and 7:00 PM from each terminal, separating a service pattern from the train departures that actually operate it.
• Added time-zone-aware arrival calculations so Phoenix-to-Salt-Lake-City schedules can correctly account for Arizona's year-round time standard and Utah daylight-saving changes.
• Expanded Route Explorer into an operational route inspector that can display service type, direction, corridor path, route nodes, scheduled passenger stops, mileage, travel duration, daily departures, and estimated arrivals.

Result: RailLogic now has a scalable operational foundation for named passenger services, route-specific schedules, reversible travel directions, later capacity simulation, and transfer-wait calculations.

Next: add scheduled Regional train runs, build the next National Hub-to-Hub travel routes, and begin the service-based Journey Planner that can compare direct, connecting, and capacity-limited options.

The RailLogic reservation system moved beyond its original hard-coded regional trip set and now loads the complete national rail network from the project Excel workbook. This creates a much larger foundation for route discovery, passenger booking, and future planning features.

• Loaded 66 interstate routes and 572 station entries.
• Added searches for direct and one-transfer journeys.
• Enabled cross-country trip booking, including New York to Los Angeles.
• Displays the interstates and transfer station used for the selected journey.
• Added departure and available-seat selection.
• Supports cash and credit-card reservations.
• Allows tickets to be confirmed or cancelled during the current session.
• Successfully tested a New York-to-Los-Angeles reservation using I-80, transferring in Sacramento, and continuing on I-5.

Result: The application can now model and book trips across the nationwide rail network rather than only within a small, fixed set of regional routes.

Next: replace the long city-selector lists with a searchable origin-and-destination form supporting city names, states, regions, three-letter airport or location codes, and spelling suggestions.

Current limitations: fares and travel times are estimated, journey planning supports no more than one transfer, and reservation records are stored only for the current session.

Today’s work advanced three active areas: Ghostline Chess presentation and accessibility, The 9th Vessel’s internal narrative-resolution design, and the Ghostline Technology contact experience.

• Documented the Ghostline Chess August 2026 development refresh: Easy, Normal, and Hard AI settings; full-square legal-move and capture highlighting; Oxblood Chapel, Crypt, and Moonlit Graveyard themes; and a cleaner command area for game, theme, and audio controls.
• Kept the public Ghostline Chess v1.2.0 download separate from the newer refresh build while final release testing and packaging remain in progress.
• Reworked The 9th Vessel’s internal outcome scoring around three miner outcomes—Released, Missed, and Claimed—while preserving independent paths for the Demon, Elias, the miners, the Priest, individual investigators, and the town.
• Confirmed that ending grades are calculated from player consequences rather than selected as inputs, keeping the system responsive to investigation choices while protecting story spoilers.
• Completed the contact-confirmation page with a clear submission acknowledgment and simple return paths to the home page or contact form.

Result: the studio’s current Chess work is accurately framed for release, The 9th Vessel has a clearer internal foundation for consequence-driven endings, and the company website now gives visitors a more complete confirmation after they reach out.

View Ghostline Chess →   Explore The 9th Vessel →   Contact Ghostline →

With the Phase 1 carrier workflow frozen, TransitLogic moved into its decision-intelligence phase. The new work is focused on helping a carrier understand not only which loads are available, but which loads best fit the truck, operating costs, schedule, and next move.

• Added a 0–100% explainable Load Match Score using equipment preference, deadhead, True Profit per mile, profit per hour, schedule cushion, and all-mile rate.
• Added Best Match sorting and a Best Matches quick filter so stronger opportunities can be surfaced without manually comparing every row.
• Added a Why This Load explanation inside Load Details so recommendation scores remain transparent.
• Added dedicated pickup and delivery date/time fields, transit-window information, and a simplified larger-font load-board layout for faster scanning.
• Added left-side red, yellow, and green urgency indicators based on the available pickup-to-delivery window, plus a clear Details action for deeper load review.
• Added a Next Load Trip Planner that searches compatible outbound freight after the selected load delivers and compares two-load chains.
• Added combined trip metrics including gross revenue, True Profit, operating miles, layover time, profit per hour, and chain score.
• Added HOS-aware schedule-feasibility planning using configurable remaining driving hours, cycle hours, stop service time, estimated break/rest requirements, and final-delivery cushion.
• Trip chains are now classified as HOS Feasible, HOS Tight, or Not Feasible, with the feasibility result incorporated into the chain score.
• HOS calculations are presented as planning assistance rather than guaranteed legal compliance; the prototype does not guess actual ELD history, exemptions, or sleeper-berth exceptions.

Result: TransitLogic is beginning to move beyond a conventional freight listing board toward a carrier decision platform that can explain which load fits, what it is expected to earn, what should follow it, and whether the combined schedule appears realistically workable.

View TransitLogic →

TransitLogic reached its Phase 1 freeze point after a concentrated workflow, interface, and prototype-stability pass designed to lock the freight platform's operating model before backend development begins.

• Standardized the primary load lifecycle around Draft, Posted, Tendered, Accepted, Assigned, In Transit, Delivered, Completed, and Cancelled, with Exception Hold reserved for active recovery cases.
• Refined role-aware workflow behavior for brokers, shippers, carrier administrators, drivers, receivers/facilities, and system administration.
• Rebuilt Carrier Search around a compact search bar, Quick Search, Saved Lanes, smart defaults, and collapsed Advanced Search & Profitability controls.
• Limited the marketplace to a 10-load visible window with an internal scrollbar and sticky result headers so the board no longer stretches the page.
• Streamlined Post a Load into clearer customer, route/appointment, load basics, pricing, and advanced-option sections while preserving draft recovery and profitability calculations.
• Connected saved pickup and delivery facilities to Facility Intelligence, including operating hours, appointment rules, parking, restroom, lumper, washout, TWIC, and special-instruction information.
• Added mobile-responsive navigation, search, advanced filters, load details, facility information, booking controls, and posting workflows.
• Added clearly labeled demo data and Phase 1 validation documentation and smoke checks to support repeatable prototype testing.

Result: Phase 1 is now frozen as the baseline prototype, providing a stable checkpoint for Phase 2 development.

View TransitLogic →

A focused website repair and synchronization pass brought the Haunted Echoes presentation back in line with the current playable builds and media assets.

• Replaced the corrupted 27 KB The 9th Vessel gameplay-teaser asset with the complete source video and confirmed a successful GitHub Pages deployment.
• Replaced the washed-out Ghostline Chess website image with the current interface screenshot showing the board, Tome, Graveyard, AI selector, board-theme selector, and audio controls.
• Added official Ghostline Chess concept/cover artwork using the canonical Hallowed Saints vs. The Damned naming, while keeping the actual playable screenshot clearly identified as the current development build.
• Updated the Haunted Echoes Ghostline Chess playable-release card to feature Easy, Normal, and Hard AI difficulty levels.
• Added the current full-square legal-move and capture highlighting to the public feature summary.
• Added Oxblood Chapel, Crypt, and Moonlit Graveyard board themes and the refined compact desktop layout to the studio page.
• Kept the published v1.2.0 download clearly separated from the newer August development refresh while final packaging remains pending.

Result: Haunted Echoes now presents the current Ghostline Chess development build accurately, and the public gameplay teaser media is restored.

Ghostline Chess received a focused usability and presentation update designed to make legal moves easier to read and the computer opponent easier to approach without changing the complete chess rules.

• Added Easy, Normal, and Hard AI difficulty choices.
• Replaced small legal-move markers with full-square destination highlighting and a distinct capture treatment.
• Added Oxblood Chapel, Crypt, and Moonlit Graveyard board themes.
• Reorganized the interface so the board and status remain on the left while the Tome, Graveyard, FEN, AI, theme, and audio controls occupy a compact right-side panel.
• Completed final selector, status-text, spacing, and audio-control polish after testing the updated layout.
• Published the latest interface screenshot and feature summary to the Ghostline Chess website.

Result: the development build compiles cleanly and the refreshed visual system is complete.

View Ghostline Chess →   Open the detailed Chess log →

A short AI-assisted visual-development teaser went live to test first-person mood, flashlight movement, environmental tension, and restrained paranormal presentation while keeping story-critical material private.

Ghostline completed a privacy and repository-maintenance pass that kept company pages visible, removed unnecessary personal search exposure, and retired outdated automation while preserving GitHub Pages deployment.

The apparition direction now favors solid, human-looking figures, period clothing, sound, behavior, and subtle visual wrongness instead of constant glow, transparency, or floating.

The Windows Forms War project was rebuilt with complete WAR resolution, automatic opponent play, Auto-War, the Blood Ledger, audio hooks, and a dedicated project page while custom gothic deck artwork entered production.

View War of the Damned →

ChoiceMaker moved beyond its original proof-of-concept role with generic project validation, ending evaluation, priority resolution, failure explanations, a public developer preview, and 46 passing automated tests.

Explore ChoiceMaker →

A dedicated software-development services page, structured metadata, robots.txt, sitemap.xml, internal linking, and Google Search Console setup established a clearer public search foundation for Ghostline Technology.

Early mining-environment studies were originally displayed with a real-property comparison gallery; those visuals have since been retired while spoiler-sensitive story and outcome material remained private.

The internal story bible aligned the historical mystery, investigation progression, late-game logic, and public spoiler boundaries into one consistent structure.

The investigation prototype could test the primary and secondary routes, replay variation, encounters, fail-forward progression, and finale outcome logic without publishing the mystery's solutions.

Ghostline completed a visual QA pass across the company website, improved brand presentation and footer hierarchy, corrected Chess download contrast, and refined the public presentation of current Haunted Echoes projects.

Ghostline packaged the tactical AI build, refreshed Chess download and social assets, reorganized active development folders, verified repositories and builds, and synchronized the company website and detailed Chess log.

View Ghostline Chess v1.2.0 →

The computer opponent moved beyond random legal moves with material-aware evaluation, minimax search, alpha-beta pruning, capture ordering, tactical scoring, and background calculation.

Carrier search, presets, KPI cards, postal route estimates, profitability calculations, registration flows, lane intelligence, facility requirements, and driver-support data were expanded.

View TransitLogic →

The active piece assets, sprite loading, theme hooks, Chronicle support, project files, and documentation were standardized for the current game presentation.

A looping gothic background suite, randomized environmental creaks, faction-and-piece move/capture cues, and deferred audio startup established the game's layered sound system.

The studio artwork, cinematic introduction, sound controls, and page organization were refreshed while software, games, Labs, company, and development-log content were separated more clearly.

Castling, en passant, promotion, check, checkmate, stalemate, repetition, fifty-move, and insufficient-material rules were completed alongside FEN tools, move history, and captured-piece displays.

The Java Swing dashboard, navigation, employee records, search, detail, new-employee, and evaluation workflows connected the object model to working interfaces.

Open FleetTrack log →

FleetTrack planning mapped trucks, drivers, employees, assignments, and operational records while establishing a backend-first path from console logic to a scalable desktop interface.