LÖVE

I recently proposed a new type of game jam on TIGForums (http://forums.tigsource.com/index.php?topic=18831.0), and thought I would suggest it here as well...

Who would be interested in doing a succession round game jam?
(If you don't know what a succession round is, look up Dwarf Fortress & Boatmurdered, or read this http://lparchive.org/Dwarf-Fortress-Boa ... roduction/)

The premise would be that each person would get a specific amount of time to work on the game, then pass it on. That person could be an artist, coder, jack of all trades, whatever. Each person is given full creative reign on the project when they have it.

I think this would be very successful within the LOVE community, being that we all know the framework, and have something unique to bring to the table.
So my questions to you are as follows-
Would you do it?
How long should each turn last?
Should there be any ground rules? (no deleting code/removing features, etc)
When should we start?
How is the order determined?

I don't see something like this working very well in the LOVE community. Most people here seem to have a very B.Y.O.B. attitude when it comes to code and the game would probably be heavily re-written every iteration with each person re-inventing the wheel in their own way.

Time and time again people make and remake physics, sound, GUI, and animation libraries that never ever get used. There must be three or four Object Orientation libraries out there that all basically do the same thing. Top all of that with a generally defensive attitude by some of the more senior members here, and it's a very bad mix.

I know full well I'll probably start a massive shitstorm over this. I'm prepared.

Ensayia wrote:...

What does B.Y.O.B. mean? I looked it up, and got about 50+ answers. Is it "Be Your Own Boss", or "Bring Your Own [Something Starting With B]"?

Sorry for the awkward slang, BYOB here meaning "Bring Your Own Bag". Essentially I feel that every programmer is going to insert their own personal version of whatever base libraries are used in development.

Essentially I see a lot of writing and re-writing, disagreement, and a lot of stuff getting talked about and not getting done. It seems to be a reoccurring theme around here.

Ensayia wrote:Sorry for the awkward slang, BYOB here meaning "Bring Your Own Bag". Essentially I feel that every programmer is going to insert their own personal version of whatever base libraries are used in development.

Essentially I see a lot of writing and re-writing, disagreement, and a lot of stuff getting talked about and not getting done. It seems to be a reoccurring theme around here.

Ah right. But yeah, I see that happening too. If you want people to work on something together, you're going to have set in force strict rules about code style, libraries, and other things; which only really happens on a team.

I think it could be a fun exercise if the libraries and patterns chosen by one dev were set in stone for future devs. Everyone would get to use everyone else's ideas of what is good. I guess not everyone would enjoy that, though.

I agree with BlackBulletIV and sharpobject.

To make this possible participants would have to vote or agree upon what libraries to use before coding got underway, to minimize different opinions on what sort of framework they would use mid-development.

Ensayia wrote:I agree with BlackBulletIV and sharpobject.

To make this possible participants would have to vote or agree upon what libraries to use before coding got underway, to minimize different opinions on what sort of framework they would use mid-development.

I was actually thinking each participant would have free reign to declare rules that all subsequent devs must follow ("we're using raw luasocket"/"our animation library is AnAL"/"our OO library is fooblibar") while working on each project. Such a process might be open to trolling, but if there are obvious trolls we can just disregard them.

Ensayia wrote:I don't see something like this working very well in the LOVE community. Most people here seem to have a very B.Y.O.B. attitude when it comes to code and the game would probably be heavily re-written every iteration with each person re-inventing the wheel in their own way.

I don't think this is necessarily a bad thing. With a strict time limit placed on each user's turn, it would promote developers to add new content features instead of completely nitpicking the previous code.

In Dwarf Fortress Succession Rounds, reverting someone's previous work becomes counter productive. This is because you will end up spending your whole turn undoing changes and not add anything to the round.

To relate this is to a game jam, I believe it also holds true. Whether we enforce a rule to prevent this behavior is up for debate.

sharpobject wrote:

Ensayia wrote:I agree with BlackBulletIV and sharpobject.

To make this possible participants would have to vote or agree upon what libraries to use before coding got underway, to minimize different opinions on what sort of framework they would use mid-development.

I was actually thinking each participant would have free reign to declare rules that all subsequent devs must follow ("we're using raw luasocket"/"our animation library is AnAL"/"our OO library is fooblibar") while working on each project. Such a process might be open to trolling, but if there are obvious trolls we can just disregard them.

This could work. It could be possible that we set the order based on agreed skill. For instance, if any of the LOVE devs join in the competition, they are the first to go. Then, we go by seniority. This could be a mutually beneficial relationship because the "younger" of us can learn from the senior devs, and the senior devs can laugh at our ignorance. (Seriously though, that might work)

I propose a "Don't be a douchebag" rule. If you disobey, well... we all know what happens when you don't Obey on these forums.

I thought these types of games generally had a rule that said you can't revert work that's already been done...

TylertheDesigner wrote:For instance, if any of the LOVE devs join in the competition, they are the first to go. Then, we go by seniority. This could be a mutually beneficial relationship because the "younger" of us can learn from the senior devs, and the senior devs can laugh at our ignorance. (Seriously though, that might work)

But.. but.. but.. then I only get to dump in a couple of classes! In that case I might as well make them impossible to work with .