ID:1768570
 
We should all band together, all developers, all artists, everyone. Let's produce a group of hundreds with no leader and only specific modules of tasks to complete to achieve one goal.

Why?

"If I had any advice for the BYOND community, it would be to stop spending so much time worrying about the latest drama, and start producing something." - Ben "SilkWizard" Mallahan

To create something unimaginable. A large development team.

Now, I know most of you are thinking this is stupid. Well, I am too. But, what else are we doing? I'm pretty sure most of us are wasting our lives. Why don't we waste it together? So, without further ado...

GitHub: Not available until project is decided on.
Kickstarter/Indiegogo/other sources of funding: Coming soon!
Website: Coming soon!

Current Jobs/Applicants:
OG Wizard
  • DarkNinjaNaut

Project Manager
  • Pongy

Programmers
  • Ease
  • Bloodocean7

Designers
  • Ease

Concept Artists
  • Albro1

Pixel Artists
  • ---

Level Designers
  • Pongy

Sound Artists
  • ---


How this will work:

1) We will need a project manager or a series of project managers who will do the following.
  • Create a task for a specific person or a group of people.
  • Give this task a description in this format --
    Module Name: [Name Here]
    Module Type: [proc, datum, verb, etc]
    Module Params: [params and a description]
    Module Functionality: [What it should do and what it should do with the params, if any. It should typically be functionally independent.]
  • They need to know that there will be small occasions when these modules will have to call other modules. In this case, it should be included in the Module Functionality what that function returns and only what it returns and why it returns that. Nothing more.

    Additionally, which is obvious, it should include the name of the module so the person creating the newer module will know what to program.

If all of the project managers does his or her job right, one of the largest projects can become whole.

2) Programmers are required to have a good amount of experience and knowledge of simplifying their code processes in such a manner that it is efficient and does not hinder the process time of other procedures. In short, it should be efficient.

They won't need to see any other code. But, they will have access to it. What is given to them by the project manager is all they need to understand what is required in their module.

3) A designer, or a series of designers, is required to tell the project managers what needs to be written. He or she should also tell the concept artist what should be drawn for art.

When telling the concept artist what should be drawn, the designer should be sure to include a shape of the art to the best of their abilities, the color, the size, and describe any animations if required at the time. Description is key to getting the best results! If you have more to put in, put it in!

Before releasing ANY ideas to the concept artist or project managers, all ideas should be talked with other designers. Designers must show a sense of good taste in terms of games, development, and design. We don't want to put out faith in the hands of a moron who has no sense of design.

Though, that may be me right now since I have no idea what the hell I am writing. But, that's besides the point. I'm not making this, you all are! I'm just here to get this thing started. So, I don't matter.

4) Concept artists draw up art/sketches for the UI, tiles, and characters. After drawing 1 item, they do not continue on to something else until their work is approved by the designer. Their work should be placed in a box on the cloud for approval and reviewing by the designers so designers can review them in bulk. The project manager will take a look at this bulk and when he or she feels that it has grown to a size that it wouldn't be a waste of time for the designers to take a look at, or if the designers are free, then the project manager should notify the designers to review it and reply to the concept artist to let them know that they need to now send it to the pixel artist for drawing.

5) Pixel artists just draw concept art to the best of their abilities. Nothing more do it. No creativity here. Draw. Shade. Color. After this is done, send it back to the concept artist for reviewing. If the concept artist likes it, he or she sends it to the designers box for future reviewing in a box labeled "finished". If at some point it is turned down, it is simply sent back down the chain to be worked on until perfection.

6) Level designers are just a sub category of the designer. They do the exact same process. Only, instead of designing tiles, UI, and other basic things, they organize the tiles, UI, or asks what type of things are needed, gives examples, and gives a brief layout as to what it will look like in the end.

7) Sound artists should ask the project manager for help with their work. The project manager should take a look at current scenes in the project and come to a conclusion what kind of theme should sounds be. 8-bit, modern, etc. Is it a cave? Being punched? Jumping? Just vague things with an example sound/song if possible to get a general idea. The project managers should work together to find what is needed. The sound artist should remind the project managers how this process works as they will be focusing on other things and may not remember this task which usually comes at the end.


Good luck! What the project will be about is up to the community. Nobody is a leader. It's a team effort. BYONDers, roll out!

