Phoenix Public Source: An InvitationPhoenix Public Source: An Invitation
This is an invitation for people who are tired of debating between FSoD, SD, or Club559 sources and would much rather prefer working on the things they want rather than what they don't know about. This is an invitation for people who wish to see a well-developed, open-source private server. This is an invitation for people who like the idea of community-voted features.
This is a project that will take the Phoenix Realms 2: Reborn source and convert it into a source that private server owners will be able to appreciate and add onto with ease. After some rather long lamenting of the amounts of backtrack work that my team has been set back due to several structural limitations, the Phoenix team decided it would be best for everyone to use our progress and put it in the favor of the community, in a way that no other RotMG source release has done before.
This is not a "let's make an open source repo whatev" attempt. I have specific goals and guidelines for this project, and I have a few notably experienced programmers who are willing to work on it.
The basic ballpark goal of this project is to create an optimized, modular source that private servers will look towards using.
Now, time for some specific insights on what this exactly means.
GOALS
This project has three main goals, each of which I will explain in detail.
1.) Production Value
I want to make it as easy as possible for server owners/scripters to create or modify content in the source.
I am focusing on making processes such as creating items, behaviors, and classes smooth as possible. This involves modularity, and partial support through a scripting/markup language. I won't make large changes to systems dependent on XML, to ensure backwards compatibility of all content created on private servers. Those who work on the actual source code itself will be confined to a specific C# code style and practices guide, to ensure maximum readability (and because mixing up a lot of people's code styles is just plain terrifying).
2.) Performance
I want to make the server capable of stable performance on reasonable hardware.
With that being said, don't come crying to me if your server lags because it can't handle ~25 people on Hamachi with your shit internet. C# is not particularly a language known for its potential to create performance-critical applications, but aside from C++, it's considered a contender. The source will employ common practices such as managed garbage disposal, concurrent threading, and elimination of network redundancy to bring a comparable performance to that of Realm of the Mad God.
3.) Features
Any high-demand features that can't be scripted in will be a goal to implement.
We could look at a base CreepyLava source and say "hey, that's nice" but in reality, the use of that kind of source often puts behind hours of possible work because of the need to implement features that were MIA from such a thing. Now, since this is a general-use source, overly-specific feature requests will NOT be implemented. However, certain possibly modular features that get a lot of approval from the community will be looked into for implementing into this general source.
Specific mini-goals
These mini-goals are more of just ideas, and may/may not go through the development process
Development Phases
There are three rough phases of development that will happen in this project.
Phase 1: Private
This is the shortest phase, and it consists of simply removing anything overly specific about the Phoenix source, and returning it to a generalized state. This means that we'll be removing the custom stats such as Resilience and Penetration, and anything else that seems more fitting for Phoenix rather than RotMG. The only people who will be working in this phase are programmers from Phoenix, but this shouldn't take too long.
Phase 2: Restructuring
This is the phase where we make it open-source, and begin working on modularity and performance, mainly. We won't touch too much on actual feature implementation, but features WILL be considered when we consider the creation of our systems, and how they can interoperate smoothly. At this point, any build, unstable or not, should and will be tested for being able to run under basic conditions.
Phase 3: Expansion
After most of the groundwork is done, phase 3 is where the source is considered "complete" but will continue in development for highly-vouched features and systems that the community requests. At this point, it's expected that the source development may slow down or even halt, but that's not a huge issue because the source has been completed already.
Collaboration
This is meant to be a collaborative project, although at first it may not seem like it. I will expend a good amount of time to see this project grow, but I will not hesitate to leave it if this community is not well-interested in this project's growth. I see this as a test for this community. This is designed to be an open source project, that will only give as much as the community gives. I will oversee the project to ensure that the system stays true to its goals and guidelines, but other than that, the great driving force of this project will come on your desire to create a better RotMG private server for everyone to enjoy.
To collaborate in phases 2-3, just fork the latest build from the repository and submit a pull request when you're finished with what you want to implement. Only very active contributors will get direct write access.
If you're not very experienced in coding, you can always help contribute by voting on or creating feature requests for the source. Remember, you as the community get to decide what features go in! Want BlockSight? We'll implement it. Want prod-like backpacks? We'll implement it. It's sort of like a democratic-monarchial process.
I'll post updates on how this project is going through Phase 1 as it makes its way to Phase 2.
This is a project that will take the Phoenix Realms 2: Reborn source and convert it into a source that private server owners will be able to appreciate and add onto with ease. After some rather long lamenting of the amounts of backtrack work that my team has been set back due to several structural limitations, the Phoenix team decided it would be best for everyone to use our progress and put it in the favor of the community, in a way that no other RotMG source release has done before.
This is not a "let's make an open source repo whatev" attempt. I have specific goals and guidelines for this project, and I have a few notably experienced programmers who are willing to work on it.
The basic ballpark goal of this project is to create an optimized, modular source that private servers will look towards using.
Now, time for some specific insights on what this exactly means.
GOALS
This project has three main goals, each of which I will explain in detail.
1.) Production Value
I want to make it as easy as possible for server owners/scripters to create or modify content in the source.
I am focusing on making processes such as creating items, behaviors, and classes smooth as possible. This involves modularity, and partial support through a scripting/markup language. I won't make large changes to systems dependent on XML, to ensure backwards compatibility of all content created on private servers. Those who work on the actual source code itself will be confined to a specific C# code style and practices guide, to ensure maximum readability (and because mixing up a lot of people's code styles is just plain terrifying).
2.) Performance
I want to make the server capable of stable performance on reasonable hardware.
With that being said, don't come crying to me if your server lags because it can't handle ~25 people on Hamachi with your shit internet. C# is not particularly a language known for its potential to create performance-critical applications, but aside from C++, it's considered a contender. The source will employ common practices such as managed garbage disposal, concurrent threading, and elimination of network redundancy to bring a comparable performance to that of Realm of the Mad God.
3.) Features
Any high-demand features that can't be scripted in will be a goal to implement.
We could look at a base CreepyLava source and say "hey, that's nice" but in reality, the use of that kind of source often puts behind hours of possible work because of the need to implement features that were MIA from such a thing. Now, since this is a general-use source, overly-specific feature requests will NOT be implemented. However, certain possibly modular features that get a lot of approval from the community will be looked into for implementing into this general source.
Specific mini-goals
These mini-goals are more of just ideas, and may/may not go through the development process
- Deobfuscation of the 123.5.1 client source
- Restructuring of account/character handling to prevent reconnect/possible dupes
- Removal the HTTP intermediary in packets
- Port to a speed-emphasized NoSQL database engine
- Track-and-log systems for diagnostics of errors/hacking
- User Feedback systems
- Resizable entity/projectile collision fields
- Settings and scale values for systems in the whole server or specific worlds (like 200% bonus loot chance for a day)
Development Phases
There are three rough phases of development that will happen in this project.
Phase 1: Private
This is the shortest phase, and it consists of simply removing anything overly specific about the Phoenix source, and returning it to a generalized state. This means that we'll be removing the custom stats such as Resilience and Penetration, and anything else that seems more fitting for Phoenix rather than RotMG. The only people who will be working in this phase are programmers from Phoenix, but this shouldn't take too long.
Phase 2: Restructuring
This is the phase where we make it open-source, and begin working on modularity and performance, mainly. We won't touch too much on actual feature implementation, but features WILL be considered when we consider the creation of our systems, and how they can interoperate smoothly. At this point, any build, unstable or not, should and will be tested for being able to run under basic conditions.
Phase 3: Expansion
After most of the groundwork is done, phase 3 is where the source is considered "complete" but will continue in development for highly-vouched features and systems that the community requests. At this point, it's expected that the source development may slow down or even halt, but that's not a huge issue because the source has been completed already.
Collaboration
This is meant to be a collaborative project, although at first it may not seem like it. I will expend a good amount of time to see this project grow, but I will not hesitate to leave it if this community is not well-interested in this project's growth. I see this as a test for this community. This is designed to be an open source project, that will only give as much as the community gives. I will oversee the project to ensure that the system stays true to its goals and guidelines, but other than that, the great driving force of this project will come on your desire to create a better RotMG private server for everyone to enjoy.
To collaborate in phases 2-3, just fork the latest build from the repository and submit a pull request when you're finished with what you want to implement. Only very active contributors will get direct write access.
If you're not very experienced in coding, you can always help contribute by voting on or creating feature requests for the source. Remember, you as the community get to decide what features go in! Want BlockSight? We'll implement it. Want prod-like backpacks? We'll implement it. It's sort of like a democratic-monarchial process.
I'll post updates on how this project is going through Phase 1 as it makes its way to Phase 2.
Originally Posted by Stellar Spark
