flintnapa wrote:

I have a few suggestions that I think anyone taking on the legacy 2Moons code should give thought.The 2Moons code based is truly over engineered and it's causing failures to maintain that code base.

1. Migrate out of Smarty and go pure PHP. Don't even bother making the mistake of upgrading to the latest version of Smarty. You will be wasting your time. Stick to version in the legacy code or better still bin Smarty altogether.

2. Get out of Ajax. It just adds unnecessary complexity.

3. Just migrate to PHP 8.x you achieve a faster core, smoother game play. Opt for PHP cache to be even faster.

The 2Moons legacy codebase is dead. Frankly, it's been well and truly over engineered, creating unnecessary complexity, and making the code dead weight.

Good luck.

flintnapa wrote:

I would also say rewrite/refactor the whole fleet code. The legacy code breaks down with stuck fleet simply due to the complex way it's coded with a really unstable cron method. Scrap using fleet tokens. Modernise the fleet database. Essentially just delete the old fleet database and create it new. Then code it in PHP 8.x, js. You'll waste days trying to unravel stuck fleets and patching it up won't work. The short cut is to build it back up from scratch.

amamoslavida_ wrote:

If I truly wanted to take this game further and make it open source for the benefit of the community, I would choose a C++ desktop architecture instead of a PHP/Web-based approach.

In my opinion, building dedicated Client and Server applications and synchronizing them through a proper networking layer such as WinSock2 (or any modern cross-platform networking library like ASIO) provides far greater control, performance, and scalability than relying on JavaScript, Bootstrap, PHP, or other web technologies.

With C++, you can design a real-time game loop that ticks and updates deterministically. You have full control over memory management, threading, and synchronization. Using tools like std::thread, std::mutex, std::lock_guard, std::unique_lock, and atomic operations, you can safely manage concurrency and prevent race conditions at the engine level — rather than depending on database-level locking like in MySQL.

Unlike PHP’s request-response lifecycle, a C++ server runs persistently. This allows you to:

• Maintain in-memory world state without constantly reading/writing to a database
  
• Avoid heavy database contention and row-level locks
  
• Eliminate many timing issues that cause lost resources, duplicated actions, or fleet inconsistencies
  
• Implement fine-grained synchronization with RAII-based locking (e.g., std::lock_guard)
  

You can also design scalable architectures such as:

• Multi-threaded zone servers
  
• Worker thread pools for combat simulations
  
• Dedicated AI servers for bots
  
• Event-driven networking using epoll / IOCP models
  

From a performance standpoint, C++ gives you:

• Deterministic execution
  
• Lower latency
  
• Zero garbage collection pauses
  
• Direct memory control
  
• Efficient use of STL containers for large-scale simulations
  

For large battles or heavy simulation workloads, C++ can process calculations significantly faster than PHP, especially when using optimized data structures and cache-friendly designs.

In short, instead of depending on stateless web requests and database synchronization, I would build a persistent C++ client-server architecture. This would allow the game to support thousands of concurrent players, handle complex simulations, and maintain consistency without suffering from performance bottlenecks or race conditions common in web-based systems.

XenQen wrote:

Of course it takes way too long to fully rewrite this in c++, on the other hand the best approach would be to leave 2moons behind and rework an open source code such as github.com/lanedirt/ogamex, its written in Laravel 12, its modern but somewhat inefficiently coded on certain areas - though its a great source to start from since well... laravel 12 is actually modern while 2moons is nearly 20 years old - i do not see a reason to edit anything anymore on that old piece of code that was may be good in 2009-2016.