P.S. If you have any other suggestions as to what other roles should be added or what roles require a different/more thorough procedure, message me or comment below. I don't care which.

Don't forget to include this on your resumes, kids.
This is stupid.

I'm in.

I'd like to take a Programming role. If more than one role is permitted per person, I'd also like to snag Designer.

My resume;
Completed GiaD with Hivemind (http://www.byond.com/games/Ease/Hivemind) - I designed the entire concept from scratch, programmed it all myself, made (barely) acceptable graphics, and pretty innovative sound effects.

I've made a simple Pong game, proving that (occasionally) I can stick a project to the end.

Stark Realities - incomplete, due to acquiring a girlfriend, and a child, and a new job three hundred miles across the country. But I believe it demonstrates the complexity I can manage: it's crafting system works well, its equipment system is intuitive and easy to the user, despite being a right mare to program, and it has some other clever features.

My biggest selling point is that since making all of these, I've been employed as an Embedded Programmer for two years at two large defence companies, and have also done a year intern-ship for IBM. My DM is weaker than ideal, but my sense of programming concepts and how software teamwork and projects work is strong.
What is this huge wall of job descriptions? I'm afraid that's not how these things work. It takes much more than this to recruit people for a project. Never expect to gather contestants without presenting them with a challenge worthy of their abilities.

Also, you seem to be taking SilkWizard's quote out of context. I think what he meant was for each individual of the community to start producing something, not band together into some massive team.

Either way, it might be nice to see a large team making something, but I'm not sure if that's even possible with this community. Everyone here has their own ideas, dreams, and programming styles, which would result in a whole lot of compromises that would need to be made. While I don't think you are going to end up with a team of hundreds, I will admit that the entire BYOND community is much larger than this main website.

The point is, what you are doing here is like trying to write a book without having an actual story, which by all logic sounds totally pointless. You are missing the most important part of this whole thing, which is the dream itself. That's the part that draws everyone in to do something. The way I see it, every dream has to start with four basic elements: an idea, a reason, a goal, and a name or symbol.

Without these things nobody is going to team up to do anything, because there simply isn't anything to do, as far as they know.

If you really want to make this happen, then you are going to have to try and change things around here. The BYOND community isn't "conditioned" to working in teams, so that's what you will have to worry about. All I can suggest is to setup some open source, team-only contests, where lone developers are denied entry. This might effectively "force" the BYOND community into working together. Later on you could make things even more interesting by putting a limit on the number of teams! These would be contest rules, and if they don't follow them, then their team just doesn't get the reward. It's simple and effective. Just imagine all of the teamwork, competition, and rivalry that could catalyze development around here. What do you think of the idea?
I'm og wizard I'm automaticly in.
Let's do this shizznits!

Ease is our programmer/designer and Ninja is our OG Wizard. We're almost set. Who else is in?

I don't have total faith in this thing working out. But, in the event that we start getting a lot of contributors, I'll put together a github for whatever project has been discussed and finalized.

File syncing for people who need to review will be done thanks to the all powerful Google Drive (I love you Google).
@Multiverse7 Don't think of this as a team. Think of it as a group of contributors to an open-source project that nobody but BYOND itself will own. While your idea sounds nice, I spent the time to write this stupid idea. So, let's see how it plays out within a month. ;)

The same goes for everyone else. People ask for a task, the respective directors (project manager, designer, etc) gives the task, they do the task, they tell the respective directors to review it, the respective director gets it added to the sources.

I won't discuss what will be made. That's up to the BYONDers (both participants and regular users) to decide within this forum. Create a project idea to represent BYOND, think of a market scheme (free, paid, or microtransactions?), design it, make it. With rules set, you'd have to be an idiot to not get anything at all done lol.
I love the idea. I'm now a fan, Xirre. Shame that my programming skills aren't up to par yet, or I'd join.
In response to Gtgoku55
Gtgoku55 wrote:
I love the idea. I'm now a fan, Xirre. Shame that my programming skills aren't up to par yet, or I'd join.

Well, you could always contribute logic. It saves time for programmers since they won't have to think what the most efficient route would be. All logic takes is a brain and some fingers to look up procedures that may be beneficial to the tasks at hand.

Much like contributing logic behind a feature request on BYOND or a Bug Report, logic given to a programmer eases the pain of completing the task for you.
Certainty of death, small chance of success... What are we waiting for?

