I have an idea!
This forum has a history of failed monday projects, I worked hard on and then dumped one rather interesting attempt myself a while ago...

How about we make it more of a game?

Someone starts a project. Lay the basics down like, C or C++, file organisation, source control etc. And you implement a first feature.

Then it's the next developers turn. Add whatever you want, submit and pass it on.

Motivation for this format. It was my impression that people in the monday thread had very different ideas about which type of game they wanted to make. If the development process itself is a game like this then each participant is the boss for his turn, there will be no debating about where to take the game.

For this thread I'd like to discuss how to best make such a game work with the least risk of breaking down.

I think a good platform to use for "passing" the project around would be to use github. A main repo is set up, each developer clones the repo, works on it for his turn and sends a pull request.
A maintainer moderates the main repo and whos turn it is.

I suggest the maintainer keeps a turn queue where people report their interest in taking a turn. Keep turn length flexible if some just wants to contribute some smaller feature and others bigger features but say the max time for a turn is one week.

If someone can't use his turn when it comes up, I don't know if he should be bumped to the next slot or to the end of the queue. This should be moderated with care as to not discourage people who show interest in the project.

Important! In order to make sure the game always moves forward, it is not allowed to remove or "replace" features. Basically, do not move backwards or sideways, only forward.

I suppose you could call this a Monday project, but those are technically reserved for complete newbies who have this great idea for a game but they just need somebody to help them code it (i.e., do the entire thing for them).

This is similar... nothing will get started. Everybody will argue over the language, the version control system, the coding style, the architecture, completely different ideas, whether or not this argument I describe will happen, etc. After a few weeks of circular arguments, people will eventually get tired and forget about everything.

I think it would be more likely to work if it were meant to be amusing from the start. e.g., Turn it into a "Telephone" type of game. Somebody would have to write a secret framework and come up with a basic concept first. Then give all the workers nothing but a) the signature of the function to implement (each person implements a different one) and b) a hand drawing of what it's supposed to do.

Then put all the functions together and see what sort of game you've got.

Yeah that's basically the idea here. I didn't intend to launch a project that had to be designed before implementation. So, just like the aforementioned monday project this isn't one noob with a vision.

The whole point of the game is that there is no planning. Instead there is a moderator that just keeps it clean and moving forward, but has no say in where this forward is going.

So it's just like the forum game where each guy posts the next sentence in the story and it just gets crazier.

Another thing I thought of to clarify the last point of my first post. The ban on moving "sideways" does not include refactoring the code if necessary. As long as the implemented features aren't severely crippled.

Of course if anyone starts to get grand visions along the way, they're free to branch off the project and go where ever he wants with it. But that branch will be a completely separate project. We can just hope such branchings doesn't make the game come to a halt.

But it's not. Stories are written sequentially and can easily be modified with a simple, "Then he woke up, and realized it was just a dream." So I wouldn't expect a game written in that manner to turn out anything like one of those stories.

Sound like fun, i'm in!
As for which language to use, i'd say to just allow a C\C++ mix, so each submitter can just use the dialect he prefers.

