Sir R. M8gic1an
2013-01-09 21:03:50
TL, DR:
I had to do a coursework on a project I partook on. I chose MSI. It basically runs through the first year of MSI and has some tips for any future group projects, plus might make for an interesting read. Notice: its 3k words
Evaluation of a project in which you have been actively involved
Multiple Script Integration (version Phoenix)
This was a project I started up and ran myself for about a year and a half before I passed on the torch due to having more pressing priorities to attend to, unfortunately. The project grew bigger and ran for another year and a half until recently, where it was called off due to lack of sufficient input and over-expanding our horizons which was great for a while but eventually became too big to maintain in its current state. Just before passing on the torch I started designing phoenix version 2, but did not have enough time to stabilize and empower the idea, which would have made the project more manageable, and therefore it kept working on its previous framework which we had already noticed would become unsustainable. Had I had the time I believe the project would still be running, but as I no longer had the time to lead the project and scarcely any time to keep on contributing I found that it was not my place to force a version and structure change and allowed the newly appointed leader to go about it whichever way he wished, having kept exchanging private messages with him for a while on tips and ideas concerning the leadership & management of the project.
Context
MSI had previously been an abbreviation for Multiple Script Include a project led by Ed of the villavu.com community that was about team scripting for an online java game, Runescape.com. There had been two attempts at bringing this project to life by gathering a few scripters (programmers) together to make team scripts (programs) to perform certain tasks on this online game. In the villavu community the norm is for each scripter to make his own scripts, as that is our way of gaining status (good quality scripts) and then maintaining them and competing against other scripters with similar scripts. The better the scripter the less likely it is for him to run (use) somebody else's work, unless that work is very good. It is not uncommon that the highly skilled user will first read the other scripters' work before using it to ensure his online character will be safe while running this program. Quality is key, and the community's hierarchy reflects this.
Goals, Objectives & Motives
At this time the community was suffering from a few “social” problems. Not enough scripters were raising up to the level needed to become a developer (a high level scripter that scripts for the community's program) or we were just simply not noticing them. Activity at the higher tiers of the hierarchy was dwindling due to lack of interesting work and small bug fixes were being left unfixed. Where there had previously been a difference between scripter only scripts (by scripters for scripters) and community wide scripts (anyone could use them) there were fewer and fewer scripts for scripters, as scripters tended to use their own or not use any scripts at all anymore. This meant that all work done was available for the whole community and scripters were having difficulty standing out from each other in the middle of a big crowd. With this in mind, the goal on the back of my head was to gather the best of these scripters who were having difficulty standing out, and personally work with them as a group to increase their programming skills, team skills and notoriety. MSI was to become the step between scripter and developer.
The Proposal
The original MSI died out pretty quick, and when I made a formal proposal to revive it I pinpointed the reasons as being lack of structure and lack of aim; To solve this problem I immediately came forth with an outline of a possible working structure which would not only cover basic functionality but also provide detailed debugging (more detail on this later) and informative, useful feedback for the user at the end of their session. This gave us something to work on and an opportunity to re-evaluate how we do the basics – One of the goals of this project was to up the ante of the concept of a good script.
Participating Members
Choosing the right team was essential. I needed a team that was small enough to foster lots of quick team-work but not so small that we'd be overworked. It is important to be noted in this report that we were all doing this as a hobby and no one was receiving no cash or other types of payment whatsoever for it. This was a relatively long process to ensure fairness, it started by making two separate application forms, one for project manager and one for project developer. Although I would be leading the project I anticipated that I would need some people helping me sorting out the little details and taking care of lists, editing pictures and other things that I was not personally inclined to do. After posting the application forms to the scripters' forums and receiving applicants these applicants were discussed over by the senior members as for integrity and skills. At the end we settled for 5 project managers and 5 developers plus me on both teams. All project managers were also scripters although not deemed as good as the chosen developers. In hindsight instead of dismissing them further down the project as happened, they would've been perfect for the contributions we had to ask from the community post-release.
Organizing a work environment
I knew this would be absolutely critical. This project could not afford to have a false nor a delayed start as my peer staff had been quite skeptical about it, so it had to be perfect from moment one. To organize the work environment not only did I have to set it up, in our Vbulletin board, it had to be simple and yet encompass all necessary for management and organized development. It had to be compact and discreet, and yet dense enough that we would not just be throwing our work into a pile in which it would get lost. With this in mind, the layout were 4 boards, one for organizing & managing the script's direction, wanted features and locations where it would work, one for general talk amongst the developers, one for script planning and one for snippets (developed code). The board for general talk amongst the developers was there so that any issues which may arise but were not necessarily script planning would have a place to be, such as discussing rights & ideas. It was the only of the developers' board which was not filled with code.
Motivating the team & initiating work
This was perhaps one of the bits that I enjoyed doing the most. The first thing to do was set a goal to work to, which was “MSI's aim is to have a*do-it-all-everywhere*script. Does this sound ambitious? It sure as hell is. It would be the*ultimate script, untraceable, impossible to detect and you could just run it, return a few years later and have a char at*all 99 levels. Now doesn't that sound amazing?”. The results we achieved were actually not far from this. The goal was huge but attainable – we individually had previously already covered most available skills, we were all good scripters and willing to work – the only thing we really needed was a stable code base and milestones to work to – the rest was just getting down and dirty which was what we do best.
While the Project Managers were busy gathering information and displaying it graphically as to which skills could be done in which locations and their relative positions to each other and in-game banks as well as interchangeability, the developers were kept busy not only discussing possible methods of dealing with the amount of skills and locations which would need to be covered but also developing the base script.
Understanding the Project Scope
A regular script, by community standards, would complete one skill at one location. There were some rarer, but popular scripts which would complete the same skill at several locations. Some even rarer and even more popular scripts would complete several skills at one location. MSI was to take it a step further and perform all skills at all locations. Each skill requires a set of tools to be performed which is usually withdrawn from the bank, walking to the correct location through the in-game map, and interacting with some skill specific objects. Each skill will have several tools and each tool will have upgrades which are visually differentiated by colour and name. Each skill will also interact with several objects which may or may not look similar and may or may not be differentiated by colour and the player is only allowed to interact with certain objects if he has achieved a certain level of skill. Certain objects will only exist in certain locations and getting to each location is different in terms of parameters for a walking function. There were several possible but not infallible walking functions before MSI, and therefore for each location several of these functions needed to be used together to make a stable walking procedure. MSI developed its own walking system to overcome this. MSI was the biggest, broadest script ever produced.
Understanding the Quality Requirements
As previously stated, MSI was meant to be a foster ground for future developers and as such, the quality requirement for the project was that a developer would be proud to have produced this script. In a nutshell the quality requirements were that simple – in technical detail it was a lot more complicated. Here I had to find a balance between what my team was used to producing and what they were used to seeing and what a developer would produce at his best level. This was very hard, because among developers' personal projects there is a fair tendency to not completely understand each others' work. Depending on the person's skills and interests each developer will understand the other's work to a certain extent, and the work itself will be documented to a certain extent, but we will not necessarily understand each point of the other person's research and code. The reason for this is probably just time and a slight lack of synergy, because the systems developed are usually not necessary only better functioning than the system currently in place. It would require testing and debugging, fixing and lots of thinking and reading to understand – and as we all do it for fun, we sometimes do not go this extra step because if it's not broken, don't fix it.
The challenge for MSI was that since it was to be created by soon to be developers it should include such difficult functionality. And it did, it had several plan-b routes in case plan-a failed, lots of artificial intelligence which was extremely rare in scripts, and it broke down tasks to very small layers dealing with each very effectively. I am proud to say that many things that were developed in MSI were then added to the developers include.
MSI also had to be extremely efficient as it was dealing with a lot more variables and inputs than any other script with the exact same resources. We had to work a lot on memory management to make this possible.
A Key Technology
One thing which I must mention, was that we had one part of our technology which was absolutely key to a project this size, which was our debugging system. We debugged every single thing that could possibly go wrong and every single variable change. To not clog the regular user's debug box we implemented debug levels and you were able to set the level of debugging you wish to see. This was absolutely key and phenomenal as it allowed you to track down an error very quickly to its exact code line – and it was also very innovative as no script before had ever had this level of debug (not the developers', not the scripters', not my own). This was what allowed us to know exactly what was wrong within seconds of it happening, and was a uniquely useful tool both to the development and testing phases of MSI.
The Tipping Point for MSI
After two to three months, MSI's first release was ready, and was released; This release included three skills and three locations per skill. We were proud of the versatility and expandability of our product as well as its high performance. The community loved it and embraced it and within another couple months it was in top 10 used scripts, soon climbing to #1 and remaining there for a long time. We were now faced with a few choices: expanding the script in terms of skills, expanding the script in terms of locations or further develop our core. Just closing down and maintaining what we already had did not actually cross our minds as we were so excited by the prospects of what we could actually do with such a strong base.
We were all tired and happy to have succeeded in this first release, I personally had other priorities clogging more and more of my time and energy was generally low after a last push, although the excitement kept us going. After a few usability problems were solved and the community was enjoying the script they started to want to contribute – and here we were faced with a problem we had not expected – The core of the script had become too complex for the average scripter (notice, scripter not user!) to understand. In hindsight, we might have just made public our development forums and allow the more wanting scripters to read through them to understand whatever it was they were not understanding – but this was not the way we were used to doing things and we had personal, confidential information in those boards which we could not just share with the whole community. Had we done a bit of cleaning that would've been possible, but that's not what happened – we did what developers do, and usually hate doing, which is documentation. We wrote pages and pages and pages of documentation, which slowed down our development and was not as exciting. Perhaps the project managers could have done this, had they not been dispensed a long, long time ago.
Expanding in terms of locations was relatively easy – we just had to gather some information about the location and the associated objects and add them to our files and the script was ready to run with a new location – within 5 minutes. This was great and we very quickly expanded and expanded big. We went from 9 scripts to over 30 in a matter of weeks. What we didn't expect was that this would come with a high level of maintenance, as the information we had gathered would slowly change and become obsolete. When this happens for one script with one location it is a 10-15 minutes fix with some testing, which occurs perhaps bi-monthly. This meant 16 hours of monthly boring work divided by very tired, busy people, which detracted from our time to do other development. Were we to approach the project again, better methods of overcoming this would definitely be on the priority list such as online records and better AI recognizing algorithms. We spent much of our little free time just maintaining, which dampened the team's morale.
Expanding in terms of skills was more complicated – not because the skills were hard to script for but because they had to be scripted for – unlike just extending locations. This also brought other problems – although we had designed a very flexible platform there are just some things you can never predict and so at points we had to edit the core to fit these new skills, something which we hadn't planned for. Editing the core was a big red flag for everyone, as the core had to be absolutely flawless and efficient otherwise all the scripts would collapse. There was a lot of pressure on editing the core and as such discussions on core editing past the first release started to become more and more drawn out as we realized there would need to be more changes to the core. Perhaps here would've been a good time to pause and go back to the drawing board, but we were eager to get more community contributions and as such just kept on running MSI throwing a few working but not perfect fixes to the core to adapt to the challenges we were facing. It was after many of these changes that I realized we did indeed need a phoenix v2 but while we planned we still had to maintain the current script and as such our attentions were split.
The last expanding method – developing a more advanced core, with the developers' methods who were now more eager to contribute was also complicated – not all of MSI's scripters had access to the developers private boards, not all developers paid attention to MSI and not all concepts were easy to implement into an already complex core. They also had to be made to work with MSI, otherwise the scripts just wouldn't work, no matter how cool the tech. At the time we were using subversion, a centralized system of versioning and so individually testing and branch programming was not possible, unfortunately, which would've been a great advantage.
Conclusion
Given the time and chance I'd do it again in a heartbeat, perhaps on smaller scales so more people can be involved and the load of maintenance is not as hard. I found the project to be a huge success as those who were involved are now senior staff and developers.
So yeh, I hope that it did make for a good read and that it might help someone out in the future :)
~RM
I had to do a coursework on a project I partook on. I chose MSI. It basically runs through the first year of MSI and has some tips for any future group projects, plus might make for an interesting read. Notice: its 3k words
Evaluation of a project in which you have been actively involved
Multiple Script Integration (version Phoenix)
This was a project I started up and ran myself for about a year and a half before I passed on the torch due to having more pressing priorities to attend to, unfortunately. The project grew bigger and ran for another year and a half until recently, where it was called off due to lack of sufficient input and over-expanding our horizons which was great for a while but eventually became too big to maintain in its current state. Just before passing on the torch I started designing phoenix version 2, but did not have enough time to stabilize and empower the idea, which would have made the project more manageable, and therefore it kept working on its previous framework which we had already noticed would become unsustainable. Had I had the time I believe the project would still be running, but as I no longer had the time to lead the project and scarcely any time to keep on contributing I found that it was not my place to force a version and structure change and allowed the newly appointed leader to go about it whichever way he wished, having kept exchanging private messages with him for a while on tips and ideas concerning the leadership & management of the project.
Context
MSI had previously been an abbreviation for Multiple Script Include a project led by Ed of the villavu.com community that was about team scripting for an online java game, Runescape.com. There had been two attempts at bringing this project to life by gathering a few scripters (programmers) together to make team scripts (programs) to perform certain tasks on this online game. In the villavu community the norm is for each scripter to make his own scripts, as that is our way of gaining status (good quality scripts) and then maintaining them and competing against other scripters with similar scripts. The better the scripter the less likely it is for him to run (use) somebody else's work, unless that work is very good. It is not uncommon that the highly skilled user will first read the other scripters' work before using it to ensure his online character will be safe while running this program. Quality is key, and the community's hierarchy reflects this.
Goals, Objectives & Motives
At this time the community was suffering from a few “social” problems. Not enough scripters were raising up to the level needed to become a developer (a high level scripter that scripts for the community's program) or we were just simply not noticing them. Activity at the higher tiers of the hierarchy was dwindling due to lack of interesting work and small bug fixes were being left unfixed. Where there had previously been a difference between scripter only scripts (by scripters for scripters) and community wide scripts (anyone could use them) there were fewer and fewer scripts for scripters, as scripters tended to use their own or not use any scripts at all anymore. This meant that all work done was available for the whole community and scripters were having difficulty standing out from each other in the middle of a big crowd. With this in mind, the goal on the back of my head was to gather the best of these scripters who were having difficulty standing out, and personally work with them as a group to increase their programming skills, team skills and notoriety. MSI was to become the step between scripter and developer.
The Proposal
The original MSI died out pretty quick, and when I made a formal proposal to revive it I pinpointed the reasons as being lack of structure and lack of aim; To solve this problem I immediately came forth with an outline of a possible working structure which would not only cover basic functionality but also provide detailed debugging (more detail on this later) and informative, useful feedback for the user at the end of their session. This gave us something to work on and an opportunity to re-evaluate how we do the basics – One of the goals of this project was to up the ante of the concept of a good script.
Participating Members
Choosing the right team was essential. I needed a team that was small enough to foster lots of quick team-work but not so small that we'd be overworked. It is important to be noted in this report that we were all doing this as a hobby and no one was receiving no cash or other types of payment whatsoever for it. This was a relatively long process to ensure fairness, it started by making two separate application forms, one for project manager and one for project developer. Although I would be leading the project I anticipated that I would need some people helping me sorting out the little details and taking care of lists, editing pictures and other things that I was not personally inclined to do. After posting the application forms to the scripters' forums and receiving applicants these applicants were discussed over by the senior members as for integrity and skills. At the end we settled for 5 project managers and 5 developers plus me on both teams. All project managers were also scripters although not deemed as good as the chosen developers. In hindsight instead of dismissing them further down the project as happened, they would've been perfect for the contributions we had to ask from the community post-release.
Organizing a work environment
I knew this would be absolutely critical. This project could not afford to have a false nor a delayed start as my peer staff had been quite skeptical about it, so it had to be perfect from moment one. To organize the work environment not only did I have to set it up, in our Vbulletin board, it had to be simple and yet encompass all necessary for management and organized development. It had to be compact and discreet, and yet dense enough that we would not just be throwing our work into a pile in which it would get lost. With this in mind, the layout were 4 boards, one for organizing & managing the script's direction, wanted features and locations where it would work, one for general talk amongst the developers, one for script planning and one for snippets (developed code). The board for general talk amongst the developers was there so that any issues which may arise but were not necessarily script planning would have a place to be, such as discussing rights & ideas. It was the only of the developers' board which was not filled with code.
Motivating the team & initiating work
This was perhaps one of the bits that I enjoyed doing the most. The first thing to do was set a goal to work to, which was “MSI's aim is to have a*do-it-all-everywhere*script. Does this sound ambitious? It sure as hell is. It would be the*ultimate script, untraceable, impossible to detect and you could just run it, return a few years later and have a char at*all 99 levels. Now doesn't that sound amazing?”. The results we achieved were actually not far from this. The goal was huge but attainable – we individually had previously already covered most available skills, we were all good scripters and willing to work – the only thing we really needed was a stable code base and milestones to work to – the rest was just getting down and dirty which was what we do best.
While the Project Managers were busy gathering information and displaying it graphically as to which skills could be done in which locations and their relative positions to each other and in-game banks as well as interchangeability, the developers were kept busy not only discussing possible methods of dealing with the amount of skills and locations which would need to be covered but also developing the base script.
Understanding the Project Scope
A regular script, by community standards, would complete one skill at one location. There were some rarer, but popular scripts which would complete the same skill at several locations. Some even rarer and even more popular scripts would complete several skills at one location. MSI was to take it a step further and perform all skills at all locations. Each skill requires a set of tools to be performed which is usually withdrawn from the bank, walking to the correct location through the in-game map, and interacting with some skill specific objects. Each skill will have several tools and each tool will have upgrades which are visually differentiated by colour and name. Each skill will also interact with several objects which may or may not look similar and may or may not be differentiated by colour and the player is only allowed to interact with certain objects if he has achieved a certain level of skill. Certain objects will only exist in certain locations and getting to each location is different in terms of parameters for a walking function. There were several possible but not infallible walking functions before MSI, and therefore for each location several of these functions needed to be used together to make a stable walking procedure. MSI developed its own walking system to overcome this. MSI was the biggest, broadest script ever produced.
Understanding the Quality Requirements
As previously stated, MSI was meant to be a foster ground for future developers and as such, the quality requirement for the project was that a developer would be proud to have produced this script. In a nutshell the quality requirements were that simple – in technical detail it was a lot more complicated. Here I had to find a balance between what my team was used to producing and what they were used to seeing and what a developer would produce at his best level. This was very hard, because among developers' personal projects there is a fair tendency to not completely understand each others' work. Depending on the person's skills and interests each developer will understand the other's work to a certain extent, and the work itself will be documented to a certain extent, but we will not necessarily understand each point of the other person's research and code. The reason for this is probably just time and a slight lack of synergy, because the systems developed are usually not necessary only better functioning than the system currently in place. It would require testing and debugging, fixing and lots of thinking and reading to understand – and as we all do it for fun, we sometimes do not go this extra step because if it's not broken, don't fix it.
The challenge for MSI was that since it was to be created by soon to be developers it should include such difficult functionality. And it did, it had several plan-b routes in case plan-a failed, lots of artificial intelligence which was extremely rare in scripts, and it broke down tasks to very small layers dealing with each very effectively. I am proud to say that many things that were developed in MSI were then added to the developers include.
MSI also had to be extremely efficient as it was dealing with a lot more variables and inputs than any other script with the exact same resources. We had to work a lot on memory management to make this possible.
A Key Technology
One thing which I must mention, was that we had one part of our technology which was absolutely key to a project this size, which was our debugging system. We debugged every single thing that could possibly go wrong and every single variable change. To not clog the regular user's debug box we implemented debug levels and you were able to set the level of debugging you wish to see. This was absolutely key and phenomenal as it allowed you to track down an error very quickly to its exact code line – and it was also very innovative as no script before had ever had this level of debug (not the developers', not the scripters', not my own). This was what allowed us to know exactly what was wrong within seconds of it happening, and was a uniquely useful tool both to the development and testing phases of MSI.
The Tipping Point for MSI
After two to three months, MSI's first release was ready, and was released; This release included three skills and three locations per skill. We were proud of the versatility and expandability of our product as well as its high performance. The community loved it and embraced it and within another couple months it was in top 10 used scripts, soon climbing to #1 and remaining there for a long time. We were now faced with a few choices: expanding the script in terms of skills, expanding the script in terms of locations or further develop our core. Just closing down and maintaining what we already had did not actually cross our minds as we were so excited by the prospects of what we could actually do with such a strong base.
We were all tired and happy to have succeeded in this first release, I personally had other priorities clogging more and more of my time and energy was generally low after a last push, although the excitement kept us going. After a few usability problems were solved and the community was enjoying the script they started to want to contribute – and here we were faced with a problem we had not expected – The core of the script had become too complex for the average scripter (notice, scripter not user!) to understand. In hindsight, we might have just made public our development forums and allow the more wanting scripters to read through them to understand whatever it was they were not understanding – but this was not the way we were used to doing things and we had personal, confidential information in those boards which we could not just share with the whole community. Had we done a bit of cleaning that would've been possible, but that's not what happened – we did what developers do, and usually hate doing, which is documentation. We wrote pages and pages and pages of documentation, which slowed down our development and was not as exciting. Perhaps the project managers could have done this, had they not been dispensed a long, long time ago.
Expanding in terms of locations was relatively easy – we just had to gather some information about the location and the associated objects and add them to our files and the script was ready to run with a new location – within 5 minutes. This was great and we very quickly expanded and expanded big. We went from 9 scripts to over 30 in a matter of weeks. What we didn't expect was that this would come with a high level of maintenance, as the information we had gathered would slowly change and become obsolete. When this happens for one script with one location it is a 10-15 minutes fix with some testing, which occurs perhaps bi-monthly. This meant 16 hours of monthly boring work divided by very tired, busy people, which detracted from our time to do other development. Were we to approach the project again, better methods of overcoming this would definitely be on the priority list such as online records and better AI recognizing algorithms. We spent much of our little free time just maintaining, which dampened the team's morale.
Expanding in terms of skills was more complicated – not because the skills were hard to script for but because they had to be scripted for – unlike just extending locations. This also brought other problems – although we had designed a very flexible platform there are just some things you can never predict and so at points we had to edit the core to fit these new skills, something which we hadn't planned for. Editing the core was a big red flag for everyone, as the core had to be absolutely flawless and efficient otherwise all the scripts would collapse. There was a lot of pressure on editing the core and as such discussions on core editing past the first release started to become more and more drawn out as we realized there would need to be more changes to the core. Perhaps here would've been a good time to pause and go back to the drawing board, but we were eager to get more community contributions and as such just kept on running MSI throwing a few working but not perfect fixes to the core to adapt to the challenges we were facing. It was after many of these changes that I realized we did indeed need a phoenix v2 but while we planned we still had to maintain the current script and as such our attentions were split.
The last expanding method – developing a more advanced core, with the developers' methods who were now more eager to contribute was also complicated – not all of MSI's scripters had access to the developers private boards, not all developers paid attention to MSI and not all concepts were easy to implement into an already complex core. They also had to be made to work with MSI, otherwise the scripts just wouldn't work, no matter how cool the tech. At the time we were using subversion, a centralized system of versioning and so individually testing and branch programming was not possible, unfortunately, which would've been a great advantage.
Conclusion
Given the time and chance I'd do it again in a heartbeat, perhaps on smaller scales so more people can be involved and the load of maintenance is not as hard. I found the project to be a huge success as those who were involved are now senior staff and developers.
So yeh, I hope that it did make for a good read and that it might help someone out in the future :)
~RM