Seriously though, I imagine that this would likely work out better if it were approached without the goal of setting up such a structured development team. These various pre-determined roles/jobs seem "strict" (for lack of a better word) for this being a community project as it sounds.

I imagine anyone being able to collaborate on the design and end-goals publicly (here on the forum, perhaps?). Anyone's suggestions and opinions can be discussed and agreed upon. Then once a Github repo has been setup, anyone could contribute art, code, or whatever and submit a pull request. The only pre-determined roles that would be needed would be determining who all would have the ability to merge pull requests.

You know, structured like many other open source, community-driven projects?

(Disclaimer: I've never actually been involved in such a project myself, but this seems to me how they are often run.)

Depending on my free-time, I wouldn't mind contributing as a programmer anyhow.
In response to TheLionsRoar
Free time is all you need. I'll review over merges with a few other reputable people (typically any BYOND mods or known BYONDers that would like to help manage just the github alone). I'll do some more thinking on who exactly should have permission on doing what.
In response to Xirre
That sounds good, but please consider the rest of my post too.

The structure of various communities and branches of SS13 come to mind when I say that specific roles and people "asking for a task" don't seem necessary. There could be a master list (or sub-lists) of tasks that need to be done overall, which combined with Github's issue tracker, would be a great source for people to know what needs to happen, what needs fixed, etc. I figure you really want to involve people that can do a good deal of thinking on their own. ;)
In response to TheLionsRoar
TheLionsRoar wrote:
That sounds good, but please consider the rest of my post too.

The structure of various communities and branches of SS13 come to mind when I say that specific roles and people "asking for a task" don't seem necessary. There could be a master list (or sub-lists) of tasks that need to be done overall, which combined with Github's issue tracker, would be a great source for people to know what needs to happen, what needs fixed, etc. I figure you really want to involve people that can do a good deal of thinking on their own. ;)

Well, the rules are there just so people aren't constantly asked, "Hey, can you look at this? Does this look good to you? How do I do this? Did I do this right?" All of those questions. Honestly, when you're asked that constantly, it can slow any progress down, even if you're not working.

I thought it would be better to have a designated time and person/group to handle bulks of jobs waiting in a folder somewhere. But, I'm not really managing this project. I came up with the idea, I let the masses know, it's their job to do with it what they will. I may put a bit of work in here and there. But, nothing major. I'll take your idea in to account though. :) It's up to the majority of contributors to decide how they should do things. The OP just servers as a base guideline.
But, what about the Nexus? Who will guide all the people? Hmm, PutYut? Answer that question, sir!
That SilkWizard quote is on my BYOND membership profile and has been ever since I interviewed him.
In response to EnigmaticGallivanter
EnigmaticGallivanter wrote:
That SilkWizard quote is on my BYOND membership profile and has been ever since I interviewed him.

That's where it's from.

Edit: To clear things up, I saw the quote from EG recently when I was reading the Webclient post by Lummox. The quote spawned the idea but the idea is not based off of the quote.
In response to EnigmaticGallivanter
I thought BYOND was a drama engine with minigames?
In response to Lugia319
Lugia319 wrote:
I thought BYOND was a drama engine with minigames?

It is.
In response to EnigmaticGallivanter
Hmm, tbh i think this is an interesting idea, "if it could be done right" haha. Despite the understandable scepticism and shocked gasps/tutting and shaking of heads i can already imagine some people might be taking up as they read this, i think i can see how this can work or at least a way something similar could be feasible.

The way i see it, this is kind of the reverse to something i'd been again considering this past week or so, whereby i would make known that i was willing to freely offer my help as a programmer to developers working on a project for which they required (or simply preferred) additional programming assistance.
So similar to some things you mentioned, they might have one or two systems or code fixes that needed attending to, but without the staff to cover them in good time. In such a case someone like me could step in -based on interest- to help submit possible solution(s) (i.e. creation of a system/fixes to code) which they could in turn review and decide to make use of, if of acceptable standard.