Everyone could have their own folder below src/ - would solve the issue of coding style. So when Trezker passes the repository to Matthew there would be for example a src/gui/ folder with some skeleton files inside (maybe either .c or .cpp depending on the participant's preference) and they have to be implemented.

The guy who starts the project kind of sets the stage. If he begins by coding C++, others are of course most encouraged to continue in the same style. Though perhaps people could be allowed to code C style, if the result doesn't get too messy.

Anyone may of course add scripting support at any turn, at that point it's his own choice which scripting language the project will be using from then on.

As for the analogy with the writing game trick of waking from a dream. Anyone could make completely different graphics and add a level that goes off on a rather different path. I don't know what level of moderation would be best in these issues, I guess that's up to the guy handling the main repo.

Another rule I just thought of, mostly relevant to graphics, but might be good for some code issues too.

Placeholder: If you put in some crappy graphics or ugly code needed to make your feature do anything useful. You can mark it as being just a placeholder. Then the rule about replacing implemented features is ignored for that piece.

I would be happy to maintain the repository.^[1] I don't foresee myself being able to contribute features necessarily, but that might change after the basic groundwork is complete.

From a spectator's point of view, it'd be more hilarious if this were not followed.

bambam raises a possible issue. How do you think the participants might feel if the game maintainer also participates, perhaps a lot, in the development?
There is a risk he might bend his own rules a bit too far and ruin the fun of the game.

The maintainer is the boss though, and you can't really prevent him from doing what he wants. I think the maintainers rights and responsibilities should be specified in the rules of the game though. If you want to be really thorough, the project should have a license including the rules of developing the project, this license should probably not require derivative projects to have the same license.

In any case I think a license needs to be used to declare all contributions to the project free. Which license should be used?

On the maintainer\moderator\boss thinghy: I think the most reasonable thing is to do it the most anti-democratic possible way.

I mean, this is your idea, you get the burden and the staff of power, if things go well you get the credit, if they don't you'll simply get the blame

If you put such delicate questions up to vote and sindacation there will never be any progress.

As for license, my first choice would be >=GPL2. My second choice would be MIT.

No more bikesheding, just get with it

Agreed, even though I don't know what bikesheding is.

http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality
http://en.wiktionary.org/wiki/bikeshedding

Basically a bunch of people getting together to make a bike-shed haven't spent a moment on the bike-shed itself, and instead argue over the color to paint it.

Ah, I get it ...

"And the wheel," said the Captain, "what about this wheel thingy? It sounds a terribly interesting project."
"Ah," said the marketing girl, "well, we're having a little difficulty there."
"Difficulty?" exclaimed Ford. "Difficulty? What do you mean, difficulty? It's the single simplest machine in the entire Universe!"
The marketing girl soured him with a look. "All right Mr. Wiseguy," she said, "you're so clever, you tell us what color it should be."

Attached is the initial source code and a simple MSVS2008 solution file.

I thought by thinking of it you lose it

I can't wait to add a physics engine and free world exploration to this sucker!

I added a few harmless comments.

Well I think the bikeshedding is done and a game has started. Though at a lower level and without the maintainer bit.

For clarity, perhaps you should move this game to a new thread if it continues much further.

I do hope someone will get off the ass and pull together a clear simple rules document, license and proper repository for a project as I envisioned it in the near future.

By someone I mean myself of course, it would only be proper for the guy who brought it all up to also get it done. But if some ambitious soul thinks I'm dragging my ass too slow I don't mind if you beat me to it.

Is the repository going to branch off for people whom wish to go a different direction?

i.e. The framework may begin and someone turns it into a platformer, then someone else disagrees and branches off that code to turn it into a space shooter. Other developers may choose to assist with one or more branches, or branch off themselves. The branches that become inactive could become disabled and deleted.

That is a possibility and I would not discourage people from doing so. I don't think it would be possible to stop it anyway, and it may not be healthy for your popularity rating to try.

One could of course use a non open source license if you really don't want branches. But that'd really put a dent in your popularity, and I'm not even sure github would like to host the project.

The branching idea sounds really great! Evolution! Think of it! On February 12th (guess whose birthday!) we could release a bunch of games, say 5 or 6 . They would look very different. After the games had gain popularity all over the world , we would reveal their true origin. All evolved from one single piece of code, that did nothing more than maybe opened a window. People would say "No, that's impossible! Someone must have created each game separately."

= optimist smiley.

There is one issue I still fear may be a bit of a bikeshed.
What to name the game, repository, project...?

My best idea so far, according to myself, is Cumulate.

Lamarck!

Nice suggestion. But I'll go with Cumulate for now.

I have created a repository now.
http://github.com/trezker/Cumulate

I've just put in the minimum code to create a window and close down on the display close event.

So, if you're interested in adding your own feature.

• Fork the repository and make sure you can build and run it.

• Send me a message. (github inbox preferably)

• Wait for me to tell you it's your turn.

Any feedback on how I have organised this thing is welcome.

I think that's generally called a fork. GitHub allows you to do that right from the site and instead of actually copying the data just references it somehow. It's therefore extremely efficient.

Forks are completely separate repositories that can just be deleted without having any effect on the original(s).

GitHub is happy to host proprietary repositories for a price. The free service requires that your code be open source.

The repository has been up for almost a day now, no one has reported their interest in taking a turn yet. I'm feeling antsy.

I've thought about starting a new thread for discussing the project itself rather than its format. But there's not much to discuss before it has at least one feature in place.

So step up and make the first feature! You have the chance to make a big impact on what direction this project will go.

Just send me a message saying you'd like to add something to the Cumulate project.

I would not worry about it. It's the middle of the week and everyone is busy doing their dayjobs.

I don't have time but here's a feature request/suggestion:
The game should have a titlescreen (placeholder) with a main menu and it should initially have three entries "Start Game" / "Options" / "Exit".

Start game should just display a message "not implemented yet". Options should have an option to "reverse stereo channels" and exit should just terminate the programme displaying "Good bye." before closing the window automatically.

Ouch! Haven't touched A5 yet. Anyway, would be fun to join, but at the moment I have absolutely no time.

Wasn't there this "project Monday" a few year back?
Dare I ask what happened to that in the end?

It died, and the SVN repo is used for the A5 version of MaSKING.

I'm still interested, not much time 'till saturday.
The point is i have no idea what type of feature should be implemented, with no idea on where the game will go, i'm a bit at a loss.

Good practice for your imagination then.

But it is true that given complete freedom and being asked to choose just one feature to implement is too open.

I think you should just imagine a full game you'd like to make, then pick the first feature that should be implemented for that game. The game you imagine probably wont be the end result of the project, it's just a helper to get it started.

Roll some Speedhack rules if your brain fails.

I am interested in joining up, I don't have allegro 5, (haven't even touched it before,) and I am yet to use git. But I have been lurking this thread and you have at least inspired me to try my hand.

