Planning a plugin...

Discussion in 'Plugin Development' started by theguynextdoor, Jun 4, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    theguynextdoor

    Now, I would imagine that a lot of developers out there are like I used to be and don't plan any plugins out before they are made. I especially know this because some people barely want to learn Java before they make the plugin, let alone take the time to think of a plugin and implementation, but that is besides the point. My main aim of this thread is to see how others plan their plugins.

    I have recently started a new plugin project, and I did decide to plan it out a bit and whilst I was doing this I was wonder if, how and to what extent other people plan out their plugins. I used to just jump straight in and smash out code, which was fine but only really for the smaller projects. I would find that once I got onto the bigger projects that by the time I got round the implementing a new feature, I would have forgotten what it was that I was going to add.

    So what kind of planning do people do? Do you write a list of features, do you do structure diagrams, flow charts, class design diagrams, do you design your databases?

    I guess it is only fair that I start. Like I said, I recently started a new project and this project is called Settlements because tbh, I enjoy making plugins based around the 'Towny' concept (simplest way to describe it). My way of planning this was to simply write a big list of features I wanted. I like this way because I can write all my initial thoughts down so I don't forget any and sometimes I even think of new ideas while I am coding so I pop to my list of features and just chuck is on there. My list is a very 'informal' list, if you can call it that, where some ideas are still in the design process themselves. You will see I sometimes put a comment and a question mark next to something.

    But enough about that, here is my plan for this new plugin I am making.
    http://pastebin.com/xF5NmKNR

    Note: Now I am taking a slight risk by chucking this plan out there. Copy it if you will, make the plugin yourself if you will (And if you have the skill). But note that I will be making this plugin and I shall release it regardless of whether anyone makes the same plugin. Besides, my list is changing quite frequently.
     
  2. Offline

    99storm2

    I think the way you planned it out is a very good idea. Its also very organized and easy to read and see what you want done with the plugin. Honestly i dont do much planning when i make my plugins but they are also only for my use and are fairly small. My code is probably messy and i dont really care about using config files because if i need to change something i can just open it in eclipse and change it. Now if i do start making plugins to publish to bukkit dev then cleaner plugins, planning, and configuration for the plugin will definitely be required.
     
  3. Offline

    RawCode

    Dont plan, you are not enterprise developer and your plugin is not commercial application with set of deadlines.

    Since you dont know, how things will pass and what you actually can do, your super big list of super cool features will change dramatically over time and it wont extend, you will drop or skip time consuming features in favor of more simple ones.

    Final result will be "all time spared on planning is actually wasted for nothing".
     
  4. Offline

    Garris0n

    I plan things because sometimes I'm in situations where I can't code anything, but I can, of course, think about stuff.
     
  5. Offline

    lycano

    I would say it depends on the target group and how complex the plugin should be.

    If it is a simple plugin that does one thing there is not really much to plan since you indirectly said "this plugin should do this" "to accomplish this i need a, b, c" if this involves the need to have a database then this is something i do not count to "creating a concept".

    Creating a multi functional plugin obviously needs more thinking since each part of the plugin might not always have a common goal.

    There are many ways to reach your goal and if you have a good plan then you might reach your goal faster but in the end i believe this does not really matter unless you have a really complex plugin like PermissionsEx for example.

    What probably does help a lot (what i do) is write down a feature list "what should the plugin do?".

    Then ask yourself what can be done in a realistic time frame. What features could be left out or what features are the so called "core"?

    If you have this figured out create a roadmap and then do the coding.

    At this point you will see that you might have to adapt your roadmap while you are working on the plugin since some parts might need longer than expected. Are they too complex? Are they needed? Try to make it simple and extend it later if it can't be done in a reasonable time frame.

    There are many ways to help you keep you focused like creating UML models or workflow charts but how you organize yourself this is the tricky part and depends on your way of thinking. As long as you dont lose yourself in overthinking and keep focused on the path everything is allowed.

    (Finish a task and when you are done dont overthink it too much. You can always change it later.)

    Some prefer pen and paper some like to use UML and since IntelliJ Ultimate (open source license available) does provide an easy way of creating those this can save you a lot of time since the needed classes can be created automatically then.

    So yeah building UML diagrams is a good starting point in my opinion.
     
  6. Offline

    theguynextdoor

    Although you are correct in that I am not an enterprise developer and plugins are most certainly not a commercial application with deadlines, I would disagree, to an extent, with the skipping features.

    This would depend upon the developer. Some people want to rush to get plugins out as soon as possible, I however am in no such rush.

    My list was more of a brainstorm of features. No one is to say that all of them will go into the plugin, heck no one is to say that any of them will (Except me, because I know some of them will). But the point I am making is this list was a collection of thoughts (A good ol' brainstorm) which took a matter of minutes to make, and takes seconds to add to. Like I also said, this is a good way for me to not forget features which I think would be nice to add into the plugin. It means I can take my time to implement bigger features without forgetting everything that needs adding. It also helps to ensure I have not missed anything when putting a feature in.

    I would agree that planning out each class, doing UML diagrams, large structure diagrams, and (in the case of most plugins) ER diagrams and such is probably not the most productive use of your time. But I would also say that, if you stick with your design, then it is not a waste of time. Heck, for the few minutes it took to make the list, there is not exactly much time to lose, since you could very well spend a few minutes thinking how you are going to implement each feature anyway.
     
  7. I personally don't really consider these people "developers" :)

    I agree with you. Plans are quite good to have and to follow. But, like most people, my smaller projects involve no planning as it seems wasteful. And it's been quite a while since I made a project complex enough to consider planning...

    Ideally though, assuming I had the inspiration, effort, and time for a complex project, I would want to follow the following idea (whether I would or not, however, is a different matter :p)

    I'd have a list of things that the project would need to accomplish. Generally this is the easiest stage, since most of the time this will be given to me since I'm not exactly the best with ideas :) Although I occasionally have to eliminate some infeasible features and tell whoever it is I'm making it for I'm doing that ("No, this simple plugin isn't going to have high definition cinema-style cutscenes") (I might also eliminate some of the features that could be done but I can't be bothered to create at that time... shhh)

    Once that's done, though, I'd think about the general 'layout' and 'style' that the plugin would have to have. In that stage would include thinking about the basic logic that the 'developers' you mentioned would avoid - thinking about stuff like the variables and objects that would need to be designed/made, for instance.

    Before starting to create the plugin, I like to have a pretty good idea of what it will look like at the end. Even so much as just thinking "right, so I'll have this method that does x thing" is good, even if that mental image doesn't include how something would be done, knowing what it needs to do is useful. But of course knowing how it is going to be done works too! While most of what I do I prefer to hold mentally, I generally like to write some things down for two reasons. One, projects can take time and memories easily disappear so it's good to have a written record about it. And two, writing it down can sometimes help you think about it, but in a subconscious and pressure-free way, which often can often result in you realising something that you wouldn't have otherwise.

    When actually making a plugin, I generally start off by creating some of the simple things that are pretty common and are quite common to most projects. Once I've done that, I generally like to create the things in a seemingly random jumble. A lot of people would advice against that and would recommend a firmer plan of what's being created and when. But for me it works quite nicely. To help explain that, imagine all the things you have to do are split into three main types - there are the simple things that you're pretty sure how to do, the complicated things that you don't really know or will take a while to create, and the research you have to do for those more complicated things (and simpler things too, but to a lesser extent).

    I find it's best to mix these different tasks so that you're not doing too much of one thing at once. Simple tasks can get pretty tedious and aren't very mentally challenging, so I like to break it up with researching and learning how to do more exciting or useful things, and more complicated things to challenge myself mentally. More complicated things can get pretty frustrating if I can't work out how to get a finer aspect working correctly, so it's good to research more about it and maybe that will help find a solution, or I complete some of the simpler things to help keep the morale up. Research can sometimes make you feel like you're making no progress at all, since no new lines of code have appeared and that's the only way the project will get completed, so it's good to complete some simpler tasks as I can get a lot of them done quickly which feels like lots of fast progress, or complete some complex tasks to implement my learning and make progress.

    So hopefully that makes it clear how I like to do things, and maybe it makes sense to you, maybe it doesn't. But for me it works out well enough. :) And while I can't see your plan right now, if it works for you, then good! I'll probably look at it later when I can, though, because the whole "if it works for you" attitude isn't a blind one. Anyone could have something that would work for you as well, so no way of knowing without sharing & trying ideas :)

    RawCode "Invalid." You can't make anything without at least knowing what it is that you're making. That would essentially be a basic plan.
     
    ZodiacTheories and Rocoty like this.
  8. Offline

    L33m4n123

    I have to admit I am lazy and will read those long posts later. Just going to share on how I do it^^

    It really depends on the situation, mood and the complexity of a plugin. If I say from the beginning. Ok. That plugin is easy. I just start coding and add then stuff when needed [however I sometimes need to redo quite some stuff :D]

    So. However if I write a bigger application [now not limited to bukkit plugins] I sit down and basicly write down the basic behaviour of the application.

    • What should it do?
    • How to accomplish what it has to do
    And after I have written down the basic layout I go ahaed and create an UML Diagramm for the Application that I want to prevent a complete rewrite and faster workflow when I then actually start coding
     
  9. Offline

    Necrodoom

    I'd say it depends on the plugin's complexity as well.

    A one feature plugin, for example a broadcast plugin, not much planning is needed and you can basically jump in and write it.

    If you expect to enhance this one feature, for example, vanishnopacket, you are going to need to plain how your plugin will generally look, and start putting some quickly accessible variables to avoid problems coding it.

    Next up you have plugins along the size of permission plugins, where the base of your plugin is basically a framework for everything else you are planning to do with it.

    Then you have a bunch of big plugins, like essentials, which are basically frameworks upon frameworks, which makes it easy to add whatever you need without having to really change anything in the plugin except add on top of it.

    The biggest problem of plugins with sufficient age encounter, is that they want to take their plugin a step up. This means that either you rewrite your plugin from ground up, or your plugin will look like a timey whimey ball that is painful to edit.

    Basically, plan ahead, and if you are planning to take the plugin for while, be prepared to rewrite it a few times.
     
  10. Offline

    RawCode

    Since some people( AdamQpzm )don't understand meaning of my post i will ask straight:

    theguynextdoor
    How many steps of your plan you did in past 48 hours? (time from posting list)
    I guess answer will be something like "zero".

    In my case, in said 48 hours i already can test prototype without wasting time on forum or favorite text editor.

    Planning only valid when you are not only developer - to distribute tasks in team.
     
  11. Offline

    Kassestral

    I normally think what plugin would I like to see out their?

    Then make a list of features it would have, slowly work through the features then after that rely on feedback from others to make decisions on what needs be done from their on
     
  12. Offline

    TheHandfish

    I pretty much just get an idea and make it. Never really do much written planning other than stating what features I want it to have. All in my head. ;)
     
  13. Offline

    Freelix2000

    I usually come up with an idea, get the basics done, (Basics as in setting up the project, plugin.yml, command method, and config/data file creating) and then just think about features and how I'm going to do it as I do other things away from my computer. It usually seems to work fine, but not all features and details can be planned before the project begins because for some of my huge plugins, (If you look at my BukkitDev account, it doesn't really appear that I have any "huge" plugins, but I'm working on a Halo plugin that is about as big as Essentials already. =P) I need to think about implementing a new feature with the API and code that I've already created, so it can't be done before. Also, why is your name "theguynextdoor" and you have a female avatar? =P
     
  14. Offline

    mythbusterma

    If it's not a simple project, a day of planning could save you a week of programming more code than you need, and debugging said code. It is very important to plan, even if you are the only one working on a project. I personally like the black box method, which is quick and dirty. You have a couple modules that will each perform a specific task, and you look at them without examining their implementation, then you go through them one by one and implement.
     
  15. Offline

    xTrollxDudex

    theguynextdoor
    I like to code on appear without an IDE or make sure I get down the logic flow. That's the first step.
    Then, you would look at it and snippet out lots of code to go with the logic.
    Then, code for real.

    You have to improve, improve, improve. Go to OOP guidelines, make local variables, create methods for constantly being called logic chains. There is no end to the section, or the next.

    Debug. Run application, and squeeze out every single bug.

    Go to improvement step.
     
  16. Offline

    Etsijä

    I'm by no means a professional developer, just one with a hobby and enthusiasm to learn write cool things in Java. My first plugins have been very small and I've sort of just jumped into hacking away the plugin. But more often than not I have bumped into extra work needed (move code around, make new classes etc.) which could have been avoided by some initial planning.

    Now as I am starting a little bigger project (Scorched Earth minigame), I ended up writing a similar list than the OP uses. Basically I think rather than being time wasted, this is a thought process which helps to answer the fundamental question: what do I really want my plugin to accomplish? When writing down stuff in my list, I often find out things that can readily be moved around, deleted, added, grouped together. Ie. basic structure of my plugin starts to form.

    I try to keep this list as short as possible, in order to avoid "requirements fatique", which was very familiar concept at my time spent on IT industry before agile methods were developed and taken into use. So, I have a smallish list of stuff I want to implement.

    The second phase for me is to write down - starting from my list - a list of commands which the plugin needs to have. Then I just pick one and start creating the necessary classes, and after that comes the first version of my plugin. I try to use agile programming as much as possible, meaning my plugin needs to compile and run daily. I am never doing stuff in so big chunks that they take like a week to implement, and only after that test. I find it a lot more manageable way to keep daily "builds" where the delta to the previous one is kept as small as possible.

    That's my five cents on this interesting topic.
     
  17. Offline

    xize

    better organized than what I do imo:p

    I just can't settle a border where it says stop don't think at adding more features while you are already bussy with a other feature for example, sometimes I want to add 5 features at once and sometimes they are half finished or I get rushed thats bad.
    but what atleast keeps it a bit organized is the base for example the listeners if you make a core plugin you could have alot of listeners and maybe even don't know what task they hide so in that case I just thread them like modules and managers under solid folder namings based on the configuration files.

    however for me this works as best, I don't think this works for everyone though the only advise I can give whenever how hard it could be add a limit of features you add because otherwise you may end with a plugin almost 650kb-1mb with 50% a bit redurant old code and 50% more better code, atleast thats how I'm ended up XD
     
  18. Offline

    Etsijä

    Just for the record, here's my "plugin plan" ie. list of features I'm planning to include in my Scorched Earth minigame (plugin name will be ScorchCraft). I myself find this list extremely useful, since it keeps me organised and always shows me where I am and how much I still have to do.

    http://pastebin.com/MFf8DPhu
     
Thread Status:
Not open for further replies.

Share This Page