The thing with that obviously though would be to not mistake my (or anyone's) capacity in that role for being the same as a core developer, suggesting that it'd be best for developers to only look to use such a service for the none vital/deeply intrinsic aspects of their game; if they're not going to be a fully committed party to your dream kinda makes sense to not have them contribute to something(read: be) at the heart of the dream ya dig?

But anyway basically it seems like your idea would work in a similar way except that there doesn't yet appear to be a core team working on things yet (which i do believe this is going to need in some fashion, else what would be the standard against which you (project managers) judged everyone else's suggested code modules/designs -for instance.

With such a core team in place, made up of a limited number of 'main' contributors to the project across all aspects (e.g. 1 - 2 Programmers, 1 - 2 Artists, 1 PM, 1 Designer, perhaps up to 2 Deputy Designers, and -if necessary- the allowance for an Additional Resources handler*(e.g. sound assets))**, the rest of the community would then be the ones in a position to contribute stuff as they wished, once a goal for the project had been decided upon and invested into completely by those who would be in the 'core positions'.

This would might best work out with a process such as:
- Designer A opens topic and shares thought out idea.
- Top 2 capable Programmers that are very interested in it, are able to see how they can accomplish the dream, and would like to commit join as main leads.
- Capable Artists likewise get on board.
- Designer A now main designer.
- any other 1 or 2 people who can contribute things of significant merit in terms of design, and have a personal interest in the kind of idea proposed can join as Dep. designers.
- Last party, preferably able to contribute/knowledgeable in all areas and would like to watch over the project to completion can apply as PM.
- Topic closed.
- Team is formed and works out a plan. Tasks are formed, those which are not intrinsic/core to the design get listed separately. Production begins.
- Above listed tasks then get posted and appended to in a new topic/area for community to contribute towards as inclined.

...And so this process might repeat for several Project ideas that whoever in the community comes up with opting to have anyone work on byond be able to contribute as opposed to working on it in a solitary manner.

What you may have gathered from this post is that my suggestions, thought for a similar effort; setting up a means by which members community can band together towards team projects, has a key difference. The Plurality. It considers the opportunity for many projects, and at smaller scales than the one big one for all of BYOND to tackle together which seems to be your objective.

While i don't see anything particularly wrong in attempting to band together everyone available towards one 'Super BYOND project'[SBP], perhaps a better approach might be to enable people from all ends of the community to want to contribute towards one or more projects within a selection of 'BYOND Affiliated Projects'(i'll elaborate on this).
That way you'd have a situation where there could be a variety of community-effort driven projects of a smaller scale -not trying to be the be all end all mega hit- each having different focuses and goals that might in turn result in a higher probability of attracting of particular members of the community as opposed to other projects***.
If done in a manner alike my suggestion above, then naturally each of these would have a team working at the core, better ensuring the likelihood of completion.

When looking at te SBP approach in comparison, it wouldn't be as easy to set a core team for this, much less one that could work effectively. With only one idea which would ultimately be directed down a particular route -no matter how ambitious the premise and dedicated the effort ...unless, any one who might otherwise have been interested in being part of such a thing would end up neither taking part at all or as much/enthusiastically if the idea wasn't one that particularly motivated them beyond contributing towards beyond.
Another foreseeable aspect to consider would be possible issues arising from the community's perception of those members that might make up the 'core team' in such an endeavour, because though i believe one to be necessary for something like this, it would seem contrary to the idea of everyone having equal opportunity to affect something so potentially big and being able to direct it in a way that fulfils their biggest of dreams, when there would be a small group of people who at heart of things would be the ones making the decisions about which direction the project should go.

---------------------------------------------
Uh.. so huh, it seems this really spurned me to consider -> write a lot on my view of your idea, and for now i'll leave things here. I think i'll edit later on to cover the *s as well as the elaboration on what the distinction might be for the "BYOND Affiliated Projects" that i mentioned earlier, in terms of considering monetary aspects, and perhaps in comparison to the SBP type initiative proposed here.

...Eh in the end this has kinda evolved into a Counter-Proposal type response. Haha, perhaps i should title it as such? :P

---------------------------------------------
P.S. Xirre whatever might or might not happen with this whole thing, you are still steadily working on the game with quaint and Toby right?
In response to Turboskill
---------------------------------------------
P.S. Xirre whatever might or might not happen with this whole thing, you are still steadily working on the game with quaint and Toby right?

Toby and I are Quaint Shanty. It's a group. Yes, we are working on 2 projects currently. As said before, I'm not working on this group thing. I simply set it up and want to see how it plays out. The community manages it. One of our projects is actually finished and playable. We're thinking about adding in game modes.
In response to Xirre
Aaah ok, cool stuff.
Page: 1 2 3 4 5 6