Melia Development Roadmap

[ovflowd]

Hello, y'all 👋, in this discussion we're addressing the Development Roadmap of Melia. This discussion is an open discussion where everyone's invited to give their punctual points about what should be the next priorities to take part in every next milestone.

[ovflowd]

Project Management Milestone

In the first brief milestone, we're deciding upon which Development and Software Engineering best practices and conventions we're going to adopt for this project.

The following patterns and conventions are being considered:

• Kanban for Project Management.
• Conventional Commits for commit messages.
• Semantic Versioning for the versioning of the software.
• GitFlow Workflow for the Git workflow.

Please feel free to add your opinions regarding the matter.

[ovflowd]

Another note: Is that we might consider adopting DDD which is Domain-Driven Design.

[ovflowd]

Melia Refactoring and Code Maintenance Milestone

This is a non-ending milestone meant to keep track of current issues or possible enhancements that can be done inside the source code of Melia.

Tasks part of this milestone are categorised by the following:

Documentation

Any tasks which aim to improve either the Markdown documentation, the Wiki Guidelines or the inline source Documentation (Class Documentation, API docs, and other docs that are added directly inside the source code)

Code Leveraging

Any tasks that aim to simplify, or reduce complexity in business logic or application logic. These also include Class refactoring, renaming of variables and overall code structure refactoring. The addition of new libraries is not considered "Code Leveraging" tasks.

Which kind of tasks do not belong inside this Milestone?

• Tasks that aim to replace a Library (Eg.: replacing a simple MySQL connector with something more robust)
  • Those should be feature tasks and be included in normal milestones since they might drastically affect the source code and pending tasks.
• Major refactoring of whole components.
  • These might be classified as separate tasks depending on how much they affect open tasks and how much the pieces of code are intertwined. It's recommended if possible to always create Contracts between classes, and if possible, maintain those contracts and only change the inner source code of those classes.

[ovflowd]

Melia Features Milestones

These are normal Milestones related to the normal development and adoption of new features inside the Melia ecosystem. Tasks that belong to these milestones are:

• Development of new Packets/Handlers/Messages that add new Client-side counterpart logic in the Server-side
  • This means the addition of new features to handle parts that were not implemented yet inside the Server-side
  • Solely for the handling of Packets or Messages that were not done or are still missing.
• Development of Emulation-related components for the leverage of the Emulation
  • GameMaps, Pathfinders and any other kind of classes and components that are responsible for handling the state, movement, actions and the life-cycle of the game itself (Characters, NPC's, Maps, and more)
• Development of Features of the Game
  • These are tasks that are responsible for the Application Logic, Database or Business Logic for features of the Game, such as Markets, Shops, Lodges and any other actual piece of code that is a feature on its own.

Every milestone is responsible for a major implementation of a feature, and we might have concurrent Milestones (aka Epics). For example "Milestone 01: Market", "Milestone 02: Battle's". These milestones should contain tasks that include contents and components that might not be directly related to the feature itself but that enables the feature of being completed.

Classification of Tasks for Features

Tasks can be classified into multiple labels and their development will be handled accordingly. For example, one task might be an MVP (Minimum-Viable-Product) for a specific feature. For example, an MVP of the Market system should allow the basics interactions of the Player Market, excluding filters or anything that is more complex for future iterations.

[exectails]

As none of this was ever properly implemented, the person planning to implement it isn't here anymore, and I'm too lazy to change my working style, I'm going to close this discussion for now. These plans would've added a lot of structure to Melia's development, which could certainly be viewed as a good thing, but it's my personal experience that strict structures in open-source projects without strong core teams only add barriers that make development more difficult. I feel that we need to be more lean and flexible to accomodate occasional contributions. You lose the moment people need to read six different kinds of documentation to truly grasp the structure of a project and how they can help.