Search the Community

Disclosure: I work with SEELE. This is a technical note from a Godot 4.6 prototype generated and reviewed in our workflow. The project is a small dungeon-management RPG with a Web export preset. Its loop is: dig, assign rooms, recruit monsters, pay upkeep, and survive a hero wave. The biggest debugging improvement came from separating three states instead of adding more systems: 1. Build state — whether a tile operation is valid and readable. 2. Economy state — whether cost, upkeep, and pressure are visible before combat. 3. Combat state — whether hero and monster outcomes explain what changed. The prototype uses an 18×13 grid, explicit room/trap tiles, four monster classes, three hero classes, and replay scenarios for the full loop, placement, combat, and results. For browser-game developers, which of these boundaries usually fails first in your prototypes? Workflow notes: https://seeles.ai/workspace?utm_source=html5gamedevs&utm_medium=community&utm_campaign=rpg_acq_202607_w1&utm_content=godot_web_state_boundaries_01

Hi all, I have been working as a Java Developer for over 7 years and while studying AngularJS I decided to create a browser strategy game for fun, like Travian/TribalWars/Ikariam etc... Right now I am thinking about how the server architecture should be. I tried to find some examples on how this kind of games distributed their servers but I couldn't find any useful resource, so I came with my own. My sketch and authentication flow (follow the numbers from 1 to 9): In a general way, is that a suitable one? From my personal developer experience I decided it was a safe idea to split the public front-end from ther auth and game servers. Do you think there are any Cons in this architecture? About hosting, which service/host is most suitable for each server? 1) Authentication server, single point 2) Front-End server, distributed over the world 3) Game Servers, each one in its specific country I am open to new ideas and changes! Thanks in advance!