The following is the breakdown of the system we're looking to use to gather and handle Minecraft API changes. We're planning to employ the use of a JIRA project for proposal gathering, organisation and discussion and GitHub Pull Requests once code becomes involved (and a proposal has been accepted).
The Minecraft API proposal system is a set of guidelines developers are expected to follow if they want to contribute to the Minecraft API. A Minecraft API proposal (MAP) is a design document detailing the specifications, justification, challenges faced and need for a new addition to the Minecraft API. Every proposal submitted to the official Minecraft API JIRA Project is required to follow the provided template and to meet the following requirements.
Minecraft API Proposal Requirements:
A specific, to the point, summary (JIRA ticket title) should be provided. Vague summaries like "Awesome new feature!" will result in the proposal being rejected.
The description of the MAP should contain detailed and justified specifications and challenges faced.
The appropriate labels and components should be set to help with organisation and searching of MAPs.
MAP Template and example: Summary: Trading API
Description:
Proposed addition:
Developers should be able to make use of the trading system in the game to set up their own trading system, inventory, prices and results. The trading API should allow developers to attach the ability to trade to any container, not just villagers.
Specific features:
Trade recipe editing
Trading related events
Justification and Use Case:
A trading API would allow developers to construct a sophisticated merchant system using the chest container.
Challenges faced:
None discovered at this time.
Affects Version/s:
Component/s:
Label/s: trading
After a MAP is properly submitted, each submission has a 2 week grace period before a decision can be made about the proposal, with some exceptions. This is to allow for ample time for the Minecraft developers community to review and comment on each proposal. However, while we are busy building the API for the first time, we may opt to skip the 2 week grace period on a per proposal basis to speed up the API design and development process.
The original author of the Minecraft API Proposal is expected to present their idea in a convincing manner and garner support from other developers in order to build up a community consensus. Alongside this public vetting process, the Minecraft team will be looking over each MAP and providing input as we feel is necessary and, ultimately, deciding to accept or reject a proposal. If we find that a proposal is popular but we need to reject it for whatever reason, we will usually look into alternatives, fixes or changes to address the issues we have with the proposal.
Once a MAP is accepted, a reference implementation will be worked on and the entire development process moves over to GitHub and its Pull Request system. In order for a reference implementation to be considered, each pull request has to meet the following requirements.
Minecraft API Pull Request (MAPR) Requirements:
The relevant MAP should be clearly associated and mentioned in the Pull Request title (see the template for an example of the expected format).
The relevant MAP should be clearly linked to so discussions about the MAP can be read over if need be.
Detailed information from the relevant MAP should be included in the Pull Request's description for easier managing of proposals.
Submitted code is expected and required to adhere to our coding guidelines.
A vetted MAP covering the Pull Request has to exist before a Pull Request is made.
Minecraft API Pull Request template and example: Title: [MCAPI-1] Trading API
Proposed addition:
Developers should be able to make use of the trading system in the game to set up their own trading system, inventory, prices and results. The trading API should allow developers to attach the ability to trade to any container, not just villagers.
Specific features:
- Trade recipe editing
- Trading related events
Justification and Use Case:
A trading API would allow developers to construct a sophisticated merchant system using the chest container.
Challenges faced:
None discovered at this time.
Thoughts and feedback on this process are greatly appreciated. We'll be constantly revising this system based on the lessons we learn from it being used and your input will help us with that immensely.
The following is the breakdown of the system we're looking to use to gather and handle Minecraft API changes. We're planning to employ the use of a JIRA project for proposal gathering, organisation and discussion and GitHub Pull Requests once code becomes involved (and a proposal has been accepted).
Thoughts and feedback on this process are greatly appreciated. We'll be constantly revising this system based on the lessons we learn from it being used and your input will help us with that immensely.
Looks decent, but I really think performance should be one of the key factors, the better you can get performance the more features you can end up packing in in the long run, it'll open up room to do more things.
Looks decent, but I really think performance should be one of the key factors, the better you can get performance the more features you can end up packing in in the long run, it'll open up room to do more things.
Will be great to have an API available for modding. I'd be so happy to have one rather than 3-4, but I do believe it can end up being a shell for the modloaders everyone seems to be using.
Seems perfectly reasonable, though I wouldn't bother inventing the terms "MAP" and "MAPR" - just call them proposals and pull requests.
Do you have an issue type called Proposal in JIRA? If not, you probably want to specify the issue type used. Also I assume you will at least have a Bug issue type. Do you want to provide some guidelines of how to write proper Bugs? Any other issue types (personally I recommend as few as possible - my experience is people will be confused)?
Do you prefer proposals come with pull requests, or at least some code examples?
Looks decent, but I really think performance should be one of the key factors, the better you can get performance the more features you can end up packing in in the long run, it'll open up room to do more things.
Seems orthogonal to this discussion, which is more a "how to write a good issue description" than "how to write a good API". But certainly any proposal should consider performance.
Pull Request requirements needs to contain something about signing-off being required (in case you didn't know it makes sure they transfer ownership of the code to Mojang, if you'd done this for Bukkit you could have used Bukkit code in Minecraft-API :P).
It will help modders make their mods and iron out bugs! (And it would be cool to look at some Minecraft code
Minecraft code is not open-source. Only the API. The API alone does not contain any implementations and if you are hoping to learn Java from it the most you will learn is formatting / structure and how to define an abstract method.
The Plug-in API (they really won't be modifications of the original Minecraft software, although I think the term "mod" is still going to stick) is a system that allows you to get custom new content that is designed by people other than Mojang... and have that custom content officially supported by Mojang.
Until now, the "mods" that you see in the Mod section of this forum and elsewhere are really "hacks" as in "hacking" and "hackers" in a very real sense. They are people who have studied the game to such detail that they know the internal structure of the game and how it has been coded, and have made changes to the raw structure of the game. I hope I don't need to go into more details about what a mod actually does, other than it allows you to do something different than the standard version of Minecraft (usually called "vanilla Minecraft" by mod developers).
Instead, what you will be able to do is to download or otherwise acquire a piece of software that the only thing you will need to do is to put that software into a special folder in the game (no need to install Mod Loader or other software). Even more important, once you have installed that software into the game, even when the game updates and changes that software will continue to work. You no longer will need to worry about updating your version of Minecraft if you have one of these plug-ins and are using it for your worlds.... for the most part. There could be times when parts of the API will break, but I will give credit to Mojang that they will keep that to a minimum and such changes will be extremely rare.
Should I start making my mod now? Or wait till 1.4. I feel like getting started now.
You should definitely get started now. It takes a lot of time to make a mod and 1.4 will be out before you know it. And when it does come out, you can always convert your mod to the new API.
You should definitely get started now. It takes a lot of time to make a mod and 1.4 will be out before you know it. And when it does come out, you can always convert your mod to the new API.
Alright, thanks for the nice info.
Rollback Post to RevisionRollBack
If my post helped you in anyway, or made you smile or share a quote of some sort, please click that cool ^ button.
Thoughts and feedback on this process are greatly appreciated. We'll be constantly revising this system based on the lessons we learn from it being used and your input will help us with that immensely.
Looks decent, but I really think performance should be one of the key factors, the better you can get performance the more features you can end up packing in in the long run, it'll open up room to do more things.
Definitely agree with this.
|HDD|SSD|Xen|1Gbps connection|VPS|
Do you have an issue type called Proposal in JIRA? If not, you probably want to specify the issue type used. Also I assume you will at least have a Bug issue type. Do you want to provide some guidelines of how to write proper Bugs? Any other issue types (personally I recommend as few as possible - my experience is people will be confused)?
Do you prefer proposals come with pull requests, or at least some code examples?
Seems orthogonal to this discussion, which is more a "how to write a good issue description" than "how to write a good API". But certainly any proposal should consider performance.
It will help modders make their mods and iron out bugs! (And it would be cool to look at some Minecraft code
Minecraft code is not open-source. Only the API. The API alone does not contain any implementations and if you are hoping to learn Java from it the most you will learn is formatting / structure and how to define an abstract method.
The Plug-in API (they really won't be modifications of the original Minecraft software, although I think the term "mod" is still going to stick) is a system that allows you to get custom new content that is designed by people other than Mojang... and have that custom content officially supported by Mojang.
Until now, the "mods" that you see in the Mod section of this forum and elsewhere are really "hacks" as in "hacking" and "hackers" in a very real sense. They are people who have studied the game to such detail that they know the internal structure of the game and how it has been coded, and have made changes to the raw structure of the game. I hope I don't need to go into more details about what a mod actually does, other than it allows you to do something different than the standard version of Minecraft (usually called "vanilla Minecraft" by mod developers).
Instead, what you will be able to do is to download or otherwise acquire a piece of software that the only thing you will need to do is to put that software into a special folder in the game (no need to install Mod Loader or other software). Even more important, once you have installed that software into the game, even when the game updates and changes that software will continue to work. You no longer will need to worry about updating your version of Minecraft if you have one of these plug-ins and are using it for your worlds.... for the most part. There could be times when parts of the API will break, but I will give credit to Mojang that they will keep that to a minimum and such changes will be extremely rare.
Version 2.1 now updated for MC 1.6.2
Be sure to check out my texture pack: Easy Ores!
Alright, thanks for the nice info.