I am going out drinking tonight, and tomorrow is work, but I am going to get all setup to have a look on the weekend. I have been involved in quite a few group things, through uni and j0rb. All it takes is strong leadership and good documentation to make something work, I am more of a sheep than a shepherd, but if I can help keep it documented to make it simpler for people to pick up when they feel like it, it has a better chance of making something crappy and lame, than not even getting started.

Would it be against the forum rules to have that here? Most of the people here are quite eloquent and intelligent(for internet standards ). It would be an awesome story with romance, action, orcs, Dr.Who, Linus Torvald, captain Piccard, time-travel... NVM
I think the 'finish-the-game-together' game would work best if there was a grid set-up beforehand f.i.

Assignment     | Assigned to
Splash screen    n/a
Level structure  n/a
* level 1        n/a
* level 2        n/a
World structure  n/a
Extra feature 1  n/a
etc.

This is mainly because IMHO a bunch of text written is always a readable story, but a game needs a lot of writing before it is playable... Just a suggestion though. But pinning down the complete game beforehand is just no fun at all IMHO.

Some of us work nights^[1].

Well... oh well.:)

All I can think of doing is fixing the code formatting. I've also added some C-style error handling, but since it's technically C++ that really isn't the best way to do it.

So, I have Code::Blocks installed, I have installed the correct a5 binary (4.9.21), installed git and premake4. I have retrieved the repository, created my cb project files. When I go to compile it, it attempts to link to -lalleg, which isn't quite right, but nothing to worry about.

Is there anything else I need to know/setup before I get started? or am I good to just wait for my turn?

(I will worry about learning to commit when I come to that.)

That's strange, it should link -lallegro. How can it lose the "ro"?
I guess you're ready to start developing. Send me a message on github.

I see you haven't forked the repository. Not technically a requirement to get coding, but you should push to your own fork on github and make a pull request when your feature is done.

I thought of finally take a look at A5. I guess A4 won't interfere, if I only keep them separated. But I don't really know what I should install. Any external libs I should install before even trying out anything, in general and for this Cumulate project in particular? Yeah yeah, just friendly google it! But the first I run into is this:

Well, I'm not planning on helping with development of A5. Simply because I lack skills and knowledge.

I have Dev-Cpp on my machine and it works very well. I dont use it on a level, where its crappiness would disturb me.

A5 is far enough developed that it wont change anymore, I think.
At least nothing troublesome should change anymore.

Doesn't seem like premake4 generates Dev-Cpp project files. So Code::Blocks is preferable for that reason too. But that's up to you.

So far the project doesn't use any A5 addons so minimal extra libraries are needed. But that'll probably change when people start putting features in.

They're listed in the documentation.

It's fine. That's an old statement, I think.

Yes.

To make your build system robust and portable, you should always link to allegro-main. Won't do anything on Windows or Linux, but it's needed on OS X and iPhone.

Weekends over and my inbox is still empty. Are you not ready yet or is githubs messaging system broken?

Yeah, I think the people here are broken

Fixed.

I've been thinking about putting in the first feature myself. I wanted to give others a chance to do it since I already took the liberty of deciding to go with A5 and which build system to use. Not to mention the game rules and version control system.

But now that it's taking so long for anyone to volunteer, I'm more likely to go ahead and implement a feature myself.

Some people have expressed that they would like a starting point with more substance, something to build onto rather than conjure something from the void.

Well I was kind of just waiting to be told it was my turn, as I was under the impression it was someone else's go at the moment. I really was going to add an object collection, and a base object that can go into the collection, put some lame something that uses it, either move whatever was being currently worked on over to my system, or implement space invaders, if there was no game ideas started, and just pass it on. But stuff for job ate my Sunday completely, so I just let it lay.

As I've said, if you're interested. You send a message on githubs messaging system. Otherwise I wont know if you're really in the game.

As for your thoughts about what to do. I want people to implement something that the end user will think of as a feature. The player wont know how objects are handled in the background, so an object collection means nothing to him.

Implement Space invaders? That's more than one feature. You should just implement one feature of space invaders in that case.

A minimal space invaders game would need at least four features.
1) Player "ship"
2) Enemies that move in a pattern
3) Shooting
4) Death / Win

You might implement the first feature, but then the next guys could implement a tilemap and then collision so suddenly it's a scrolling shooter instead of space invaders.

The feature to the code base was going to be a collection to manage game objects, it was not about how they interact. Evidently I didn't have the same understanding of what a feature was as you. But I will create a GitHub account and email you when I am ready to go, probably Friday when I get home from work.

Edit: With my feature likely to be random objects moving on the screen.

You guys are arguing endlessly without anything getting done. This is the perfect Monday thread!

It has now been almost a week since the last post in this thread.
And I have still not received any messages.

So I decided to push my own choice of first feature. Perhaps that could make people more eager to participate.

The feature I implemented was player movement. There is now a static image representing the player (placeholder). You can go left, right and jump using the arrow keys.

http://github.com/trezker/Cumulate

Nicely done, Trezker. That certainly looks like something more substantial to build onto.

I noticed a bug. You didn't set a default variable to jump.

Ah, the first bug, our little game is growing up so fast!

I'm too busy right now. I'd have loved to take this opportunity to finally start with A5.

I'm trying to memorize 15 songs for our choir. I'm trying to get print work ready for our concert. I'm trying to get some big band arrangements ready, as well as some compositions and arrangements for our wind orchestra. And there's a week time to compose the opening scene of "Opera by You", an open source opera project I've mentioned earlier. This is all the interesting stuff. Then I have lots of dull stuff I should get done as well.

I just got an internet connection at the new place (I moved recently), so I might contribute something at some point.

Things started happening. A pull request for the bug came from MiquelFire, it's been handled. So now I know how pull requests work.

And bamccaig sent his idea and request to be queued, so now it's his turn.